I had to hit the sack last night as it was 2am CET, but I'd like to sum up the discussion we had on IRC about scalability and SatoshiDice in particular.
I think we all agreed on the following: - Having senders/buyers pay no fees is psychologically desirable even though we all understand that eventually, somebody, somewhere will be paying fees to use Bitcoin - In the ideal world Bitcoin would scale perfectly and there would be no need for there to be some "winners" and some "losers" when it comes to confirmation time. There was discussion of some one-off changes to address the current situation, namely de-ranking transactions that re-use addresses. Gavin and myself were not keen on this idea, primarily because it just avoids the real problem and Bitcoin already has a good way to prioritize transactions via the fees mechanism itself. The real issue is that SatoshiDice does indeed pay fees and generates a lot of transactions, pushing more traditional traffic out due to artificial throttles. The following set of proposals were discussed: (1) Change the mining code to group transactions together with their mempool dependencies and then calculate all fees as a group. A tx with a fee of 1 BTC that depends on 5 txns with zero fees would result in all 6 transactions being considered to have a fee of 1BTC and therefore become prioritized for inclusion. This allows a transition to "receiver pays" model for fees. There are many advantages. One is that it actually makes sense ... it's always the receiver who wants confirmations because it's the receiver that fears double spends. Senders never do. What's more, whilst Bitcoin is designed to operate on a zero-trust model in the real world trust often exists and it can be used to optimize by passing groups of transactions around with their dependencies, until that group passes a trust boundary and gets broadcast with a send-to-self tx to add fees. Another advantage is it simplifies usage for end users who primarily buy rather than sell, because it avoids the need to guess at fees, one of the most problematic parts of Bitcoins design now. The disadvantages are that it can result in extra transactions that exist only for adding fees, and it requires a more modern payment protocol than the direct-IP protocol Satoshi designed. It would help address the current situation by avoiding angry users who want to buy things, but don't know what fee to set and so their transactions get stuck. (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to avoid paying excessive fees and queue-jumping. Guess that's on my plate. (3) Scalability improvements seem like a no brainer to everyone, it's just a case of how complicated they are. (4) Making the block size limit float is better than picking a new arbitrary threshold. On the forums Matt stated that block chain pruning was a no-go because "it makes bitcoin more centralized". I think we've thrashed this one out sufficiently well by now that there should be a united opinion on it. There are technical ways to implement it such that there is no change of trust requirements. All the other issues (finding archival nodes, etc) can be again addressed with sufficient programming. For the case of huge blocks slowing down end user syncing and wasting their resources, SPV clients like MultiBit and Android Wallet already exist and will get better with time. If Jeff implements the bloom filtering p2p commands I'll make bitcoinj use them and that'll knock out excessive bandwidth usage and parse overheads from end users who are on these clients. At some point Bitcoin-Qt can have a dual mode, but who knows when that'll get implemented. Does that all sound reasonable? ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
