From: gb <kiwigb@yahoo•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 10:03:52 +1300 [thread overview]
Message-ID: <1476651832.2406.2.camel@yahoo.com> (raw)
In-Reply-To: <7939356.11nSWPlGYM@strawberry>
It's controversial not contriversial.
And it isn't controversial except among a small clique, which you seem
to be the sole representative of here. It might be time to consider
unsubscribing (again) if you don't seem to know when to shut up and the
moderators are letting you go on an inappropriate crusade here.
On Sun, 2016-10-16 at 22:58 +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
> wrote:
> > It's not the website's fault if wallet devs aren't updating their
> > statuses. Besides, "WIP" can mean an awful lot of things.
>
> As I said, it would be nice to get an updated version so we can see more
> than 20% readyness of wallets.
> The wallet devs not caring enough to update the status should be a worrying
> sign, though.
>
> > A lot of devs have already worked on SegWit support. This has been
> > covered. Even if they don't support SegWit, the wallets will probably
> > work just fine. (For awhile, Armory did crash when trying to read SegWit
>
> SegWit is probably the most disruptive and most invasive change ever made to
> Bitcoin. We have miners actively saying they don't like it and this makes it
> a contriversial upgrade which means the network may split and other issues.
>
> Your "wallets will probably work just fine" comment is honestly not the
> answer to make people put faith in the way that this is being vetted and
> checked...
>
> > Also, once again, FlexTrans is off-topic.
>
> Its an alternative and brought up in that vain. Nothing more. Feel free to
> respond to the BIP discussion (134) right on this list if you have any
> opinions on it. They will be on-topic there. No problems have been found so
> far.
>
> 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.
>
> People are not even acknowledging the damage a contriversial soft fork of
> the scope and magnitude of SegWit can have, and a simple request to extend
> the fallow time for safety is really not a big deal.
> SegWit has been in development for 18 months or so, what is a couple of
> extra week??
>
> I would just like to ask people to take the safety of Bitcoin serious. This
> discussion and refusal to extend the safety period is not a good sign.
next prev parent reply other threads:[~2016-10-16 21:03 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 [this message]
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
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=1476651832.2406.2.camel@yahoo.com \
--to=kiwigb@yahoo$(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