Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too. Of course this is a pretty serious redesign of bitcoin, and I'm not offering a concrete proposal at this time (but have one in the works, and I'd like to see others). I call the parameters of these hacky heuristics Consensus Threatening Quantities (CTQs) because changing them induces a hard fork. Bitcoin is full of them (block time, block size, target difficulty, retarget time, etc) and bitcoin would do well to face difficult redesign questions head on, and remove them entirely. (Proposal to appear...) On June 8, 2015 5:44:43 PM EDT, Peter Todd p...@petertodd.org wrote: On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality. There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. Keep in mind, that at some point it'd be cheaper to just 51% attack the network. Based on the current block subsidy of 25BTC/MB that's at the point where transaction fees are 25mBTC/KB, which corresponds to $2/tx fees - not that cheap, but still quite affordable for a large percentage of Bitcoin's users right now. And that's the *absolute worst-case* attack possible. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- !DSPAM:55760d26244955859016385! ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development !DSPAM:55760d26244955859016385! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
That's a lot of work, a lot of extra utxo's, and a lot of blockchain spam, just so I can do a convoluted form of arithmetic on my balance. If a tx contained an explicit miner fee and a change address, but did not compute the change, letting the network compute it (and therefore merge transactions spending the same utxo), could one add some form of ring signature a la Dash to alleviate the worsened privacy implications? Jeff Garzik [jgar...@bitpay.com] wrote: This has been frequently explored on IRC. My general conclusion is dollar bills - pick highly common denominations of bitcoins. Aggregate to obtain these denominations, but do not aggregate further. This permits merge avoidance (privacy++), easy coinjoin where many hide in the noise (privacy++), wallet dust de-fragmentation, while avoiding the over-aggregation problem where you have consolidated down to one output. Thus a wallet would have several consolidation targets. Another strategy is simply doubling outputs. Say you pay 0.1 BTC to Starbucks. Add another 0.1 BTC output to yourself, and a final change output. Who can say which output goes to Starbucks? There are many iterations and trade-offs between fragmentation and privacy. -- Cheers, Bob McElrath The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
This is my biggest headache with practical bitcoin usage. I'd love to hear it if anyone has any clever solutions to the wallet/utxo locked problem. Spending unconfirmed outputs really requires a different security model on the part of the receiver than #confirmations, but isn't inherently bad if the receiver has a better security model and knows how to compute the probability that an unconfirmed-spend will get confirmed. Of course the bigger problem is wallet software that refuses to spend unconfirmed outputs. I've thought a bit about a fork/merge design: if the change were computed by the network instead of the submitter, two transactions having the same change address and a common input could be straightforwardly merged or split (in a reorg), where with bitcoin currently it would be considered a double-spend. Of course that has big privacy implications since it directly exposes the change address, and is a hard fork, but is much closer to what people expect of a debit-based account in traditional banking. The fact of the matter is that having numerous sequential debits on an account is an extremely common use case, and bitcoin is obtuse in this respect. On May 9, 2015 1:09:32 PM EDT, Jim Phillips j...@ergophobia.org wrote: Forgive me if this idea has been suggested before, but I made this suggestion on reddit and I got some feedback recommending I also bring it to this list -- so here goes. I wonder if there isn't perhaps a simpler way of dealing with UTXO growth. What if, rather than deal with the issue at the protocol level, we deal with it at the source of the problem -- the wallets. Right now, the typical wallet selects only the minimum number of unspent outputs when building a transaction. The goal is to keep the transaction size to a minimum so that the fee stays low. Consequently, lots of unspent outputs just don't get used, and are left lying around until some point in the future. What if we started designing wallets to consolidate unspent outputs? When selecting unspent outputs for a transaction, rather than choosing just the minimum number from a particular address, why not select them ALL? Take all of the UTXOs from a particular address or wallet, send however much needs to be spent to the payee, and send the rest back to the same address or a change address as a single output? Through this method, we should wind up shrinking the UTXO database over time rather than growing it with each transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database will grow, simply because there are 7 billion people in the world, and eventually a good percentage of them will have one or more wallets with spendable bitcoin. But this idea could limit the growth at least. The vast majority of users are running one of a handful of different wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle; Blockchain.info; and maybe a few others. The developers of all these wallets have a vested interest in the continued usefulness of Bitcoin, and so should not be opposed to changing their UTXO selection algorithms to one that reduces the UTXO database instead of growing it. From the miners perspective, even though these types of transactions would be larger, the fee could stay low. Miners actually benefit from them in that it reduces the amount of storage they need to dedicate to holding the UTXO. So miners are incentivized to mine these types of transactions with a higher priority despite a low fee. Relays could also get in on the action and enforce this type of behavior by refusing to relay or deprioritizing the relay of transactions that don't use all of the available UTXOs from the addresses used as inputs. Relays are not only the ones who benefit the most from a reduction of the UTXO database, they're also in the best position to promote good behavior. -- *James G. Phillips IV* https://plus.google.com/u/0/113107039501292625391/posts *Don't bunt. Aim out of the ball park. Aim for the company of immortals. -- David Ogilvy* *This message was created with 100% recycled electrons. Please think twice before printing.* !DSPAM:554e4e5450787476022393! -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y !DSPAM:554e4e5450787476022393! ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development !DSPAM:554e4e5450787476022393! -- Sent from my Android
Re: [Bitcoin-development] Synchronization: 19.5 % orphaned blocks at height 197'324
I had the same problem (repeatedly) which came down a hardware problem. Bitcoin more than other applications is very sensitive to single bit flips in memory or during computation. (In the end I under-clocked my CPU and RAM to fix the problem) Attached is a small python script which will run sha256 on random data repeatedly and will print a message if a mismatch is found. For me it took many hours of running before a sha256 mismatch, but one is enough to fork the blockchain. m...@bitwatch.co [m...@bitwatch.co] wrote: Hello all, I'm currently synchronizing a new node and right now, at a progress of a height of 197'324 blocks, I count in my debug.log an aweful amount of 38'447 orphaned blocks which is about 19.5 %. It has been I while since I watched the synchronization process closely, but this number seems pretty high to me. I'm wondering about the following: would it be possible for a malicious party to generate chains of blocks with low difficulity which are not part of the main chain to slow down the sync process? Build and version information: https://github.com/jmcorgan/bitcoin/tree/026686c7de76dfde6fcacfc3d667fb3418a946a7 (sipa/jmcorgan address index) Rebased with: https://github.com/bitcoin/bitcoin/tree/94e1b9e05b96e4fe639e5b07b7a53ea216170962 (almost up-to-date mainline) Compressed debug.log attached: https://www.dropbox.com/s/uvtd91xiwmdmun7/debug.7z?m= (filesize: 7.67 MB, uncompressed: 41.3 MB) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Cheers, Bob McElrath The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche #!/usr/bin/python # Repeatedly run a sha256 on random data. Keeps a rolling buffer of the last # buflen hashes and re-checks them. Prints an error ONLY if a mismatch is # found. If a mismatch is found, you have a hardware problem. from hashlib import sha256 from collections import deque import random buflen = 10 hashbuf = deque(maxlen=buflen) for i in range(buflen): hashbuf.append([str(i), sha256(str(i)).hexdigest()]) while True: k, khash = hashbuf.popleft() pophash = sha256(k).hexdigest() if pophash != khash: print ERROR: sha256(%s) = %s does not match:%(k, khash) printsha256(%s) = %s%(k, pophash) k = str(random.getrandbits(1000)) khash = sha256(k).hexdigest() hashbuf.append([k, khash]) signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
