mirror of
https://github.com/ElementsProject/lightning.git
synced 2024-11-20 10:39:49 +01:00
ba12e316f1
Only the side *accepting* the connection gives a `minumum_depth`, but both sides are supposed to wait that long: BOLT #2: ### The `funding_locked` message ... #### Requirements The sender MUST wait until the funding transaction has reached `minimum-depth` before sending this message. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2.9 KiB
2.9 KiB
| 1 | # These shouldn't happen |
|---|---|
| 2 | opening_bad_command,0x8000 |
| 3 | opening_key_derivation_failed,0x8001 |
| 4 | opening_bad_param,0x8002 |
| 5 | opening_hsm_failed,0x8003 |
| 6 | # These are due to peer. |
| 7 | opening_peer_write_failed,0x8010 |
| 8 | opening_peer_read_failed,0x8011 |
| 9 | opening_peer_bad_funding,0x8012 |
| 10 | opening_peer_bad_config,0x8013 |
| 11 | opening_peer_bad_initial_message,0x8014 |
| 12 | #include <lightningd/cryptomsg.h> |
| 13 | #include <lightningd/channel_config.h> |
| 14 | opening_init,0 |
| 15 | # Base configuration we'll offer (channel reserve will vary with amount) |
| 16 | opening_init,0,our_config,struct channel_config |
| 17 | # Minimum/maximum configuration values we'll accept |
| 18 | opening_init,36,max_to_self_delay,4 |
| 19 | opening_init,40,min_effective_htlc_capacity_msat,8 |
| 20 | opening_init,48,crypto_state,struct crypto_state |
| 21 | # Seed to generate all the keys from |
| 22 | opening_init,196,seed,struct privkey |
| 23 | # This means we offer the open. |
| 24 | opening_open,1 |
| 25 | opening_open,0,funding_satoshis,8 |
| 26 | opening_open,8,push_msat,8 |
| 27 | opening_open,16,feerate_per_kw,4 |
| 28 | opening_open,20,max_minimum_depth,4 |
| 29 | # Reply asks for txid of funding transaction. |
| 30 | opening_open_reply,101 |
| 31 | opening_open_reply,0,local_fundingkey,33 |
| 32 | opening_open_reply,0,remote_fundingkey,33 |
| 33 | # Now we give the funding txid and outnum. |
| 34 | opening_open_funding,2 |
| 35 | opening_open_funding,0,txid,struct sha256_double |
| 36 | opening_open_funding,32,txout,u16 |
| 37 | # This gives their sig, means we can broadcast tx: we're done. |
| 38 | opening_open_funding_reply,102 |
| 39 | opening_open_funding_reply,0,their_config,struct channel_config |
| 40 | opening_open_funding_reply,36,first_commit_sig,secp256k1_ecdsa_signature |
| 41 | opening_open_funding_reply,100,crypto_state,struct crypto_state |
| 42 | opening_open_funding_reply,244,revocation_basepoint,33 |
| 43 | opening_open_funding_reply,277,payment_basepoint,33 |
| 44 | opening_open_funding_reply,310,delayed_payment_basepoint,33 |
| 45 | opening_open_funding_reply,343,their_per_commit_point,33 |
| 46 | opening_open_funding_reply,376,minimum_depth,4 |
| 47 | # This means they offer the open (contains their offer packet) |
| 48 | opening_accept,3 |
| 49 | opening_accept,0,minimum_depth,4 |
| 50 | opening_accept,0,min_feerate,4 |
| 51 | opening_accept,4,max_feerate,4 |
| 52 | opening_accept,8,len,2 |
| 53 | opening_accept,10,msg,len*u8 |
| 54 | # This gives the txid of their funding tx to watch. |
| 55 | opening_accept_reply,103 |
| 56 | opening_accept_reply,0,funding_txid,struct sha256_double |
| 57 | # Acknowledge watch is in place, now can send sig. |
| 58 | opening_accept_finish,4 |
| 59 | opening_accept_finish_reply,104 |
| 60 | opening_accept_finish_reply,32,funding_txout,u16 |
| 61 | opening_accept_finish_reply,0,their_config,struct channel_config |
| 62 | opening_accept_finish_reply,36,first_commit_sig,secp256k1_ecdsa_signature |
| 63 | opening_accept_finish_reply,100,crypto_state,struct crypto_state |
| 64 | opening_accept_finish_reply,244,remote_fundingkey,33 |
| 65 | opening_accept_finish_reply,277,revocation_basepoint,33 |
| 66 | opening_accept_finish_reply,310,payment_basepoint,33 |
| 67 | opening_accept_finish_reply,343,delayed_payment_basepoint,33 |
| 68 | opening_accept_finish_reply,377,their_per_commit_point,33 |
| 69 | opening_accept_finish_reply,410,funding_satoshis,8 |
| 70 | opening_accept_finish_reply,418,push_msat,8 |