Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

Thanks for the info.

> you could "sponsor yourself" directly or through a cycle involving > 1
txn.

Ah I see, because the sighash flags aren't used to create the TXID. I don't
really see the problem with cycles tho. Could a cycle cause problems for
anyone? Seems like it would be a harmless waste of bytes. The
fee-sponsoring OP_VER looks good too tho.

On Wed, Jan 19, 2022 at 2:08 PM Jeremy  wrote:

> SIGHASH_BUNDLE
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
>
> By cycles I meant that if you commit to the sponsors by TXID from the
> witness, you could "sponsor yourself" directly or through a cycle involving
> > 1 txn.
>
> With OP_VER I was talking about the proposal I linked here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
> in the output space, and uses TXIDs, it is cycle-free.
>
>
> --
> @JeremyRubin 
> 
>
>
> On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud 
> wrote:
>
>> Hmm, I don't know anything about  SIGHASH_BUNDLE. The only references
>> online I can find are just mentions (mostly from you). What is
>> SIGHASH_BUNDLE?
>>
>> > unless you're binding a WTXID
>>
>> That could work, but it would exclude cases where you have a transaction
>> that has already been partially signed and someone wants to, say, only sign
>> that transaction if some 3rd party signs a transaction paying part of the
>> fee for it. Kind of a niche use case, but it would be nice to support it if
>> possible. If the transaction hasn't been signed at all yet, a new
>> transaction can just be created that includes the prospective fee-payer,
>> and if the transaction is fully signed then it has a WTXID to use.
>>
>> > then you can have fee bumping cycles
>>
>> What kind of cycles do you mean? You're saying these cycles would make it
>> less robust to reorgs?
>>
>> > OP_VER
>>
>> I assume you mean something other than pushing the version onto the stack
>> ?
>> Is that related to your fee account idea?
>>
>>
>> On Wed, Jan 19, 2022 at 1:32 AM Jeremy  wrote:
>>
>>> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
>>> like proposals.
>>>
>>> For what you're discussing, I previously proposed
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> which is similar.
>>>
>>> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
>>> that unless you're binding a WTXID (which is maybe too specific?) then you
>>> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
>>> you are acyclic.
>>>
>>> The difference between a fee account and this approach basically boils
>>> down to the impact on e.g. reorg stability, where the deposit/withdraw
>>> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
>>> transaction approach, although they are very similar.
>>>
>>> --
>>> @JeremyRubin 
>>> 
>>>
>>>
>>> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud 
>>> wrote:
>>>
 >  because you make transactions third party malleable it becomes
 possible to bundle and unbundle transactions.

 What I was suggesting doesn't make it possible to malleate someone
 else's transaction. I guess maybe my proposal of using a sighash flag
 might have been unclear. Imagine it as a script opcode that just says "this
 transaction must be mined with this other transaction" - the only
 difference being that you can use any output with any encumberance as an
 input for fee bumping. It doesn't prevent the original transaction from
 being mined on its own. So adding junk inputs would be no more of a problem
 than dust attacks already are. It would be used exactly like cpfp, except
 it doesn't spend the parent.

 I don't think what I was suggesting is as different from your proposal.
 All the problems of fee revenue optimization and feerate rules that you
 mentioned seem like they'd also exist for your proposal, or for cpfp. Let
 me know if I should clarify further.

 On Tue, Jan 18, 2022 at 8:51 PM Jeremy  wrote:

> The issue with sighash flags is that because you make transactions
> third party malleable it becomes possible to bundle and unbundle
> transactions.
>
> This means there are circumstances where an attacker could e.g. see
> your txn, and then add a lot of junk change/inputs + 25 descendants and
> strongly anchor your transaction to the bottom of the mempool.
>
> because of rbf rules requiring more fee and feerate, this means you
> have to bump across the whole package and that can get really messy.
>
> more generally speaking, 

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy]

SIGHASH_BUNDLE
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html

By cycles I meant that if you commit to the sponsors by TXID from the
witness, you could "sponsor yourself" directly or through a cycle involving
> 1 txn.

With OP_VER I was talking about the proposal I linked here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
which used OP_VER to indicate a txn sponsoring txn. Because the OP_VER is
in the output space, and uses TXIDs, it is cycle-free.


--
@JeremyRubin 



On Wed, Jan 19, 2022 at 8:52 AM Billy Tetrud  wrote:

> Hmm, I don't know anything about  SIGHASH_BUNDLE. The only references
> online I can find are just mentions (mostly from you). What is
> SIGHASH_BUNDLE?
>
> > unless you're binding a WTXID
>
> That could work, but it would exclude cases where you have a transaction
> that has already been partially signed and someone wants to, say, only sign
> that transaction if some 3rd party signs a transaction paying part of the
> fee for it. Kind of a niche use case, but it would be nice to support it if
> possible. If the transaction hasn't been signed at all yet, a new
> transaction can just be created that includes the prospective fee-payer,
> and if the transaction is fully signed then it has a WTXID to use.
>
> > then you can have fee bumping cycles
>
> What kind of cycles do you mean? You're saying these cycles would make it
> less robust to reorgs?
>
> > OP_VER
>
> I assume you mean something other than pushing the version onto the stack
> ?
> Is that related to your fee account idea?
>
>
> On Wed, Jan 19, 2022 at 1:32 AM Jeremy  wrote:
>
>> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
>> like proposals.
>>
>> For what you're discussing, I previously proposed
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>> which is similar.
>>
>> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
>> that unless you're binding a WTXID (which is maybe too specific?) then you
>> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
>> you are acyclic.
>>
>> The difference between a fee account and this approach basically boils
>> down to the impact on e.g. reorg stability, where the deposit/withdraw
>> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
>> transaction approach, although they are very similar.
>>
>> --
>> @JeremyRubin 
>> 
>>
>>
>> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud 
>> wrote:
>>
>>> >  because you make transactions third party malleable it becomes
>>> possible to bundle and unbundle transactions.
>>>
>>> What I was suggesting doesn't make it possible to malleate someone
>>> else's transaction. I guess maybe my proposal of using a sighash flag
>>> might have been unclear. Imagine it as a script opcode that just says "this
>>> transaction must be mined with this other transaction" - the only
>>> difference being that you can use any output with any encumberance as an
>>> input for fee bumping. It doesn't prevent the original transaction from
>>> being mined on its own. So adding junk inputs would be no more of a problem
>>> than dust attacks already are. It would be used exactly like cpfp, except
>>> it doesn't spend the parent.
>>>
>>> I don't think what I was suggesting is as different from your proposal.
>>> All the problems of fee revenue optimization and feerate rules that you
>>> mentioned seem like they'd also exist for your proposal, or for cpfp. Let
>>> me know if I should clarify further.
>>>
>>> On Tue, Jan 18, 2022 at 8:51 PM Jeremy  wrote:
>>>
 The issue with sighash flags is that because you make transactions
 third party malleable it becomes possible to bundle and unbundle
 transactions.

 This means there are circumstances where an attacker could e.g. see
 your txn, and then add a lot of junk change/inputs + 25 descendants and
 strongly anchor your transaction to the bottom of the mempool.

 because of rbf rules requiring more fee and feerate, this means you
 have to bump across the whole package and that can get really messy.

 more generally speaking, you could imagine a future where mempools
 track many alternative things that might want to be in a transaction.

 suppose there are N inputs each with a weight and an amount of fee
 being added and the sighash flags let me pick any subset of them. However,
 for a txn to be standard it must be < 100k bytes and for it to be consensus
 < 1mb. Now it is possible you have to solve a knapsack problem in order to
 rationally bundle this transaction out of all possibilities.

 This problem 

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Billy Tetrud]

Hmm, I don't know anything about  SIGHASH_BUNDLE. The only references
online I can find are just mentions (mostly from you). What is
SIGHASH_BUNDLE?

> unless you're binding a WTXID

That could work, but it would exclude cases where you have a transaction
that has already been partially signed and someone wants to, say, only sign
that transaction if some 3rd party signs a transaction paying part of the
fee for it. Kind of a niche use case, but it would be nice to support it if
possible. If the transaction hasn't been signed at all yet, a new
transaction can just be created that includes the prospective fee-payer,
and if the transaction is fully signed then it has a WTXID to use.

> then you can have fee bumping cycles

What kind of cycles do you mean? You're saying these cycles would make it
less robust to reorgs?

> OP_VER

I assume you mean something other than pushing the version onto the stack
?
Is that related to your fee account idea?


On Wed, Jan 19, 2022 at 1:32 AM Jeremy  wrote:

> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
> like proposals.
>
> For what you're discussing, I previously proposed
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which is similar.
>
> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
> that unless you're binding a WTXID (which is maybe too specific?) then you
> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
> you are acyclic.
>
> The difference between a fee account and this approach basically boils
> down to the impact on e.g. reorg stability, where the deposit/withdraw
> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
> transaction approach, although they are very similar.
>
> --
> @JeremyRubin 
> 
>
>
> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud 
> wrote:
>
>> >  because you make transactions third party malleable it becomes
>> possible to bundle and unbundle transactions.
>>
>> What I was suggesting doesn't make it possible to malleate someone else's
>> transaction. I guess maybe my proposal of using a sighash flag might
>> have been unclear. Imagine it as a script opcode that just says "this
>> transaction must be mined with this other transaction" - the only
>> difference being that you can use any output with any encumberance as an
>> input for fee bumping. It doesn't prevent the original transaction from
>> being mined on its own. So adding junk inputs would be no more of a problem
>> than dust attacks already are. It would be used exactly like cpfp, except
>> it doesn't spend the parent.
>>
>> I don't think what I was suggesting is as different from your proposal.
>> All the problems of fee revenue optimization and feerate rules that you
>> mentioned seem like they'd also exist for your proposal, or for cpfp. Let
>> me know if I should clarify further.
>>
>> On Tue, Jan 18, 2022 at 8:51 PM Jeremy  wrote:
>>
>>> The issue with sighash flags is that because you make transactions third
>>> party malleable it becomes possible to bundle and unbundle transactions.
>>>
>>> This means there are circumstances where an attacker could e.g. see your
>>> txn, and then add a lot of junk change/inputs + 25 descendants and strongly
>>> anchor your transaction to the bottom of the mempool.
>>>
>>> because of rbf rules requiring more fee and feerate, this means you have
>>> to bump across the whole package and that can get really messy.
>>>
>>> more generally speaking, you could imagine a future where mempools track
>>> many alternative things that might want to be in a transaction.
>>>
>>> suppose there are N inputs each with a weight and an amount of fee being
>>> added and the sighash flags let me pick any subset of them. However, for a
>>> txn to be standard it must be < 100k bytes and for it to be consensus <
>>> 1mb. Now it is possible you have to solve a knapsack problem in order to
>>> rationally bundle this transaction out of all possibilities.
>>>
>>> This problem can get even thornier, suppose that the inputs I'm adding
>>> themselves are the outputs of another txn in the mempool, now i have to
>>> track and propagate the feerates of that child back up to the parent txn
>>> and track all these dependencies.
>>>
>>> perhaps with very careful engineering these issues can be tamed. however
>>> it seems with sponsors or fee accounts, by separating the pays-for from the
>>> participates-in concerns we can greatly simplify it to something like:
>>> compute effective feerate for a txn, including all sponsors that pay more
>>> than the feerate of the base txn. Mine that txn and it's subsidies using
>>> the normal algo. If you run out of space, all subsidies are same-sized so
>>> just take the ones that pay the highest amount up until the 

Re: [Lightning-dev] Lightning RPC

[Christian Decker]

Hi Will,

> I noticed you are doing RPC stuff... I'm looking to do RPC over
> lightning itself. I started a C library called lnsocket[1], scrounged
> from clightning parts, so that I can send messages from iOS to control
> my lightning node.

Sounds interesting, and similar to commando's goals. Rusty also has a
summer of bitcoin project attempting to expose a websocket directly to
browsers in order to provide another way to communicate with your node,
and of course there's commando.

> I've got to the point with lnsocket where I can send TLVs to my node,
> and now I'm starting to think about what format the RPC commands should
> be.
>
> I noticed the commando c-lightning plugin just uses the JSON-RPC
> payload, but perhaps something more compact and rpc-friendly like grpc
> would be better... which is why this cln-grpc PR peaked my curiosity.

Yep, JSON-RPC is rather bad with binary data, and doesn't have any
concept of streaming. I personally like grpc because it ticks a lot of
boxes: secure transport over TLS, mutual authentication via mTLS,
possibility to add metadata to calls (technically prohibited by the
JSON-RPC spec) which can help us use macaroons/runes in future,
streaming support and compact binary format.

Having an IDL to describe the interface is also rather nice, even though
for cln-grpc we actually generate that from the JSON-RPC schemas, so
it's a bit less expressive than .proto files.

> I think the end goal of an RPC bolt would be super powerful, so that
> lnsocket could talk to any lightning node, but that could be further
> down the line. Choosing the right data format seemed like an important
> step in that direction. Would love to hear your thoughts on this!

I agree. Exchanging the transport layer underneath grpc doesn't change
semantics, but does unlock a number of potential use-cases. I think
either the JSON-RPC or grpc can serve as a basis for a common RPC
definition that can have any number of bindings, since we generate
conversion code to/from JSON-RPC and grpc we can transparently map them
back and forth.

> I've cc'd clightning/lightning-dev as well to see if anyone else is
> working on this or thinking about this stuff right now.

Definitely open to suggestions, comments and criticism: the cln-grpc [1]
crate is rather new, and will see a number of rebases and fixups, but
should be reviewable as is. The cln-plugin [2] crate is a bit less
well-fleshed-out, but has the core functionality needed for
cln-grpc-plugin which was the goal of this first exploration. The
cln-rpc [4] crate is also missing many RPC commands, but that's just
grunt work that I plan to tackle separately :-)

Cheers,
Christian

[1] https://github.com/ElementsProject/lightning/pull/5011
[2] https://github.com/ElementsProject/lightning/pull/5012
[3] https://github.com/ElementsProject/lightning/pull/5013
[4] https://github.com/ElementsProject/lightning/pull/5010
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev