[WIP] HTLC implementation in the wallet #7601

Open
wants to merge 1 commit into
from

Projects

None yet
@ebfull
ebfull commented Feb 25, 2016 edited

This adds support for timelocked contracts which can be used to atomically
swap hash preimages over the blockchain. It is very similar to the script
used by the lightning network.

Written in collaboration with Pieter Wuille.

@jonasschnelli
Member

Interesting!
Haven't looked at it in detail, but would this affect "policy" by adding the TX_HTLC as to the standard templates?

@sipa
Member
sipa commented Feb 25, 2016
@jonasschnelli
Member

@sipa: Ah. Right. Then – I guess – the standard.cpp -> Solver() changes are only because we want to detect these types of P2SH scripts in the wallet.

@sipa
Member
sipa commented Feb 25, 2016

@jonasschnelli To be clear: this indeed does make the HTLC type transaction standard in non-P2SH setting; it's however still smaller and cheaper than the largest raw multisig that is allowed. Perhaps that indeed shouldn't happen.

@gmaxwell
Member

Concept ACK.

@dcousens
Contributor

concept ACK

@petertodd
Member

Interestingly, this is useful for Paypub, as well as ZKCP, among other things.

Concept ACK

@petertodd
Member

@sipa For Paypub, having the payments be visible in the blockchain for the receiver is extremely useful; w/o the ability to do so in scriptPubKey you'd likely implement it with an extra OP_RETURN output (maybe until we have a better Bitmessage to use instead). Not necessarily an argument either for or against doing so, but worth noting.

@btcdrak
Member
btcdrak commented Feb 26, 2016

Concept ACK

@paveljanik
Contributor

Some tests fail with:

Running testscript wallet.py ...
Initializing test directory /tmp/testr_T8PJ
start_node: bitcoind started, calling bitcoin-cli -rpcwait getblockcount
start_node: calling bitcoin-cli -rpcwait getblockcount returned
JSONRPC error: preimage must be hexadecimal string (not '')

I can't reproduce locally 8)

@paveljanik
Contributor

Concept ACK
Needs some tests. Needs BIP for new OP_ANYDATA.

@jonasschnelli
Member

Concept ACK.

1.) Not sure if this requires a BIP, I guess we don't need a BIP for every contract template and I can't find the other template matching params (like OP_SMALLINTEGER) in the BIPs.

I also concept ACK the IsStandard rule for HTLC to allow blockchain-visible HTLC, though, this might require a BIP.

@sipa
Member
sipa commented Feb 26, 2016
@luke-jr
Member
luke-jr commented Feb 26, 2016

I agree IsStandard changes do not need a BIP, but it seems any transaction type supported by the reference implementation necessarily involves coordination with other software/people, and therefore should have a BIP written describing how it works.

Is there a benefit to bare HTLC over P2SH (or SegWit) HTLC? If not, it seems pointless to expand the policy to allow for it. Note that many users do not enable bare multisig (and it should probably be disabled by default).

@ebfull
ebfull commented Feb 26, 2016

I don't think initially we should make this standard outside P2SH (yet), so that's definitely a change that should be made to this PR.

This work so far allows you to "import" a preimage into CWallet (so that you can redeem the atomic swap branch of the script) but it does not persist this to disk, and I'm curious if others think it should. (I'm skeptical of making bitcoind store secrets, especially if for some use cases they are ephemeral.)

@gmaxwell
Member
@jtimon
Member
jtimon commented Feb 26, 2016

Wow, concept ACK.

@sipa
Member
sipa commented Mar 5, 2016

We should probably also wait until CSV is in, and add support for it in the constructed scripts here.

@jtimon jtimon commented on an outdated diff Mar 6, 2016
src/rpc/rawtransaction.cpp
@@ -839,3 +839,4 @@ UniValue sendrawtransaction(const UniValue& params, bool fHelp)
return hashTx.GetHex();
}
+
@jtimon
jtimon Mar 6, 2016 Member

This new line?

@gmaxwell
Member

@sipa CSV is almost in, but I don't think we should be deploying enabled generation for them until the softfork is good and settled. Maybe behind a hidden option or testnet only?

@ebfull
ebfull commented Mar 30, 2016

Additionally, supporting RIPEMD160 for ZKCPs is a must. I will try to find some time to write an arithmetic circuit for it.

@ebfull
ebfull commented Jun 7, 2016

After segwit lands (?) I will try to rebase and clean this PR up.

@btcdrak
Member
btcdrak commented Jun 26, 2016

@ebfull segwit has been merged to master and is also activated on testnet.

@gmaxwell
Member
gmaxwell commented Jul 5, 2016

CSV is active on mainnet!

@ebfull
ebfull commented Jul 18, 2016

Rebased this on to master. Now supports RIPEMD160. Switched to CSV (block denominated mode). Added some RPC tests.

It can be trivially extended to use CLTV in the RPC, I just need to come up with a solid UX for it. The same goes for "relative" time strings like "10h" or "5d." Also, still need to bring over the "preimage" display that showed in listtransactions.

I'll try to work alongside #7534 for the remaining work, including submitting a BIP.

@jl2012 jl2012 commented on the diff Aug 23, 2016
src/script/standard.cpp
@@ -54,6 +55,26 @@ bool Solver(const CScript& scriptPubKey, txnouttype& typeRet, vector<vector<unsi
// Sender provides N pubkeys, receivers provides M signatures
mTemplates.insert(make_pair(TX_MULTISIG, CScript() << OP_SMALLINTEGER << OP_PUBKEYS << OP_SMALLINTEGER << OP_CHECKMULTISIG));
+
+ // HTLC where sender requests preimage of a hash
+ {
+ const opcodetype accepted_hashers[] = {OP_SHA256, OP_RIPEMD160};
+ const opcodetype accepted_timeout_ops[] = {OP_CHECKLOCKTIMEVERIFY, OP_CHECKSEQUENCEVERIFY};
+
+ BOOST_FOREACH(opcodetype hasher, accepted_hashers) {
+ BOOST_FOREACH(opcodetype timeout_op, accepted_timeout_ops) {
+ mTemplates.insert(make_pair(TX_HTLC, CScript()
+ << hasher << OP_ANYDATA << OP_EQUAL
@jl2012
jl2012 Aug 23, 2016 Member

In the "ELSE" case any relay node may replace the top stack with anything without invalidating the tx. See related discussion at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html

@afk11
Contributor
afk11 commented Nov 23, 2016

Needs rebase

@jtimon
Member
jtimon commented Dec 27, 2016

Still needs rebase.

@ebfull
ebfull commented Dec 28, 2016

Before I rebase, I need to understand the consensus regarding preventing malleability of these scripts.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html

Multiple suggestions were made and I'm not personally qualified to pick from them.

@jl2012
Member
jl2012 commented Dec 29, 2016

@ebfull: I'd suggest this one. But you may want to discuss it on mailing list to make sure it is compatible with other implementations (if any)

OP_IF [HASHOP] <digest> OP_EQUALVERIFY <seller pubkey> OP_ELSE <num> [TIMEOUTOP] OP_DROP <buyer pubkey> OP_ENDIF OP_CHECKSIG

@da2ce7
da2ce7 commented Feb 20, 2017

@ebfull, this looks very interesting to me and many others. Would be wonderful for you can find the time to have a second look at this pull request since v0.14 has been forked off.

@zookozcash zookozcash referenced this pull request in zcash/zcash Feb 20, 2017
Open

HTLC for Bitcoin #2116

@ebfull
ebfull commented Feb 21, 2017

I will be rebasing using @jl2012's script as the foundation, and update my BIP draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment