public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew C <achow101@gmail•com>
To: Tom Zander <tomz@freedommail•ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
Date: Mon, 17 Oct 2016 09:19:29 -0400	[thread overview]
Message-ID: <ee5e672d-9bbb-d7f3-2360-64871fc1b6a5@gmail.com> (raw)
In-Reply-To: <2381760.VTJ5BOIlGi@strawberry>



On 10/17/2016 7:17 AM, Tom Zander via bitcoin-dev wrote:
> 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.
But again, how does having a longer fallow period make this any safer?
As was mentioned before, a lot of the wallets listed as WIP have code
ready and tested, just not officially released, so not listed as ready.
It doesn't take 2 months to roll out a software update that is already
prepared beforehand.
> 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.
I think it's rather odd that no major Bitcoin companies have raised any
such issues with Segwit and in fact many already have the upgrade in the
works. I think it's rather odd that individuals who are not opposed to
segwit would choose to not upgrade even though it has been actively
discussed for the past year.
> 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.
While flaws can still be found, unlike the DAO, Segwit has been tested
extensively for a much longer period of time. Waiting any longer isn't
likely to help given that so much testing and review has already been
done. Even so, that is a pointless argument as it is impossible to know
whether waiting a little longer would reveal an issue.
>
> 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.
Really? How so? It's been active on 4 different segwit specific testnets
and it has been active on the Testnet for the past several months.
People have been spamming segwit transactions and extensively testing
Segwit since its deployment on Testnet. I think we know how segwit
transactions and all aspects of the changes work together as it has been
tested as such for several months now.



  parent reply	other threads:[~2016-10-17 13:18 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
2016-10-17 13:09                 ` Peter Todd
2016-10-17 13:19                 ` Andrew C [this message]
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=ee5e672d-9bbb-d7f3-2360-64871fc1b6a5@gmail.com \
    --to=achow101@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tomz@freedommail$(echo .)ch \
    /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