📅 Original date posted:2016-10-16
📝 Original message:I can see how it looks but actually most of the underlying libraries have
already been adapted or are almost finished being adapted for segwit. Since
segwit is not live on mainnet, most are not released (either still in PR
form or merged to a development branch). As a software developer, I think
you can appreciate that libraries cant actually release a segwit supported
versions until segwit is released as final in 0.13.1. Obviously consumers
of the libraries cant update for segwit until the libraries are released -
you get the idea. I wouldn't be too concerned about the adoption chart,
it's just very difficult to reflect the actual state of affairs. For
example Trezor is marked as wip, but they have had an updated, but
unreleased firmware version for many months[1]. We are in the process of
planning a migration guide and updating the existing development notes[2].
Additionally, many companies are already planning to update their services
for segwit.
Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and
activation. The starttime delay is simply designed to avoid miners
signalling before the soft fork has been made available for general
release; so the starttime prevents unreleased software from setting the
version bit prematurely. The whole BIP9 state machine allows predictable
activation. Non mining full nodes are under no constraints to upgrade on a
specific schedule, which is by design of soft forks. Signalling will not
begin until the first diff retarget period after the starttime of 15th Nov.
Practically it means there will be a minimum of 4-6 weeks at the very least
before activation can happen.
[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu
ecomment-217329474
[2] https://bitcoincore.org/en/segwit_wallet_dev/
On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
> > Would I want anyone to lose money due to faulty wallets? Of course not.
> > By the same token, devs have had almost a year to tinker with SegWit and
> > make sure the wallet isn't so poorly written that it'll flame out when
> > SegWit comes along. It's not like this is some untested, mostly unknown
> > feature that's being slipped out at the last minute
>
> 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.
> 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.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161016/db56653c/attachment-0001.html>;
Btc Drak [ARCHIVE] /
npub1lh…zg7ed
2023-06-07 17:54:07
in reply to nevent1q…7awd
Author Public Key
npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7edPublished at
2023-06-07 17:54:07Event JSON
{
"id": "c1d63ea853f3139b1448e5db4506d9084ffd8f43a22980fee6e7011c0f5345d7",
"pubkey": "fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83",
"created_at": 1686160447,
"kind": 1,
"tags": [
[
"e",
"013851964e0006d489daca620e14c7c6c63358b79bff34620f9703c31bcdc761",
"",
"root"
],
[
"e",
"c9cc546d4bfd4ff0874573473e1a25face7b62c0f4d7a38c9762b385b467adfb",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2016-10-16\n📝 Original message:I can see how it looks but actually most of the underlying libraries have\nalready been adapted or are almost finished being adapted for segwit. Since\nsegwit is not live on mainnet, most are not released (either still in PR\nform or merged to a development branch). As a software developer, I think\nyou can appreciate that libraries cant actually release a segwit supported\nversions until segwit is released as final in 0.13.1. Obviously consumers\nof the libraries cant update for segwit until the libraries are released -\nyou get the idea. I wouldn't be too concerned about the adoption chart,\nit's just very difficult to reflect the actual state of affairs. For\nexample Trezor is marked as wip, but they have had an updated, but\nunreleased firmware version for many months[1]. We are in the process of\nplanning a migration guide and updating the existing development notes[2].\nAdditionally, many companies are already planning to update their services\nfor segwit.\n\nRegarding BIP9, it's purpose is to co-ordinate *miner upgrade* and\nactivation. The starttime delay is simply designed to avoid miners\nsignalling before the soft fork has been made available for general\nrelease; so the starttime prevents unreleased software from setting the\nversion bit prematurely. The whole BIP9 state machine allows predictable\nactivation. Non mining full nodes are under no constraints to upgrade on a\nspecific schedule, which is by design of soft forks. Signalling will not\nbegin until the first diff retarget period after the starttime of 15th Nov.\nPractically it means there will be a minimum of 4-6 weeks at the very least\nbefore activation can happen.\n\n[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu\necomment-217329474\n[2] https://bitcoincore.org/en/segwit_wallet_dev/\n\nOn Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Would I want anyone to lose money due to faulty wallets? Of course not.\n\u003e \u003e By the same token, devs have had almost a year to tinker with SegWit and\n\u003e \u003e make sure the wallet isn't so poorly written that it'll flame out when\n\u003e \u003e SegWit comes along. It's not like this is some untested, mostly unknown\n\u003e \u003e feature that's being slipped out at the last minute\n\u003e\n\u003e There have been objections to the way that SegWit has been implemented for\n\u003e a\n\u003e long time, some wallets are taking a \"wait and see\" approach. If you look\n\u003e at the page you linked[1], that is a very very sad state of affairs. The\n\u003e vast majority is not ready. Would be interesting to get a more up-to-date\n\u003e view.\n\u003e Wallets probably won't want to invest resources adding support for a\n\u003e feature\n\u003e that will never be activated. The fact that we have a much safer\n\u003e alternative\n\u003e in the form of Flexible Transactions may mean it will not get activated. We\n\u003e won't know until its actually locked in.\n\u003e Wallets may not act until its actually locked in either. And I think we\n\u003e should respect that.\n\u003e\n\u003e Even if all wallets support it (and thats a big if), they need to be rolled\n\u003e out and people need to actually download those updates.\n\u003e This takes time, 2 months after the lock-in of SegWit would be the minimum\n\u003e safe time for people to actually upgrade.\n\u003e\n\u003e 1) https://bitcoincore.org/en/segwit_adoption/\n\u003e --\n\u003e Tom Zander\n\u003e Blog: https://zander.github.io\n\u003e Vlog: https://vimeo.com/channels/tomscryptochannel\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161016/db56653c/attachment-0001.html\u003e",
"sig": "ca6b649f8eb787452d66363668d2746d910b08a5ec1de941f90fbf0260132cf4113b431ad319541b439b492d2f5ef404cb4a6d7ab2346ee5684555277c329ead"
}