core-lightning/openingd/opening_wire.csv
Rusty Russell 8f38a46584 lightningd: correctly store our own channel_reserve_satoshis
openingd calculates our reserve based on the channel amount (even if
we're funding, to keep the calculation in one place), but it wasn't
reporting it back to the master daemon.  We initialized it to 0 so that
valgrind wouldn't get upset, as it's part of a structure we send over
the wire.

Have openingd report back, and also initialize it to an impossible value
as extra assurance.  And remove a stray (harmless but weird) semicolon.

Reported-by: Gálli Zoltán
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-06 19:34:43 +02:00

79 lines
3.2 KiB
Plaintext

#include <common/cryptomsg.h>
#include <common/channel_config.h>
#include <common/derive_basepoints.h>
opening_init,6000
# Which network are we configured for (as index into the chainparams)?
opening_init,,network_index,u32
# Base configuration we'll offer (channel reserve will vary with amount)
opening_init,,our_config,struct channel_config
# Minimum/maximum configuration values we'll accept
opening_init,,max_to_self_delay,u32
opening_init,,min_effective_htlc_capacity_msat,u64
opening_init,,crypto_state,struct crypto_state
opening_init,,our_basepoints,struct basepoints
opening_init,,our_funding_pubkey,struct pubkey
#include <common/bip32.h>
#include <common/htlc_wire.h>
# This means we offer the open.
opening_funder,6001
opening_funder,,funding_satoshis,u64
opening_funder,,push_msat,u64
opening_funder,,feerate_per_kw,u32
opening_funder,,change_satoshis,u64
opening_funder,,change_keyindex,u32
opening_funder,,channel_flags,u8
#include <common/utxo.h>
opening_funder,,num_inputs,u16
opening_funder,,inputs,num_inputs*struct utxo
opening_funder,,bip32,struct ext_key
# This gives their sig, means we can broadcast tx: we're done.
opening_funder_reply,6101
opening_funder_reply,,their_config,struct channel_config
opening_funder_reply,,first_commit,struct bitcoin_tx
opening_funder_reply,,first_commit_sig,secp256k1_ecdsa_signature
opening_funder_reply,,crypto_state,struct crypto_state
opening_funder_reply,,revocation_basepoint,struct pubkey
opening_funder_reply,,payment_basepoint,struct pubkey
opening_funder_reply,,htlc_basepoint,struct pubkey
opening_funder_reply,,delayed_payment_basepoint,struct pubkey
opening_funder_reply,,their_per_commit_point,struct pubkey
opening_funder_reply,,minimum_depth,u32
opening_funder_reply,,remote_fundingkey,struct pubkey
opening_funder_reply,,funding_txid,struct bitcoin_txid
opening_funder_reply,,feerate_per_kw,u32
opening_funder_reply,,our_channel_reserve_satoshis,u64
# This means they offer the open (contains their offer packet)
opening_fundee,6003
opening_fundee,,minimum_depth,u32
opening_fundee,,min_feerate,u32
opening_fundee,,max_feerate,u32
opening_fundee,,len,u16
opening_fundee,,msg,len*u8
# This gives their txid and info, means we can send funding_signed: we're done.
opening_fundee_reply,6103
opening_fundee_reply,,their_config,struct channel_config
opening_fundee_reply,,first_commit,struct bitcoin_tx
opening_fundee_reply,,first_commit_sig,secp256k1_ecdsa_signature
opening_fundee_reply,,crypto_state,struct crypto_state
opening_fundee_reply,,revocation_basepoint,struct pubkey
opening_fundee_reply,,payment_basepoint,struct pubkey
opening_fundee_reply,,htlc_basepoint,struct pubkey
opening_fundee_reply,,delayed_payment_basepoint,struct pubkey
opening_fundee_reply,,their_per_commit_point,struct pubkey
opening_fundee_reply,,remote_fundingkey,struct pubkey
opening_fundee_reply,,funding_txid,struct bitcoin_txid
opening_fundee_reply,,funding_txout,u16
opening_fundee_reply,,funding_satoshis,u64
opening_fundee_reply,,push_msat,u64
opening_fundee_reply,,channel_flags,u8
opening_fundee_reply,,feerate_per_kw,u32
# The (encrypted) funding signed message: send this and we're committed.
opening_fundee_reply,,msglen,u16
opening_fundee_reply,,funding_signed_msg,msglen*u8
opening_fundee_reply,,our_channel_reserve_satoshis,u64