📅 Original date posted:2017-12-18
📝 Original message:Hi Mark
Yes, it seems like sign-to-contract protocols, which I just now briefly
read about [1][2], may need to use historic witnesses. That raises the
question, what are Bitcoin witnesses for?
To me it seems witnesses should be regarded as temporary. But it seems both
respondents to this thread, Eric and Mark, mean that witnesses are forever.
I regard witnesses as a way to authenticate updates to the UTXO set, and
once buried deep enough in the blockchain, the witness is no longer needed,
because consensus has formed around the UTXO set update.
Suppose a transaction with an invalid witness happens to enter the
blockchain and gets buried 100000 blocks down with the witness still
available. Is the blockchain above it valid? I'd say the blockchain is
valid and that it was a bug that the transaction made it into the
blockchain. We will have to live with such bugs.
Another way to put it: Suppose that all witnesses from 2017 dissappears
from all nodes in 2020. Is the blockchain still valid? I think so. I would
continue using it without looking back.
With that approach, I think sign-to-contract protocols has to find ways to
work in a witnessless environment. For example, users of such protocols can
setup their own archival nodes.
I'd love to hear alternative views on this.
Thanks,
/Kalle
[1]
https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf
[2] https://bitcointalk.org/index.php?topic=893898.msg9861102#msg9861102
2017-12-18 18:30 GMT+01:00 Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Sign-to-contract enables some interesting protocols, none of which are in
> wide use as far as I’m aware. But if they were (and arguably this is an
> area that should be more developed), then SPV nodes validating these
> protocols will need access to witness data. If a node is performing IBD
> with assumevalid set to true, and is also intending to prune history, then
> there’s no reason to fetch those witnesses as far as I’m aware. But it
> would be a great disservice to the network for nodes intending to serve SPV
> clients to prune this portion of the block history.
>
>
> On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> You can't know (assume) a block is valid unless you have previously
> validated the block yourself. But in the case where you have, and then
> intend to rely on it in a future sync, there is no need for witness data
> for blocks you are not going to validate. So you can just not request it.
>
> However you will not be able to provide those blocks to nodes that *are*
> validating; the client is pruned and therefore not a peer (cannot
> reciprocate). (An SPV client is similarly not a peer; it is a more deeply
> pruned client than the witnessless client.)
>
> There is no other reason that a node requires witness data. SPV clients
> don't need it as it is neither require it to verify header commitment to
> transactions nor to extract payment addresses from them.
>
> The harm to the network by pruning is that eventually it can become harder
> and even impossible for anyone to validate the chain. But because you are
> fully validating you individually remain secure, so there is no individual
> incentive working against this system harm.
>
> e
>
> On Dec 18, 2017, at 08:35, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
>
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>
>>
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Dear list,
>> >
>> > I find it hard to understand why a full node that does initial block
>> > download also must download witnesses if they are going to skip
>> verification anyway.
>>
>> Why run a full node if you are not going to verify the chain?
>>
>
> I meant to say "I find it hard to understand why a full node that does
> initial block
> download also must download witnesses when it is going to skip
> verification of the witnesses anyway."
>
> I'm referring to the "assumevalid" feature of Bitcoin Core that skips
> signature verification up to block X. Or have I misunderstood assumevalid?
>
> /Kalle
>
>
>>
>> > If my full node skips signature verification for
>> > blocks earlier than X, it seems the reasons for downloading the
>> > witnesses for those blocks are:
>> >
>> > * to be able to send witnesses to other nodes.
>> >
>> > * to verify the witness root hash of the blocks
>> >
>> > I suppose that it's important to verify the witness root hash because
>> > a bad peer may send me invalid witnesses during initial block
>> > download, and if I don't verify that the witness root hash actually
>> > commits to them, I will get banned by peers requesting the blocks from
>> > me because I send them garbage.
>> > So both the reasons above (there may be more that I don't know about)
>> > are actually the same reason: To be able to send witnesses to others
>> > without getting banned.
>> >
>> > What if a node could chose not to download witnesses and thus chose to
>> > send only witnessless blocks to peers. Let's call these nodes
>> > witnessless nodes. Note that witnessless nodes are only witnessless
>> > for blocks up to X. Everything after X is fully verified.
>> >
>> > Witnessless nodes would be able to sync faster because it needs to
>> > download less data to calculate their UTXO set. They would therefore
>> > more quickly be able to provide full service to SPV wallets and its
>> > local wallets as well as serving blocks to other witnessless nodes
>> > with same or higher assumevalid block. For witnessless nodes with
>> > lower assumevalid they can serve at least some blocks. It could also
>> > serve blocks to non-segwit nodes.
>> >
>> > Do witnessless nodes risk dividing the network in two parts, one
>> > witnessless and one with full nodes, with few connections between the
>> > parts?
>> >
>> > So basically, what are the reasons not to implement witnessless
>> > nodes?
>> >
>> > Thank you,
>> > /Kalle
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> 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/20171218/966989da/attachment-0001.html>;
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 18:08:48
in reply to nevent1q…tpn0
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 18:08:48Event JSON
{
"id": "fbc4c4751020ee02a4a4d669e44f91bd044b345dcf561d8dca96c4221705f11f",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686161328,
"kind": 1,
"tags": [
[
"e",
"3bf66450158b6747187be2f444dc90bea29f78652b9c8d6e39a4f19b4db1e66b",
"",
"root"
],
[
"e",
"5bedf9d26c13833017f2c9bb3db86f60fdbede0451ecc4bf8668040d585625f2",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2017-12-18\n📝 Original message:Hi Mark\n\nYes, it seems like sign-to-contract protocols, which I just now briefly\nread about [1][2], may need to use historic witnesses. That raises the\nquestion, what are Bitcoin witnesses for?\n\nTo me it seems witnesses should be regarded as temporary. But it seems both\nrespondents to this thread, Eric and Mark, mean that witnesses are forever.\nI regard witnesses as a way to authenticate updates to the UTXO set, and\nonce buried deep enough in the blockchain, the witness is no longer needed,\nbecause consensus has formed around the UTXO set update.\n\nSuppose a transaction with an invalid witness happens to enter the\nblockchain and gets buried 100000 blocks down with the witness still\navailable. Is the blockchain above it valid? I'd say the blockchain is\nvalid and that it was a bug that the transaction made it into the\nblockchain. We will have to live with such bugs.\n\nAnother way to put it: Suppose that all witnesses from 2017 dissappears\nfrom all nodes in 2020. Is the blockchain still valid? I think so. I would\ncontinue using it without looking back.\n\nWith that approach, I think sign-to-contract protocols has to find ways to\nwork in a witnessless environment. For example, users of such protocols can\nsetup their own archival nodes.\n\nI'd love to hear alternative views on this.\n\nThanks,\n/Kalle\n\n[1]\nhttps://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf\n[2] https://bitcointalk.org/index.php?topic=893898.msg9861102#msg9861102\n\n2017-12-18 18:30 GMT+01:00 Mark Friedenbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e Sign-to-contract enables some interesting protocols, none of which are in\n\u003e wide use as far as I’m aware. But if they were (and arguably this is an\n\u003e area that should be more developed), then SPV nodes validating these\n\u003e protocols will need access to witness data. If a node is performing IBD\n\u003e with assumevalid set to true, and is also intending to prune history, then\n\u003e there’s no reason to fetch those witnesses as far as I’m aware. But it\n\u003e would be a great disservice to the network for nodes intending to serve SPV\n\u003e clients to prune this portion of the block history.\n\u003e\n\u003e\n\u003e On Dec 18, 2017, at 8:19 AM, Eric Voskuil via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e You can't know (assume) a block is valid unless you have previously\n\u003e validated the block yourself. But in the case where you have, and then\n\u003e intend to rely on it in a future sync, there is no need for witness data\n\u003e for blocks you are not going to validate. So you can just not request it.\n\u003e\n\u003e However you will not be able to provide those blocks to nodes that *are*\n\u003e validating; the client is pruned and therefore not a peer (cannot\n\u003e reciprocate). (An SPV client is similarly not a peer; it is a more deeply\n\u003e pruned client than the witnessless client.)\n\u003e\n\u003e There is no other reason that a node requires witness data. SPV clients\n\u003e don't need it as it is neither require it to verify header commitment to\n\u003e transactions nor to extract payment addresses from them.\n\u003e\n\u003e The harm to the network by pruning is that eventually it can become harder\n\u003e and even impossible for anyone to validate the chain. But because you are\n\u003e fully validating you individually remain secure, so there is no individual\n\u003e incentive working against this system harm.\n\u003e\n\u003e e\n\u003e\n\u003e On Dec 18, 2017, at 08:35, Kalle Rosenbaum \u003ckalle at rosenbaum.se\u003e wrote:\n\u003e\n\u003e 2017-12-18 13:43 GMT+01:00 Eric Voskuil \u003ceric at voskuil.org\u003e:\n\u003e\n\u003e\u003e\n\u003e\u003e \u003e On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Dear list,\n\u003e\u003e \u003e\n\u003e\u003e \u003e I find it hard to understand why a full node that does initial block\n\u003e\u003e \u003e download also must download witnesses if they are going to skip\n\u003e\u003e verification anyway.\n\u003e\u003e\n\u003e\u003e Why run a full node if you are not going to verify the chain?\n\u003e\u003e\n\u003e\n\u003e I meant to say \"I find it hard to understand why a full node that does\n\u003e initial block\n\u003e download also must download witnesses when it is going to skip\n\u003e verification of the witnesses anyway.\"\n\u003e\n\u003e I'm referring to the \"assumevalid\" feature of Bitcoin Core that skips\n\u003e signature verification up to block X. Or have I misunderstood assumevalid?\n\u003e\n\u003e /Kalle\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e \u003e If my full node skips signature verification for\n\u003e\u003e \u003e blocks earlier than X, it seems the reasons for downloading the\n\u003e\u003e \u003e witnesses for those blocks are:\n\u003e\u003e \u003e\n\u003e\u003e \u003e * to be able to send witnesses to other nodes.\n\u003e\u003e \u003e\n\u003e\u003e \u003e * to verify the witness root hash of the blocks\n\u003e\u003e \u003e\n\u003e\u003e \u003e I suppose that it's important to verify the witness root hash because\n\u003e\u003e \u003e a bad peer may send me invalid witnesses during initial block\n\u003e\u003e \u003e download, and if I don't verify that the witness root hash actually\n\u003e\u003e \u003e commits to them, I will get banned by peers requesting the blocks from\n\u003e\u003e \u003e me because I send them garbage.\n\u003e\u003e \u003e So both the reasons above (there may be more that I don't know about)\n\u003e\u003e \u003e are actually the same reason: To be able to send witnesses to others\n\u003e\u003e \u003e without getting banned.\n\u003e\u003e \u003e\n\u003e\u003e \u003e What if a node could chose not to download witnesses and thus chose to\n\u003e\u003e \u003e send only witnessless blocks to peers. Let's call these nodes\n\u003e\u003e \u003e witnessless nodes. Note that witnessless nodes are only witnessless\n\u003e\u003e \u003e for blocks up to X. Everything after X is fully verified.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Witnessless nodes would be able to sync faster because it needs to\n\u003e\u003e \u003e download less data to calculate their UTXO set. They would therefore\n\u003e\u003e \u003e more quickly be able to provide full service to SPV wallets and its\n\u003e\u003e \u003e local wallets as well as serving blocks to other witnessless nodes\n\u003e\u003e \u003e with same or higher assumevalid block. For witnessless nodes with\n\u003e\u003e \u003e lower assumevalid they can serve at least some blocks. It could also\n\u003e\u003e \u003e serve blocks to non-segwit nodes.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Do witnessless nodes risk dividing the network in two parts, one\n\u003e\u003e \u003e witnessless and one with full nodes, with few connections between the\n\u003e\u003e \u003e parts?\n\u003e\u003e \u003e\n\u003e\u003e \u003e So basically, what are the reasons not to implement witnessless\n\u003e\u003e \u003e nodes?\n\u003e\u003e \u003e\n\u003e\u003e \u003e Thank you,\n\u003e\u003e \u003e /Kalle\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\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\u003e\n\u003e\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171218/966989da/attachment-0001.html\u003e",
"sig": "605bc574d2a4c03ac479e6c0c5e053a342f50be929e6ff8660673e310d5edc92d242022c9276012e88422051a06a3e39f9b11267fabd585391df90046354219f"
}