From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] how to disable segwit in my build?
Date: Fri, 14 Jul 2017 10:03:58 +0100 [thread overview]
Message-ID: <CAE-z3OUdfgpfe30gTp8ptqxgpyLYys+feGA3Cx98d3z9gFtQdw@mail.gmail.com> (raw)
In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]
On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time. So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party. Is that accurate?
>
You would also have to ensure that everyone you give your addresses to
follows the same rule. As time passes, there would be fewer and fewer
people who have "clean" outputs.
From the perspective of old nodes, segwit looks like lots of people are
transferring money to "anyone-can-spend" outputs. This outputs are
completely unprotected. Literally, anyone can spend them. (In practice,
miners would spend them, since why would they include a transaction that
sends "free money" to someone else).
If you run an old node, then someone could send you a transaction that only
spends segwit outputs and you would think it is a valid payment.
Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the
Bitcoins).
UTXO-1: Requires signature by Alice (legacy output)
UTXO-2: Anyone can pay (but is actually a segwit output that needs to be
signed by Bob)
UTXO-3: Anyone can pay (but is actually a segwit output that needs to be
signed by Carl)
Only Bob can spend UTXO-2, since it needs his signature.
Anyone could create a transaction that spends UTXO-2 and it would look good
to all legacy nodes. It is an "anyone can spend" output after all.
However, if they submit the transaction to the miners, then it will be
rejected, because according to the new rules, it is invalid (it needs to be
signed by Bob).
Once a soft fork goes through, then all miners will enforce the new rules.
A miner who added the transaction to one of his blocks (since it is valid
under the old rules) would find that no other miners would accept his block
and he would get no fees for that block. This means that all miners have
an incentive to upgrade once a soft fork activates.
His block would be accepted by legacy nodes, for a short while. However,
since 95% of the miners are on the main chain, their chain (which rejects
his block) would end up the longest.
If you are running a legacy client when a soft fork comes in, then you can
be tricked with "zero confirm" transactions. The transaction will look
good to you, but will be invalid under the new rules. This makes your
client think you have received (a lot of) money, but in practice, the
transaction will not be accepted by the miners.
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx. I guess the benefit
> is that I could be certain of the remaining funds I have.
>
If you wanted, you could mark any transaction that has a segwit looking
output as "dirty" and then all of its descendants as dirty.
However, pretty quickly, only a tiny fraction of all bitcoins would be
clean.
I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
Right.
I think a reasonably compromise would be to assume that all transactions
buried more than a few hundred blocks deep are probably ok. Only segwit
looking outputs would be marked as "uncertain".
[-- Attachment #2: Type: text/html, Size: 4837 bytes --]
next prev parent reply other threads:[~2017-07-14 9:04 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 16:50 [bitcoin-dev] Updating the Scaling Roadmap Paul Sztorc
2017-07-11 16:03 ` Chris Stewart
2017-07-11 16:49 ` Adam Back
2017-07-11 20:01 ` Pieter Wuille
2017-07-11 20:36 ` Paul Sztorc
2017-07-11 21:40 ` Pieter Wuille
2017-07-11 22:49 ` Paul Sztorc
2017-07-11 21:16 ` CryptAxe
2017-07-11 20:18 ` Paul Sztorc
2017-07-11 21:31 ` Gregory Maxwell
2017-07-11 22:27 ` Paul Sztorc
2017-07-11 21:11 ` Gregory Maxwell
2017-07-11 21:40 ` Gregory Maxwell
2017-07-11 22:17 ` Paul Sztorc
2017-07-11 22:41 ` Tao Effect
2017-07-11 22:57 ` Paul Sztorc
2017-07-11 23:12 ` Tao Effect
2017-07-12 0:21 ` Paul Sztorc
2017-07-12 7:27 ` Jacob Eliosoff
2017-07-12 19:19 ` Chris Stewart
2017-07-12 19:24 ` Tao Effect
2017-07-12 19:34 ` Chris Stewart
2017-07-12 19:42 ` Tao Effect
2017-07-12 19:54 ` CryptAxe
2017-07-12 21:55 ` Tao Effect
2017-07-12 22:07 ` CryptAxe
2017-07-11 23:36 ` Bryan Bishop
2017-07-12 0:07 ` Gregory Maxwell
2017-07-12 1:40 ` Paul Sztorc
2017-07-12 2:48 ` Bryan Bishop
2017-07-12 3:33 ` Gregory Maxwell
2017-07-12 6:17 ` [bitcoin-dev] how to disable segwit in my build? Dan Libby
2017-07-13 1:04 ` Gregory Maxwell
2017-07-13 13:11 ` Federico Tenga
2017-07-13 13:39 ` Hampus Sjöberg
2017-07-13 16:19 ` Dan Libby
2017-07-13 16:35 ` Jameson Lopp
2017-07-13 21:58 ` Dan Libby
2017-07-13 22:50 ` Hampus Sjöberg
2017-07-13 23:20 ` Dan Libby
2017-07-14 8:52 ` Hampus Sjöberg
2017-07-14 9:03 ` Tier Nolan [this message]
2017-07-13 23:19 ` Lucas Clemente Vella
2017-07-13 16:05 ` Dan Libby
2017-07-14 21:11 ` Troy Benjegerdes
2017-07-13 1:48 ` Anthony Towns
2017-07-13 16:13 ` Dan Libby
2017-07-12 1:22 ` [bitcoin-dev] Updating the Scaling Roadmap Karl Johan Alm
2017-07-12 9:37 ` Tom Zander
2017-07-12 9:02 ` Tom Zander
2017-07-11 23:28 ` Anthony Towns
2017-07-17 17:13 ` [bitcoin-dev] Updating the Scaling Roadmap [Update] Paul Sztorc
2017-07-17 18:49 ` Alex Morcos
2017-07-17 20:13 ` Paul Sztorc
2017-07-17 21:50 ` Peter Todd
[not found] ` <20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
2017-07-17 22:04 ` Paul Sztorc
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=CAE-z3OUdfgpfe30gTp8ptqxgpyLYys+feGA3Cx98d3z9gFtQdw@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--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