public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Douglas Roark <joroark@vt.edu>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Start time for BIP141 (segwit)
Date: Sun, 16 Oct 2016 12:49:47 -0700	[thread overview]
Message-ID: <03831fcd-1fd5-b769-0b3b-41e996894e1f@vt.edu> (raw)
In-Reply-To: <2034434.4WpKWoeOrB@strawberry>


[-- Attachment #1.1: Type: text/plain, Size: 3135 bytes --]

Before getting to my reply to Tom's message, I forgot to give my
thoughts on the Nov. 15 date. I think it's a reasonable date. With
various holidays coming up in the West, it's probably best to get the
word out now so that work can progress before some people get sucked
into family obligations and such. A month gives a bit of time without
dragging out the waiting game, IMO.

Now then....

On 2016/10/16 11:20, Tom Zander via bitcoin-dev wrote:
> There have been objections to the way that SegWit has been implemented for a 
> long time, some wallets are taking a "wait and see" approach.  If you look 
> at the page you linked[1], that is a very very sad state of affairs. The 
> vast majority is not ready.  Would be interesting to get a more up-to-date 
> view.

It's not the website's fault if wallet devs aren't updating their
statuses. Besides, "WIP" can mean an awful lot of things. For example, I
know Armory made significant progress with SegWit support as part of
their upcoming 0.95 release. I have full confidence they'll be ready
relatively soon. Other wallets may be ready. Other wallets may be stuck
where they were in the spring. In any event, it's a free country. Unlike
consensus rules and such, it's trivial to move one's funds to a wallet
that fully supports SegWit if that's what one desires.

In addition, I was at the wallet workshop at Scaling Bitcoin last week.
An awful lot of things were on the board as potential discussion points.
I think SegWit was mentioned but wasn't really discussed. I don't think
FlexTrans was even mentioned (and it's off-topic anyway). Wallet devs
are far more concerned about things like UI and standards for HW wallets
than they are about their ability to support SegWit. I think wallet devs
are quite capable of making noise if they felt that SegWit was a bad
feature, or a difficult-to-support feature.

> Wallets probably won't want to invest resources adding support for a feature 
> that will never be activated. The fact that we have a much safer alternative 
> in the form of Flexible Transactions may mean it will not get activated. We 
> won't know until its actually locked in.

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
data in Core's blockchain files. That problem was fixed, and it was
probably a rarity since very few wallets rely directly on Core.) As long
as devs use testnet or regtest to iron out their kinks before hitting
mainnet, I can't think of a single good reason to hold back SegWit
solely due to wallet support.

Also, once again, FlexTrans is off-topic. As others have said, you're
basically being stubborn at this point. If you insist on discussing
FlexTrans, start another thread. It sounds like quite a few devs would
be more than happy to say a word or two about your proposal.

-- 
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark@vt.edu
PGP key ID: 26623924


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  parent reply	other threads:[~2016-10-16 19:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) 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         ` Douglas Roark [this message]
2016-10-16 20:58           ` [bitcoin-dev] Start time for BIP141 (segwit) 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
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=03831fcd-1fd5-b769-0b3b-41e996894e1f@vt.edu \
    --to=joroark@vt.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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