Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Improving SPV security with PoW fraud proofs
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. 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). If users do not wait and happen to accept payments from an invalid chain during this time, these payments could get reverted. This is a weakness, but still seems preferably to continually following an invalid chain. As long as a reasonable number of miners remains honest, a dishonest majority can only temporarily control the network, and their blocks (and all coins gained from it) will eventually be rejected. -- Ruben Somsen [0] Olaoluwa Osuntokun, BIP 157: Client Side Block Filtering, https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki [1] Peter Todd, TXO commitments do not need a soft-fork to be useful, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIPS (re:LORD HIS EXCELLENCY JAMES HRMH)
Here is where I keep track, in general (don't know if that helps, but thought I'd send it) https://github.com/bitcoin/bips/blob/master/README.mediawiki Regards, Bill ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Smart Contracts Unchained
Hi all! I've been thinking a lot about how to add the benefits that lightning provides in terms of privacy and speed to the smart contracts unchained setup. The high-level idea is to utilize the fact that a lightning channel already has on-chain funds locked up, and if parties cooperate, some of these funds can be moved into the 2/3 MultiSig output needed for the escrow scheme by cooperating off-chain (and then moved back to their channel balances off-chain as well). The following is an admittedly pretty rough outline of how this might be accomplished. A - B : Smart Contracts in a Lightning Channel 1) Parties both commit to a 2/3 MultiSig output on their next commitment transaction 2) Parties then both revoke_and_ack 3) When the contract yields a result, the to_local and to_remote balances can be updated and the 2/3 MultiSig output can be removed 4) If either party is uncooperative, their counter-party can force close the channel and funds can be resolved on-chain using the escrow If either party does not revoke_and_ack well before any potential for them to discover if they have an advantage in the contract (or after some small but reasonable time), their counter-party should go on chain with the commitment transaction containing the 2/3 MultiSig A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case, wants to provide a hub that matches users wanting to enter smart contracts) 1) A irrevocably commits to a 2/3 MultiSig output on their commitment transaction with B (which B also commits to but does not yet revoke their old state) 2) C irrevocably commits to the same 2/3 MultiSig output on their commitment transaction with B (which B also commits to) 3) B irrevocably commits to both outputs 4) When the contract yields a result, say A should win some money from C, then A can ask B to remove that output (and update balances) by revealing to B how to claim funds from C 5) B can then ask C to remove the output and add to B's balance If B does not revoke_and_ack on either channel, then the affected counter-party should close the channel and go on chain with the 2/3 MultiSig transaction If B refuses to remove the output, A can claim their funds on-chain where B can learn how to claim funds from C If C refuses to remove the output, B can claim their funds on-chain using the information revealed by A Problems: How do we ensure that only B can claim the 2/3 MultiSig from C, and not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm pretty sure this is possible to do but I don't know Script well enough A - B - C - D : Fully Routed Smart Contracts 1) Given the n possible outcomes in which A gets money from the contract between A and D, a_1 < a_2 < ... < a_n, and the m possible outcomes in which D gets money, d_1 < d_2 < ... < d_m, D must send n HTLCs to A with the amounts a_1, a_2 - a_1, a_3 - a_2, ..., a_n - a_(n-1) and A must send m HTLCs to D with amounts d_1, d_2 - d_1, d_3 - d_2, ..., d_m - d_(m-1) 2) These HTLCs must be special and have two hashes, where either preimage unlocks the funds 3) In the payments from A to D, A knows one preimage and the smart contracting platform knows the other (and similarly for D to A) 4) Should a_i be the outcome of the contract, D should tell A what the preimages are to payments 1 through i 5) D should fail all m payments 6) A should fail all payments i+1 through n (It is possible and in fact likely that there can be ways to use fewer transactions and thus less collateral than this, perhaps by using subtraction and not just addition as in a_i - d_j, what I've presented is simply a lower bound that works in all cases) If D does not reveal their preimages, A can get the relevant preimages from the smart contracting platform Problems: The smart contracting platform is given more information about the contract in the happy path in this scheme. Also, all routers need to support special double-hash HTLCs An alternative way to possibly do multi-hop routing that would require less be told to the escrow service, is to have each routing node add an output on either side where it takes one position in one channel and the other position in the other channel (essentially allowing them to break event when the contract is completed). This has the same problems as the Single Hop case as well as the additional problem (that I couldn't imagine a solution for) of making the commitments to the 2/3 MultiSig output on commitment transactions atomic; in the single hop case incentives seem to work out but I don't know how "failed routing" would be detected or handled in the multi-hop case. Feedback welcome! Best, Nadav On Wed, Apr 3, 2019 at 9:14 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > https://zmnscpxj.github.io/bitcoin/unchained.html > > Smart contracts have traditionally been implemented as part of the > consensus rules of some blokchain. Often this means creating a new > blockchain, or at least a sidechain to an
Re: [bitcoin-dev] Smart Contracts Unchained
Good morning Nadav,
Yes, transporting contracts over a single direct channel is always possible.
When Lightning switches to Decker-Russell-Osuntokun ("eltoo"), do note that
contracts with an absolute timelock must be forced onchain earlier than the
absolute timelock by the CSV requirement of the channel (unilateral close time).
With current Poon-Dryja channels, transported contracts must be augmented by a
2-of-2 on all branches, which can be done by adding a 2-of-2 multisig on the
escrow branch, using temporary keys.
The purpose of the 2-of-2 is to enforce that the only valid claims to the
contract have an `nSequence` representing the unilateral close time of the
channel.
xref. HTLC-timeout and HTLC-success transactions in BOLT#3.
Transporting over multiple hops requires that compliance to a contract makes
one side reveal information that the other side does not know, together with
some kind of timeout/backoff.
Practically speaking, only HTLC-type contracts can be transported.
For example, DLCs will have many possible branches where the Oracle provides a
signature for one branch, and this signature is what is learned by the other
party in the contract.
In addition, DLCs for practical use require a timeout (in case the Oracle fails
to reveal the signature on the appointed time).
Thus, far fewer contracts can be transported over the network.
(Of note is that a Lightning channel is itself a contract (that is
transportable only within a direct channel); this is the basis of channel
factories, where the factory level is effectively a "channel" with more than
two participants, and transporting Lightning channels instead of HTLCs)
(You may be interested in looking at the "Fulgurite" effort)
OF note is that DLCs have an Oracle.
I observe that escrow services (which are specializations of the Smart
Contracts Unchained technique) are basically oracles also.
If DLCs can transport their oracle signatures over multiple hops, then it
should be possible for Smart Contracts Unchained to transport the
federation/escrow signatures over multiple hops also.
I do not know the math behind DLCs enough to be certain, however, and leave it
to better mathematicians than I.
Regards,
ZmnSCPxj
Regards,
ZmnSCPxj
‐‐‐ Original Message ‐‐‐
On Thursday, April 18, 2019 12:17 AM, Nadav Kohen wrote:
> Hi all!
>
> I've been thinking a lot about how to add the benefits that lightning
> provides in terms of privacy and speed to the smart contracts unchained
> setup. The high-level idea is to utilize the fact that a lightning channel
> already has on-chain funds locked up, and if parties cooperate, some of these
> funds can be moved into the 2/3 MultiSig output needed for the escrow scheme
> by cooperating off-chain (and then moved back to their channel balances
> off-chain as well). The following is an admittedly pretty rough outline of
> how this might be accomplished.
>
> A - B : Smart Contracts in a Lightning Channel
>
> 1) Parties both commit to a 2/3 MultiSig output on their next commitment
> transaction
> 2) Parties then both revoke_and_ack
> 3) When the contract yields a result, the to_local and to_remote balances can
> be updated and the 2/3 MultiSig output can be removed
> 4) If either party is uncooperative, their counter-party can force close the
> channel and funds can be resolved on-chain using the escrow
>
> If either party does not revoke_and_ack well before any potential for them to
> discover if they have an advantage in the contract (or after some small but
> reasonable time), their counter-party should go on chain with the commitment
> transaction containing the 2/3 MultiSig
>
> A - B - C : Single Hop Smart Contracts (Useful if someone, B in this case,
> wants to provide a hub that matches users wanting to enter smart contracts)
>
> 1) A irrevocably commits to a 2/3 MultiSig output on their commitment
> transaction with B (which B also commits to but does not yet revoke their old
> state)
> 2) C irrevocably commits to the same 2/3 MultiSig output on their commitment
> transaction with B (which B also commits to)
> 3) B irrevocably commits to both outputs
> 4) When the contract yields a result, say A should win some money from C,
> then A can ask B to remove that output (and update balances) by revealing to
> B how to claim funds from C
> 5) B can then ask C to remove the output and add to B's balance
>
> If B does not revoke_and_ack on either channel, then the affected
> counter-party should close the channel and go on chain with the 2/3 MultiSig
> transaction
> If B refuses to remove the output, A can claim their funds on-chain where B
> can learn how to claim funds from C
> If C refuses to remove the output, B can claim their funds on-chain using the
> information revealed by A
>
> Problems: How do we ensure that only B can claim the 2/3 MultiSig from C, and
> not anyone who sees A's on-chain spend of their 2/3 MultiSig? I'm pretty sure
> this is possible to do
