Peter Todd [ARCHIVE] on Nostr: š Original date posted:2016-10-17 š Original message:On Mon, Oct 17, 2016 at ...
š
Original date posted:2016-10-17
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161017/1cc41f27/attachment.sig>;
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161017/1cc41f27/attachment.sig>;