Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Eric Voskuil via bitcoin-dev
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 
>  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 10 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 
> :
>> 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 
>>>  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  wrote:
 
 2017-12-18 13:43 GMT+01:00 Eric Voskuil :
> 
> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev 
> >  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 actual

Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Kalle Rosenbaum via bitcoin-dev
Hi Greg,

2017-12-18 21:42 GMT+01:00 Gregory Maxwell :

> Because it would make no meaningful difference now,


Sure.


> and if you are not
> going to check the history


I'm not going to do any less checks than a node running with assumevalid.
Well not exactly true, because a node running today with assumevalid will
verify the witness root hash, right?


> there are much more efficient things to
> do-- like not transfer it at all.
>

I'm not sure what you are referring to.

Thank you
/Kalle


>
> On Mon, Dec 18, 2017 at 8:32 AM, Kalle Rosenbaum via bitcoin-dev
>  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. 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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Kalle Rosenbaum via bitcoin-dev
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 10 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  wrote:
>
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil :
>
>>
>> > 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 cou

Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Gregory Maxwell via bitcoin-dev
Because it would make no meaningful difference now, and if you are not
going to check the history there are much more efficient things to
do-- like not transfer it at all.

On Mon, Dec 18, 2017 at 8:32 AM, Kalle Rosenbaum via bitcoin-dev
 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. 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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Kalle Rosenbaum via bitcoin-dev
Thanks Eric.

It would be a pity if early witnesses got lost due to nodes abandoning them
by running witnessless. But as long as there's at least one accessible
source for them left we're OKish. Let's hope we don't get to that point in
the near future. As long as Bitcoin Core doesn't implement witnessless
mode, there's little risk.

What do people here think about the benefits and risks with running
witnessless?

/Kalle

Sent from my Sinclair ZX81

Den 18 dec. 2017 17:19 skrev "Eric Voskuil" :

> 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  wrote:
>
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil :
>
>>
>> > 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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Mark Friedenbach via bitcoin-dev
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 
>  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  > wrote:
> 
>> 2017-12-18 13:43 GMT+01:00 Eric Voskuil > >:
>> 
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev 
>> > > > > 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

_

Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Eric Voskuil via bitcoin-dev
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  wrote:
> 
> 2017-12-18 13:43 GMT+01:00 Eric Voskuil :
>> 
>> > On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev 
>> >  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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Kalle Rosenbaum via bitcoin-dev
2017-12-18 13:43 GMT+01:00 Eric Voskuil :

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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Eric Voskuil via bitcoin-dev

> On Dec 18, 2017, at 03:32, Kalle Rosenbaum via bitcoin-dev 
>  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?

> 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


Re: [bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Ozgur via bitcoin-dev
Hello Kalle, If want to talk theoretically: "a hacker has have to hash power than hash value of the entire bitcoin network, it could mislead all operations and invalidate the node." This bitcoin.pdf is clearly written. Ask your questions, Yes will now hacked the blockchain that has more of total power and No the stub record is up-to-date and secure.So, the bans node solution is not good, if good bitcoin couldn't be a reliable proof-of-work currency. Read: http://satoshi.nakamotoinstitute.org/posts/ Regards Ozgur 18.12.2017, 14:55, "Kalle Rosenbaum via bitcoin-dev" :Dear list, I find it hard to understand why a full node that does initial blockdownload also must download witnesses if they are going to skipverification anyway. If my full node skips signature verification forblocks earlier than X, it seems the reasons for downloading thewitnesses 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 becausea bad peer may send me invalid witnesses during initial blockdownload, and if I don't verify that the witness root hash actuallycommits to them, I will get banned by peers requesting the blocks fromme 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 otherswithout getting banned. What if a node could chose not to download witnesses and thus chose tosend only witnessless blocks to peers. Let's call these nodeswitnessless nodes. Note that witnessless nodes are only witnesslessfor blocks up to X. Everything after X is fully verified. Witnessless nodes would be able to sync faster because it needs todownload less data to calculate their UTXO set. They would thereforemore quickly be able to provide full service to SPV wallets and itslocal wallets as well as serving blocks to other witnessless nodeswith same or higher assumevalid block. For witnessless nodes withlower assumevalid they can serve at least some blocks. It could alsoserve blocks to non-segwit nodes. Do witnessless nodes risk dividing the network in two parts, onewitnessless and one with full nodes, with few connections between theparts? So basically, what are the reasons not to implement witnesslessnodes? Thank you,/Kall___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Why not witnessless nodes?

2017-12-18 Thread Kalle Rosenbaum via bitcoin-dev
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. 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