From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2853EB1D for ; Fri, 14 Jul 2017 08:52:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com [209.85.216.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2468ECD for ; Fri, 14 Jul 2017 08:52:44 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id i2so57264309qta.3 for ; Fri, 14 Jul 2017 01:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JF+ImJ3B7NLi2JFYu0pwZUxzjq5bxiu1L4nqhyDAeOk=; b=c3UloQnSmwoeBIEbybkM2Z2WrG6zx5i1fnDlNBof0uZ0qGXS7ReNHZJtpNq2mMfreu qcdIwK+7Wd//9lafS7F2ZZn53y4DeO1YoqlWzwJ9QOSaupg+31K8ZylxV19VQ+x7JGU7 aY5XAHiY4w7dL5jThIxMBVTjKtG5Wu60/swW1pn7yMC37DGdvq53CGRaBmOkehZWtJQ8 4YuDS/slOZdfoIo08ep9N1xMq36Jm6C3g23Lol8Jz7up30oE5zdUQkGEmkCVvWqYdLqr /Q1GbIFJ8XYnqv/jFssHdbBIgfsE4lUEy/Fpux0nWvjaKi+/1AW7vQA2gvY5uI8y8I8m iWiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JF+ImJ3B7NLi2JFYu0pwZUxzjq5bxiu1L4nqhyDAeOk=; b=DxR4k8kPdvPRb3YQ68rFckZ4w2ez2ZyY0KmWXDFMpIrmCf/pAuuJHUDIDCEw2qPmuA Zi1snj3dxCY7XLRrDiuIVCpUkhaptnpk3jlcqOlhAdoUpFQUAmwJhxjrqYRalElLfkDe SquhR3FnTFHy91VAEv7tAkhV6K81Do5Pl26m26wsFJdrKTXlQDBFmtCrpwImWtOICZXx a1RKiOJnMgRm9X0QiT3dDwLlrZ7mH703b2DooyhpGb1XZOO6T+9W1I8vgPHeybJXXIPH AeErooj9zDM5YS5jfSy+i4HPosNsvFSEC9Vtm2Kd6dH0NqwH/CICJecZVPGOsbqc0SXS Ivwg== X-Gm-Message-State: AIVw111esSY+Mx8hbR/rAAovUrEfidYxX+AVj6z/hK1ij9GL8LTtslRz 4errGqNu9Sy3j+nxeqwlytYBb8doedE+7nSjyg== X-Received: by 10.237.44.7 with SMTP id f7mr10829282qtd.52.1500022363279; Fri, 14 Jul 2017 01:52:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.186.175 with HTTP; Fri, 14 Jul 2017 01:52:42 -0700 (PDT) In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com> <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr> <0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr> <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr> <5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Fri, 14 Jul 2017 10:52:42 +0200 Message-ID: To: Dan Libby , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c05df901e56310554432c5b" X-Spam-Status: No, score=-2.2 required=5.0 tests=AC_DIV_BONANZA,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 14 Jul 2017 11:54:56 +0000 Subject: Re: [bitcoin-dev] how to disable segwit in my build? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 08:52:45 -0000 --94eb2c05df901e56310554432c5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=C3=B6berg 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 detail= s > > 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 > --94eb2c05df901e56310554432c5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> sou= nds 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.=C2=A0 So it seems the only possible wa= y
to be certain is to run a node that has never published an address to a
3rd party.=C2=A0 Is that accurate?

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

> Anoth= er 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.=C2=A0 I guess the benef= it
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 l= ose 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 expl= anation!

You're welcome!
I personally very much l= ike 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=C3=B6berg 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<= br> > 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) gi= ven that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time.=C2=A0 So it seems the only possible wa= y
to be certain is to run a node that has never published an address to a
3rd party.=C2=A0 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.=C2=A0 I guess the benef= it
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 understandin= g.


> See
> https://gi= thub.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
> So the witness program is encoded in a new format that old nodes do no= t
> 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/b= ips/blob/master/bip-0143.mediawiki also
> explains the new witness program more in detail (I left out some detai= ls
> 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

--94eb2c05df901e56310554432c5b--