public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>
To: Dan Libby <dan@osc.co.cr>,
	 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:52:42 +0200	[thread overview]
Message-ID: <CAFMkqK_epizUDe4+7v2AqoWnC4L1-OALETVG-PtD9CrWrfKf4g@mail.gmail.com> (raw)
In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

> 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?

Yes, as soon as you receive new Bitcoins, there's a chance that they have
been in a SegWit transaction at some point.
I'm not sure if you can see the chain of transactions for an address in
bitcoin-cli, but if that is possible, you should be able to double check
the transaction types.

> 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.

Hmm yes, if you reject a such transaction, you'll hardfork the network.
If you ignore it in your wallet, you'll be safe, but you'll lose those
bitcoins ofc.
It's a difficult situation.

> I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

Should be possible.

> Hampus, thanks for the explanation!

You're welcome!
I personally very much like and want SegWit, but I respect people that
wants to maintain the status quo, it's what will make Bitcoin strong in the
long run.

Cheers
Hampus

2017-07-14 1:20 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Hampus, thanks for the explanation!
>
> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
>
> > Yes.
> > So you have two choices to be fully secure:
> > 1. Validate using the new rules of the network (in other words, run a
> > SegWit node)
> > 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?
>
> 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.
>
> I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
> I don't intend to do such modifications! just grasping for understanding.
>
>
> > See
> > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_
> compatibility
> > So the witness program is encoded in a new format that old nodes do not
> > understand.
> > This means that for old nodes, a number >0 will be put on the stack.
> > When the script is done, it will be evaluated to true (because of >0)
> > and be counted as a valid spend.
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> > explains the new witness program more in detail (I left out some details
> > in my explanation).
>
> I read the relevant parts, thanks!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4977 bytes --]

  reply	other threads:[~2017-07-14  8:52 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 [this message]
2017-07-14  9:03                             ` Tier Nolan
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=CAFMkqK_epizUDe4+7v2AqoWnC4L1-OALETVG-PtD9CrWrfKf4g@mail.gmail.com \
    --to=hampus.sjoberg@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dan@osc.co.cr \
    /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