From: Tom Zander <tomz@freedommail•ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
Date: Mon, 17 Oct 2016 13:17:39 +0200 [thread overview]
Message-ID: <2381760.VTJ5BOIlGi@strawberry> (raw)
In-Reply-To: <22046ac7-df36-2e2a-759e-b3dd01601c59@gmail.com>
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.
> You said something about rolling back the changes. There is no
> mechanism for roll backs, and the whole point of the soft fork
> signalling is such that there is no need to roll back anything because
> miners have signaled that they are supporting the fork.
There are a bunch of really large assumptions in there that I disagree with.
First of all, miners running the latest software doesn't mean the software
is free from flaws. Everyone makes mistakes. People that see a way to abuse
the system may have found things and are not reporting it because they want
to abuse the flaw for their own gains. Which is exactly what happened with
Etherium.
The amount of code and the amount of changes in SegWit makes this a very
dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin
being changed with it. We don't yet know how they will interact. We can’t.
You are asking people to create everyone-can-spend transactions that would
mean a loss of funds to everyone that used it if we do find a major flaw and
need to rollback.
The gamble is rather uncomforable to many...
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
next prev parent reply other threads:[~2016-10-17 11:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-16 14:31 Pieter Wuille
2016-10-16 14:58 ` Tom Zander
2016-10-16 16:35 ` Gavin Andresen
2016-10-16 16:42 ` Tom Zander
2016-10-16 16:57 ` Johnson Lau
2016-10-16 17:04 ` [bitcoin-dev] On the security of soft forks Matt Corallo
2016-10-16 16:42 ` [bitcoin-dev] Start time for BIP141 (segwit) Eric Voskuil
2016-10-16 16:47 ` Douglas Roark
2016-10-16 18:20 ` Tom Zander
2016-10-16 18:41 ` Jorge Timón
2016-10-16 18:54 ` Tom Zander
2016-10-16 19:11 ` Johnson Lau
2016-10-16 20:08 ` Tom Zander
2016-10-17 3:46 ` Johnson Lau
2016-10-16 19:35 ` [bitcoin-dev] (no subject) Matt Corallo
2016-10-16 20:45 ` Tom Zander
2016-10-17 13:13 ` Btc Drak
2016-10-16 19:49 ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark
2016-10-16 20:58 ` Tom Zander
2016-10-16 21:03 ` gb
2016-10-16 21:08 ` Marek Palatinus
2016-10-16 21:19 ` Andrew C
2016-10-17 11:17 ` Tom Zander [this message]
2016-10-17 13:09 ` Peter Todd
2016-10-17 13:19 ` Andrew C
2016-10-17 13:27 ` Btc Drak
2016-10-17 13:31 ` Jorge Timón
2016-10-16 20:14 ` Btc Drak
2016-10-16 16:08 ` Chris Belcher
2016-10-16 17:52 ` Matt Corallo
2016-10-16 21:49 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2381760.VTJ5BOIlGi@strawberry \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox