Mike wrote: >> Businesses who are keen to >> have more transactions, would make it their problem to implement in >> their wallet, or ask the wallet vendor/maintainer they're working with >> to do it. Nothing breaks if they dont use it. > > > I don't see how this is the case. If an exchange supports extension blocks > and I withdraw from that to a wallet that doesn't, the money will never > arrive from my perspective. Yet the exchange will claim they sent it and > they will wash their hands of the matter. Disaster.
To be clear in case you are missing part of the mechanism.: it is forward and backwards compatible meaning a 1MB address can receive payments from an 8MB address (at reduced security if it has software that doesnt understand it) and a 1MB address can pay an 8MB address by paying to an OP_TRUE that has meaning to the extension block nodes. A 1MB client wont even understand the difference between a 1MB and 8MB out payment. An 8MB client will understand and pay 1MB addresses in a different way (moving the coin back to the 1MB chain). So its opt-in and incrementally deployable. Exchanges could encourage their users to use wallets that support 8MB blocks, eg by charging a fee for 1MB transactions. If 1MB blocks experience significant fee pressure, this will be persuasive. Or they could chose not to and eat the cost. This is all normal market adoption of a new cheaper technical option (in this case with a tradeoff of reduced security/more centralisation for those opting in to it). >> Because the more complex one is safer, more flexible, more future >> proof and better for decentralisation > > I disagree with all of those points. I find Lightning/Stroem etc to be more > dangerous, less flexible, and worse for decentralisation. I explain why > here: Extension blocks & lightning are unrelated things. While I understand the need for being practical, there is IMO, amongst engineering maxims something as far as being too pragmatic, dangerously pragmatic even. We cant do stuff in bitcoin that has bad carry costs, nor throw out the baby with the bathwater. The situation is just that we are facing a security vs volume tradeoff and different people will have different requirements and comfort zones. If I am not misremembering, I think you've sided typically with the huge block, big data center only end of the spectrum. What I am proposing empowers you to do experiments in that direction without getting into a requirements conflict with people who value more strongly the bitcoin properties arising from it being robustly decentralised. I am not sure personally where the blocksize discussion comes out - if it stays as is for a year, in a wait and see, reduce spam, see fee-pressure take effect as it has before, work on improving improve decentralisation metrics, relay latency, and do a blocksize increment to kick the can if-and-when it becomes necessary and in the mean-time try to do something more long-term ambitious about scale rather than volume. Bitcoin without scale improvements probably wont get the volume people would like. So scale is more important than volume; and security (decentralisation) is important too. To the extreme analogy we could fix scale tomorrow by throwing up a single high perf database, but then we'd break the security properties arising from decentralisation. We should improve both within an approximately safe envelope IMO. Adam ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
