On Mon, Oct 17, 2016 at 01:17:39PM +0200, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote: > > On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote: > > > Lets get back to the topic. Having a longer fallow period is a simple > > > way to be safe. Your comments make me even more scared that safety is > > > not taken into account the way it would. > > > > Can you please explain how having a longer grace period makes it any > > safer? Once the fork reaches the LOCKED_IN status, the fork will become > > active after the period is over. How does having a longer grace period > > make this any safer besides just adding more waiting before it goes > > active? > > As Marek wrote just minutes before your email came in; companies will not > roll out their updates until it locks in. Peter Todd says the same thing. > So your assumption that the lock-in time is the END of the upgrading is > false. Thats only the case for miners. > > The entire point here is that SegWit is much bigger than just full nodes > (including miner). > An entire ecosystem of Bitconin will have a need to upgrade. > > I understand people saying that non-miners don't *need* to upgrade in order > to avoid being kicked of the network, but truely, thats a bogus argument. > > People want to actually participate in Bitcoin and that means they need to > understand all of it. Not just see anyone-can-spend transactions. > I think its rather odd to think that developers on this list can decide > the risk profile that Bitcoin using companies or individuals should have.
Please don't misleadingly reference/quote me. I made it quite clear in my last post that because segwit is a backwards compatible soft-fork, the vast majority of code out there will not have to change; my own OpenTimestamps being a good example. All I'll have to do to prepare for segwit is upgrade the (pruned) full nodes that the OpenTimestamps servers depend on to determine what's the most-work valid chain, and in the event I was concerned about compatibility issues, I could easily run my existing nodes behind updated segwit-supporting (pruned) nodes. Like most users, my OpenTimestamps code doesn't "fully understand" transactions at all - I rely on my full node to do that for me. What it does understand about transactions and blocks remains the same in segwit. I can receive transactions from segwit users with lite-client security without any action at all, and full-node security once I upgrade my full nodes (or run them behind upgraded nodes). Your proposed alternative to segwit - flexible transactions - has none of these beneficial properties. And as Matt Corallo reported, it's no-where near ready for deployment: three buffer overflows in 80 lines of code is a serious problem. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
