Hello all,
This proposal went through the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016805.html without any further discussion. Currently this proposal has been implemented by in the ChainAbstractionLayer (https://github.com/liquality/chainabstractionlayer/tree/dev). I would like to kindly ask for BIP # assignment and have this merged into upstream bips.
Cheers,
Matthew Black
Never self-assign BIP numbers.
(BIP 200 is already reserved for something else)
27 | +These funds are locked into two scripts. Refundable Collateral and Seizable Collateral scripts. The funds sent to these scripts represent the percentage of collateral that each party is entitled to in the case that repayment fails, and the parties don't opt for liquidation. 28 | + 29 | +The Refundable Collateral script takes the following form: 30 | + 31 | + OP_IF 32 | + OP_SIZE OP_PUSHDATA(1) <secret b2 length> OP_EQUALVERIFY [HASHOP] <secret b2> OP_EQUALVERIFY OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG
This doesn't make sense to me. Secret b2 length must always be 1 for EQUALVERIFY to pass... And then you're hashing the size of the 2nd stack item and comparing it to secret b2???
So the purpose of this script is not to ensure that secret b2 length must always be 1, it is actually using the OP_SIZE opcode to check the length of the secret. That pops the length of the secret to the stack, and then pushes secret b2 length to the stack, which is compared with OP_EQUALVERIFY.
Example: The next item on the stack is a secret of length 32 bytes. OP_SIZE is called, which pushes 20 to the stack. <secret b2 length> is 20, which pushes 20 to the stack. OP_EQUALVERIFY succeeds.
So an example of items pushed to the stack would be
1. 01
2. 6443b923b04a21839c44c8f5e54c360af7b5a4541f11511584b6e413a358aa80
3. 02dbf5bf2e114c5e778c904cf8569c77cc18bb32df27bd3d3c539d898ea7150f15
4. 3045022100b302c7fb9cab9978df85ab25be7f8705367e8168c3a6c5c40014acca150c1f6d0220776a0a595b3cec56fe5452a272729cc1215b029c61a2f49a8dffc6ddb96a90a6
Where
51within btcdeb this would look like this
btcdeb --txin=0100000001899afa569a843d13bb5b1002f1ba1e9122db5ae7a6a8d913d6cb32cad698e85b010000006b483045022100e408b398b2850c8c8130964fbd4c596aa450ecb5e4c063893b1db49847ac9fea02204d35647416be8a9d2a25484361c5d190afdcab3d79673eade297d207a274427b012102068b045421cc93a1100fa8bfbd81d5edb82c70b44f92666742e4edd46af847bbffffffff02a08601000000000017a914536f6b5a66eb7db8d729c30954da27a1ba748f3187a23fd211000000001976a9140bb2fc4ea28987e8138420c07c95c40b3433e48f88ac00000000 --tx=0100000001c23f56ede1d633789055cf3e862ea902e0dd2564d7d98fb77fe781a782d238fb00000000fd8d01483045022100b302c7fb9cab9978df85ab25be7f8705367e8168c3a6c5c40014acca150c1f6d0220776a0a595b3cec56fe5452a272729cc1215b029c61a2f49a8dffc6ddb96a90a6012102dbf5bf2e114c5e778c904cf8569c77cc18bb32df27bd3d3c539d898ea7150f15206443b923b04a21839c44c8f5e54c360af7b5a4541f11511584b6e413a358aa80514cfe6382012088a82028f71373c8b55f533f5620f838b87d3a1311ac55f571dc7f820416ea1350140d8876a914cbc6adb577679303b91eb69d44fa46ba9c367f2f88ac676382012088a82071f2c5b20684aeb4515068cecc22262fc12cc6b5875cd19377c539d48b8cec1c8882012088a820a9294a6754739dc61a0d49d4ec898f41be27cd7c6c42a0c84d7190605848b2ed880431bf785db175522102dbf5bf2e114c5e778c904cf8569c77cc18bb32df27bd3d3c539d898ea7150f152102dbf5bf2e114c5e778c904cf8569c77cc18bb32df27bd3d3c539d898ea7150f1552ae6700b17576a914cbc6adb577679303b91eb69d44fa46ba9c367f2f88ac6868000000000160840100000000001976a914cbc6adb577679303b91eb69d44fa46ba9c367f2f88ac00000000
Let me know if that makes sense @luke-jr and if this requires more documentation for the BIP
But you have an OP_PUSHDATA(1) after OP_SIZE
Ah! yes my bad. Thanks for catching that. That should be simply 01
Updated
6 | + Tony Cai <tony@atomicloans.io> 7 | + Atomic Loans team <info@atomicloans.io> 8 | + Comments-Summary: No comments yet. 9 | + Comments-URI: TBD 10 | + Status: Proposal 11 | + Type: Informational
This should be Standards Track
5 | + Author: Matthew Black <matthew@atomicloans.io> 6 | + Tony Cai <tony@atomicloans.io> 7 | + Atomic Loans team <info@atomicloans.io> 8 | + Comments-Summary: No comments yet. 9 | + Comments-URI: TBD 10 | + Status: Proposal
This should be Draft
For a BIP number to be assigned, you must add a Backwards compatibility section.
27 | +These funds are locked into two scripts. Refundable Collateral and Seizable Collateral scripts. The funds sent to these scripts represent the percentage of collateral that each party is entitled to in the case that repayment fails, and the parties don't opt for liquidation. 28 | + 29 | +The Refundable Collateral script takes the following form: 30 | + 31 | + OP_IF 32 | + OP_SIZE <secret b2 length> OP_EQUALVERIFY [HASHOP] <secret hash b2> OP_EQUALVERIFY OP_DUP OP_HASH160 <borrower pubkey hash> OP_EQUALVERIFY OP_CHECKSIG
Why are you checking the length and the hash separately? If the hash is secure, only two identical items of the same length will match. Additionally, SHA2 hashes explicitly commit to the length.
This script checks the length because it's being used alongside the HTLPC (initially Ethereum with ERC 1850 https://github.com/ethereum/EIPs/pull/1850). The SHA256 function in Ethereum takes up to 32 bytes, no more. Therefore, it is necessary to ensure that the secret b2 cannot be more than 32 bytes. Otherwise, you could end up with a situation where the secret corresponds to the correct secrethash on Bitcoin, but not Ethereum.
Ex. btcdeb 216443b923b04a21839c44c8f5e54c360af7b5a4541f11511584b6e413a358aa8080a8 will be a different result than btcdeb 206443b923b04a21839c44c8f5e54c360af7b5a4541f11511584b6e413a358aa80a8 which is problematic for Ethereum
You should write this up in the (currently non-existent) Rationale section. ;)
(There's also too many Ethereum references elsewhere - remember BIPs are about Bitcoin, so probably it only makes sense to reference Ethereum-side stuff in Rationale)
Great idea! Reduced talk of Ethereum and added Rationale section.
Please use BIP number 197 (and purge the incorrect number from the git branch history)
0 | @@ -0,0 +1,156 @@ 1 | +<pre> 2 | + BIP: 197 3 | + Layer: Applications 4 | + Title: Hashed Time-Locked Collateral Contract 5 | + Author: Matthew Black <matthew@atomicloans.io> 6 | + Tony Cai <tony@atomicloans.io> 7 | + Atomic Loans team <info@atomicloans.io>
Not sure teams can be authors; either way, this needs to match what's in README
Removed Atomic Loans team <info@atomicloans.io> from Author list
0 | @@ -0,0 +1,156 @@ 1 | +<pre> 2 | + BIP: 197 3 | + Layer: Applications 4 | + Title: Hashed Time-Locked Collateral Contract
Needs to match README
Changed title in README for BIP 197 to Hashed Time-Locked Collateral Contract