📅 Original date posted:2017-07-13
📝 Original message:> I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes? So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.
Yes, this applies to all non-SegWit nodes.
> If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.
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
> I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.
So how softforks often work is that you make the transaction appear to be
always spendable for old nodes, regardless if it really was spendable or
not. This will make sure it is a softfork, the update is backwards
compatible.
If it would be the other way around, if new rules that the node doesn't
understand would always be invalid, it would be hardfork, which is what
we're trying to avoid in the first place.
> so if
someone can point me towards a document that explains it I'd be happy to
read that.
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).
Cheers
Hampus
2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> > >> I believe that a good reason not to wish your node to be segwit
> > > compliant is to avoid having to deal with the extra bandwidth that
> > > segwit could require. Running a 0.14.2 node means being ok with
> >1MB
> > > blocks, in case segwit is activated and widely used. Users not
> > > interested in segwit transactions may prefer to keep the cost of
> their
> > > node lower.
> > >
> > > If the majority of the network decides to deploy SegWit, it would
> be in
> > > your best interest to validate the SegWit transactions, because you
> > > might will be downgraded to near-SPV node validation.
> > > It would be okay to still run a "non-SegWit" node if there's no
> SegWit
> > > transactions in the chain of transactions for your bitcoins,
> otherwise
> > > you cannot fully verify the the ownership of your bitcoins.
> > > I'm not sure the practicality of this in the long run, but it
> makes a
> > > case for having an up-to-date non-SegWit node, although I think
> it's a
> > > bit of a stretch.
> >
> > Right. Well, if I never upgrade to segwit, then there seems little
> > (zero?) risk of having any segwit tx in my tx chain.
> >
> >
> > If you mean you wish to avoid receiving UTXOs that have value that was
> > at one point previously encumbered by a SegWit output then no, you can't
> > avoid that. No more than you can currently avoid receiving BTC that were
> > at one point in time encumbered by a P2SH output.
>
> fair enough. This actually wasn't an area I'd considered much before
> Hampus brought it up.
>
> I would like to understand it a bit better, as I think it applies
> equally to any pre-segwit node, yes? So let's say I am running 0.13.0
> and someone sends me bitcoins to a P2PKH address, but that person
> previously received them to a P2WPKH address.
>
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated. I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid. I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
> thanks!
> _______________________________________________
> 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/20170714/6adac594/attachment-0001.html>;
Hampus Sjöberg [ARCHIVE] /
npub10u…hln8t
2023-06-07 18:04:27
in reply to nevent1q…t42p
Author Public Key
npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8tPublished at
2023-06-07 18:04:27Event JSON
{
"id": "a109f574b6a1b66781b6a44297434fbacd848fdc0dee5c3078ff23d91c981a8d",
"pubkey": "7f05c6d469aea3aebb69433a3de1336e36d9b0e34b54488cca80118b30a2e0ea",
"created_at": 1686161067,
"kind": 1,
"tags": [
[
"e",
"c3417a9d5ad76947acf26c6783addd471ca3bcc5d3ed57deae65203b0eaf5238",
"",
"root"
],
[
"e",
"e316b176b843f8bf1d9c0fb786ab40efd906c75d4ebe9f4f420fe06f342ee164",
"",
"reply"
],
[
"p",
"bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9"
]
],
"content": "📅 Original date posted:2017-07-13\n📝 Original message:\u003e I would like to understand it a bit better, as I think it applies\nequally to any pre-segwit node, yes? So let's say I am running 0.13.0\nand someone sends me bitcoins to a P2PKH address, but that person\npreviously received them to a P2WPKH address.\n\nYes, this applies to all non-SegWit nodes.\n\n\u003e If I understand correctly, my node will accept the incoming tx inputs\nbut obviously will not perform any segwit related validation, thus those\ninputs are not fully validated.\n\nYes.\nSo you have two choices to be fully secure:\n1. Validate using the new rules of the network (in other words, run a\nSegWit node)\n2. Avoid any chain of transaction that contains a SegWit transaction\n\n\u003e I don't yet understand how my node\nthinks they are valid at all given that it does not understand P2WPKH\naddress format, so either it doesn't need to, or P2WPKH is somehow\nalready valid.\n\nSo how softforks often work is that you make the transaction appear to be\nalways spendable for old nodes, regardless if it really was spendable or\nnot. This will make sure it is a softfork, the update is backwards\ncompatible.\nIf it would be the other way around, if new rules that the node doesn't\nunderstand would always be invalid, it would be hardfork, which is what\nwe're trying to avoid in the first place.\n\n\u003e so if\nsomeone can point me towards a document that explains it I'd be happy to\nread that.\n\nSee\nhttps://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility\nSo the witness program is encoded in a new format that old nodes do not\nunderstand.\nThis means that for old nodes, a number \u003e0 will be put on the stack. When\nthe script is done, it will be evaluated to true (because of \u003e0) and be\ncounted as a valid spend.\n\nhttps://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also\nexplains the new witness program more in detail (I left out some details in\nmy explanation).\n\nCheers\nHampus\n\n2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e On 07/13/2017 09:35 AM, Jameson Lopp wrote:\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:\n\u003e \u003e \u003e\u003e I believe that a good reason not to wish your node to be segwit\n\u003e \u003e \u003e compliant is to avoid having to deal with the extra bandwidth that\n\u003e \u003e \u003e segwit could require. Running a 0.14.2 node means being ok with\n\u003e \u003e1MB\n\u003e \u003e \u003e blocks, in case segwit is activated and widely used. Users not\n\u003e \u003e \u003e interested in segwit transactions may prefer to keep the cost of\n\u003e their\n\u003e \u003e \u003e node lower.\n\u003e \u003e \u003e\n\u003e \u003e \u003e If the majority of the network decides to deploy SegWit, it would\n\u003e be in\n\u003e \u003e \u003e your best interest to validate the SegWit transactions, because you\n\u003e \u003e \u003e might will be downgraded to near-SPV node validation.\n\u003e \u003e \u003e It would be okay to still run a \"non-SegWit\" node if there's no\n\u003e SegWit\n\u003e \u003e \u003e transactions in the chain of transactions for your bitcoins,\n\u003e otherwise\n\u003e \u003e \u003e you cannot fully verify the the ownership of your bitcoins.\n\u003e \u003e \u003e I'm not sure the practicality of this in the long run, but it\n\u003e makes a\n\u003e \u003e \u003e case for having an up-to-date non-SegWit node, although I think\n\u003e it's a\n\u003e \u003e \u003e bit of a stretch.\n\u003e \u003e\n\u003e \u003e Right. Well, if I never upgrade to segwit, then there seems little\n\u003e \u003e (zero?) risk of having any segwit tx in my tx chain.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e If you mean you wish to avoid receiving UTXOs that have value that was\n\u003e \u003e at one point previously encumbered by a SegWit output then no, you can't\n\u003e \u003e avoid that. No more than you can currently avoid receiving BTC that were\n\u003e \u003e at one point in time encumbered by a P2SH output.\n\u003e\n\u003e fair enough. This actually wasn't an area I'd considered much before\n\u003e Hampus brought it up.\n\u003e\n\u003e I would like to understand it a bit better, as I think it applies\n\u003e equally to any pre-segwit node, yes? So let's say I am running 0.13.0\n\u003e and someone sends me bitcoins to a P2PKH address, but that person\n\u003e previously received them to a P2WPKH address.\n\u003e\n\u003e If I understand correctly, my node will accept the incoming tx inputs\n\u003e but obviously will not perform any segwit related validation, thus those\n\u003e inputs are not fully validated. I don't yet understand how my node\n\u003e thinks they are valid at all given that it does not understand P2WPKH\n\u003e address format, so either it doesn't need to, or P2WPKH is somehow\n\u003e already valid. I know this has all been discussed in the past, so if\n\u003e someone can point me towards a document that explains it I'd be happy to\n\u003e read that.\n\u003e\n\u003e thanks!\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/20170714/6adac594/attachment-0001.html\u003e",
"sig": "b85b42c4c8ee83f3e4c9447d2362aeb75596b5352a48251299e6d21937308f00dea591cf13cc6229757dadde5b7ab0726ee217a73f899fa76728329758e10b5f"
}