Re: [bitcoin-dev] Using the same public keys, the p2sh returned by `addmultisigaddress` differs from the one returned by `createmultisigaddress`
Hi Michele,
You are seeing this discrepancy due to the address types in use.
addmultisigaddress uses the default address type of the wallet, which is
p2sh-segwit. createmultisig uses a default address type of legacy. To have
createmultisig get addmultisigaddress's result, you need to add the string
"p2sh-segwit" to the end of your command. To have addmultisigaddress get
createmultisig's result, you need to add the string "legacy" to the end of your
command.
On 4/19/19 7:53 AM, Michele Federici via bitcoin-dev wrote:
> Hi everyone,
>
> I'm writing here because I didn't find any resources in the docs or
> somewhere else online explaining this, I don't get if this is a bug or
> I'm missing something.
>
> I was working on a function to derive the pay-to-script-hash from a
> multisig script and I was checking the results against the bitcoin
> core's `addmultisigaddress` output, although I was quite sure that my
> implementation was correct, my output address was different.
> By chance, I then tried the `createmultisigaddress` method, using the
> same public keys, and this time the output was matching with mine.
>
> I thought the outputs of `addmultisigaddress` and
> `createmultisigaddress` were supposed to be the same, but instead are
> inconsistent from each other:
>
> ```
> bitcoin-cli addmultisigaddress 1
> '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0c
> e382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46
> c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc
> 5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
> {
> "address": "36ULucjWUTrDvaJzCyhFoVbDoNS6Zum2Du",
> "redeemScript":
> "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
> 0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
> 6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
> 5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
> }
> ```
>
> ```
> bitcoin-cli createmultisig 1
> '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0c
> e382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46
> c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc
> 5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
> {
> "address": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1",
> "redeemScript":
> "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
> 0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
> 6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
> 5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
> }
> ```
>
> I was also pretty confused by the fact that the `redeemScript` is the
> same, only the addresses are different, and calling `decodescript` with
> it I get the same address as `createmultisig`:
>
> ```
> bitcoin-cli decodescript
> "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
> 0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
> 6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
> 5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
> {
> "asm": "1
> 045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce38
> 2458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d
> 02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831
> 0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07 3
> OP_CHECKMULTISIG",
> "reqSigs": 1,
> "type": "multisig",
> "addresses": [
> "12PfkcWheYsfFddWfHhaXpFDVx78gnKQ9k",
> "1AYLXzXd6N2avqW4j8Gyhb8jb2jXvNPyuV",
> "1PWsxtcBMRHTSX2L7wrXgwnFigHD3KhbFT"
> ],
> "p2sh": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1"
> }
> ```
>
> I don't understand, how can this be possible?
>
> Thank you,
> Michele
> ___
> 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] Using the same public keys, the p2sh returned by `addmultisigaddress` differs from the one returned by `createmultisigaddress`
Hi everyone,
I'm writing here because I didn't find any resources in the docs or
somewhere else online explaining this, I don't get if this is a bug or
I'm missing something.
I was working on a function to derive the pay-to-script-hash from a
multisig script and I was checking the results against the bitcoin
core's `addmultisigaddress` output, although I was quite sure that my
implementation was correct, my output address was different.
By chance, I then tried the `createmultisigaddress` method, using the
same public keys, and this time the output was matching with mine.
I thought the outputs of `addmultisigaddress` and
`createmultisigaddress` were supposed to be the same, but instead are
inconsistent from each other:
```
bitcoin-cli addmultisigaddress 1
'["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0c
e382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46
c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc
5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
"address": "36ULucjWUTrDvaJzCyhFoVbDoNS6Zum2Du",
"redeemScript":
"5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}
```
```
bitcoin-cli createmultisig 1
'["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0c
e382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46
c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc
5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
"address": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1",
"redeemScript":
"5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}
```
I was also pretty confused by the fact that the `redeemScript` is the
same, only the addresses are different, and calling `decodescript` with
it I get the same address as `createmultisig`:
```
bitcoin-cli decodescript
"5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c
0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac4
6c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc
5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
{
"asm": "1
045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce38
2458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d
02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831
0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07 3
OP_CHECKMULTISIG",
"reqSigs": 1,
"type": "multisig",
"addresses": [
"12PfkcWheYsfFddWfHhaXpFDVx78gnKQ9k",
"1AYLXzXd6N2avqW4j8Gyhb8jb2jXvNPyuV",
"1PWsxtcBMRHTSX2L7wrXgwnFigHD3KhbFT"
],
"p2sh": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1"
}
```
I don't understand, how can this be possible?
Thank you,
Michele
signature.asc
Description: This is a digitally signed message part
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Hi ZmnSCPxj and Ethan, I apologize if my initial explanation was confusing, but it looks like you figured it out. For every fork, SPV clients only have to download one block. If there is a fork after block N, this means there are two blocks at N+1. You only download and verify N+1 from the longer chain. >Mining a block which will never be accepted is an expensive way to make SPV >clients download validate and discard ~2-4 megabytes of data Absolutely, hence the name "PoW fraud proof". It gets naturally created by honest miners and is prohibitively expensive to forge. >SPV clients may not even learn about these splits because it requires that >someone relay the split to them. Honest full nodes should not relay such >splits. You could perform a fully valid repeated 1-block reorg from the top of the chain. So at least theoretically you could get an honest network to relay every split. >Having SPV clients slow down or become full nodes when a malicious miner with >significant mining power is attempting to disrupt the network is probably a >best case outcome. That is an excellent point. >As I understand it, this requires that UTXO commitments be mandatory. Perhaps UTXO sets can be made useful without committing them. I have some very loose thoughts on the subject, I consider it an open question. > More difficult is: how can an SPV node acquire the UTXO set at a particular > block? I think you are asking fair questions about how the UTXO set commitments would work in practice, and how viable that makes it. I'm not sure. The most comprehensive work I have seen on this topic has been the utreexo proposal by Tadge Dryja: https://www.youtube.com/watch?v=edRun-6ubCc Actually, now that I think about it... As an alternative to UTXO set commitments, the old fraud proofs idea for segwit can be applied here. We get miners to commit to the location of the UTXOs that are being spent (e.g. transaction 5 in block 12). This allows full nodes to succinctly prove invalidity to SPV clients in the following ways: - a committed location does not contain the stated UTXO - the UTXO has already been spent in a prior block If no fraud proofs are given, then the inputs can be assumed to be valid. As you may recall, these kinds of fraud proofs were abandoned mainly because the data unavailability claim could only be verified by downloading the data, resulting in a DoS vector where all blocks had to be downloaded. This problem does not seem to apply here, because we are only interested in blocks which have forks, so it's more doable to download them. -- Ruben Somsen On Fri, Apr 19, 2019 at 6:48 AM ZmnSCPxj wrote: > > Good morning Ethan, > > > My above email contains an error. The SPV client needs to only > > download S+1, not S+1 and S+2. > > > > I agree with you that a weakness of this approach is a miner can make > > SPV clients do substantially more work. However: > > > > 1. Mining a block which will never be accepted is an expensive way to > > make SPV clients download, validate and discard ~2-4 megabytes of > > data. There are far less expensive ways of wasting the resources of > > SPV clients. Its unclear why someone would want to do this instead of > > just packeting full nodes or SPV servers like we saw with the recent > > DDoS attacks against electrum servers. > > > > 2. SPV clients may not even learn about these splits because it > > requires that someone relay the split to them. Honest full nodes > > should not relay such splits. To their bitcoin's worth the attacker > > must also connect to lots of SPV clients. > > > > 3. Having SPV clients slow down or become full nodes when a malicious > > miner with significant mining power is attempting to disrupt the > > network is probably a best case outcome. I would prefer this failure > > mode to the current SPV behavior which is to just go with the > > "longest" chain. > > > I understand. > It seems a reasonable point to do so. > > As I understand it, this requires that UTXO commitments be mandatory. > In particular, if UTXO commitments were not mandatory, it would be trivial to > force chainsplits at heights where a UTXO commitment was not made, and force > an SPV node to download more blocks backwards until a block with a UTXO > commitment is found. > > More difficult is: how can an SPV node acquire the UTXO set at a particular > block? > Fullnodes automatically update their UTXO set at each block they accept as > tip. > Reversing the blocks to update the UTXO set at a particular past time would > require a good amount of CPU and memory. > Thus any service that can provide the actual UTXO set at each block would > potentially be attackable by simply requesting enough past blocks. > > > Regards, > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Good morning Ethan, > My above email contains an error. The SPV client needs to only > download S+1, not S+1 and S+2. > > I agree with you that a weakness of this approach is a miner can make > SPV clients do substantially more work. However: > > 1. Mining a block which will never be accepted is an expensive way to > make SPV clients download, validate and discard ~2-4 megabytes of > data. There are far less expensive ways of wasting the resources of > SPV clients. Its unclear why someone would want to do this instead of > just packeting full nodes or SPV servers like we saw with the recent > DDoS attacks against electrum servers. > > 2. SPV clients may not even learn about these splits because it > requires that someone relay the split to them. Honest full nodes > should not relay such splits. To their bitcoin's worth the attacker > must also connect to lots of SPV clients. > > 3. Having SPV clients slow down or become full nodes when a malicious > miner with significant mining power is attempting to disrupt the > network is probably a best case outcome. I would prefer this failure > mode to the current SPV behavior which is to just go with the > "longest" chain. I understand. It seems a reasonable point to do so. As I understand it, this requires that UTXO commitments be mandatory. In particular, if UTXO commitments were not mandatory, it would be trivial to force chainsplits at heights where a UTXO commitment was not made, and force an SPV node to download more blocks backwards until a block with a UTXO commitment is found. More difficult is: how can an SPV node acquire the UTXO set at a particular block? Fullnodes automatically update their UTXO set at each block they accept as tip. Reversing the blocks to update the UTXO set at a particular past time would require a good amount of CPU and memory. Thus any service that can provide the actual UTXO set at each block would potentially be attackable by simply requesting enough past blocks. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Good morning to you as well ZmnSCPxj, My above email contains an error. The SPV client needs to only download S+1, not S+1 and S+2. I agree with you that a weakness of this approach is a miner can make SPV clients do substantially more work. However: 1. Mining a block which will never be accepted is an expensive way to make SPV clients download, validate and discard ~2-4 megabytes of data. There are far less expensive ways of wasting the resources of SPV clients. Its unclear why someone would want to do this instead of just packeting full nodes or SPV servers like we saw with the recent DDoS attacks against electrum servers. 2. SPV clients may not even learn about these splits because it requires that someone relay the split to them. Honest full nodes should not relay such splits. To their bitcoin's worth the attacker must also connect to lots of SPV clients. 3. Having SPV clients slow down or become full nodes when a malicious miner with significant mining power is attempting to disrupt the network is probably a best case outcome. I would prefer this failure mode to the current SPV behavior which is to just go with the "longest" chain. Thanks, Ethan On Thu, Apr 18, 2019 at 10:53 PM ZmnSCPxj wrote: > > Good morning Ethan, > > Thank you for clarifying, I understand better now. > > It seems that minority miners can disrupt SPV clients such that SPV clients > will download 2 blocks for every block the minority miner can find, not 1. > > This can be done by simply making multiple 1-block chainsplits, rather than a > single persistent chainsplit, and alternating split-off and non-split-off. > > For instance, such a minority miner might split at S+1, forcing SPV clients > to download S+1 and S+2. > Then the minority miner splits at S+3, forcing SPV clients to download S+3 > and S+4. > With a mere 33% hashrate, this can force SPV clients to download every block, > i.e. become a fullnode anyway. > > Since there exist pools with >33% hashrate, the above attack is possible so > the only solution is to become a fullnode anyway. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, April 19, 2019 9:13 AM, Ethan Heilman wrote: > > > Hi ZmnSCPxj, > > > > Let's see if I understand what you are saying. In your scenario chain > > A consists of honest miners (10% of the hash rate) and chain B (90% > > of the hash rate) consists of dishonest miners who are inflating the > > coin supply. > > > > Chain A: S, S+1 > > Chain B: S, S+1 (invalid), S+2, S+3, S+4, S+5, S+6, S+7, S+8, S+9 > > > > Chain B S+1 has a invalid coinbase > > > > > At around height S+9, the minority miners generate an alternate block at > > > height S+1. So SPV nodes download S+9 and S+8 on the longer chain, and > > > see nothing wrong with those blocks. > > > > What I am suggesting is that when the minority miners generate an > > alternate block at S+1 (chain A) the SPV node would download blocks > > S+1 and S+2 from chain B (the dishonest chain). Since S+1 has the > > invalid coinbase the SPV node would learn that chain B is invalid and > > abandon it. > > > > Bitcoin is in big trouble if a malicious party controls 90% of the > > mining power. The malicious miners can spend +11% of their mining > > power ensuring that the honest chain never reaches consensus by > > continuously forking it. The malicious miners can then extend their > > favored chain using the other 79% of the mining power. This would > > produce a scenario in which users are forced to choose between a > > stable chain that violates a consensus rule and an unstable honest > > chain that is completely unusable and which never pays out mining > > rewards. I agree that SPV nodes and many wallets would make this even > > worse especially in their current condition where they just trust the > > hash rate/wallet provider and there are no fraud proofs. > > > > On Thu, Apr 18, 2019 at 8:25 PM ZmnSCPxj zmnsc...@protonmail.com wrote: > > > > > Good morning Ethan, > > > Sent with ProtonMail Secure Email. > > > ‐‐‐ Original Message ‐‐‐ > > > On Friday, April 19, 2019 4:12 AM, Ethan Heilman eth...@gmail.com wrote: > > > > > > > I'm probably repeating a point which has been said before. > > > > > > > > > I suppose a minority miner that wants to disrupt the network could > > > > > simply create a valid block at block N+1 and deliberately ignore > > > > > every other valid block at N+1, N+2, N+3 etc. that it did not create > > > > > itself. > > > > > > > > If this minority miner has > 10% of network hashrate, then the rule of > > > > thumb above would, on average, give it the ability to disrupt the > > > > SPV-using network. > > > > Proposed rule: > > > > Whenever a chainsplit occurs SPV clients should download and validate > > > > the "longest chain" up to more than one block greater than the height > > > > of the losing chain. > > > > Lets say a block split causes chain A and chain B: Chain A is N blocks > > > > long,
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Good morning Ethan, Thank you for clarifying, I understand better now. It seems that minority miners can disrupt SPV clients such that SPV clients will download 2 blocks for every block the minority miner can find, not 1. This can be done by simply making multiple 1-block chainsplits, rather than a single persistent chainsplit, and alternating split-off and non-split-off. For instance, such a minority miner might split at S+1, forcing SPV clients to download S+1 and S+2. Then the minority miner splits at S+3, forcing SPV clients to download S+3 and S+4. With a mere 33% hashrate, this can force SPV clients to download every block, i.e. become a fullnode anyway. Since there exist pools with >33% hashrate, the above attack is possible so the only solution is to become a fullnode anyway. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, April 19, 2019 9:13 AM, Ethan Heilman wrote: > Hi ZmnSCPxj, > > Let's see if I understand what you are saying. In your scenario chain > A consists of honest miners (10% of the hash rate) and chain B (90% > of the hash rate) consists of dishonest miners who are inflating the > coin supply. > > Chain A: S, S+1 > Chain B: S, S+1 (invalid), S+2, S+3, S+4, S+5, S+6, S+7, S+8, S+9 > > Chain B S+1 has a invalid coinbase > > > At around height S+9, the minority miners generate an alternate block at > > height S+1. So SPV nodes download S+9 and S+8 on the longer chain, and see > > nothing wrong with those blocks. > > What I am suggesting is that when the minority miners generate an > alternate block at S+1 (chain A) the SPV node would download blocks > S+1 and S+2 from chain B (the dishonest chain). Since S+1 has the > invalid coinbase the SPV node would learn that chain B is invalid and > abandon it. > > Bitcoin is in big trouble if a malicious party controls 90% of the > mining power. The malicious miners can spend +11% of their mining > power ensuring that the honest chain never reaches consensus by > continuously forking it. The malicious miners can then extend their > favored chain using the other 79% of the mining power. This would > produce a scenario in which users are forced to choose between a > stable chain that violates a consensus rule and an unstable honest > chain that is completely unusable and which never pays out mining > rewards. I agree that SPV nodes and many wallets would make this even > worse especially in their current condition where they just trust the > hash rate/wallet provider and there are no fraud proofs. > > On Thu, Apr 18, 2019 at 8:25 PM ZmnSCPxj zmnsc...@protonmail.com wrote: > > > Good morning Ethan, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, April 19, 2019 4:12 AM, Ethan Heilman eth...@gmail.com wrote: > > > > > I'm probably repeating a point which has been said before. > > > > > > > I suppose a minority miner that wants to disrupt the network could > > > > simply create a valid block at block N+1 and deliberately ignore every > > > > other valid block at N+1, N+2, N+3 etc. that it did not create itself. > > > > > > If this minority miner has > 10% of network hashrate, then the rule of > > > thumb above would, on average, give it the ability to disrupt the > > > SPV-using network. > > > Proposed rule: > > > Whenever a chainsplit occurs SPV clients should download and validate > > > the "longest chain" up to more than one block greater than the height > > > of the losing chain. > > > Lets say a block split causes chain A and chain B: Chain A is N blocks > > > long, chain B is M blocks long, and N < M. Then the SPV client should > > > download all the block data of N+1 blocks from Chain B to verify > > > availability of chain B. Once the SPV client has verified that chain B > > > is available they can use fraud proofs determine if chain B is valid. > > > > Let us then revert to the original scenario. > > Suppose a supermajority (90%) of miners decide to increase inflation of the > > currency. > > They do this by imposing the rule: > > > > 1. For 1 block, the coinbase is 21,000,000 times the pre-fork coinbase > > value. > > 2. For 9 blocks, the coinbase is the pre-fork value. > > 3. Repeat this pattern every 10 blocks. > > > > The above is a hardfork. > > However, as they believe that SPV nodes dominate the economy, this mining > > supermajority believes it can take over the network hashpower and impose > > its will on the network. > > At height S+1, they begin the above rule. > > This implies that at heights S+1, S+11, S+21, s+31... the coinbase violates > > the pre-hardfork rules. > > At around height S+9, the minority miners generate an alternate block at > > height S+1. > > So SPV nodes download S+9 and S+8 on the longer chain, and see nothing > > wrong with those blocks. > > At around height S+18, the minority miners generate an alternate block at > > height S+2. > > So SPV nodes download S+18, S+17, S+16 and again see not
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Hi ZmnSCPxj, Let's see if I understand what you are saying. In your scenario chain A consists of honest miners (10% of the hash rate) and chain B (90% of the hash rate) consists of dishonest miners who are inflating the coin supply. Chain A: S, S+1 Chain B: S, S+1 (invalid), S+2, S+3, S+4, S+5, S+6, S+7, S+8, S+9 Chain B S+1 has a invalid coinbase >At around height S+9, the minority miners generate an alternate block at >height S+1. So SPV nodes download S+9 and S+8 on the longer chain, and see >nothing wrong with those blocks. What I am suggesting is that when the minority miners generate an alternate block at S+1 (chain A) the SPV node would download blocks S+1 and S+2 from chain B (the dishonest chain). Since S+1 has the invalid coinbase the SPV node would learn that chain B is invalid and abandon it. Bitcoin is in big trouble if a malicious party controls 90% of the mining power. The malicious miners can spend +11% of their mining power ensuring that the honest chain never reaches consensus by continuously forking it. The malicious miners can then extend their favored chain using the other 79% of the mining power. This would produce a scenario in which users are forced to choose between a stable chain that violates a consensus rule and an unstable honest chain that is completely unusable and which never pays out mining rewards. I agree that SPV nodes and many wallets would make this even worse especially in their current condition where they just trust the hash rate/wallet provider and there are no fraud proofs. On Thu, Apr 18, 2019 at 8:25 PM ZmnSCPxj wrote: > > Good morning Ethan, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, April 19, 2019 4:12 AM, Ethan Heilman wrote: > > > I'm probably repeating a point which has been said before. > > > > > I suppose a minority miner that wants to disrupt the network could simply > > > create a valid block at block N+1 and deliberately ignore every other > > > valid block at N+1, N+2, N+3 etc. that it did not create itself. > > > > If this minority miner has > 10% of network hashrate, then the rule of > > thumb above would, on average, give it the ability to disrupt the > > SPV-using network. > > > > Proposed rule: > > Whenever a chainsplit occurs SPV clients should download and validate > > the "longest chain" up to more than one block greater than the height > > of the losing chain. > > > > Lets say a block split causes chain A and chain B: Chain A is N blocks > > long, chain B is M blocks long, and N < M. Then the SPV client should > > download all the block data of N+1 blocks from Chain B to verify > > availability of chain B. Once the SPV client has verified that chain B > > is available they can use fraud proofs determine if chain B is valid. > > Let us then revert to the original scenario. > Suppose a supermajority (90%) of miners decide to increase inflation of the > currency. > > They do this by imposing the rule: > > 1. For 1 block, the coinbase is 21,000,000 times the pre-fork coinbase value. > 2. For 9 blocks, the coinbase is the pre-fork value. > 3. Repeat this pattern every 10 blocks. > > The above is a hardfork. > However, as they believe that SPV nodes dominate the economy, this mining > supermajority believes it can take over the network hashpower and impose its > will on the network. > > At height S+1, they begin the above rule. > This implies that at heights S+1, S+11, S+21, s+31... the coinbase violates > the pre-hardfork rules. > > At around height S+9, the minority miners generate an alternate block at > height S+1. > So SPV nodes download S+9 and S+8 on the longer chain, and see nothing wrong > with those blocks. > > At around height S+18, the minority miners generate an alternate block at > height S+2. > So SPV nodes download S+18, S+17, S+16 and again see nothing wrong with those > blocsk. > > This can go on for a good amount of time. > With a "rare enough" inflation event, miners may even be able to spend some > coinbases on SPV nodes that SPV nodes become unwilling to revert to the > minority pre-hardfork chain, economically locking in the post-hardfork > inflation. > > Again: every rule is an opportunity to loophole. > > Regards, > ZmnSCPxj > > > An attacker could use this to force SPV clients to download 1 block > > per block the attacker mines. This is strictly weaker security than > > provided by a full-node because chain B will only be validated if the > > client knows chain A exists. If the SPV client's view of the > > blockchain is eclipsed then the client will never learn that chain A > > exists and thus never validate chain B's availability nor will the > > client be able to learn fraud proofs about chain B. A full node in > > this circumstance would notice that the chain B is invalid and reject > > it because a full node would not depend on fraud proofs. That being > > said this rule would provide strictly more security than current SPV > > clients. > > >
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
Good morning Ethan, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, April 19, 2019 4:12 AM, Ethan Heilman wrote: > I'm probably repeating a point which has been said before. > > > I suppose a minority miner that wants to disrupt the network could simply > > create a valid block at block N+1 and deliberately ignore every other valid > > block at N+1, N+2, N+3 etc. that it did not create itself. > > If this minority miner has > 10% of network hashrate, then the rule of > thumb above would, on average, give it the ability to disrupt the > SPV-using network. > > Proposed rule: > Whenever a chainsplit occurs SPV clients should download and validate > the "longest chain" up to more than one block greater than the height > of the losing chain. > > Lets say a block split causes chain A and chain B: Chain A is N blocks > long, chain B is M blocks long, and N < M. Then the SPV client should > download all the block data of N+1 blocks from Chain B to verify > availability of chain B. Once the SPV client has verified that chain B > is available they can use fraud proofs determine if chain B is valid. Let us then revert to the original scenario. Suppose a supermajority (90%) of miners decide to increase inflation of the currency. They do this by imposing the rule: 1. For 1 block, the coinbase is 21,000,000 times the pre-fork coinbase value. 2. For 9 blocks, the coinbase is the pre-fork value. 3. Repeat this pattern every 10 blocks. The above is a hardfork. However, as they believe that SPV nodes dominate the economy, this mining supermajority believes it can take over the network hashpower and impose its will on the network. At height S+1, they begin the above rule. This implies that at heights S+1, S+11, S+21, s+31... the coinbase violates the pre-hardfork rules. At around height S+9, the minority miners generate an alternate block at height S+1. So SPV nodes download S+9 and S+8 on the longer chain, and see nothing wrong with those blocks. At around height S+18, the minority miners generate an alternate block at height S+2. So SPV nodes download S+18, S+17, S+16 and again see nothing wrong with those blocsk. This can go on for a good amount of time. With a "rare enough" inflation event, miners may even be able to spend some coinbases on SPV nodes that SPV nodes become unwilling to revert to the minority pre-hardfork chain, economically locking in the post-hardfork inflation. Again: every rule is an opportunity to loophole. Regards, ZmnSCPxj > An attacker could use this to force SPV clients to download 1 block > per block the attacker mines. This is strictly weaker security than > provided by a full-node because chain B will only be validated if the > client knows chain A exists. If the SPV client's view of the > blockchain is eclipsed then the client will never learn that chain A > exists and thus never validate chain B's availability nor will the > client be able to learn fraud proofs about chain B. A full node in > this circumstance would notice that the chain B is invalid and reject > it because a full node would not depend on fraud proofs. That being > said this rule would provide strictly more security than current SPV > clients. > > On Thu, Apr 18, 2019 at 3:08 PM ZmnSCPxj via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Good morning Ruben, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, April 18, 2019 9:44 PM, Ruben Somsen via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > Simplified-Payment-Verification (SPV) is secure under the assumption > > > that the chain with the most Proof-of-Work (PoW) is valid. As many > > > have pointed out before, and attacks like Segwit2x have shown, this is > > > not a safe assumption. What I propose below improves this assumption > > > -- invalid blocks will be rejected as long as there are enough honest > > > miners to create a block within a reasonable time frame. This still > > > doesn’t fully inoculate SPV clients against dishonest miners, but is a > > > clear improvement over regular SPV (and compatible with the privacy > > > improvements of BIP157[0]). > > > The idea is that a fork is an indication of potential misbehavior -- > > > its block header can serve as a PoW fraud proof. Conversely, the lack > > > of a fork is an indication that a block is valid. If a fork is created > > > from a block at height N, this means a subset of miners may disagree > > > on the validity of block N+1. If SPV clients download and verify this > > > block, they can judge for themselves whether or not the chain should > > > be rejected. Of course it could simply be a natural fork, in which > > > case we continue following the chain with the most PoW. > > > > I presume you mean a chain split? > > > > > The way Bitcoin currently works, it is impossible to verify the > > > validity of block N+1 without knowing the UTXO set at block N, even if > >
Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
I'm probably repeating a point which has been said before. >I suppose a minority miner that wants to disrupt the network could simply >create a *valid* block at block N+1 and deliberately ignore every other valid >block at N+1, N+2, N+3 etc. that it did not create itself. If this minority miner has > 10% of network hashrate, then the rule of thumb above would, on average, give it the ability to disrupt the SPV-using network. Proposed rule: Whenever a chainsplit occurs SPV clients should download and validate the "longest chain" up to more than one block greater than the height of the losing chain. Lets say a block split causes chain A and chain B: Chain A is N blocks long, chain B is M blocks long, and N < M. Then the SPV client should download all the block data of N+1 blocks from Chain B to verify availability of chain B. Once the SPV client has verified that chain B is available they can use fraud proofs determine if chain B is valid. An attacker could use this to force SPV clients to download 1 block per block the attacker mines. This is strictly weaker security than provided by a full-node because chain B will only be validated if the client knows chain A exists. If the SPV client's view of the blockchain is eclipsed then the client will never learn that chain A exists and thus never validate chain B's availability nor will the client be able to learn fraud proofs about chain B. A full node in this circumstance would notice that the chain B is invalid and reject it because a full node would not depend on fraud proofs. That being said this rule would provide strictly more security than current SPV clients. On Thu, Apr 18, 2019 at 3:08 PM ZmnSCPxj via bitcoin-dev wrote: > > Good morning Ruben, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, April 18, 2019 9:44 PM, Ruben Somsen via bitcoin-dev > wrote: > > > Simplified-Payment-Verification (SPV) is secure under the assumption > > that the chain with the most Proof-of-Work (PoW) is valid. As many > > have pointed out before, and attacks like Segwit2x have shown, this is > > not a safe assumption. What I propose below improves this assumption > > -- invalid blocks will be rejected as long as there are enough honest > > miners to create a block within a reasonable time frame. This still > > doesn’t fully inoculate SPV clients against dishonest miners, but is a > > clear improvement over regular SPV (and compatible with the privacy > > improvements of BIP157[0]). > > > > The idea is that a fork is an indication of potential misbehavior -- > > its block header can serve as a PoW fraud proof. Conversely, the lack > > of a fork is an indication that a block is valid. If a fork is created > > from a block at height N, this means a subset of miners may disagree > > on the validity of block N+1. If SPV clients download and verify this > > block, they can judge for themselves whether or not the chain should > > be rejected. Of course it could simply be a natural fork, in which > > case we continue following the chain with the most PoW. > > I presume you mean a chain split? > > > > > The way Bitcoin currently works, it is impossible to verify the > > validity of block N+1 without knowing the UTXO set at block N, even if > > you are willing to assume that block N (and everything before it) is > > valid. This would change with the introduction of UTXO set > > commitments, allowing block N+1 to be validated by verifying whether > > its inputs are present in the UTXO set that was committed to in block > > N. An open question is whether a similar result can be achieved > > without a soft fork that commits to the UTXO set[0][1]. > > > > If an invalid block is created and only 10% of the miners are honest, > > on average it would take 100 minutes for a valid block to appear. > > During this time, the SPV client will be following the invalid chain > > and see roughly 9 confirmations before the chain gets rejected. It may > > therefore be prudent to wait for a number of confirmations that > > corresponds to the time it may take for the conservative percentage of > > miners that you think may behave honestly to create a block (including > > variance). > > I suppose a minority miner that wants to disrupt the network could simply > create a *valid* block at block N+1 and deliberately ignore every other valid > block at N+1, N+2, N+3 etc. that it did not create itself. > If this minority miner has > 10% of network hashrate, then the rule of thumb > above would, on average, give it the ability to disrupt the SPV-using network. > > >10% of network hashrate to disrupt the SPV-using nodes would be a rather low > >bar to disruption. > Consider that SPV-using nodes would be disrupted, without this rule, only by > >50% network hashrate. > > It is helpful to consider that every rule you impose is potentially a > loophole by which a new attack is possible. > > Regards, > ZmnSCPxj > __
