Pass htlc amount exceeded to exception

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195

[m-schmoock]

This will pass HTLC fee amounts into the "Capacity exception" so they can be catched and parsed by a upper layer plugin (i.e. lightningd/plugins#22 ). This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Rationale

currently, if a payment is made, the required HTLC onchain fees will be substracted from the spendable amount. This is a temporary hedge against the channel balance, if anything goes wrong. This is done in an opaque way, so the upper layers (like plugins) can't know the correct value that needs to be subtracted from the spendable amount, in order for the node to make the payment. For example the drain plugin has a ugly whiletry/except loop to increase gradually until the Capacity exceeded exception is not thrown any more.

[ZmnSCPxj]

This change is useful, because the required HTLC fees cannot be computed/checked in advance.

Do you mean the onchain fees? But the onchain fees are the responsibility of the forwarding node. Do you mean the Lightning forwarding fees? But the fees are computed based on route (pay simply rejects routes that exceeds the user-imposed maxfeepercent and exemptfee)

[m-schmoock]

@ZmnSCPxj

Do you mean the onchain fees?

Yes and no. Its correct the LN fees can be calculated preciesly. But, the initiating node of a payment checks if the HTLC fees can be covered and dynamically and intransparently hides this from the user. The HTLC fee is just required as a temporary hedge against the channel balance. Normally, if the payment does not fail hard, the (properly accounted for) fees are left as 'our' balance on the channel.

Edit: Practically the HTLC fees have to be substracted from the spendable amount in order for a node to bring a channel to its hard limits. This is also the core reason why a channel can be drained 'twice'.

[ZmnSCPxj]

Ah, I understand a little better, then.

Even so, would it not be better for plugin to use feerates command?

lightning/lightningd/chaintopology.c

Lines 527 to 531 in 1141243

	staticconststructjson_commandfeerates_command= {
	"feerates",
	json_feerates,
	"Return feerate estimates, either satoshi-per-kw ({style} perkw) or satoshi-per-kb ({style} perkb)."
	};

Plugin would need to do some retries possibly, as feerate may change, though.

[m-schmoock]

@ZmnSCPxj

Even so, would it not be better for plugin to use feerates command?

Yes, the feerate is just half the rent, the problem is that a plugin does not know the Bitcoin transaction nor its size that is computed by the daemon. Actually, the daemon itself does not know, as is the case on the 'second' drain the transaction is smaller, thus less fee, thus the second drain, thus the whole mess...

[m-schmoock]

@rustyrussell@cdecker@ZmnSCPxj I changed it slightly to directly tell the client about the htlc_fee in satoshi that was used. I think its finished and it can be reviewed.

I also tested this successfully in lightningd/plugins#22

(I can't remove the "work-in-progress" tag)

[cdecker]

Is there a point in avoiding having to parse the error message to extract that information? It just feels strange that we have all the information needed, smash it into a string, and then have to parse it on the caller side again.

[m-schmoock]

@cdecker there is no API for all the logic that is in channeld/full_channel.c regarding calculation of TX fee for untrimmed outputs etc. Do you know how to get and calculate this information at a plugin level? I would be glad to do so... Only thing we have is rpc.feerates but that does not help, as I cant create the correct HTLC transaction.

[rustyrussell]

Ack d502195