How does one know what consensus has formed (around a UTXO set)?

e

> On Dec 18, 2017, at 16:27, Kalle Rosenbaum via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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@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@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 <ka...@rosenbaum.se> wrote:
>>>> 
>>>> 2017-12-18 13:43 GMT+01:00 Eric Voskuil <e...@voskuil.org>:
>>>>> 
>>>>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev 
>>>>> > <bitcoin-dev@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@lists.linuxfoundation.org
>>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> 
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to