mirror of
https://github.com/lightningnetwork/lnd.git
synced 2025-11-10 14:17:56 +01:00
sqldb/sqlc: add message and channe flags to channel_policies table
We need to explicitly store the entire bitfield types since we may have channel_updates with bitfields containing bits we just dont need or understand but we still need to store the entire bitfield so that the reconstructed announcement remains valid. This commit only adds the new columns but does not use them yet. NOTE: this is ok since the migration adding this schema is not available in the production build yet.
This commit is contained in:
@@ -228,7 +228,7 @@ CREATE TABLE IF NOT EXISTS channel_policies (
|
||||
-- The DB ID of the node that created the policy update.
|
||||
node_id BIGINT NOT NULL REFERENCES nodes(id) ON DELETE CASCADE,
|
||||
|
||||
-- The number of blocks that the node will subtrace from the expiry
|
||||
-- The number of blocks that the node will subtract from the expiry
|
||||
-- of an incoming HTLC.
|
||||
timelock INTEGER NOT NULL,
|
||||
|
||||
@@ -266,6 +266,25 @@ CREATE TABLE IF NOT EXISTS channel_policies (
|
||||
-- charge for incoming HTLCs.
|
||||
inbound_fee_rate_milli_msat BIGINT,
|
||||
|
||||
-- A bitfield used to provide extra details about the message. This is
|
||||
-- nullable since for later protocol versions, this might not be
|
||||
-- present. Even though we explicitly store some details from the
|
||||
-- message_flags in other ways (for example, max_htlc_msat being not
|
||||
-- null means that bit 0 of the message_flags is set), we still store
|
||||
-- the full message_flags field so that we can reconstruct the original
|
||||
-- announcement if needed, even if the bitfield contains bits that we
|
||||
-- don't use or understand.
|
||||
message_flags SMALLINT CHECK (message_flags >= 0 AND message_flags <= 255),
|
||||
|
||||
-- A bitfield used to provide extra details about the update. This is
|
||||
-- nullable since for later protocol versions, this might not be present.
|
||||
-- Even though we explicitly store some details from the channel_flags in
|
||||
-- other ways (for example, the disabled field's value is derived directly
|
||||
-- from the channel_flags), we still store the full bitfield so that we
|
||||
-- can reconstruct the original announcement if needed, even if the
|
||||
-- bitfield contains bits that we don't use or understand.
|
||||
channel_flags SMALLINT CHECK (channel_flags >= 0 AND channel_flags <= 255),
|
||||
|
||||
-- The signature of the channel update announcement.
|
||||
signature BLOB
|
||||
);
|
||||
|
||||
Reference in New Issue
Block a user