[Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
Hi Gavin Sorry for slow response broken threading - mailbox filled up only saw your response on archive. I do earnestly think opt-in block-size increases are politically cleaner (gives different people different sized blocks by their own volition without forcing a compromise) and less risky

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
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

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Mike Hearn
(at reduced security if it has software that doesnt understand it) Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Tom Harding
On 6/1/2015 10:21 AM, Adam Back wrote: 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

[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

2015-05-29 Thread Adam Back
I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an