Nostr notes by Johan Torås Halseth [ARCHIVE]

📅 Original date posted:2023-09-29 🗒️ Summary of this ...

2023-10-03T21:44:19Z

In reply to nevent1q…k6vn
_________________________

📅 Original date posted:2023-09-29
🗒️ Summary of this message: The author has implemented the MATT challenge protocol in Bitcoin Script and provides a detailed description and instructions on how to run the code. They propose using OP_CHECKCONTRACTVERIFY and OP_CAT opcodes to trace program execution and challenge computations. The next steps involve creating a generic framework for compiling high-level programs into MATT-compatible Bitcoin Scripts.
📝 Original message:
Hi, all!

I've been working on an implementation of the original MATT challenge
protocol[0], with a detailed description of how we go from a
"high-level arbitrary program" to something that can be verified
on-chain in Bitcoin Script.

You can find the write-up here, which also includes instructions of
how to run the code and inspect the transactions using a local block
explorer: https://github.com/halseth/mattlab/blob/main/docs/challenge.md

TLDR; Using the proposed opcode OP_CHECKCONTRACTVERIFY and OP_CAT, we
show to trace execution of the program `multiply` [1] and challenge
this computation in O(n logn) on-chain transactions:

func multiply(x int) int {
i := 0
while {
if i < 8 {
x = x + x
i = i + 1
} else {
break
}
}
return x
}

Next steps would be to make this a generic framework with tools to
automatically compile arbitrary high-level programs down to
MATT-compatible Bitcoin Scripts.

All feedback appreciated!

- Johan

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021205.html

📅 Original date posted:2023-08-07 🗒️ Summary of this ...

2023-08-08T14:20:52Z

In reply to nevent1q…t60e
_________________________

📅 Original date posted:2023-08-07
🗒️ Summary of this message: The sender thanks Salvatore for the update on taptree verification and offers suggestions on the proposal, including opcode parameter ordering and the deferred amount check.
📝 Original message:
Hi, Salvatore.

Thanks for the update! I like the fact that taptree verification now
can be done on both input and outputs, and having them be symmetrical
also makes the learning curve a bit easier.

I have implemented the updated opcodes in btcd (very rough
implementation)]1] as well as updated the example scripts for
simulating CTV[2] and Coinpools[3].

>From doing this I would again like to offer some suggestions on the proposal.

- For the opcode parameter ordering, it feels unnatural for the two
tweaks (data, taptree) to be separated by the internal key. A more
natural ordering of parameters IMO would be (of course this is all
subjective):
<data> <taptree> <internalkey> <index> <flags> OP_CCV.

If you disagree, I would love some rationale for the ordering you
chose! (looks like you also changed it again after your last post?).

- The deferred amount check seems a bit out of place, and insufficient
at least for the use cases I had in mind. They work well in a vault
setting, where you want to consolidate many outputs into a single new
one, and in 1-input-1-output settings where you want to preserve the
amount exactly. However, for coinpools, CTV with more than one output
and other interesting contracts where you want to split or combine
amounts it won't be powerful enough.

I'm wondering what other use cases you had in mind for the deferred
output amount check? Maybe I have missed something, but if not it
would perhaps be better to leave out the amount preservation check, or
go the extra mile and propose a more powerful amount introspection
machinery.

Cheers,
Johan

[1] - https://github.com/halseth/btcd/pull/1
[2] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a1b7247cadf/examples/matt/ctv2/README.md
[3] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a1b7247cadf/examples/matt/coinpool/README.md

On Sun, Jul 30, 2023 at 11:51 PM Salvatore Ingala via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I have put together a first complete proposal for the core opcodes of
> MATT [1][2].
> The changes make the opcode functionally complete, and the
> implementation is revised and improved.
>
> The code is implemented in the following fork of the
> bitcoin-inquisition repo:
>
> https://github.com/Merkleize/bitcoin/tree/checkcontractverify
>
> Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
> previous early demo for vaults [3].
>
> Please check out the diff [4] if you are interested in the
> implementation details. It includes some basic functional tests for
> the main cases of the opcode.
>
> ## Changes vs the previous draft
>
> These are the changes compared to the initial incomplete proposal:
> - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode
> OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows
> to specify if the opcode operates on an input or an output.
> This also allows inspection of other inputs, that was not possible
> with the original opcodes.
> - For outputs, the default behavior is to have the following deferred
> checks mechanism for amounts: all the inputs that have a CCV towards
> the same output, have their input amounts summed, and that act as a
> lower bound for that output's amount.
> A flag can disable this behavior. [*]
> - A number of special values of the parameters were defined in order
> to optimize for common cases, and add some implicit introspection.
> - The order of parameters is modified (particularly, <data> is at the
> bottom of the arguments, as so is more natural when writing Scripts).
>
> ## Semantics
>
> The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:
>
> <data>, <index>, <pk>, <taptree>, <flags>
>
> The core logic of the opcode is as follows:
>
> "Check if the <index>-th input/output's scriptPubKey is a P2TR
> whose public key is obtained from <pk>, (optionally) tweaked with
> <data>, (optionally) tap-tweaked with <taptree>".
>
> The following are special values of the parameters:
>
> - if <pk> is empty, it is replaced with a fixed NUMS point. [**]
> - if <pk> is -1, it is replaced with the current input's taproot
> internal key.
> - if <index> is -1, it is replaced with the current input's index.
> - if <data> is empty, the data tweak is skipped.
> - if <taptree> is empty, the taptweak is skipped.
> - if <taptree> is -1, it is replaced with the current input's root
> of the taproot merkle tree.
>
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.
>
> Finally, if both the flags CCV_FLAG_CHECK_INPUT and
> CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent:
> - Add the current input's amount to the <index>-th output's bucket.
>
> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).
>
> ## Comment
>
> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.
>
> With this new opcode, the full generality of MATT (including the fraud
> proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY
> and OP_CAT.
> However, additional opcodes (and additional introspection) would
> surely benefit some applications.
>
> I look forward to your comments, and to start drafting a BIP proposal.
>
> Best,
> Salvatore Ingala
>
>
> [*] - Credits go to James O'Beirne for this approach, taken from his
> OP_VAULT proposal. I cherry-picked the commit containing the
> Deferred Checks framework.
> [**] - The same NUMS point suggested in BIP-0341 was used.
>
>
> References:
>
> [1] - https://merkle.fun/
> [2] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
> [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
> [4] - https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-11-07 📝 Original message: Hi ...

2023-06-09T13:07:16Z

In reply to nevent1q…jq6c
_________________________

📅 Original date posted:2022-11-07
📝 Original message:
Hi Laolu,

Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.

And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems indeed to be a prerequisite for
making the scheme safe in terms of re-orgs and asynchronicity.

I do think the scheme itself is sound though (maybe not off-chain, see
below): it prevents double spending and as long as the clients adhere
to the "rule" of not sending to a spent UTXO you'll be fine (if not
your tokens will be burned, the same way as if you don't satisfy the
Taro script when spending).

Thinking more about the examples you gave, I think you are right it
won't easily be compatible with LN channels though:
If you want to refill an existing channel with tokens, you need the
channel counterparties to start signing new commitments that include
spending the newly sent tokens. A problem arises however, if the
channel is force-closed with a pre-existing commitment from before the
token transfer took place. Since this commitment will be spending the
funding UTXO, but not the new tokens, the tokens will be burned. And
that seems to be harder to deal with (Eltoo style channels could be an
avenue to explore, if one could override the broadcasted commitment).

Tl;dr: I think you're right, the scheme is not compatible with LN.

- Johan

On Sat, Nov 5, 2022 at 1:36 AM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Johan,
>
> I haven't really been able to find a precise technical explanation of the
> "utxo teleport" scheme, but after thinking about your example use cases a
> bit, I don't think the scheme is actually sound. Consider that the scheme
> attempts to target transmitting "ownership" to a UTXO. However, by the time
> that transaction hits the chain, the UTXO may no longer exist. At that
> point, what happens to the asset? Is it burned? Can you retry it again? Does
> it go back to the sender?
>
> As a concrete example, imagine I have a channel open, and give you an
> address to "teleport" some additional assets to it. You take that addr, then
> make a transaction to commit to the transfer. However, the block before you
> commit to the transfer, my channel closes for w/e reason. As a result, when
> the transaction committing to the UTXO (blinded or not), hits the chain, the
> UTXO no longer exists. Alternatively, imagine the things happen in the
> expected order, but then a re-org occurs, and my channel close is mined in a
> block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
> used as a serialization point, the scheme seems to lack a necessary total
> ordering to ensure safety.
>
> If we look at Taro's state transition model in contrast, everything is fully
> bound to a single synchronization point: a normal Bitcoin transaction with
> inputs consumed and outputs created. All transfers, just like Bitcoin
> transactions, end up consuming assets from the set of inputs, and
> re-creating them with a different distribution with the set of outputs. As a
> result, Taro transfers inherit the same re-org safety traits as regular
> Bitcoin transactions. It also isn't possible to send to something that won't
> ultimately exist, as sends create new outputs just like Bitcoin
> transactions.
>
> Taro's state transition model also means anything you can do today with
> Bitcoin/LN also apply. As an example, it would be possible for you to
> withdrawn from your exchange into a Loop In address (on chain to off chain
> swap), and have everything work as expected, with you topping off your
> channel. Stuff like splicing, and other interactive transaction construction
> schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.
>
> Ignoring the ordering issue I mentioned above, I don't think this is a great
> model for anchoring assets in channels either. With Taro, when you make the
> channel, you know how many assets are committed since they're all committed
> to in the funding output when the channel is created. However, let's say we
> do teleporting instead: at which point would we recognize the new asset
> "deposits"? What if we close before a pending deposits confirms, how can one
> regain those funds? Once again you lose the serialization of events/actions
> the blockchain provides. I think you'd also run into similar issues when you
> start to think about how these would even be advertised on a hypothetical
> gossip network.
>
> I think one other drawback of the teleport model iiuc is that: it either
> requires an OP_RETURN, or additional out of band synchronization to complete
> the transfer. Since it needs to commit to w/e hash description of the
> teleport, it either needs to use an OP_RETURN (so the receiver can see the
> on chain action), or the sender needs to contact the receiver to initiate
> the resolution of the transfer (details committed to in a change addr or
> w/e).
>
> With Taro, sending to an address creates an on-chain taproot output just
> like sending to a P2TR address. The creation of the output directly creates
> the new asset anchor/output as well, which allows the receiver to look for
> that address on chain just like a normal on chain transaction. To 3rd party
> observers, it just looks like a normal P2TR transfer. In order to finalize
> the receipt of the asset, the receiver needs to obtain the relevant
> provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
> service keyed by the input outpoint and output index. In short, the send
> process is fully async, with the sender and receiver using the blockchain
> itself as a synchronization point like a normal Bitcoin wallet.
>
> -- Laolu

📅 Original date posted:2022-11-03 📝 Original message: Hi, I ...

2023-06-09T13:07:15Z

In reply to nevent1q…n2yu
_________________________

📅 Original date posted:2022-11-03
📝 Original message:
Hi,

I wanted to chime in on the "teleport" feature explained by Ruben, as I
think exploring something similar for Taro could be super useful in an LN
setting.

In today's Taro, to transfer tokens you have to spend a UTXO, and present a
proof showing that there are tokens committed to in the output you are
spending. Let's say this UTXO is 'utxo:0'.

In contrast, to spend teleported tokens, you would still spend utxo:0, but
you would only have to present a proof that _some txout_ on-chain have
committed tokens to utxo:0.

As Ruben points out, this makes it possible to send tokens to an already
spent TXO, essentially burning the tokens.

However, it opens up some exciting possibilities IMO. You can in essence
use this to "re-fill" UTXOs with tokens, which is very interesting for LN
channels:

- You could "add" tokens to your already open channels. The only thing
needed is for the channel participants to be presented the proof that
tokens were sent to the funding output, and they can update their
commitment transaction to start spending these tokens.
- You can "top-up" all your channels in a single on-chain tx. Since a
single output can commit tokens to several UTXOs, you could with a single
on-chain transaction add tokens to many channels without opening and
closing them.

RGB also has the ability to "blind" the UTXO that tokens get teleported to,
hiding the recipient UTXO. This is cool, since I could withdraw tokens from
an exchange directly into my LN channel, without revealing my channel UTXO.

I found the explanation of the teleport feature in this blog post pretty
good:
https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059

- Johan

On Sun, Apr 10, 2022 at 6:52 PM Ruben Somsen <rsomsen at gmail.com> wrote:

> Hi Laolu,
>
> >happy to hear that someone was actually able to extract enough details
> from the RGB devs/docs to be able to analyze it properly
>
> Actually, even though I eventually puzzled everything together, this did
> not go well for me either. There is a ton of documentation, but it's a maze
> of unhelpful details, and none of it clearly maps out the fundamental
> design. I was also disappointed by the poor response I received when asking
> questions, and I ended up getting chastised for helping others understand
> it and pointing out potential flaws[1][2][3].Given my experience, I think
> the project is not in great shape, so the decision to rebuild from scratch
> seems right to me.
>
> That said, in my opinion the above should not factor into the decision of
> whether RGB should be credited in the Taro documentation. The design
> clearly precedes (and seems to have inspired) Taro, so in my opinion this
> should be acknowledged. Also, the people that are responsible for the
> current shape of RGB aren't the people who originated the idea, so it would
> not be fair to the originators either (Peter Todd, Alekos Filini, Giacomo
> Zucco).
>
> >assets can be burnt if a user doesn't supply a valid witness
>
> I am in agreement with what you said, but it is not clear to me whether we
> are on the same page. What I tried to say was that it does not make sense
> to build scripting support into Taro, because you can't actually do
> anything interesting with it due to this limitation. The only type of smart
> contract you can build is one where you limit what the owner (as defined by
> Bitcoin's script) can do with their own Taro tokens, or else he will burn
> them – not very useful. Anything involving a conditional transfer of
> ownership to either A or B (i.e. any meaningful type of script) won't work.
> Do you see what I mean, or should I elaborate further?
>
> >TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions
> at the Bitcoin level, without Bitcoin explicitly needing to be aware
>
> That is conceptually quite interesting. So theoretically you could get
> Bitcoin covenants to enforce certain spending conditions on Taro assets.
> Not sure how practical that ends up being, but intriguing to consider.
>
> >asset issuer to do a "re-genesis"
>
> Yes, RGB suggested the same thing, and this can work under some
> circumstances, but note that this won't help for tokens that aim to have a
> publicly audited supply, as the proof that a token was legitimately
> re-issued is the history of the previous token (so you'd actually be making
> things worse, as now everyone has to verify it). And of course the idea
> also requires the issuer to be active, which may not always be the case.
>
> >I'm not familiar with how the RGB "teleport" technique works [...] Can
> you point me to a coherent explanation of the technique
>
> To my knowledge no good explanation exists. "Teleporting" is just what I
> thought was a good way of describing it. Basically, in your design when
> Alice wants to send a Taro token to Bob, Alice has to spend her own output,
> make a new output for Bob, and make a change output for herself. Inside the
> Taro tree you'll then point to the index of Bob's output in order to assign
> the tokens to his new output. Instead of pointing to the index, you could
> point to the outpoint (txid, index) of an existing UTXO owned by Bob, thus
> "teleporting" the Taro tokens to this UTXO. This saves on-chain space, as
> now you don't have to create a new output for Bob (but now you have to
> ensure Bob doesn't spend from this output while you're simultaneously
> sending tokens to it, as I mentioned in my previous post, as this would
> destroy the tokens).
>
> The above also reminds me of another potential issue which you need to be
> aware of, if you're not already. Similar to my comment about how the
> location of the Taro tree inside the taproot tree needs to be deterministic
> for the verifier, the output in which you place the Taro tree also needs to
> be. If it's not, then you can commit to a different Taro tree in each
> output of the transaction, allowing you to secretly fork the history.
>
> Hope this helps.
>
> Cheers,
> Ruben
>
> [1] https://twitter.com/SomsenRuben/status/1397267261619064836
> [2] https://twitter.com/SomsenRuben/status/1397559406565462017
> [3] https://twitter.com/afilini/status/1397484341236797441
>
> On Fri, Apr 8, 2022 at 7:48 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> (this might be a double post as it ran into the size limit)
>>
>> Hi Ruben,
>>
>> Thanks! I don't really consider things final until we have a good set of
>> test
>> vectors in the final set, after which we'd start to transition the set of
>> documents beyond the draft state.
>>
>> > Seeing as there's a large amount of overlap with RGB, a protocol which
>> I have
>> > examined quite extensively, I believe some of the issues I uncovered in
>> that
>> > project also apply here.
>>
>> I'm happy to hear that someone was actually able to extract enough
>> details from
>> the RGB devs/docs to be able to analyze it properly! In the past I tried
>> to ask
>> their developers questions about how things like transfers worked[1][2],
>> but it
>> seemed either people didn't know, or they hadn't finished the core design
>> (large TBD sections) as they were working on adding other components to
>> create
>> a "new new Internet".
>>
>> > Furthermore, the Taro script is not enforced by Bitcoin, meaning those
>> who
>> > control the Bitcoin script can always choose to ignore the Taro script
>> and
>> > destroy the Taro assets as a result.
>>
>> This is correct, as a result in most contexts, an incentive exists for the
>> holder of an asset to observe the Taro validation rules as otherwise,
>> their
>> assets are burnt in the process from the PoV of asset verifiers. In the
>> single
>> party case things are pretty straight forward, but more care needs to be
>> taken
>> in cases where one attempts to express partial application and permits
>> anyone
>> to spend a UTXO in question.
>>
>> By strongly binding all assets to Bitcoin UTXOs, we resolve issues
>> related to
>> double spending or duplicate assets, but needs to mind the fact that
>> assets can
>> be burnt if a user doesn't supply a valid witness. There're likely ways
>> to get
>> around this by lessening the binding to Bitcoin UTXO's, but then the
>> system
>> would need to be able to collect, retain and order all the set of possible
>> spends, essentially requiring a parallel network. The core of the system
>> as it
>> stands today is pretty simple (which was an explicit design goal to avoid
>> getting forever distracted by the large design space), with a minimal
>> implementation being relatively compact given all the Bitcoin
>> context/design
>> re-use.
>>
>> Also one cool trait of the way commitments are designed is that the Taro
>> commitment impact the final derived taproot output key. As a result,
>> potential
>> Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to
>> further
>> _bind_ Taro transitions at the Bitcoin level, without Bitcoin explicitly
>> needing to be aware of the Taro rules. In short, covenants can allow
>> Bitcoin
>> Script to bind Taro state transitions, without any of the logic bleeding
>> over,
>> as the covenant just checks for a certain output key, which is a function
>> of
>> the Taro commitment being present.
>>
>> > There are two possible designs here: a.) The token history remains
>> separate –
>> > Dave receives Alice's 2 tokens, Bob's tokens are split and he receives
>> 2 (or
>> > 3 from Bob 1 from Alice). b.) The token history gets merged – Dave
>> receives
>> > 4 tokens (linking the new output with both Alice and Bob's history).
>>
>> Mechanically, with respect to the way the change/UTXOs work in the
>> system, both
>> are expressible: Dave can chose to merge them into a single UTXO (with the
>> appropriate witnesses included for each of them), or Dave can keep them
>> distinct in the asset tree. You're correct in that asset issuers may opt
>> to
>> issue assets in denominations vs allowing them to be fully divisible.
>> Ultimately, the compatibility with the LN layer will be the primary way
>> to keep
>> asset histories compressed, without relying on another trust model, or
>> relying
>> on the incentive of an asset issuer to do a "re-genesis" which would
>> effectively re-create assets in a supply-preserving manner (burn N units,
>> then
>> produce a new genesis outpoint for N units). Alternatively,
>> implementations can
>> also chose to utilize a checkpointing system similar to what some Bitcoin
>> full
>> node clients do today.
>>
>> > is that you end up with a linked transaction graph, just like in
>> Bitcoin
>>
>> This is correct, the protocol doesn't claim to achieve better privacy
>> guarantees than the base chain. However inheriting this transaction graph
>> model
>> imo makes it easier for existing Bitcoin developers to interact with the
>> system, and all the data structures are very familiar tooling wise.
>> However any
>> privacy enhancing protocol used for on-chain top-level Bitcoin UTXOs can
>> also
>> be applied to Taro, so people can use things like coinswap and coinjoin,
>> along
>> with LN to shed prior coin lineages.
>>
>> > This implies the location of the Taro tree inside the taproot tree is
>> not
>> > fixed. What needs to be prevented here is that a taproot tree contains
>> more
>> > than one Taro tree, as that would enable the owner of the commitment to
>> show
>> > different histories to different people.
>>
>> Great observation, I patched a similar issue much earlier in the design
>> process
>> by strongly binding all signatures to a prevOut super-set (so the outpoint
>> along with the unique key apth down into the tree), which prevents
>> duplicating
>> the asset across outputs, as signature verification would fail.
>>
>> In terms of achieving this level of binding within the Taro tree itself,
>> I can
>> think of three options:
>>
>> 1. Require the Taro commitment to be in the first/last position within
>> the
>> (fully sorted?) Tapscript tree, and also require its sibling to be the
>> hash
>> of some set string (all zeroes or w/e). We'd require the sibling to the
>> empty
>> as the tapscript hashes are sorted before hashing so you sort of lose
>> that
>> final ordering information.
>>
>> 2. Include the position of the Taro commitment within the tapscript tree
>> within the sighash digest (basically the way the single input in the
>> virtual
>> transaction is created from the TLV structure).
>>
>> 3. Include the position of the Taro commitment within the tapscript
>> tree as
>> part of the message that's hashed to derive asset IDs.
>>
>> AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of
>> the
>> canonical history invalid, and #2 minds hte asset ID to the initial
>> position
>> meaning you can track a canonical lineage from the very start.
>>
>> > Finally, let me conclude with two questions. Could you clarify the
>> purpose of
>> > the sparse merkle tree in your design?
>>
>> Sure, it does a few things:
>>
>> * Non-inclusion proofs so I can do things like prove to your I'm no
>> longer
>> committing to my 1-of-1 holographic beefzard card when we swap.
>>
>> * The key/tree structure means that the tree is history independent,
>> meaning
>> that if you and I insert the same things into the tree in a different
>> order, we'll get the same root hash. This is useful for things like
>> tracking all the issuance events for a given asset, or allowing two
>> entities to sync their knowledge/history of a single asset, or a set
>> of
>> assets.
>>
>> * Each asset/script mapping to a unique location within the tree means
>> it's
>> easy to ensure uniqueness of certain items/commitments (not possible
>> to
>> commit to the same asset ID twice in the tree as an example).
>>
>> * The merkle-sum trait means I that validation is made simpler, as you
>> just
>> check that the input+output commitment sum to the same value, and I
>> can
>> also verify that if we're swapping, then you aren't committing to more
>> units that exist (so I make sure I don't get an invalid split).
>>
>> > And the second question – when transferring Taro token ownership from
>> one
>> > Bitcoin UTXO to another, do you generate a new UTXO for the recipient
>> or do
>> > you support the ability to "teleport" the tokens to an existing UTXO
>> like how
>> > RGB does it? If the latter, have you given consideration to timing
>> issues
>> > that might occur when someone sends tokens to an existing UTXO that
>> > simultaneously happens to get spent by the owner?
>>
>> So for interactive transfers, the UTXOs generated as just the ones part
>> of the
>> MIMO transaction. When sending via the address format, a new non-dust
>> output is
>> created which holds the new commitment, and uses an internal key provided
>> by
>> the receiver, so only they can move the UTXO. Admittedly, I'm not
>> familiar with
>> how the RGB "teleport" technique works, I checked out some slide decks a
>> while
>> back, but they were mostly about all the new components they were
>> creating and
>> their milestone of 1 million lines of code. Can you point me to a coherent
>> explanation of the technique? I'd love to compare/contrast so we can
>> analyze
>> the diff tradeoffs being made here.
>>
>> Thanks for an initial round of feedback/analysis, I'll be updating the
>> draft
>> over the next few days to better spell things out and particularly that
>> commitment/sighash uniqueness trait.
>>
>> -- Laolu
>>
>> [1]:
>> https://twitter.com/roasbeef/status/1330654936074371073?s=20&t=feV0kWAjJ6MTQlFm06tSxA
>> [2]:
>> https://twitter.com/roasbeef/status/1330692571736117249?s=20&t=feV0kWAjJ6MTQlFm06tSxA
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221103/a53b523d/attachment-0001.html>;

📅 Original date posted:2022-10-28 📝 Original message: Hi, ...

2023-06-09T13:07:09Z

In reply to nevent1q…9n89
_________________________

📅 Original date posted:2022-10-28
📝 Original message:
Hi, Matt.

You're correct, I made the suggestion mainly because it would open up for
PTLCs (or other future features) in today's channels.

Having the existing network close and reopen new channels would really slow
the adoption of new channel features I reckon.

And I don't think it adds much complexity compared to the adapter approach.

- Johan

On Thu, Oct 27, 2022 at 4:54 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> I’m not sure I understand this - is there much reason to want taproot
> commitment outputs? I mean they’re cool, and witnesses are a bit smaller,
> which is nice I guess, but they’re not providing materially new features,
> AFAIU. Taproot funding, on the other hand, provides a Bitcoin-wide privacy
> improvement as well the potential future ability of channel participants to
> use multisig for their own channel funds transparently.
>
> Sure, if we’re doing taproot funding outputs we should probably just do it
> for the commitment outputs as well, because why not (and it’s a prereq for
> PTLCs). But trying to split them up seems like added complexity “just
> because”? I suppose it tees us up for eventual PTLC support in todays
> channels, but we can also consider that separately when we get to that
> point, IMO.
>
> Am I missing some important utility of taproot commitment transaction
> outputs?
>
> Matt
>
> On Oct 27, 2022, at 02:17, Johan Torås Halseth <johanth at gmail.com> wrote:
>
>
> Hi, Laolu.
>
> I think it could be worth considering dividing the taprootyness of a
> channel into two:
> 1) taproot funding output
> 2) taproot commitment outputs
>
> That way we could upgrade existing channels only on the commitment level,
> not needing to close or re-anchor the channels using an adapter in order to
> get many of the taproot benefits.
>
> New channels would use taproot multisig (musig2) for the funding output.
>
> This seems to be less disruptive to the existing network, and we could get
> features enabled by taproot to larger parts of the network quicker. And to
> me this seems to carry less complexity (and closing fees) than an adapter.
>
> One caveat is that this wouldn't work (I think) for Eltoo channels, as the
> funding output would not be plain multisig anymore.
>
> - Johan
>
> On Sat, Mar 26, 2022 at 1:27 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Laolu,
>>
>> Thanks for the proposal, quick feedback.
>>
>> > It *is* still the case that _ultimately_ the two transactions to close
>> the
>> > old segwit v0 funding output, and re-open the channel with a new segwit
>> v1
>> > funding output are unavoidable. However this adapter commitment lets
>> peers
>> > _defer_ these two transactions until closing time.
>>
>> I think there is one downside coming with adapter commitment, which is
>> the uncertainty of the fee overhead at the closing time. Instead of closing
>> your segwit v0 channel _now_ with known fees, when your commitment is empty
>> of time-sensitive HTLCs, you're taking the risk of closing during fees
>> spikes, due a move triggered by your counterparty, when you might have
>> HTLCs at stake.
>>
>> It might be more economically rational for a LN node operator to pay the
>> upgrade cost now if they wish to benefit from the taproot upgrade early,
>> especially if long-term we expect block fees to increase, or wait when
>> there is a "normal" cooperative closing.
>>
>> So it's unclear to me what the economic gain of adapter commitments ?
>>
>> > In the remainder of this mail, I'll describe an alternative
>> > approach that would allow upgrading nearly all channel/commitment
>> related
>> > values (dust limit, max in flight, etc), which is inspired by the way
>> the
>> > Raft consensus protocol handles configuration/member changes.
>>
>> Long-term, I think we'll likely need a consensus protocol anyway for
>> multi-party constructions (channel factories/payment pools). AFAIU this
>> proposal doesn't aim to roll out a full-fledged consensus protocol *now*
>> though it could be wise to ensure what we're building slowly moves in this
>> direction. Less critical code to maintain across bitcoin
>> codebases/toolchains.
>>
>> > The role of the signature it to prevent "spoofing" by one of the parties
>> > (authenticate the param change), and also it serves to convince a party
>> that
>> > they actually sent a prior commitment propose update during the
>> > retransmission phase.
>>
>> What's the purpose of data origin authentication if we assume only
>> two-parties running over Noise_XK ?
>>
>> I think it's already a security property we have. Though if we think
>> we're going to reuse these dynamic upgrades for N counterparties
>> communicating through a coordinator, yes I think it's useful.
>>
>> > In the past, when ideas like this were brought up, some were concerned
>> that
>> > it wouldn't really be possible to do this type of updates while existing
>> > HTLCs were in flight (hence some of the ideas to clear out the
>> commitment
>> > beforehand).
>>
>> The dynamic upgrade might serve in an emergency context where we don't
>> have the leisury to wait for the settlement of the pending HTLCs. The
>> timing of those ones might be beyond the coordination of link
>> counterparties. Thus, we have to allow upgrade of non-empty commitments
>> (and if there are undesirable interferences between new commitment types
>> and HTLCs/PTLCs present, deal case-by-case).
>>
>> Antoine
>>
>> Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com> a
>> écrit :
>>
>>> Hi y'all,
>>>
>>> ## Dynamic Commitments Retrospective
>>>
>>> Two years-ish ago I made a mailing list post on some ideas re dynamic
>>> commitments [1], and how the concept can be used to allow us to upgrade
>>> channel types on the fly, and also remove pesky hard coded limits like
>>> the
>>> 483 HTLC in-flight limit that's present today. Back then my main target
>>> was
>>> upgrading all the existing channels over to the anchor output commitment
>>> variant, so the core internal routing network would be more resilient in
>>> a
>>> persistent high fee environment (which hasn't really happened over the
>>> past
>>> 2 years for various reasons tbh). Fast forward to today, and with taproot
>>> now active on mainnet, and some initial design work/sketches for
>>> taproot-native channels underway, I figure it would be good to bump this
>>> concept as it gives us a way to upgrade all 80k+ public channels to
>>> taproot
>>> without any on chain transactions.
>>>
>>> ## Updating Across Witness Versions w/ Adapter Commitments
>>>
>>> In my original mail, I incorrectly concluded that the dynamic commitments
>>> concept would only really work within the confines of a "static"
>>> multi-sig
>>> output, meaning that it couldn't be used to help channels upgrade to
>>> future
>>> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj,
>>> outlined a
>>> way to achieve this in practice. At a high level he proposes an "adaptor
>>> commitment" (similar to the kickoff transaction in eltoo/duplex), which
>>> is
>>> basically an upgrade transaction that spends one witness version type,
>>> and
>>> produces an output with the next (upgraded) type. In the context of
>>> converting from segwit v0 to v1 (taproot), two peers would
>>> collaboratively
>>> create a new adapter commitment that spends the old v0 multi-sig output,
>>> and
>>> produces a _new_ v1 multi-sig output. The new commitment transaction
>>> would
>>> then be anchored using this new output.
>>>
>>> Here's a rough sequence diagram of the before and after state to better
>>> convey the concept:
>>>
>>> * Before: fundingOutputV0 -> commitmentTransaction
>>>
>>> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
>>> commitmentTransaction
>>>
>>> It *is* still the case that _ultimately_ the two transactions to close
>>> the
>>> old segwit v0 funding output, and re-open the channel with a new segwit
>>> v1
>>> funding output are unavoidable. However this adapter commitment lets
>>> peers
>>> _defer_ these two transactions until closing time. When force closing two
>>> transactions need to be confirmed before the commitment outputs can be
>>> resolved. However, for co-op close, you can just spend the v0 output, and
>>> deliver to the relevant P2TR outputs. The adapter commitment can leverage
>>> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
>>> additional inputs for fees (to avoid introducing the old update_fee
>>> related
>>> static fee issues), or alternatively inherit the anchor output pattern at
>>> this level.
>>>
>>> ## Existing Dynamic Commitments Proposals
>>>
>>> Assuming this concept holds up, then we need an actual concrete protocol
>>> to
>>> allow for dynamic commitment updates. Last year, Rusty made a spec PR
>>> outlining a way to upgrade the commitment type (leveraging the new
>>> commitment type feature bits) upon channel re-establish [3]. The proposal
>>> relies on another message that both sides send (`stfu`) to clear the
>>> commitment (similar to the shutdown semantics) before the switch over
>>> happens. However as this is tied to the channel re-establish flow, it
>>> doesn't allow both sides to do things like only allow your peer to
>>> attach N
>>> HTLCs to start with, slowing increasing their allotted slots and possibly
>>> reducing them (TCP AIMD style).
>>>
>>> ## A Two-Phase Dynamic Commitment Update Protocol
>>>
>>> IMO if we're adding in a way to do commitment/channel upgrades, then it
>>> may
>>> be worthwhile to go with a more generalized, but slightly more involved
>>> route instead. In the remainder of this mail, I'll describe an
>>> alternative
>>> approach that would allow upgrading nearly all channel/commitment related
>>> values (dust limit, max in flight, etc), which is inspired by the way the
>>> Raft consensus protocol handles configuration/member changes.
>>>
>>> For those that aren't aware, Raft is a consensus protocol analogous to
>>> Paxos
>>> (but isn't byzantine fault tolerant out of the box) that was designed as
>>> a
>>> more understandable alternative to Paxos for a pedagogical environment.
>>> Typically the algorithm is run in the context of a fixed cluster with N
>>> machines, but supports adding/removing machines from the cluster with a
>>> configuration update protocol. At a high level the way this works is
>>> that a
>>> new config is sent to the leader, with the leader synchronizing the
>>> config
>>> change with the other members of the cluster. Once a majority threshold
>>> is
>>> reached, the leader then commits the config change with the acknowledged
>>> parties using the new config (basically a two phase commit). I'm skipping
>>> over some edge cases here that can arise if the new nodes participate
>>> consensus too early, which can cause a split majority leading to two
>>> leaders
>>> being elected.
>>>
>>> Applying this to the LN context is a bit simpler than a generalized
>>> protocol, as we typically just have two parties involved. The initiator
>>> is
>>> already naturally a "leader" in our context, as they're the only ones
>>> that
>>> can do things like trigger fee updates.
>>>
>>> ### Message Structure
>>>
>>> At a high level I propose we introduce two new messages, with the fields
>>> looking something like this for `commitment_update_propose`:
>>> * type: 0 (`channel_id`)
>>> * value: [`32*byte`:`chan_id`]
>>> * type: 1 (`propose_sig`)
>>> * value: [`64*byte`:`sig`]
>>> * type: 2 (`update_payload`)
>>> * value: [`*byte`:`tlv_payload`]
>>>
>>> and this `commitment_update_apply`:
>>> * type: 0 (`channel_id`)
>>> * value: [`32*byte`:`chan_id`]
>>> * type: 1 (`local_propose`)
>>> * value: [`*byte`:`commitment_update_propose`]
>>> * type: 2 (`remote_propose`)
>>> * value: [`*byte`:`commitment_update_propose`]
>>>
>>> ### Protocol Flow
>>>
>>> The core idea here is that either party can propose a commitment/channel
>>> param update, but only the initiator can actually apply it. The
>>> `commitment_update_propose` encodes the new set of updates, with a
>>> signature
>>> covering the TLV blob for the new params (more on why that's needed
>>> later).
>>> The `commitment_update_apply` includes up to _two_
>>> `commitment_update_propose` messages (one for the initiator and one for
>>> the
>>> responder, as nested TLV messages). The `commitment_update_propose`
>>> message
>>> would be treated like any other `update_*` message, in that it takes a
>>> new
>>> commitment signature to properly commit/apply it.
>>>
>>> The normal flow takes the form of both sides sending a
>>> `commitment_update_propose` message, with the initiator finally
>>> committing
>>> both by sending a `commitment_update_apply` message. In the event that
>>> only
>>> the responder wants to apply a param change/update, then the initiator
>>> can
>>> reply immediately with a `commitment_update_apply` message that doesn't
>>> include a param change for their commitment (or they just echo the
>>> parameters if they're acceptable).
>>>
>>> ### Handling Retransmissions
>>>
>>> The role of the signature it to prevent "spoofing" by one of the parties
>>> (authenticate the param change), and also it serves to convince a party
>>> that
>>> they actually sent a prior commitment propose update during the
>>> retransmission phase. As the `commitment_update_propose` message would be
>>> retransmitted like any other message, if the initiator attempts to commit
>>> the update but the connection dies, they'll retransmit it as normal along
>>> with their latest signature.
>>>
>>> ### Nested TLV Param Generality
>>>
>>> The messages as sketched out here just have an opaque nested TLV field
>>> which
>>> makes it extensible to add in other things like tweaking the total
>>> number of
>>> max HTLCs, the current dust values, min/max HTLCs, etc (all things that
>>> are
>>> currently hard coded for the lifetime of the channel). An initial target
>>> would likely just be a `chan_type` field, with future feature bits
>>> governing
>>> _what_ type of commitment updates both parties understand in the future.
>>>
>>> In the past, when ideas like this were brought up, some were concerned
>>> that
>>> it wouldn't really be possible to do this type of updates while existing
>>> HTLCs were in flight (hence some of the ideas to clear out the commitment
>>> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
>>> allowed, as from the point of view of the channel update state machine,
>>> all
>>> updates (adds/removes) get applied as normal, but with this _new_
>>> commitment
>>> type/params. The main edge case we'll need to consider is cases where the
>>> new params make older HTLCs invalid for some reason.
>>>
>>> ## Conclusion
>>>
>>> Using the adapter commitment idea combined with a protocol for updating
>>> commitments on the fly, would potentially allow us to update all 80k+
>>> segwit
>>> v0 channels to the base level of taprooty channels without any on chain
>>> transactions. The two transactions (open+close) must happen eventually,
>>> but
>>> by holding another layer of spends off-chain we can defer them
>>> (potentially
>>> indefinitely, as we have channels today that have been opened for over a
>>> year).
>>>
>>> Deploying a generalised on-the-fly dynamic commitment update protocol
>>> gives
>>> us a tool to future proof the _existing_ anchored multi-sig outputs in
>>> the
>>> chain, and also a way to remove many of the hard coded parameters we have
>>> today in the protocol. One overly inflexible parameter we have today in
>>> the
>>> network is the 483 HTLC limit. Allowing this value to float would allow
>>> peers to apply similar congestion avoidance algorithm that are used in
>>> TCP
>>> today, and also give us a way to protect the network against future
>>> unforeseen widespread policy changes (like a raising of the dust limit).
>>>
>>> -- Laolu
>>>
>>> [1]:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>>> [2]:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
>>> [3]: https://github.com/lightning/bolts/pull/868
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
On Thu, Oct 27, 2022 at 4:54 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> I’m not sure I understand this - is there much reason to want taproot
> commitment outputs? I mean they’re cool, and witnesses are a bit smaller,
> which is nice I guess, but they’re not providing materially new features,
> AFAIU. Taproot funding, on the other hand, provides a Bitcoin-wide privacy
> improvement as well the potential future ability of channel participants to
> use multisig for their own channel funds transparently.
>
> Sure, if we’re doing taproot funding outputs we should probably just do it
> for the commitment outputs as well, because why not (and it’s a prereq for
> PTLCs). But trying to split them up seems like added complexity “just
> because”? I suppose it tees us up for eventual PTLC support in todays
> channels, but we can also consider that separately when we get to that
> point, IMO.
>
> Am I missing some important utility of taproot commitment transaction
> outputs?
>
> Matt
>
> On Oct 27, 2022, at 02:17, Johan Torås Halseth <johanth at gmail.com> wrote:
>
>
> Hi, Laolu.
>
> I think it could be worth considering dividing the taprootyness of a
> channel into two:
> 1) taproot funding output
> 2) taproot commitment outputs
>
> That way we could upgrade existing channels only on the commitment level,
> not needing to close or re-anchor the channels using an adapter in order to
> get many of the taproot benefits.
>
> New channels would use taproot multisig (musig2) for the funding output.
>
> This seems to be less disruptive to the existing network, and we could get
> features enabled by taproot to larger parts of the network quicker. And to
> me this seems to carry less complexity (and closing fees) than an adapter.
>
> One caveat is that this wouldn't work (I think) for Eltoo channels, as the
> funding output would not be plain multisig anymore.
>
> - Johan
>
> On Sat, Mar 26, 2022 at 1:27 AM Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> Hi Laolu,
>>
>> Thanks for the proposal, quick feedback.
>>
>> > It *is* still the case that _ultimately_ the two transactions to close
>> the
>> > old segwit v0 funding output, and re-open the channel with a new segwit
>> v1
>> > funding output are unavoidable. However this adapter commitment lets
>> peers
>> > _defer_ these two transactions until closing time.
>>
>> I think there is one downside coming with adapter commitment, which is
>> the uncertainty of the fee overhead at the closing time. Instead of closing
>> your segwit v0 channel _now_ with known fees, when your commitment is empty
>> of time-sensitive HTLCs, you're taking the risk of closing during fees
>> spikes, due a move triggered by your counterparty, when you might have
>> HTLCs at stake.
>>
>> It might be more economically rational for a LN node operator to pay the
>> upgrade cost now if they wish to benefit from the taproot upgrade early,
>> especially if long-term we expect block fees to increase, or wait when
>> there is a "normal" cooperative closing.
>>
>> So it's unclear to me what the economic gain of adapter commitments ?
>>
>> > In the remainder of this mail, I'll describe an alternative
>> > approach that would allow upgrading nearly all channel/commitment
>> related
>> > values (dust limit, max in flight, etc), which is inspired by the way
>> the
>> > Raft consensus protocol handles configuration/member changes.
>>
>> Long-term, I think we'll likely need a consensus protocol anyway for
>> multi-party constructions (channel factories/payment pools). AFAIU this
>> proposal doesn't aim to roll out a full-fledged consensus protocol *now*
>> though it could be wise to ensure what we're building slowly moves in this
>> direction. Less critical code to maintain across bitcoin
>> codebases/toolchains.
>>
>> > The role of the signature it to prevent "spoofing" by one of the parties
>> > (authenticate the param change), and also it serves to convince a party
>> that
>> > they actually sent a prior commitment propose update during the
>> > retransmission phase.
>>
>> What's the purpose of data origin authentication if we assume only
>> two-parties running over Noise_XK ?
>>
>> I think it's already a security property we have. Though if we think
>> we're going to reuse these dynamic upgrades for N counterparties
>> communicating through a coordinator, yes I think it's useful.
>>
>> > In the past, when ideas like this were brought up, some were concerned
>> that
>> > it wouldn't really be possible to do this type of updates while existing
>> > HTLCs were in flight (hence some of the ideas to clear out the
>> commitment
>> > beforehand).
>>
>> The dynamic upgrade might serve in an emergency context where we don't
>> have the leisury to wait for the settlement of the pending HTLCs. The
>> timing of those ones might be beyond the coordination of link
>> counterparties. Thus, we have to allow upgrade of non-empty commitments
>> (and if there are undesirable interferences between new commitment types
>> and HTLCs/PTLCs present, deal case-by-case).
>>
>> Antoine
>>
>> Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com> a
>> écrit :
>>
>>> Hi y'all,
>>>
>>> ## Dynamic Commitments Retrospective
>>>
>>> Two years-ish ago I made a mailing list post on some ideas re dynamic
>>> commitments [1], and how the concept can be used to allow us to upgrade
>>> channel types on the fly, and also remove pesky hard coded limits like
>>> the
>>> 483 HTLC in-flight limit that's present today. Back then my main target
>>> was
>>> upgrading all the existing channels over to the anchor output commitment
>>> variant, so the core internal routing network would be more resilient in
>>> a
>>> persistent high fee environment (which hasn't really happened over the
>>> past
>>> 2 years for various reasons tbh). Fast forward to today, and with taproot
>>> now active on mainnet, and some initial design work/sketches for
>>> taproot-native channels underway, I figure it would be good to bump this
>>> concept as it gives us a way to upgrade all 80k+ public channels to
>>> taproot
>>> without any on chain transactions.
>>>
>>> ## Updating Across Witness Versions w/ Adapter Commitments
>>>
>>> In my original mail, I incorrectly concluded that the dynamic commitments
>>> concept would only really work within the confines of a "static"
>>> multi-sig
>>> output, meaning that it couldn't be used to help channels upgrade to
>>> future
>>> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj,
>>> outlined a
>>> way to achieve this in practice. At a high level he proposes an "adaptor
>>> commitment" (similar to the kickoff transaction in eltoo/duplex), which
>>> is
>>> basically an upgrade transaction that spends one witness version type,
>>> and
>>> produces an output with the next (upgraded) type. In the context of
>>> converting from segwit v0 to v1 (taproot), two peers would
>>> collaboratively
>>> create a new adapter commitment that spends the old v0 multi-sig output,
>>> and
>>> produces a _new_ v1 multi-sig output. The new commitment transaction
>>> would
>>> then be anchored using this new output.
>>>
>>> Here's a rough sequence diagram of the before and after state to better
>>> convey the concept:
>>>
>>> * Before: fundingOutputV0 -> commitmentTransaction
>>>
>>> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
>>> commitmentTransaction
>>>
>>> It *is* still the case that _ultimately_ the two transactions to close
>>> the
>>> old segwit v0 funding output, and re-open the channel with a new segwit
>>> v1
>>> funding output are unavoidable. However this adapter commitment lets
>>> peers
>>> _defer_ these two transactions until closing time. When force closing two
>>> transactions need to be confirmed before the commitment outputs can be
>>> resolved. However, for co-op close, you can just spend the v0 output, and
>>> deliver to the relevant P2TR outputs. The adapter commitment can leverage
>>> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
>>> additional inputs for fees (to avoid introducing the old update_fee
>>> related
>>> static fee issues), or alternatively inherit the anchor output pattern at
>>> this level.
>>>
>>> ## Existing Dynamic Commitments Proposals
>>>
>>> Assuming this concept holds up, then we need an actual concrete protocol
>>> to
>>> allow for dynamic commitment updates. Last year, Rusty made a spec PR
>>> outlining a way to upgrade the commitment type (leveraging the new
>>> commitment type feature bits) upon channel re-establish [3]. The proposal
>>> relies on another message that both sides send (`stfu`) to clear the
>>> commitment (similar to the shutdown semantics) before the switch over
>>> happens. However as this is tied to the channel re-establish flow, it
>>> doesn't allow both sides to do things like only allow your peer to
>>> attach N
>>> HTLCs to start with, slowing increasing their allotted slots and possibly
>>> reducing them (TCP AIMD style).
>>>
>>> ## A Two-Phase Dynamic Commitment Update Protocol
>>>
>>> IMO if we're adding in a way to do commitment/channel upgrades, then it
>>> may
>>> be worthwhile to go with a more generalized, but slightly more involved
>>> route instead. In the remainder of this mail, I'll describe an
>>> alternative
>>> approach that would allow upgrading nearly all channel/commitment related
>>> values (dust limit, max in flight, etc), which is inspired by the way the
>>> Raft consensus protocol handles configuration/member changes.
>>>
>>> For those that aren't aware, Raft is a consensus protocol analogous to
>>> Paxos
>>> (but isn't byzantine fault tolerant out of the box) that was designed as
>>> a
>>> more understandable alternative to Paxos for a pedagogical environment.
>>> Typically the algorithm is run in the context of a fixed cluster with N
>>> machines, but supports adding/removing machines from the cluster with a
>>> configuration update protocol. At a high level the way this works is
>>> that a
>>> new config is sent to the leader, with the leader synchronizing the
>>> config
>>> change with the other members of the cluster. Once a majority threshold
>>> is
>>> reached, the leader then commits the config change with the acknowledged
>>> parties using the new config (basically a two phase commit). I'm skipping
>>> over some edge cases here that can arise if the new nodes participate
>>> consensus too early, which can cause a split majority leading to two
>>> leaders
>>> being elected.
>>>
>>> Applying this to the LN context is a bit simpler than a generalized
>>> protocol, as we typically just have two parties involved. The initiator
>>> is
>>> already naturally a "leader" in our context, as they're the only ones
>>> that
>>> can do things like trigger fee updates.
>>>
>>> ### Message Structure
>>>
>>> At a high level I propose we introduce two new messages, with the fields
>>> looking something like this for `commitment_update_propose`:
>>> * type: 0 (`channel_id`)
>>> * value: [`32*byte`:`chan_id`]
>>> * type: 1 (`propose_sig`)
>>> * value: [`64*byte`:`sig`]
>>> * type: 2 (`update_payload`)
>>> * value: [`*byte`:`tlv_payload`]
>>>
>>> and this `commitment_update_apply`:
>>> * type: 0 (`channel_id`)
>>> * value: [`32*byte`:`chan_id`]
>>> * type: 1 (`local_propose`)
>>> * value: [`*byte`:`commitment_update_propose`]
>>> * type: 2 (`remote_propose`)
>>> * value: [`*byte`:`commitment_update_propose`]
>>>
>>> ### Protocol Flow
>>>
>>> The core idea here is that either party can propose a commitment/channel
>>> param update, but only the initiator can actually apply it. The
>>> `commitment_update_propose` encodes the new set of updates, with a
>>> signature
>>> covering the TLV blob for the new params (more on why that's needed
>>> later).
>>> The `commitment_update_apply` includes up to _two_
>>> `commitment_update_propose` messages (one for the initiator and one for
>>> the
>>> responder, as nested TLV messages). The `commitment_update_propose`
>>> message
>>> would be treated like any other `update_*` message, in that it takes a
>>> new
>>> commitment signature to properly commit/apply it.
>>>
>>> The normal flow takes the form of both sides sending a
>>> `commitment_update_propose` message, with the initiator finally
>>> committing
>>> both by sending a `commitment_update_apply` message. In the event that
>>> only
>>> the responder wants to apply a param change/update, then the initiator
>>> can
>>> reply immediately with a `commitment_update_apply` message that doesn't
>>> include a param change for their commitment (or they just echo the
>>> parameters if they're acceptable).
>>>
>>> ### Handling Retransmissions
>>>
>>> The role of the signature it to prevent "spoofing" by one of the parties
>>> (authenticate the param change), and also it serves to convince a party
>>> that
>>> they actually sent a prior commitment propose update during the
>>> retransmission phase. As the `commitment_update_propose` message would be
>>> retransmitted like any other message, if the initiator attempts to commit
>>> the update but the connection dies, they'll retransmit it as normal along
>>> with their latest signature.
>>>
>>> ### Nested TLV Param Generality
>>>
>>> The messages as sketched out here just have an opaque nested TLV field
>>> which
>>> makes it extensible to add in other things like tweaking the total
>>> number of
>>> max HTLCs, the current dust values, min/max HTLCs, etc (all things that
>>> are
>>> currently hard coded for the lifetime of the channel). An initial target
>>> would likely just be a `chan_type` field, with future feature bits
>>> governing
>>> _what_ type of commitment updates both parties understand in the future.
>>>
>>> In the past, when ideas like this were brought up, some were concerned
>>> that
>>> it wouldn't really be possible to do this type of updates while existing
>>> HTLCs were in flight (hence some of the ideas to clear out the commitment
>>> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
>>> allowed, as from the point of view of the channel update state machine,
>>> all
>>> updates (adds/removes) get applied as normal, but with this _new_
>>> commitment
>>> type/params. The main edge case we'll need to consider is cases where the
>>> new params make older HTLCs invalid for some reason.
>>>
>>> ## Conclusion
>>>
>>> Using the adapter commitment idea combined with a protocol for updating
>>> commitments on the fly, would potentially allow us to update all 80k+
>>> segwit
>>> v0 channels to the base level of taprooty channels without any on chain
>>> transactions. The two transactions (open+close) must happen eventually,
>>> but
>>> by holding another layer of spends off-chain we can defer them
>>> (potentially
>>> indefinitely, as we have channels today that have been opened for over a
>>> year).
>>>
>>> Deploying a generalised on-the-fly dynamic commitment update protocol
>>> gives
>>> us a tool to future proof the _existing_ anchored multi-sig outputs in
>>> the
>>> chain, and also a way to remove many of the hard coded parameters we have
>>> today in the protocol. One overly inflexible parameter we have today in
>>> the
>>> network is the 483 HTLC limit. Allowing this value to float would allow
>>> peers to apply similar congestion avoidance algorithm that are used in
>>> TCP
>>> today, and also give us a way to protect the network against future
>>> unforeseen widespread policy changes (like a raising of the dust limit).
>>>
>>> -- Laolu
>>>
>>> [1]:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>>> [2]:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
>>> [3]: https://github.com/lightning/bolts/pull/868
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221028/c91f1825/attachment-0001.html>;

📅 Original date posted:2022-10-27 📝 Original message: Hi, ...

2023-06-09T13:07:09Z

In reply to nevent1q…xqn3
_________________________

📅 Original date posted:2022-10-27
📝 Original message:
Hi, Laolu.

I think it could be worth considering dividing the taprootyness of a
channel into two:
1) taproot funding output
2) taproot commitment outputs

That way we could upgrade existing channels only on the commitment level,
not needing to close or re-anchor the channels using an adapter in order to
get many of the taproot benefits.

New channels would use taproot multisig (musig2) for the funding output.

This seems to be less disruptive to the existing network, and we could get
features enabled by taproot to larger parts of the network quicker. And to
me this seems to carry less complexity (and closing fees) than an adapter.

One caveat is that this wouldn't work (I think) for Eltoo channels, as the
funding output would not be plain multisig anymore.

- Johan

On Sat, Mar 26, 2022 at 1:27 AM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi Laolu,
>
> Thanks for the proposal, quick feedback.
>
> > It *is* still the case that _ultimately_ the two transactions to close
> the
> > old segwit v0 funding output, and re-open the channel with a new segwit
> v1
> > funding output are unavoidable. However this adapter commitment lets
> peers
> > _defer_ these two transactions until closing time.
>
> I think there is one downside coming with adapter commitment, which is the
> uncertainty of the fee overhead at the closing time. Instead of closing
> your segwit v0 channel _now_ with known fees, when your commitment is empty
> of time-sensitive HTLCs, you're taking the risk of closing during fees
> spikes, due a move triggered by your counterparty, when you might have
> HTLCs at stake.
>
> It might be more economically rational for a LN node operator to pay the
> upgrade cost now if they wish to benefit from the taproot upgrade early,
> especially if long-term we expect block fees to increase, or wait when
> there is a "normal" cooperative closing.
>
> So it's unclear to me what the economic gain of adapter commitments ?
>
> > In the remainder of this mail, I'll describe an alternative
> > approach that would allow upgrading nearly all channel/commitment related
> > values (dust limit, max in flight, etc), which is inspired by the way the
> > Raft consensus protocol handles configuration/member changes.
>
> Long-term, I think we'll likely need a consensus protocol anyway for
> multi-party constructions (channel factories/payment pools). AFAIU this
> proposal doesn't aim to roll out a full-fledged consensus protocol *now*
> though it could be wise to ensure what we're building slowly moves in this
> direction. Less critical code to maintain across bitcoin
> codebases/toolchains.
>
> > The role of the signature it to prevent "spoofing" by one of the parties
> > (authenticate the param change), and also it serves to convince a party
> that
> > they actually sent a prior commitment propose update during the
> > retransmission phase.
>
> What's the purpose of data origin authentication if we assume only
> two-parties running over Noise_XK ?
>
> I think it's already a security property we have. Though if we think we're
> going to reuse these dynamic upgrades for N counterparties communicating
> through a coordinator, yes I think it's useful.
>
> > In the past, when ideas like this were brought up, some were concerned
> that
> > it wouldn't really be possible to do this type of updates while existing
> > HTLCs were in flight (hence some of the ideas to clear out the commitment
> > beforehand).
>
> The dynamic upgrade might serve in an emergency context where we don't
> have the leisury to wait for the settlement of the pending HTLCs. The
> timing of those ones might be beyond the coordination of link
> counterparties. Thus, we have to allow upgrade of non-empty commitments
> (and if there are undesirable interferences between new commitment types
> and HTLCs/PTLCs present, deal case-by-case).
>
> Antoine
>
> Le jeu. 24 mars 2022 à 18:53, Olaoluwa Osuntokun <laolu32 at gmail.com> a
> écrit :
>
>> Hi y'all,
>>
>> ## Dynamic Commitments Retrospective
>>
>> Two years-ish ago I made a mailing list post on some ideas re dynamic
>> commitments [1], and how the concept can be used to allow us to upgrade
>> channel types on the fly, and also remove pesky hard coded limits like the
>> 483 HTLC in-flight limit that's present today. Back then my main target
>> was
>> upgrading all the existing channels over to the anchor output commitment
>> variant, so the core internal routing network would be more resilient in a
>> persistent high fee environment (which hasn't really happened over the
>> past
>> 2 years for various reasons tbh). Fast forward to today, and with taproot
>> now active on mainnet, and some initial design work/sketches for
>> taproot-native channels underway, I figure it would be good to bump this
>> concept as it gives us a way to upgrade all 80k+ public channels to
>> taproot
>> without any on chain transactions.
>>
>> ## Updating Across Witness Versions w/ Adapter Commitments
>>
>> In my original mail, I incorrectly concluded that the dynamic commitments
>> concept would only really work within the confines of a "static" multi-sig
>> output, meaning that it couldn't be used to help channels upgrade to
>> future
>> segwit witness versions. Thankfully this reply [2] by ZmnSCPxj, outlined
>> a
>> way to achieve this in practice. At a high level he proposes an "adaptor
>> commitment" (similar to the kickoff transaction in eltoo/duplex), which is
>> basically an upgrade transaction that spends one witness version type, and
>> produces an output with the next (upgraded) type. In the context of
>> converting from segwit v0 to v1 (taproot), two peers would collaboratively
>> create a new adapter commitment that spends the old v0 multi-sig output,
>> and
>> produces a _new_ v1 multi-sig output. The new commitment transaction would
>> then be anchored using this new output.
>>
>> Here's a rough sequence diagram of the before and after state to better
>> convey the concept:
>>
>> * Before: fundingOutputV0 -> commitmentTransaction
>>
>> * After fundingOutputV0 -> fundingOutputV1 (the adapter) ->
>> commitmentTransaction
>>
>> It *is* still the case that _ultimately_ the two transactions to close the
>> old segwit v0 funding output, and re-open the channel with a new segwit v1
>> funding output are unavoidable. However this adapter commitment lets peers
>> _defer_ these two transactions until closing time. When force closing two
>> transactions need to be confirmed before the commitment outputs can be
>> resolved. However, for co-op close, you can just spend the v0 output, and
>> deliver to the relevant P2TR outputs. The adapter commitment can leverage
>> sighash anyonecanpay to let both parties (assuming it's symmetric) attach
>> additional inputs for fees (to avoid introducing the old update_fee
>> related
>> static fee issues), or alternatively inherit the anchor output pattern at
>> this level.
>>
>> ## Existing Dynamic Commitments Proposals
>>
>> Assuming this concept holds up, then we need an actual concrete protocol
>> to
>> allow for dynamic commitment updates. Last year, Rusty made a spec PR
>> outlining a way to upgrade the commitment type (leveraging the new
>> commitment type feature bits) upon channel re-establish [3]. The proposal
>> relies on another message that both sides send (`stfu`) to clear the
>> commitment (similar to the shutdown semantics) before the switch over
>> happens. However as this is tied to the channel re-establish flow, it
>> doesn't allow both sides to do things like only allow your peer to attach
>> N
>> HTLCs to start with, slowing increasing their allotted slots and possibly
>> reducing them (TCP AIMD style).
>>
>> ## A Two-Phase Dynamic Commitment Update Protocol
>>
>> IMO if we're adding in a way to do commitment/channel upgrades, then it
>> may
>> be worthwhile to go with a more generalized, but slightly more involved
>> route instead. In the remainder of this mail, I'll describe an alternative
>> approach that would allow upgrading nearly all channel/commitment related
>> values (dust limit, max in flight, etc), which is inspired by the way the
>> Raft consensus protocol handles configuration/member changes.
>>
>> For those that aren't aware, Raft is a consensus protocol analogous to
>> Paxos
>> (but isn't byzantine fault tolerant out of the box) that was designed as a
>> more understandable alternative to Paxos for a pedagogical environment.
>> Typically the algorithm is run in the context of a fixed cluster with N
>> machines, but supports adding/removing machines from the cluster with a
>> configuration update protocol. At a high level the way this works is that
>> a
>> new config is sent to the leader, with the leader synchronizing the config
>> change with the other members of the cluster. Once a majority threshold is
>> reached, the leader then commits the config change with the acknowledged
>> parties using the new config (basically a two phase commit). I'm skipping
>> over some edge cases here that can arise if the new nodes participate
>> consensus too early, which can cause a split majority leading to two
>> leaders
>> being elected.
>>
>> Applying this to the LN context is a bit simpler than a generalized
>> protocol, as we typically just have two parties involved. The initiator is
>> already naturally a "leader" in our context, as they're the only ones that
>> can do things like trigger fee updates.
>>
>> ### Message Structure
>>
>> At a high level I propose we introduce two new messages, with the fields
>> looking something like this for `commitment_update_propose`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`propose_sig`)
>> * value: [`64*byte`:`sig`]
>> * type: 2 (`update_payload`)
>> * value: [`*byte`:`tlv_payload`]
>>
>> and this `commitment_update_apply`:
>> * type: 0 (`channel_id`)
>> * value: [`32*byte`:`chan_id`]
>> * type: 1 (`local_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>> * type: 2 (`remote_propose`)
>> * value: [`*byte`:`commitment_update_propose`]
>>
>> ### Protocol Flow
>>
>> The core idea here is that either party can propose a commitment/channel
>> param update, but only the initiator can actually apply it. The
>> `commitment_update_propose` encodes the new set of updates, with a
>> signature
>> covering the TLV blob for the new params (more on why that's needed
>> later).
>> The `commitment_update_apply` includes up to _two_
>> `commitment_update_propose` messages (one for the initiator and one for
>> the
>> responder, as nested TLV messages). The `commitment_update_propose`
>> message
>> would be treated like any other `update_*` message, in that it takes a new
>> commitment signature to properly commit/apply it.
>>
>> The normal flow takes the form of both sides sending a
>> `commitment_update_propose` message, with the initiator finally committing
>> both by sending a `commitment_update_apply` message. In the event that
>> only
>> the responder wants to apply a param change/update, then the initiator can
>> reply immediately with a `commitment_update_apply` message that doesn't
>> include a param change for their commitment (or they just echo the
>> parameters if they're acceptable).
>>
>> ### Handling Retransmissions
>>
>> The role of the signature it to prevent "spoofing" by one of the parties
>> (authenticate the param change), and also it serves to convince a party
>> that
>> they actually sent a prior commitment propose update during the
>> retransmission phase. As the `commitment_update_propose` message would be
>> retransmitted like any other message, if the initiator attempts to commit
>> the update but the connection dies, they'll retransmit it as normal along
>> with their latest signature.
>>
>> ### Nested TLV Param Generality
>>
>> The messages as sketched out here just have an opaque nested TLV field
>> which
>> makes it extensible to add in other things like tweaking the total number
>> of
>> max HTLCs, the current dust values, min/max HTLCs, etc (all things that
>> are
>> currently hard coded for the lifetime of the channel). An initial target
>> would likely just be a `chan_type` field, with future feature bits
>> governing
>> _what_ type of commitment updates both parties understand in the future.
>>
>> In the past, when ideas like this were brought up, some were concerned
>> that
>> it wouldn't really be possible to do this type of updates while existing
>> HTLCs were in flight (hence some of the ideas to clear out the commitment
>> beforehand). I don't see a reason why this fundamentally _shouldn't_ be
>> allowed, as from the point of view of the channel update state machine,
>> all
>> updates (adds/removes) get applied as normal, but with this _new_
>> commitment
>> type/params. The main edge case we'll need to consider is cases where the
>> new params make older HTLCs invalid for some reason.
>>
>> ## Conclusion
>>
>> Using the adapter commitment idea combined with a protocol for updating
>> commitments on the fly, would potentially allow us to update all 80k+
>> segwit
>> v0 channels to the base level of taprooty channels without any on chain
>> transactions. The two transactions (open+close) must happen eventually,
>> but
>> by holding another layer of spends off-chain we can defer them
>> (potentially
>> indefinitely, as we have channels today that have been opened for over a
>> year).
>>
>> Deploying a generalised on-the-fly dynamic commitment update protocol
>> gives
>> us a tool to future proof the _existing_ anchored multi-sig outputs in the
>> chain, and also a way to remove many of the hard coded parameters we have
>> today in the protocol. One overly inflexible parameter we have today in
>> the
>> network is the 483 HTLC limit. Allowing this value to float would allow
>> peers to apply similar congestion avoidance algorithm that are used in TCP
>> today, and also give us a way to protect the network against future
>> unforeseen widespread policy changes (like a raising of the dust limit).
>>
>> -- Laolu
>>
>> [1]:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
>> [2]:
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002770.html
>> [3]: https://github.com/lightning/bolts/pull/868
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221027/70db062c/attachment-0001.html>;

📅 Original date posted:2020-11-23 📝 Original message: Hi, ...

2023-06-09T13:01:30Z

In reply to nevent1q…6wv2
_________________________

📅 Original date posted:2020-11-23
📝 Original message:
Hi,

Posting an update to this thread, as we are inching closer to an
implementation in lnd that handles this scenario.

I put up a proposed PR today that attempts to solve this in a
backwards compatible manner:
https://github.com/lightningnetwork/lnd/pull/4795

The gist is that in every state we check that the "worst case fee
leak" is at most the channel reserve. The idea is that there should be
no incentive to perform the attack as described, as the cheating party
will gain at most the channel reserve, but at the same time lose its
channel reserve.

Since this makes small channels unusable at high fee rates (the leaked
fee would exceed the channel reserve for just a few, even a single
HTLC) we also clamp the maximum update_fee we'll send at 10 sat/b (a
configurable value). As an example a 1,000,000 sat channel with a 1%
channel reserve would have space for 6 HTLCs at this fee rate.

> Completely adhering to the bring-your-own-fee model for HTLC-txn sounds better as it splits more fairly fees burden between channel participants.

I totally agree that this sounds like the best solution! AFAICT this
would require a (simple) spec change, but would definitely be a big
win and a simple implementation change when we are doing BYOF on the
HTLC transactions anyway :)

- Johan

On Mon, Sep 14, 2020 at 1:30 AM Antoine Riard <antoine.riard at gmail.com> wrote:
>
> Hi Johan,
>
> > I would be open to patching the spec to disallow update_fee for anchor
> > channels, but maybe we can just add a warning and discourage it.
>
> My initial thinking was just to restrain it for the commitment-level only.
>
> Completely adhering to the bring-your-own-fee model for HTLC-txn sounds better as it splits more fairly fees burden between channel participants. The initiator won't have to pay for the remote's HTLC-txn, especially in periods of high-congestion. A participant shouldn't have to bear the cost of the counterparty choosing to go onchain, as it's mostly a client security parameter ("how many blocks it will take me to confirm ?") or an economic decision ("is this HTLC worthy to claim/expire ?").
>
> One could argue it's increasing the blockspace footprint as you will use one more pair of input-output but if you're paying the feerate that's lawful usage.
>
> Antoine
>
> Le ven. 11 sept. 2020 à 04:15, Johan Torås Halseth <johanth at gmail.com> a écrit :
>>
>> Hi,
>>
>> Very good observation, most definitely not a type of attack I forseen!
>>
>> Luckily, it was the plan to phase out update_fee all along, in favor
>> of only accepting the minimum relay fee (zero fee if/when package
>> relay is a reality). If I understand the scenario correctly, that
>> should mitigate this attack completely, as the attacker cannot impact
>> the intended miner fees on the HTLCs, and could only siphon off the
>> minimal miner fee if anything at all.
>>
>> I would be open to patching the spec to disallow update_fee for anchor
>> channels, but maybe we can just add a warning and discourage it.
>>
>> Johan
>>
>>
>> On Thu, Sep 10, 2020 at 8:13 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>> >
>> > Hi Antoine,
>> >
>> > Great findings!
>> >
>> > I think an even simpler mitigation is just for the non-initiator to _reject_
>> > update_fee proposals that are "unreasonable". The non-initiator can run a
>> > "fee leak calculation" to compute the worst-case leakage of fees in the
>> > revocation case. This can be done to day without any significant updates to
>> > implementations, and some implementations may already be doing this.
>> >
>> > One issue is that we don't have a way to do a "soft reject" of an update_fee
>> > as is. However, depending on the implementations, it may be possible to just
>> > reconnect and issue a co-op close if there're no HTLCs on the commitment
>> > transaction.
>> >
>> > As you mentioned by setting proper values for max allowed htlcs, max in
>> > flight, reserve, etc, nodes are able to quantify this fee leak risk ahead of
>> > time, and set reasonable parameters based on their security model. One issue
>> > is that these values are set in stone rn when the channel is opened, but
>> > future iterations of dynamic commitments may allow us to update them on the
>> > fly.
>> >
>> > In the mid-term, implementations can start to phase out usage of update_fee
>> > by setting a minimal commitment fee when the channel is first opened, then
>> > relying on CPFP to bump up the commitment and any HTLCs if needed. This
>> > discovery might very well hasten the demise of update_fee in the protocol
>> > all together as well. I don't think we need to depend entirely on a
>> > theoretical package relay Bitcoin p2p upgrade assuming implementations are
>> > willing to make an assumption that say 20 sat/byte or w/e has a good chance
>> > of widespread propagation into mempools.
>> >
>> > From the perspective of channel safety, and variations of attacks like
>> > "flood & loot", imo it's absolutely critical that nodes are able to update
>> > the fees on their second-level HTLC transactions. As this is where the real
>> > danger lies: if nodes aren't able to get 2nd level HTLCs in the chain in
>> > time, then the incoming HTLC expiry will expire, creating a race condition
>> > across both commitments which can potentially cascade.
>> >
>> > In lnd today, anchors is still behind a build flag, but we plan to enable
>> > it by default for our upcoming 0.12 release. The blockers on our end were to
>> > add support for towers, and add basic deadline aware bumping, both of which
>> > are currently on track. We'll now also look into setting clamps on the
>> > receiver end to just not accept unreasonable values for the fee rate of a
>> > commitment, as this ends up eating into the true HTLC values for both sides.
>> >
>> > -- Laolu
>> >
>> >
>> > On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard <antoine.riard at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> In this post, I would like to expose a potential vulnerability introduced by the recent anchor output spec update related to the new usage of SIGHASH_SINGLE for HTLC transactions. This new malleability combined with the currently deployed mechanism of `update_fee` is likely harmful for funds safety.
>> >>
>> >> This has been previously shared with deployed implementations devs, as anchor channels are flagged as experimental it's better to discuss and solve this publicly. That said, if you're currently running experimental anchor channels with non-trusted parties on mainnet, you might prefer to close them.
>> >>
>> >> # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)
>> >>
>> >> First, let's get started by a quick reminder of the data set committed by signature digest algorithm of Segwit transactions (BIP 143):
>> >> * nVersion
>> >> * hashPrevouts
>> >> * hashSequence
>> >> * outpoint
>> >> * scriptCode of the input
>> >> * value of the output spent by this input
>> >> * nSequence of the input
>> >> * hashOutputs
>> >> * nLocktime
>> >> * sighash type of the signature
>> >>
>> >> Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus it can spend non-cooperatively its HTLC outputs on its commitment transactions. I.e when Alice broadcasts her commitment transaction, every Bob's signatures on Alice's HTLC-Success/Timeout transactions are now flagging the new sighash type.
>> >>
>> >> Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs` (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the output scriptpubkey/amount at the same index that
>> >> the spending input. Alice is free to attach additional inputs/outputs to her HTLC transaction. This change is aiming to let a single-party bump the feerate of 2nd-stage HTLC transactions in case of mempool-congestion, without counterparty cooperation and thus make HTLC funds safer.
>> >>
>> >> The attached outputs are _not_ encumbered by a revokeable redeemscript for a potential punishment.
>> >>
>> >> That said, anchor ouput spec didn't change disable the current fee mechanism already covering HTLC transactions. Pre/post-anchor channels are negotiating a feerate through `update_fee` exchange, initiated by the channel funder. This `update_fee` can be rejected by the receiver if it's deemed unreasonable compared to your local fee estimator view, but as of today implementations are pretty liberal in their acceptance, admitting a divergence from a scale of 1 to no-bound at all.
>> >>
>> >> This negotiated feerate (`feerate_per_kw`) is used by channel participants to compute effective fees which have to be deduced either from the funder balance output for commitment transactions or from HTLC output value for HTLC transactions.
>> >>
>> >> # The Vulnerability : a Penalty Escape Vector
>> >>
>> >> By increasing the feerate thanks to `update_fee`, a malicious party can inflate fees committed on HTLC input/output pairs and redirect this inflated fee to a single-controlled output attached to these malleable pairs. This won't be punishable by an honest party in case of revoked state broadcast and thus enable to partially escape the penalty.
>> >>
>> >> As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw` is 10000 sats.
>> >>
>> >> At state N, Alice balance is all on her side. She announces 10 outgoing HTLCs of value 7000 sats.
>> >>
>> >> As Commitment tx weight with 10 outputs is 2844 (post-anchor), the absolute fee committed is 28440 sats.
>> >>
>> >> As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat. This absolute fee aims to pay the miner fee in case Alice needs to timeout HTLC onchain.
>> >>
>> >> Her remaining balance is 1560 sat, above both dust_limit_satoshi and the channel reserve as constrained by Bob (likely 1%).
>> >>
>> >> Alice waits for HTLCs to expire and advances state to N+1. Then she empties her balance minus reserve by sending a HTLC relayed by Bob either to a colluding channel on the rest of network or back to an onchain address thanks to a swap service.
>> >>
>> >> At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost all of the absolute fee to a new P2WPKH output only controlled by her. She broadcasts the revoked commitment tx N and burns 28440 sats in commitment fee.
>> >>
>> >> Her balance of 1560 sats is punished by Bob's justice transaction.
>> >>
>> >> After confirmation and thus maturing of the CSV of 1 on her HTLC output Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.
>> >>
>> >> Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560 (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs fees) - 340*10 (HTLCs output) = 125600 sats.
>> >>
>> >> Alice's gain is superior at channel value as it has been partially double-spend by bypassing the revocation punishment.
>> >>
>> >> # Limitations of Attacker Success
>> >>
>> >> A first limitation of attack success which can be point of is the fact that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a honest party can punish this output before the malicious spend them with the revoked HTLC txn. In practice a malicious party can attach a branch of descendants to its anchor output and that way only allowing one more mempool victim's transaction on the revoked commitment. The victim must spend all outputs at once or otherwise they're going to obstrucate each other at mempool acceptance.
>> >>
>> >> Secondly, other limitations are the per-implementation channel policy `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and acceptance bound of `update_fee`. A quick look at default policies, even if they vary between deploy implementations, let it think there is room to escape a substantial part of channel value.
>> >>
>> >> Lastly, after the revoked commitment transaction is confirmed, both attacker and victim are in a feerate race to confirm either a justice transaction or a malicious HTLC-timeout. As fee estimator logic of the victim's implementation is a public piece of knowledge, it shouldn't be hard for the attacker to know the range of the first fee bid and override it by a bit to confirm it before the victim RBF at next block. Currently, not all implementations have RBF of justice transactions.
>> >>
>> >> As of today, if anchor output is deployed and given how LN implementations are managing fees/rebroadcast of onchain transactions, the chance of attack success sounds high in my opinion.
>> >>
>> >> # Countermeasures
>> >>
>> >> Channel policies could be tighter, like bounded further down `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the latter, it's pretty hard as a) fee estimators diverge on mempool views b) an attacker can craft escape HTLC-txn in a period of high-fee and patiently waits a low-fee period to launch the exploitation.
>> >>
>> >> Justice transactions can adopt a scorched earth approach binding their feerate to the max to increase odds of winning the feerate race and thus deter attackers. But this sounds like introducing a griefing attack vector. Your counterparty can burn more of your lawful balance in fees than you'll punish its revoked balance.
>> >>
>> >> A workable option would be to patch current anchor spec to remove `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing a minimal relay fee.
>> >>
>> >> Thoughts of further countermeasures ?
>> >>
>> >> I think the vulnerability described is mostly right but please point any missing details.
>> >>
>> >> Cheers,
>> >>
>> >> Antoine
>> >> _______________________________________________
>> >> Lightning-dev mailing list
>> >> Lightning-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-10-16 📝 Original message: Many ...

2023-06-09T13:01:03Z

In reply to nevent1q…cwqw
_________________________

📅 Original date posted:2020-10-16
📝 Original message:
Many good thoughts here.

Personally I think we should design any changes for a package-relay
future, where the commitment can be 0-fee, update_fee doesn't longer
exist and fees are only decided upon on channel close.

- johan

On Wed, Oct 14, 2020 at 10:25 AM Bastien TEINTURIER via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> I totally agree with the simplicity argument, I wanted to raise this because it's (IMO) an issue
> today because of the way we deal with on-chain fees, but it's less impactful once update_fee is
> scoped to some min_relay_fee.
>
> Let's put this aside for now then and we can revisit later if needed.
>
> Thanks for the feedback everyone!
> Bastien
>
> Le lun. 12 oct. 2020 à 20:49, Olaoluwa Osuntokun <laolu32 at gmail.com> a écrit :
>>
>> > It seems to me that the "funder pays all the commit tx fees" rule exists
>> > solely for simplicity (which was totally reasonable).
>>
>> At this stage, I've learned that simplicity (when doing anything that
>> involves multi-party on-chain fee negotiating/verification/enforcement can
>> really go a long way). Just think about all the edge cases w.r.t _allocating
>> enough funds to pay for fees_ we've discovered over the past few years in
>> the state machine. I fear adding a more elaborate fee splitting mechanism
>> would only blow up the number of obscure edge cases that may lead to a
>> channel temporarily or permanently being "borked".
>>
>> If we're going to add a "fairer" way of splitting fees, we'll really need to
>> dig down pre-deployment to ensure that we've explored any resulting edge
>> cases within our solution space, as we'll only be _adding_ complexity to fee
>> splitting.
>>
>> IMO, anchor commitments in their "final form" (fixed fee rate on commitment
>> transaction, only "emergency" use of update_fee) significantly simplifies
>> things as it shifts from "funding pay fees", to "broadcaster/confirmer pays
>> fees". However, as you note this doesn't fully distribute the worst-case
>> cost of needing to go to chain with a "fully loaded" commitment transaction.
>> Even with HTLCs, they could only be signed at 1 sat/byte from the funder's
>> perspective, once again putting the burden on the broadcaster/confirmer to
>> make up the difference.
>>
>> -- Laolu
>>
>>
>> On Mon, Oct 5, 2020 at 6:13 AM Bastien TEINTURIER via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Good morning list,
>>>
>>> It seems to me that the "funder pays all the commit tx fees" rule exists solely for simplicity
>>> (which was totally reasonable). I haven't been able to find much discussion about this decision
>>> on the mailing list nor in the spec commits.
>>>
>>> At first glance, it's true that at the beginning of the channel lifetime, the funder should be
>>> responsible for the fee (it's his decision to open a channel after all). But as time goes by and
>>> both peers earn value from this channel, this rule becomes questionable. We've discovered since
>>> then that there is some risk associated with having pending HTLCs (flood-and-loot type of attacks,
>>> pinning, channel jamming, etc).
>>>
>>> I think that *in some cases*, fundees should be paying a portion of the commit-tx on-chain fees,
>>> otherwise we may end up with a web-of-trust network where channels would only exist between peers
>>> that trust each other, which is quite limiting (I'm hoping we can do better).
>>>
>>> Routing nodes may be at risk when they *receive* HTLCs. All the attacks that steal funds come from
>>> the fact that a routing node has paid downstream but cannot claim the upstream HTLCs (correct me
>>> if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of the HTLCs they offer
>>> while they're pending in the commit-tx, regardless of whether they're funder or fundee.
>>>
>>> The simplest way to do this would be to deduce the HTLC cost (172 * feerate) from the offerer's
>>> main output (instead of the funder's main output, while keeping the base commit tx weight paid
>>> by the funder).
>>>
>>> A more extreme proposal would be to tie the *total* commit-tx fee to the channel usage:
>>>
>>> * if there are no pending HTLCs, the funder pays all the fee
>>> * if there are pending HTLCs, each node pays a proportion of the fee proportional to the number of
>>> HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob pays 75% of the
>>> commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is redistributed.
>>>
>>> This model uses the on-chain fee as collateral for usage of the channel. If Alice wants to forward
>>> HTLCs through this channel (because she has something to gain - routing fees), she should be taking
>>> on some of the associated risk, not Bob. Bob will be taking the same risk downstream if he chooses
>>> to forward.
>>>
>>> I believe it also forces the fundee to care about on-chain feerates, which is a healthy incentive.
>>> It may create a feedback loop between on-chain feerates and routing fees, which I believe is also
>>> a good long-term thing (but it's hard to predict as there may be negative side-effects as well).
>>>
>>> What do you all think? Is this a terrible idea? Is it okay-ish, but not worth the additional
>>> complexity? Is it an amazing idea worth a lightning nobel? Please don't take any of my claims
>>> for granted and challenge them, there may be negative side-effects I'm completely missing, this is
>>> a fragile game of incentives...
>>>
>>> Side-note: don't forget to take into account that the fees for HTLC transactions (second-level txs)
>>> are always paid by the party that broadcasts them (which makes sense). I still think this is not
>>> enough and can even be abused by fundees in some setups.
>>>
>>> Thanks,
>>> Bastien
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-09-11 📝 Original message: Hi, ...

2023-06-09T13:00:52Z

In reply to nevent1q…drph
_________________________

📅 Original date posted:2020-09-11
📝 Original message:
Hi,

Very good observation, most definitely not a type of attack I forseen!

Luckily, it was the plan to phase out update_fee all along, in favor
of only accepting the minimum relay fee (zero fee if/when package
relay is a reality). If I understand the scenario correctly, that
should mitigate this attack completely, as the attacker cannot impact
the intended miner fees on the HTLCs, and could only siphon off the
minimal miner fee if anything at all.

I would be open to patching the spec to disallow update_fee for anchor
channels, but maybe we can just add a warning and discourage it.

Johan

On Thu, Sep 10, 2020 at 8:13 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Antoine,
>
> Great findings!
>
> I think an even simpler mitigation is just for the non-initiator to _reject_
> update_fee proposals that are "unreasonable". The non-initiator can run a
> "fee leak calculation" to compute the worst-case leakage of fees in the
> revocation case. This can be done to day without any significant updates to
> implementations, and some implementations may already be doing this.
>
> One issue is that we don't have a way to do a "soft reject" of an update_fee
> as is. However, depending on the implementations, it may be possible to just
> reconnect and issue a co-op close if there're no HTLCs on the commitment
> transaction.
>
> As you mentioned by setting proper values for max allowed htlcs, max in
> flight, reserve, etc, nodes are able to quantify this fee leak risk ahead of
> time, and set reasonable parameters based on their security model. One issue
> is that these values are set in stone rn when the channel is opened, but
> future iterations of dynamic commitments may allow us to update them on the
> fly.
>
> In the mid-term, implementations can start to phase out usage of update_fee
> by setting a minimal commitment fee when the channel is first opened, then
> relying on CPFP to bump up the commitment and any HTLCs if needed. This
> discovery might very well hasten the demise of update_fee in the protocol
> all together as well. I don't think we need to depend entirely on a
> theoretical package relay Bitcoin p2p upgrade assuming implementations are
> willing to make an assumption that say 20 sat/byte or w/e has a good chance
> of widespread propagation into mempools.
>
> From the perspective of channel safety, and variations of attacks like
> "flood & loot", imo it's absolutely critical that nodes are able to update
> the fees on their second-level HTLC transactions. As this is where the real
> danger lies: if nodes aren't able to get 2nd level HTLCs in the chain in
> time, then the incoming HTLC expiry will expire, creating a race condition
> across both commitments which can potentially cascade.
>
> In lnd today, anchors is still behind a build flag, but we plan to enable
> it by default for our upcoming 0.12 release. The blockers on our end were to
> add support for towers, and add basic deadline aware bumping, both of which
> are currently on track. We'll now also look into setting clamps on the
> receiver end to just not accept unreasonable values for the fee rate of a
> commitment, as this ends up eating into the true HTLC values for both sides.
>
> -- Laolu
>
>
> On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard <antoine.riard at gmail.com> wrote:
>>
>> Hi,
>>
>> In this post, I would like to expose a potential vulnerability introduced by the recent anchor output spec update related to the new usage of SIGHASH_SINGLE for HTLC transactions. This new malleability combined with the currently deployed mechanism of `update_fee` is likely harmful for funds safety.
>>
>> This has been previously shared with deployed implementations devs, as anchor channels are flagged as experimental it's better to discuss and solve this publicly. That said, if you're currently running experimental anchor channels with non-trusted parties on mainnet, you might prefer to close them.
>>
>> # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)
>>
>> First, let's get started by a quick reminder of the data set committed by signature digest algorithm of Segwit transactions (BIP 143):
>> * nVersion
>> * hashPrevouts
>> * hashSequence
>> * outpoint
>> * scriptCode of the input
>> * value of the output spent by this input
>> * nSequence of the input
>> * hashOutputs
>> * nLocktime
>> * sighash type of the signature
>>
>> Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus it can spend non-cooperatively its HTLC outputs on its commitment transactions. I.e when Alice broadcasts her commitment transaction, every Bob's signatures on Alice's HTLC-Success/Timeout transactions are now flagging the new sighash type.
>>
>> Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs` (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the output scriptpubkey/amount at the same index that
>> the spending input. Alice is free to attach additional inputs/outputs to her HTLC transaction. This change is aiming to let a single-party bump the feerate of 2nd-stage HTLC transactions in case of mempool-congestion, without counterparty cooperation and thus make HTLC funds safer.
>>
>> The attached outputs are _not_ encumbered by a revokeable redeemscript for a potential punishment.
>>
>> That said, anchor ouput spec didn't change disable the current fee mechanism already covering HTLC transactions. Pre/post-anchor channels are negotiating a feerate through `update_fee` exchange, initiated by the channel funder. This `update_fee` can be rejected by the receiver if it's deemed unreasonable compared to your local fee estimator view, but as of today implementations are pretty liberal in their acceptance, admitting a divergence from a scale of 1 to no-bound at all.
>>
>> This negotiated feerate (`feerate_per_kw`) is used by channel participants to compute effective fees which have to be deduced either from the funder balance output for commitment transactions or from HTLC output value for HTLC transactions.
>>
>> # The Vulnerability : a Penalty Escape Vector
>>
>> By increasing the feerate thanks to `update_fee`, a malicious party can inflate fees committed on HTLC input/output pairs and redirect this inflated fee to a single-controlled output attached to these malleable pairs. This won't be punishable by an honest party in case of revoked state broadcast and thus enable to partially escape the penalty.
>>
>> As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw` is 10000 sats.
>>
>> At state N, Alice balance is all on her side. She announces 10 outgoing HTLCs of value 7000 sats.
>>
>> As Commitment tx weight with 10 outputs is 2844 (post-anchor), the absolute fee committed is 28440 sats.
>>
>> As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat. This absolute fee aims to pay the miner fee in case Alice needs to timeout HTLC onchain.
>>
>> Her remaining balance is 1560 sat, above both dust_limit_satoshi and the channel reserve as constrained by Bob (likely 1%).
>>
>> Alice waits for HTLCs to expire and advances state to N+1. Then she empties her balance minus reserve by sending a HTLC relayed by Bob either to a colluding channel on the rest of network or back to an onchain address thanks to a swap service.
>>
>> At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost all of the absolute fee to a new P2WPKH output only controlled by her. She broadcasts the revoked commitment tx N and burns 28440 sats in commitment fee.
>>
>> Her balance of 1560 sats is punished by Bob's justice transaction.
>>
>> After confirmation and thus maturing of the CSV of 1 on her HTLC output Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.
>>
>> Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560 (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs fees) - 340*10 (HTLCs output) = 125600 sats.
>>
>> Alice's gain is superior at channel value as it has been partially double-spend by bypassing the revocation punishment.
>>
>> # Limitations of Attacker Success
>>
>> A first limitation of attack success which can be point of is the fact that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a honest party can punish this output before the malicious spend them with the revoked HTLC txn. In practice a malicious party can attach a branch of descendants to its anchor output and that way only allowing one more mempool victim's transaction on the revoked commitment. The victim must spend all outputs at once or otherwise they're going to obstrucate each other at mempool acceptance.
>>
>> Secondly, other limitations are the per-implementation channel policy `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and acceptance bound of `update_fee`. A quick look at default policies, even if they vary between deploy implementations, let it think there is room to escape a substantial part of channel value.
>>
>> Lastly, after the revoked commitment transaction is confirmed, both attacker and victim are in a feerate race to confirm either a justice transaction or a malicious HTLC-timeout. As fee estimator logic of the victim's implementation is a public piece of knowledge, it shouldn't be hard for the attacker to know the range of the first fee bid and override it by a bit to confirm it before the victim RBF at next block. Currently, not all implementations have RBF of justice transactions.
>>
>> As of today, if anchor output is deployed and given how LN implementations are managing fees/rebroadcast of onchain transactions, the chance of attack success sounds high in my opinion.
>>
>> # Countermeasures
>>
>> Channel policies could be tighter, like bounded further down `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the latter, it's pretty hard as a) fee estimators diverge on mempool views b) an attacker can craft escape HTLC-txn in a period of high-fee and patiently waits a low-fee period to launch the exploitation.
>>
>> Justice transactions can adopt a scorched earth approach binding their feerate to the max to increase odds of winning the feerate race and thus deter attackers. But this sounds like introducing a griefing attack vector. Your counterparty can burn more of your lawful balance in fees than you'll punish its revoked balance.
>>
>> A workable option would be to patch current anchor spec to remove `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing a minimal relay fee.
>>
>> Thoughts of further countermeasures ?
>>
>> I think the vulnerability described is mostly right but please point any missing details.
>>
>> Cheers,
>>
>> Antoine
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-02-04 📝 Original message: 2) ...

2023-06-09T12:58:30Z

In reply to nevent1q…vsw4
_________________________

📅 Original date posted:2020-02-04
📝 Original message:
2) lnd is getting the API you need in the next release (v0.10), that
let you subscribe to HTLC events. See PR
https://github.com/lightningnetwork/lnd/pull/3848. The notification
won't be signed (but the stream uses TLS), but that can easily be
added using the `signmessage` API:
https://api.lightning.community/#signmessage

Cheers,
Johan

On Sun, Feb 2, 2020 at 1:46 PM Pavol Rusnak via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Hi all!
>
> I have a couple of unrelated questions, hope you can give me some pointers.
>
> 1) Is c-lightning going to support Sphinx or other form of spontaneous payments?
>
> 2) Can a lightning node (such as lnd or c-lightning) send a push notification (e.g. to a webhook) when it receives or routes a payment? If yes, is this notification cryptographically signed (for example with the node's private key)? Is this documented somewhere?
>
> Thanks!
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2019-10-30 📝 Original message: On ...

2023-06-09T12:56:49Z

In reply to nevent1q…00qq
_________________________

📅 Original date posted:2019-10-30
📝 Original message:
On Mon, Oct 28, 2019 at 6:16 PM David A. Harding <dave at dtrt.org> wrote:

> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
> than the default maximum mempool size in Bitcoin Core).
>

Thanks, Dave, I wasn't aware the limits would allow this many outputs. And
as your calculation shows, this opens up the potential for free relay of
large amounts of data.

We could start special casing to only allow this for "LN commitment-like"
transactions, but this would be application specific changes, and your
calculation shows that even with the BOLT2 numbers there still exists cases
with a large number of children.

We are moving forward with adding a 1 block delay to all outputs to utilize
the current carve-out rule, and the changes aren't that bad. See Joost's
post in "[PATCH] First draft of option_simplfied_commitment"

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191030/bc2a90f3/attachment.html>;

📅 Original date posted:2019-10-28 📝 Original message: > ...

2023-06-09T12:56:48Z

In reply to nevent1q…pjm6
_________________________

📅 Original date posted:2019-10-28
📝 Original message:
>
>
> I don’te see how? Let’s imagine Party A has two spendable outputs, now
> they stuff the package size on one of their spendable outlets until it is
> right at the limit, add one more on their other output (to meet the
> Carve-Out), and now Party B can’t do anything.

Matt: With the proposed change, party B would always be able to add a child
to its output, regardless of what games party A is playing.

Thanks for the explanation, Jeremy!

> In terms of relay cost, if an ancestor can be replaced, it will invalidate
> all it's children, meaning that no one paid for that broadcasting. This can
> be fixed by appropriately assessing Replace By Fee update fees to
> encapsulate all descendants, but there are some tricky edge cases that make
> this non-obvious to do.

Relay cost is the obvious problem with just naively removing all limits.
Relaxing the current rules by allowing to add a child to each output as
long as it has a single unconfirmed parent would still only allow free
relay of O(size of parent) extra data (which might not be that bad? Similar
to the carve-out rule we could put limits on the child size). This would be
enough for the current LN use case (increasing fee of commitment tx), but
not for OP_SECURETHEBAG I guess, as you need the tree of children, as you
mention.

I imagine walking the mempool wouldn't change much, as you would only have
one extra child per output. But here I'm just speculating, as I don't know
the code well enough know what the diff would look like.

> OP_SECURETHEBAG can help with the LN issue by putting all HTLCS into a
> tree where they are individualized leaf nodes with a preceding CSV. Then,
> the above fix would ensure each HTLC always has time to close properly as
> they would have individualized lockpoints. This is desirable for some
> additional reasons and not for others, but it should "work".

This is interesting for an LN commitment! You could really hide every
output of the commitment within OP_STB, which could either allow bypassing
the fee-pinning attack entirely (if the output cannot be spent unconfirmed)
or adding fees to the commitment using SIGHASH_SINGLE|ANYONECANPAY.

- Johan

On Sun, Oct 27, 2019 at 8:13 PM Jeremy <jlrubin at mit.edu> wrote:

> Johan,
>
> The issues with mempool limits for OP_SECURETHEBAG are related, but have
> distinct solutions.
>
> There are two main categories of mempool issues at stake. One is relay
> cost, the other is mempool walking.
>
> In terms of relay cost, if an ancestor can be replaced, it will invalidate
> all it's children, meaning that no one paid for that broadcasting. This can
> be fixed by appropriately assessing Replace By Fee update fees to
> encapsulate all descendants, but there are some tricky edge cases that make
> this non-obvious to do.
>
> The other issue is walking the mempool -- many of the algorithms we use in
> the mempool can be N log N or N^2 in the number of descendants. (simple
> example: an input chain of length N to a fan out of N outputs that are all
> spent, is O(N^2) to look up ancestors per-child, unless we're caching).
>
> The other sort of walking issue is where the indegree or outdegree for a
> transaction is high. Then when we are computing descendants or ancestors we
> will need to visit it multiple times. To avoid re-expanding a node, we
> currently cache it with a set. This uses O(N) extra memory and makes O(N
> Log N) (we use std::set not unordered_set) comparisons.
>
> I just opened a PR which should help with some of the walking issues by
> allowing us to cheaply cache which nodes we've visited on a run. It makes a
> lot of previously O(N log N) stuff O(N) and doesn't allocate as much new
> memory. See: https://github.com/bitcoin/bitcoin/pull/17268.
>
>
> Now, for OP_SECURETHEBAG we want a particular property that is very
> different from with lightning htlcs (as is). We want that an unlimited
> number of child OP_SECURETHEBAG txns may extend from a confirmed
> OP_SECURETHEBAG, and then at the leaf nodes, we want the same rule as
> lightning (one dangling unconfirmed to permit channels).
>
> OP_SECURETHEBAG can help with the LN issue by putting all HTLCS into a
> tree where they are individualized leaf nodes with a preceding CSV. Then,
> the above fix would ensure each HTLC always has time to close properly as
> they would have individualized lockpoints. This is desirable for some
> additional reasons and not for others, but it should "work".
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Fri, Oct 25, 2019 at 10:31 AM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> I don’te see how? Let’s imagine Party A has two spendable outputs, now
>> they stuff the package size on one of their spendable outlets until it is
>> right at the limit, add one more on their other output (to meet the
>> Carve-Out), and now Party B can’t do anything.
>>
>> On Oct 24, 2019, at 21:05, Johan Torås Halseth <johanth at gmail.com> wrote:
>>
>>
>> It essentially changes the rule to always allow CPFP-ing the commitment
>> as long as there is an output available without any descendants. It changes
>> the commitment from "you always need at least, and exactly, one non-CSV
>> output per party. " to "you always need at least one non-CSV output per
>> party. "
>>
>> I realize these limits are there for a reason though, but I'm wondering
>> if could relax them. Also now that jeremyrubin has expressed problems with
>> the current mempool limits.
>>
>> On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists at mattcorallo.com>
>> wrote:
>>
>>> I may be missing something, but I'm not sure how this changes anything?
>>>
>>> If you have a commitment transaction, you always need at least, and
>>> exactly, one non-CSV output per party. The fact that there is a size
>>> limitation on the transaction that spends for carve-out purposes only
>>> effects how many other inputs/outputs you can add, but somehow I doubt
>>> its ever going to be a large enough number to matter.
>>>
>>> Matt
>>>
>>> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
>>> > Reviving this old thread now that the recently released RC for bitcoind
>>> > 0.19 includes the above mentioned carve-out rule.
>>> >
>>> > In an attempt to pave the way for more robust CPFP of on-chain
>>> contracts
>>> > (Lightning commitment transactions), the carve-out rule was added in
>>> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked
>>> on
>>> > an implementation of a new commitment format for utilizing the Bring
>>> > Your Own Fees strategy using CPFP, I’m wondering if the special case
>>> > rule should have been relaxed a bit, to avoid the need for adding a 1
>>> > CSV to all outputs (in case of Lightning this means HTLC scripts would
>>> > need to be changed to add the CSV delay).
>>> >
>>> > Instead, what about letting the rule be
>>> >
>>> > The last transaction which is added to a package of dependent
>>> > transactions in the mempool must:
>>> > * Have no more than one unconfirmed parent.
>>> >
>>> > This would of course allow adding a large transaction to each output of
>>> > the unconfirmed parent, which in effect would allow an attacker to
>>> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
>>> > this a problem with the current mempool acceptance code in bitcoind? I
>>> > would imagine evicting transactions based on feerate when the max
>>> > mempool size is met handles this, but I’m asking since it seems like
>>> > there has been several changes to the acceptance code and eviction
>>> > policy since the limit was first introduced.
>>> >
>>> > - Johan
>>> >
>>> >
>>> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au
>>> > <mailto:rusty at rustcorp.com.au>> wrote:
>>> >
>>> > Matt Corallo <lf-lists at mattcorallo.com
>>> > <mailto:lf-lists at mattcorallo.com>> writes:
>>> > >>> Thus, even if you imagine a steady-state mempool growth,
>>> unless the
>>> > >>> "near the top of the mempool" criteria is "near the top of the
>>> next
>>> > >>> block" (which is obviously *not* incentive-compatible)
>>> > >>
>>> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
>>> next
>>> > >> block, and assumed you'd only allow RBF if the old package
>>> wasn't
>>> > in the
>>> > >> top and the replacement would be. That seems incentive
>>> > compatible; more
>>> > >> than the current scheme?
>>> > >
>>> > > My point was, because of block time variance, even that criteria
>>> > doesn't hold up. If you assume a steady flow of new transactions
>>> and
>>> > one or two blocks come in "late", suddenly "top 4MWeight" isn't
>>> > likely to get confirmed until a few blocks come in "early". Given
>>> > block variance within a 12 block window, this is a relatively
>>> likely
>>> > scenario.
>>> >
>>> > [ Digging through old mail. ]
>>> >
>>> > Doesn't really matter. Lightning close algorithm would be:
>>> >
>>> > 1. Give bitcoind unileratal close.
>>> > 2. Ask bitcoind what current expidited fee is (or survey your
>>> mempool).
>>> > 3. Give bitcoind child "push" tx at that total feerate.
>>> > 4. If next block doesn't contain unilateral close tx, goto 2.
>>> >
>>> > In this case, if you allow a simpified RBF where 'you can replace
>>> if
>>> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
>>> > old tx isnt',
>>> > it works.
>>> >
>>> > It allows someone 100k of free tx spam, sure. But it's simple.
>>> >
>>> > We could further restrict it by marking the unilateral close
>>> somehow to
>>> > say "gonna be pushed" and further limiting the child tx weight
>>> (say,
>>> > 5kSipa?) in that case.
>>> >
>>> > Cheers,
>>> > Rusty.
>>> > _______________________________________________
>>> > Lightning-dev mailing list
>>> > Lightning-dev at lists.linuxfoundation.org
>>> > <mailto:Lightning-dev at lists.linuxfoundation.org>
>>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>> >
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191028/92777d7b/attachment-0001.html>;

📅 Original date posted:2019-10-24 📝 Original message: ...

2023-06-09T12:56:46Z

In reply to nevent1q…p0m0
_________________________

📅 Original date posted:2019-10-24
📝 Original message:
Reviving this old thread now that the recently released RC for bitcoind
0.19 includes the above mentioned carve-out rule.

In an attempt to pave the way for more robust CPFP of on-chain contracts
(Lightning commitment transactions), the carve-out rule was added in
https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on an
implementation of a new commitment format for utilizing the Bring Your Own
Fees strategy using CPFP, I’m wondering if the special case rule should
have been relaxed a bit, to avoid the need for adding a 1 CSV to all
outputs (in case of Lightning this means HTLC scripts would need to be
changed to add the CSV delay).

Instead, what about letting the rule be

The last transaction which is added to a package of dependent
transactions in the mempool must:
* Have no more than one unconfirmed parent.

This would of course allow adding a large transaction to each output of the
unconfirmed parent, which in effect would allow an attacker to exceed the
MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is this a problem
with the current mempool acceptance code in bitcoind? I would imagine
evicting transactions based on feerate when the max mempool size is met
handles this, but I’m asking since it seems like there has been several
changes to the acceptance code and eviction policy since the limit was
first introduced.

- Johan

On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Matt Corallo <lf-lists at mattcorallo.com> writes:
> >>> Thus, even if you imagine a steady-state mempool growth, unless the
> >>> "near the top of the mempool" criteria is "near the top of the next
> >>> block" (which is obviously *not* incentive-compatible)
> >>
> >> I was defining "top of mempool" as "in the first 4 MSipa", ie. next
> >> block, and assumed you'd only allow RBF if the old package wasn't in the
> >> top and the replacement would be. That seems incentive compatible; more
> >> than the current scheme?
> >
> > My point was, because of block time variance, even that criteria doesn't
> hold up. If you assume a steady flow of new transactions and one or two
> blocks come in "late", suddenly "top 4MWeight" isn't likely to get
> confirmed until a few blocks come in "early". Given block variance within a
> 12 block window, this is a relatively likely scenario.
>
> [ Digging through old mail. ]
>
> Doesn't really matter. Lightning close algorithm would be:
>
> 1. Give bitcoind unileratal close.
> 2. Ask bitcoind what current expidited fee is (or survey your mempool).
> 3. Give bitcoind child "push" tx at that total feerate.
> 4. If next block doesn't contain unilateral close tx, goto 2.
>
> In this case, if you allow a simpified RBF where 'you can replace if
> 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3. old tx
> isnt',
> it works.
>
> It allows someone 100k of free tx spam, sure. But it's simple.
>
> We could further restrict it by marking the unilateral close somehow to
> say "gonna be pushed" and further limiting the child tx weight (say,
> 5kSipa?) in that case.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191024/065e650f/attachment.html>;

📅 Original date posted:2019-10-25 📝 Original message: It ...

2023-06-09T12:56:46Z

In reply to nevent1q…ecj4
_________________________

📅 Original date posted:2019-10-25
📝 Original message:
It essentially changes the rule to always allow CPFP-ing the commitment as
long as there is an output available without any descendants. It changes
the commitment from "you always need at least, and exactly, one non-CSV
output per party. " to "you always need at least one non-CSV output per
party. "

I realize these limits are there for a reason though, but I'm wondering if
could relax them. Also now that jeremyrubin has expressed problems with the
current mempool limits.

On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> I may be missing something, but I'm not sure how this changes anything?
>
> If you have a commitment transaction, you always need at least, and
> exactly, one non-CSV output per party. The fact that there is a size
> limitation on the transaction that spends for carve-out purposes only
> effects how many other inputs/outputs you can add, but somehow I doubt
> its ever going to be a large enough number to matter.
>
> Matt
>
> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
> > Reviving this old thread now that the recently released RC for bitcoind
> > 0.19 includes the above mentioned carve-out rule.
> >
> > In an attempt to pave the way for more robust CPFP of on-chain contracts
> > (Lightning commitment transactions), the carve-out rule was added in
> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on
> > an implementation of a new commitment format for utilizing the Bring
> > Your Own Fees strategy using CPFP, I’m wondering if the special case
> > rule should have been relaxed a bit, to avoid the need for adding a 1
> > CSV to all outputs (in case of Lightning this means HTLC scripts would
> > need to be changed to add the CSV delay).
> >
> > Instead, what about letting the rule be
> >
> > The last transaction which is added to a package of dependent
> > transactions in the mempool must:
> > * Have no more than one unconfirmed parent.
> >
> > This would of course allow adding a large transaction to each output of
> > the unconfirmed parent, which in effect would allow an attacker to
> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
> > this a problem with the current mempool acceptance code in bitcoind? I
> > would imagine evicting transactions based on feerate when the max
> > mempool size is met handles this, but I’m asking since it seems like
> > there has been several changes to the acceptance code and eviction
> > policy since the limit was first introduced.
> >
> > - Johan
> >
> >
> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au
> > <mailto:rusty at rustcorp.com.au>> wrote:
> >
> > Matt Corallo <lf-lists at mattcorallo.com
> > <mailto:lf-lists at mattcorallo.com>> writes:
> > >>> Thus, even if you imagine a steady-state mempool growth, unless
> the
> > >>> "near the top of the mempool" criteria is "near the top of the
> next
> > >>> block" (which is obviously *not* incentive-compatible)
> > >>
> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
> next
> > >> block, and assumed you'd only allow RBF if the old package wasn't
> > in the
> > >> top and the replacement would be. That seems incentive
> > compatible; more
> > >> than the current scheme?
> > >
> > > My point was, because of block time variance, even that criteria
> > doesn't hold up. If you assume a steady flow of new transactions and
> > one or two blocks come in "late", suddenly "top 4MWeight" isn't
> > likely to get confirmed until a few blocks come in "early". Given
> > block variance within a 12 block window, this is a relatively likely
> > scenario.
> >
> > [ Digging through old mail. ]
> >
> > Doesn't really matter. Lightning close algorithm would be:
> >
> > 1. Give bitcoind unileratal close.
> > 2. Ask bitcoind what current expidited fee is (or survey your
> mempool).
> > 3. Give bitcoind child "push" tx at that total feerate.
> > 4. If next block doesn't contain unilateral close tx, goto 2.
> >
> > In this case, if you allow a simpified RBF where 'you can replace if
> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
> > old tx isnt',
> > it works.
> >
> > It allows someone 100k of free tx spam, sure. But it's simple.
> >
> > We could further restrict it by marking the unilateral close somehow
> to
> > say "gonna be pushed" and further limiting the child tx weight (say,
> > 5kSipa?) in that case.
> >
> > Cheers,
> > Rusty.
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191025/58a3d7b8/attachment.html>;

📅 Original date posted:2019-04-03 📝 Original message: Hi ...

2023-06-09T12:54:46Z

In reply to nevent1q…ztll
_________________________

📅 Original date posted:2019-04-03
📝 Original message:
Hi Pierre and list folks,

I haven't looked at the technical implications of implementing this in
detail, but I like the high-level direction this proposal is taking :)

I think it nicely ties together several concepts that have been proposed
earlier, and with the correct design could give the sender all the
flexibility needed to craft payments according to its own
reliability/privacy/fee tradeoff.

In an ideal world we would have:
- Multi-hop locks: hop decorrelation will be even more important when the
sender no longer controls the whole payment path.

- Packet switched routing: the sender can choose whether to route purely
packet switched (only knowing the destination, no need to keep any routing
table) or route purely onion-based (as today), or something in between. As
Christian mentions, this is similar to how TOR/TCP works, and I like the
flexibility this layering allows.

- Rendezvous routing: such a proposal would be nice to combine with
rendezvous routing. This way even the sender wouldn't necessarily know if
the "destination node" is just another trampoline. Maybe maybe this concern
shouldn't be on this layer though?

- Fees: (as today) the sender would set the fees it is willing to pay
between trampolines, and it could dynamically learn about fee levels needed
to reach different parts of the network. Today we know the fee needed to
reach the next hop, but here we could start out low (for the
trampoline-to-trampoline fee) and let different trampolines return
competing fee offers to get to the next hop.

As mentioned, I haven't thought about the technical implications of all
this, and it would certainly require a lot of work to get this actually
implemented.

Cheers,
Johan

On Wed, Apr 3, 2019 at 5:42 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Pierre and list,
>
> > There is another unrelated issue: because trampoline nodes don't know
> > anything about what happened before they received the onion, they may
> > unintentionnaly create overlapping routes. So we can't simply use the
> > payment_hash as we currently do, we would have to use something a bit
> > more elaborate.
>
> Just to be clear, the issue is for example with a network like:
>
>
> A ------- B -------- C
> / \
> / \
> / \
> / \
> D ------- E
>
> Then, A creates an inner trampoline onion "E->C", and an outer onion
> "A->B->E".
>
> E, on receiving the inner trampoline onion "E->C", finds that E->B
> direction is low capacity, so routes over the outer onion "E->D->B->C" with
> inner trampoline onion "C".
>
> This creates an overall route A->B->E->D->B->C.
>
> When the B->C HTLC is resolved, B can instead claim the A->B HTLC and just
> fail the D->B HTLC, thereby removing D and E from the route and claiming
> their fees, even though they participated in the route.
>
> > (maybe private keys?)
>
> Do you refer to the changing from "H"TLC to "P"TLC point-locked timelocked
> contracts?
> i.e. instead of payment hash / preimage, we use payment point / scalar.
>
> I think a few ideas would be improved by this.
>
> 1. Trampoline payments, as described above.
> 2. Offline vending machines
> - Instead of storing a fixed number of invoices from the always-online
> payment node, store a HD parent point and derive child points for payments.
> 3. Enables payment decorrelation.
>
> Perhaps we should consider switching to payment points/scalars sometime
> soon.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190403/24eb7d58/attachment.html>;

📅 Original date posted:2018-11-27 📝 Original message: ...

2023-06-09T12:52:47Z

In reply to nevent1q…2dgg
_________________________

📅 Original date posted:2018-11-27
📝 Original message:
(excuse me for not yet understanding what this extra complexity gives us)

To summarize: My suggestion was to only add an optional field to the
invoice, and let the recepient wait until all funds have received before
pulling the payment. No changes to the onion.

We briefly discussed this during the last call, that the extra bit set in
the onion will be necessary to support Partial Payments (PP?) in the
spontaneous payments case.

However, as we don't yet have spontaneous payments specced out, wouldn't
this be something to be added at that point?

I just feel not adding the extra bit to the onion would make the
implementation of PP near trivial, and still don't see the downsides of not
adding it.

Cheers, Johan

On Mon, Nov 26, 2018, 09:10 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:

> Good morning Johan,
>
> I believe what Rusty refers to here is a probe by an intermediate node,
> rather than a probe by the source node (who, as we know, already knows
> whether the payee supports AMP or not, by the invoice).
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, November 26, 2018 3:58 PM, Johan Torås Halseth <
> johanth at gmail.com> wrote:
>
> This shouldn't be problem, as the invoice will already indicate that the
> node supports BaseAMP. If you have a reason to not reveal that you support
> BAMP for certain invoices, you'll just not specify it in the invoice, and
> act non-BAMPy when receiving payments to this payment hash.
>
> Of course, this will also be opt-in for both sides and won't affect
> existing nodes in any way.
>
> Cheers,
> Johan
>
> On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Johan Torås Halseth <johanth at gmail.com> writes:
>> > Seems like we can restrict the changes to BOLT11 by having the receiver
>> > assume NAMP for incoming payments < invoice_amount. (with some timeout
>> of
>> > course, but that would need to be the case even when the sender is
>> > signalling NAMP).
>>
>> This would effectively become a probe for Base AMP; if you get a partial
>> payment error, it's because the recipient didn't support Base AMP.
>>
>> Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then
>> it's explicitly opt-in for both sides and doesn't affect existing nodes
>> in any way.
>>
>> Cheers,
>> Rusty.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181127/760d330d/attachment-0001.html>;

📅 Original date posted:2018-11-26 📝 Original message: This ...

2023-06-09T12:52:46Z

In reply to nevent1q…d9xg
_________________________

📅 Original date posted:2018-11-26
📝 Original message:
This shouldn't be problem, as the invoice will already indicate that the
node supports BaseAMP. If you have a reason to not reveal that you support
BAMP for certain invoices, you'll just not specify it in the invoice, and
act non-BAMPy when receiving payments to this payment hash.

Of course, this will also be opt-in for both sides and won't affect
existing nodes in any way.

Cheers,
Johan

On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell <rusty at rustcorp.com.au>
wrote:

> Johan Torås Halseth <johanth at gmail.com> writes:
> > Seems like we can restrict the changes to BOLT11 by having the receiver
> > assume NAMP for incoming payments < invoice_amount. (with some timeout of
> > course, but that would need to be the case even when the sender is
> > signalling NAMP).
>
> This would effectively become a probe for Base AMP; if you get a partial
> payment error, it's because the recipient didn't support Base AMP.
>
> Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then
> it's explicitly opt-in for both sides and doesn't affect existing nodes
> in any way.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181126/67166a9b/attachment.html>;

📅 Original date posted:2018-11-21 📝 Original message: Seems ...

2023-06-09T12:52:45Z

In reply to nevent1q…k3cd
_________________________

📅 Original date posted:2018-11-21
📝 Original message:
Seems like we can restrict the changes to BOLT11 by having the receiver
assume NAMP for incoming payments < invoice_amount. (with some timeout of
course, but that would need to be the case even when the sender is
signalling NAMP).

Cheers,
Johan

On Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Rusty,
>
> > And do not play with `amount_to_forward`, as it's an important
> > signal to the final node that the previous node did not offer less value
> > for the HTLC than it was supposed to. (You could steal the top bit to
> > signal partial payment if you really want to).
>
> I do not view this as playing with the existing `amt_to_forward`, but
> rather retaining its previous use.
>
> If it helps, we can rewrite the *current* pre-AMP spec as below:
>
> 2. data:
> ...
> * [`8` : `amt_to_forward` / `amt_to_pay`]
>
> ...
>
> * `amt_to_forward` - for **non-final** nodes, this is the value to forward
> to the next node.
> Non-final nodes MUST check:
>
> incoming_htlc_amt - fee >= amt_to_forward
>
> * `amt_to_pay` - for **final** nodes, this is the value that is intended
> to reach it.
> Final nodes MUST check:
>
> incoming_htlc_amt >= amt_to_pay
>
> Then for Base AMP:
>
> * `amt_to_pay` - for **final** nodes, this is the total value that is
> intended to reach it.
> If `incomplete_payment` flag is not set, final nodes MUST check:
>
> incoming_htlc_amt >= amt_to_pay
>
> If `incomplete_payment` flag is set, then final nodes must claim HTLCs
> only if:
>
> sum(incoming_htlc_amt) >= amt_to_pay
>
> Where `sum(incoming_htlc_amt)` is the total `incoming_htlc_amt` for all
> incoming HTLCs terminating at this final node with the same `payment_hash`.
>
>
>
> Now perhaps we can argue that for AMP we should have two fields
> `amt_to_pay_for_this_partial_payment` and `amt_to_pay_for_total_payment`
> instead.
>
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181121/8f56db8f/attachment.html>;

📅 Original date posted:2018-11-13 📝 Original message: Good ...

2023-06-09T12:52:40Z

In reply to nevent1q…h5na
_________________________

📅 Original date posted:2018-11-13
📝 Original message:
Good evening Z and list,

I'm wondering, since these payments are no longer atomic, should we name it
accordingly?

Cheers,
Johan

On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> I propose the below to support Base AMP.
>
> The below would allow arbitrary merges of paths, but not arbitrary
> splits. I am uncertain about the safety of arbitrary splits.
>
> ### The `multipath_merge_per_hop` type (`option_base_amp`)
>
> This indicates that payment has been split by the sender using Base AMP,
> and that the receiver should wait for the total intended payment before
> forwarding or claiming the payment.
> In case the receiving node is not the last node in the path, then
> succeeding hops MUST be the same across all splits.
>
> 1. type: 1 (`termination_per_hop`)
> 2. data:
> * [`8` : `short_channel_id`]
> * [`8` : `amt_to_forward`]
> * [`4` : `outgoing_cltv_value`]
> * [`8` : `intended_total_payment`]
> * [`4` : `zeros`]
>
> The contents of this hop will be the same across all paths of the Base AMP.
> The `payment_hash` of the incoming HTLCs will also be the same across all
> paths of the Base AMP.
>
> `intended_total_payment` is the total amount of money that this node
> should expect to receive in all incoming paths to the same `payment_hash`.
>
> This may be the last hop of a payment onion, in which case the `HMAC` for
> this hop will be `0` (the same rule as for `per_hop_type` 0).
>
> The receiver:
>
> * MUST impose a reasonable timeout for waiting to receive all component
> paths, and fail all incoming HTLC offers for the `payment_hash` if they
> have not totalled equal to `intended_total_payment`.
> * MUST NOT forward (if an intermediate node) or claim (if the final node)
> unless it has received a total greater or equal to `intended_total_payment`
> in all incoming HTLCs for the same `payment_hash`.
>
> The sender:
>
> * MUST use the same `payment_hash` for all paths of a single multipath
> payment.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181113/6342ecf1/attachment-0001.html>;

📅 Original date posted:2018-11-09 📝 Original message: Neat! ...

2023-06-09T12:52:23Z

In reply to nevent1q…zmr4
_________________________

📅 Original date posted:2018-11-09
📝 Original message:
Neat! I think this is similar to what has been briefly discussed earlier
about hybrid packet-switched/circuit-switched payment routing.

B doesn't have to care about how the payment gets from C to D, but she
knows it must go through D, keeping privacy intact. This would be exactly
equivalent to how TOR works today I would think.

C must also make sure the detour route stays within the fee limit of course.

Cheers,
Johan

On Fri, Nov 9, 2018 at 7:02 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> As was discussed directly in summit, we accept link-lvel payment splitting
> (scid is not binding), and provisionally accept rendez-vous routing.
>
> It strikes me, that even if your node has only a single channel to the
> next node (c-lightning), it is possible, to still perform link-level
> payment splitting/re-routing.
>
> For instance, consider this below graph:
>
> E<---D--->C<---B
> ^ /
> | /
> |L
> A
>
> In the above, B requests a route from B->C->D->E.
>
> However, C cannot send to D, since the channel direction is saturated in
> favor of D.
>
> Alternately, C can route to D via A instead. It holds the (encrypted)
> route from D to E. It can take that sub-route and treat it as a partial
> route-to-payee under rendez-vous routing, as long as node A supports
> rendez-vous routing.
>
> This can allow re-routing or payment splitting over multiple hops.
>
> Even though C does not know the number of remaining hops between D and the
> destination, its alternative is to earn nothing anyway as its only
> alternative is to fail the routing. At least with this, there is a chance
> it can succeed to send the payment to the final destination.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/813c32fc/attachment.html>;

📅 Original date posted:2018-11-01 📝 Original message: Hi, ...

2023-06-09T12:52:00Z

In reply to nevent1q…vqu0
_________________________

📅 Original date posted:2018-11-01
📝 Original message:
Hi, Margherita,

If you haven't already, look into "data loss protection" as defined in the
BOLTs. It is similar to to what you are suggesting, with A being able to
tell B that it lost state for the A<->B channel, and if B is cooperative it
will help A recover its funds.

You can also look into watchtowers, and static and dynamic channel backups,
as they touch onto what you are describing.

Cheers,
Johan

On Thu, Nov 1, 2018 at 12:59 AM Margherita Favaretto <s170065 at student.dtu.dk>
wrote:

> Good morning dev-lightning community,
>
> Last weekend, I had the opportunity to take part in "LightningHackdayNYC".
> It was an incredible event, thanks to all organizers, to all speakers and
> all people available to share all own knowledge.
> Discussing with the people of the community, I could define better the
> problem that I'm focusing on and have some ideas for the solution.
> I've created a project on GitHub:
> https://github.com/margheritafav/LightningNetworkProject , where you
> could find a draft of my research, and also you are welcome to add your
> comments and feedback.
>
>
> To recap, the aim of the project is realizing a recovering protocol for
> Lightning Network. As someone suggested me in the previous e-mails, Eltoo
> is already solving this problem in part. With Eltoo, the nodes are able to
> share the last status of the channel, so if one of the two nodes loses some
> information, it can simply ask to the other node to share the most recent
> status. Unfortunately, this mechanism doesn't include the case that the
> other node doesn't share the last transaction, but instead an older one,
> more favourable for own balance. My project aims to solve this particular
> issue and make the protocol more solid to face completely the case of a
> false positive node.
>
> Idea: The main idea of the design is using the other connected nodes as a
> back-up of own recent status.
> *I**f a node A is connected to a node B and a node C, for each
> transaction between A and B, A sends an encrypted information, regarding
> the last commitment transaction with B, to C. For each commitment
> transaction with C, A sends an encrypted information, regarding the
> last commitment transaction with C, to B.*
> In this way, if A loses the last transactions, she may ask the information
> to the other connected node and update the status.
>
> I think that this idea can solve the current lack in Eltoo and I'm
> planning to analyze more this solution in the next days. Any
> thoughts/suggestions are really appreciated to proceed in the wisest way
> and find a solution that can also cover all your needs. If someone of you
> is interested in this research, I'm available to share more details about
> the design of my idea and I'm open to discussion. Moreover, if someone is
> already working on this research topic, please not hesitate to write me for
> possible collaborations to work together.
>
>
> Thank you in advance,
> Margherita Favaretto
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181101/0b2b32b3/attachment-0001.html>;

📅 Original date posted:2018-10-16 📝 Original message: > ...

2023-06-09T12:51:47Z

In reply to nevent1q…vzlu
_________________________

📅 Original date posted:2018-10-16
📝 Original message:
>
> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.
>

I think we should strive to splice in 1 on-chain tx, as if not the biggest
benefit really is lost compared to just closing and reopening the channel.

Complexity wise I don't think it will be that much to gain from the 2-tx
proposal as (if I understand the proposal correctly) there will be even
more transaction types with new scripts to code up and maintain.

On Tue, Oct 16, 2018 at 5:38 AM Christian Decker <decker.christian at gmail.com>
wrote:

> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
> writes:
>
> >> One thing that I think we should lift from the multiple funding output
> >> approach is the "pre seating of inputs". This is cool as it would allow
> >> clients to generate addresses, that others could deposit to, and then
> have
> >> be spliced directly into the channel. Public derivation can be used,
> along
> >> with a script template to do it non-interactively, with the clients
> picking
> >> up these deposits, and initiating a splice in as needed.
> >
> > I am uncertain what this means in particular, but let me try to
> > restate what you are talking about in other terms:
> >
> > 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> > 2. When somebody sends to one of the onchain addresses in the path,
> their client detects this.
> > 3. The client initiates a splice-in automatically from this UTXO paying
> to that address into the channel.
> >
> > It seems to me naively that the above can be done by the client
> > software without any modifications to the Lightning Network BOLT
> > protocol, as long as the BOLT protocol is capable of supporting *some*
> > splice-in operation, i.e. it seems to be something that a client
> > software can implement as a feature without requiring a BOLT change.
> > Or is my above restatement different from what you are talking about?
> >
> > How about this restatement?
> >
> > 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> > 2. The base of the above is actually a combined private-public keypair
> of both sides (e.g. created via MuSig or some other protocol). Thus the
> addresses require cooperation of both parties to spend.
> > 3. When somebody sends to one of the onchain addresses in the path,
> their client detects this.
> > 4. The client updates the current transaction state, such that the new
> commit transaction has two inputs ( the original channel transaction and
> the new UTXO).
> >
> > The above seems unsafe without trust in the other peer, as, the other
> > peer can simply refuse to create the new commit transaction. Since
> > the address requires both parties to spend, the money cannot be spent
> > and there is no backoff transaction that can be used. But maybe you
> > can describe some mechanism to ensure this, if this is what is meant
> > instead?
>
> This could easily be solved by making the destination address a Taproot
> address, which by default is just a 2-of-2, but in the uncooperative
> case it can reveal the script it commits to, which is just a timelocked
> refund that requires a single-sig. The only problem with this is that
> the refund would be non-interactive, and so the entirety of the funds,
> that may be from a third-party, need to be claimed by one endpoint,
> i.e., there is no splitting the funds in case of an uncollaborative
> refund. Not sure how important that is though, since I don't think
> third-party funds will come from unrelated parties, e.g., most of these
> funds will come from an on-chain wallet that is under the control of
> either parties so the refund should go back to that party anyway.
>
> Cheers,
> Christian
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181016/5a6baacf/attachment.html>;

📅 Original date posted:2018-10-10 📝 Original message: I ...

2023-06-09T12:51:33Z

In reply to nevent1q…vzqd
_________________________

📅 Original date posted:2018-10-10
📝 Original message:
I agree the r-fields are useful to populate for public channels in many
situations, but care must be taken to not _always_ try them first without
accounting for potentially high fees on those channels.

- Johan
On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell <rusty at blockstream.com> wrote:

> Pierre <pm+lists at acinq.fr> writes:
> >> But there's no reason to believe that the invoicer has more knowledge
> about all but the last hop.
> >
> > I disagree: there is a good chance that the receiver is a 24/7 running
> > merchant/website, with a full up-to-date view of the network, whereas
> > the payer is most likely a mobile wallet with less
> > accurate/partial/out of date information.
> >
> > At least this is what we are seeing on the current mainnet. Routing
> > table sync is hard on mobile clients, and I think that it makes sense
> > that receivers "help" senders, after all incentives are aligned.
>
> Good qualification; I agree. Certainly if the payer knows its
> information is less reliable it should prefer the provided route.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181010/f522d3b5/attachment-0001.html>;

📅 Original date posted:2018-09-20 📝 Original message: I was ...

2023-06-09T12:51:31Z

In reply to nevent1q…2c6g
_________________________

📅 Original date posted:2018-09-20
📝 Original message:
I was thinking you could just make many requests to get the same
information, but if you always choose the same channel as long as its
capacity meets the requirement, then not much is learnt :)

On Thu, Sep 20, 2018 at 9:26 AM Christian Decker <decker.christian at gmail.com>
wrote:

> That might not be so desirable, since it leaks the current channel
> capacity to the user. Depending on how fine grained the amount in the
> invoice is and how the user can control it, he could do a binary search
> over capacities and very reliably tell how much capacity you have and
> track it over time. That is still the case for a single channel, but if
> you always chose the same channel it reduces how much info is leaked.
>
> Cheers,
> Christian
>
> Johan Torås Halseth <johanth at gmail.com> writes:
> > Any reason not to include _all_ (up to a limit) incoming channels with
> > sufficient capacity?
> >
> > Cheers,
> > Johan
> >
> > On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <rusty at blockstream.com>
> wrote:
> >
> >> Hi all,
> >>
> >> I'm considering a change to c-lightning, where `invoice` would
> >> automatically append an 'r' field for a channel which has sufficient
> >> *incoming* capacity for the amount (using a weighted probability across
> >> our peers).
> >>
> >> This isn't quite what 'r' was for, but it would be a useful
> >> hint for payment routing and also potentially for establishing an
> >> initial channel. This is an issue for the Blockstream Store which
> >> deliberately doesn't advertize an address any more to avoid
> >> centralization.
> >>
> >> Thoughts welcome!
> >> Rusty.
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180920/114dfd18/attachment.html>;

📅 Original date posted:2018-09-20 📝 Original message: Any ...

2023-06-09T12:51:30Z

In reply to nevent1q…w4dh
_________________________

📅 Original date posted:2018-09-20
📝 Original message:
Any reason not to include _all_ (up to a limit) incoming channels with
sufficient capacity?

Cheers,
Johan

On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell <rusty at blockstream.com> wrote:

> Hi all,
>
> I'm considering a change to c-lightning, where `invoice` would
> automatically append an 'r' field for a channel which has sufficient
> *incoming* capacity for the amount (using a weighted probability across
> our peers).
>
> This isn't quite what 'r' was for, but it would be a useful
> hint for payment routing and also potentially for establishing an
> initial channel. This is an issue for the Blockstream Store which
> deliberately doesn't advertize an address any more to avoid
> centralization.
>
> Thoughts welcome!
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180920/83c90ab3/attachment.html>;

📅 Original date posted:2018-07-10 📝 Original message: A ...

2023-06-09T12:51:01Z

In reply to nevent1q…gyfg
_________________________

📅 Original date posted:2018-07-10
📝 Original message:
A simple way to see how rebalancing could be beneficial, is to observe that you only know the channel capacity (not the balance!) of the channels you don’t belong to.
If everybody is being good stewards and are rebalancing their channels, then picking a route to send a payment over is more likely to succeed than if everybody only has channels depleted in one direction (extreme case).

On Thu, Jul 5, 2018 at 12:06, Dmytro Piatkivskyi <dmytro.piatkivskyi at ntnu.no> wrote:
Hi Olaoluwa,

I¹m glad we¹re thinking the same direction.

Generally, I think we (the community) worry too much about equilibrium.
There is no really proof that it improves the network. On the other hand,
money being locked in channel is of major issue. Some nodes may be used
mostly for sending payments, whereas others mostly receiving. Therefore,
the distribution of funds in channels should be dictated not by
equilibrium but by nodes' plans to send and receive.

> In this case, equilibrium means being able to recv as much as you can
>send on all your channels.

Now it seems there are two ways to define equilibrium. You have described
one where each node is trying to keep the ability to send and receive at
the same level. I¹ll repeat the above argument, some nodes may be used
mostly for sending payments, whereas others mostly receiving. Therefore,
such definition is unjustified from the individual viewpoint. Another
definition of equilibrium is when a node distributes equally the available
balance amongst the channels it has. Your argument still stands here as
such equilibrium minimises the number of depleted channels.

> The argument here is that by maintaining this balance, one is likely to
>reduce the number of routing failures from failed HTLC forwarding, as the
>channel is equally likely to be able to carry an HTLC in either direction.

If a node has no balance, its channels are depleted. There is nothing we
can do with this. Such nodes are bad for topology and should be
discouraged. Possibly by the autopilot.

> However if a few sources/sinks dominate, then channels may regularly
>become biased requiring more maintenance.

Now you¹re bringing up even more important question. If we had balanced
payments, LN could function without touching blockchain ever again
indefinitely. Skewed traffic is a big problem. Re-balancing won¹t be of
use here because having a fixed nodes¹ balances, there is only a limited
max flow that can be pushed in a particular direction. I believe autopilot
could mitigate the problem. Please, find my argument at the bottom of [1].

[1] https://github.com/lightningnetwork/lnd/issues/677

Best,
Dmytro

From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Date: Tuesday, 3 July 2018 at 22:13
To: Dmytro Piatkivskyi <dmytro.piatkivskyi at ntnu.no>
Cc: "lightning-dev at lists.linuxfoundation.org"
<lightning-dev at lists.linuxfoundation.org>
Subject: Re: [Lightning-dev] Rebalancing argument

Hi Dmytro,

Thanks for bringing this up! Sometime last year when I was at a developer
meetup that cdecker also attended, we briefly discussed a similar
question. We
we're discussing if "active rebalancing" was actually ever really
necessary.
>From my PoV, active rebalancing is rebalancing done for the purpose of
being
able to send/recv a particular payment. On white board, cdecer sketched
out a
similar argument as to Lemma 2 in that paper you linked: namely that there
will
exist an alternative path, therefore active rebalancing isn't necessary.

IMO, in a world pre-AMP, it is indeed necessary. Consider a node Bob that
wishes to receive a payment of 0.5 BTC. Bob has two channels, one with 2
BTC
max capacity, and the other with 1 BTC max capacity. If channel 1 only has
0.2
available for him to receive, and channel 2 only has 0.3 available for him
to
receive, then without active rebalancing, he's unable to receive the
payment.
However, if he completes a circular payment from channel 1 to channel 2
(or the
other way around), then he's able to receive the payment (under ideal
conditions).

In a world post-AMP, then this would seem to no longer apply. Alice the
sender
may be able to utilize the aggregate bandwidth of the network to send
minimally
two payment flows (one 0.2 and one 0.3) to satisfy the payment. As a
result,
active rebalancing isn't needed as payments can be split up to fully
utilize
the payment bandwidth at both the sender and the receiver.

> total balances of nodes in the network define the feasibility of a
>particular
> transaction, not the distribution of balances.

With multi-path payments this is precisely the case!

However, there might be an argument in favor of "passive rebalancing". I
define
passive rebalancing as rebalancing a node carries out independent of
needing to
send/receive payments themselves, in order to ensure an equilibrium state
amongst the available balances of their channels. In this case, equilibrium
means being able to recv as much as you can send on all your channels. The
argument here is that by maintaining this balance, one is likely to reduce
the
number of routing failures from failed HTLC forwarding, as the channel is
equally likely to be able to carry an HTLC in either direction.

One relevant detail w.r.t to the necessity of active rebalancing is the
directionality of payment flows in the network. If payment flows are more
or
less balanced (kinda like the ideal world Byran Vu describes in the post
[1]),
meaning people are sending out as much as they receive (so they get their
paycheck streamed to them over LN, then stream BitFlix w/ that), then it's
possible passive rebalancing isn't really necessary. However if a few
sources/sinks dominate, then channels may regularly become biased requiring
more maintenance.

Also thanks for bringing this paper to my attention! Haven't yet read it in
full yet, but happy to discover that this isn't completes new territory
and is
a problem that's been explored in the existing literature.

[1]:
https://blog.lightning.engineering/posts/2018/05/30/routing.html
<https://blog.lightning.engineering/posts/2018/05/30/routing.html>;

-- Laolu

On Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi
<dmytro.piatkivskyi at ntnu.no> wrote:

Hi everyone,

I have been working academically on the Lightning network for a while now.
I didn¹t not participate in the list to form my own vision of what it
should be. So please, bear with me if I¹ll be saying nonsense sometimes.

There has been a lot of discussion on sending cycle transactions to
oneself to Œre-balance¹ the network. On LN mailing list
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/00
1005.html> [1] or numerous
places elsewhere. There has been even a paper suggesting a smart
mechanism to do the re-balancing (see Revive or Liquidity network [2]). My
question is what do we actually get from it? [3] states that the
distribution of funds in channels does not really affect
the network liquidity. I can see cheaper fees or shorter paths if the
network is kept balanced. But don¹t you think that a smart fee strategy
will do the job?

To save your time, [4] explains the gist from [3].

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001
005.html
[2]
https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announ
ce_the_liquiditynetwork/
[3] https://arxiv.org/abs/1007.0515
[4]
https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-netw
ork-796756ad4f31

_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180710/aa9097bd/attachment.html>;

📅 Original date posted:2018-02-08 📝 Original message: Yeah, ...

2023-06-09T12:49:01Z

In reply to nevent1q…wdly
_________________________

📅 Original date posted:2018-02-08
📝 Original message:
Yeah, that is true, it would only give you the atomicity, not the decorrelation. I don’t see how you could get all the same properties using only one hash though. I guess the sender has no incentive to claim any of the payments before all of them have arrived, but you get no guarantee that partial payments cannot be made. Seems hard to do without introducing new primitives.
- Johan

On Thu, Feb 8, 2018 at 12:44, Jim Posen <jim.posen at gmail.com> wrote:
If using two hashes to deliver the payment while still getting a proof, I'm not sure what that provides above just sending regular lightning payments over multiple routes with one hash. Firstly, if there is a second hash, it would presumably be the same for all routes, making them linkable again, which AMP tries to solve. And secondly, the receiver has no incentive to claim any of the HTLCs before all of them are locked in, because in that case they are releasing the transaction receipt before fully being paid.

On Thu, Feb 8, 2018 at 8:41 AM, Johan Torås Halseth < johanth at gmail.com [johanth at gmail.com] > wrote:
An obvious way to make this compatible with proof-of-payment would be to require two hashes to claim the HTLC: the presage from the invoice payment hash (as today) + the new hash introduced here. This would give the sender a receipt after only one of the HTLCs was claimed. Would require changes to the scripts of course.
With Schnorr/EC operations this could probably be made more elegant, as mentioned.

- Johan
On Wed, Feb 7, 2018 at 18:21, Rusty Russell < rusty at rustcorp.com.au [rusty at rustcorp.com.au] > wrote:
Olaoluwa Osuntokun < laolu32 at gmail.com [laolu32 at gmail.com] > writes:
> Hi Y'all,
>
> A common question I've seen concerning Lightning is: "I have five $2
> channels, is it possible for me to *atomically* send $6 to fulfill a
> payment?". The answer to this question is "yes", provided that the receiver

This is awesome! I'm kicking myself for not proposing it :)

Unfortunately, your proposal defines a way to make multipath donations,
not multipath payments :(

In other words, you've lost proof of payment, which IMHO is critical.

Fortunately, this can be fairly trivially fixed when we go to scriptless
scripts or other equivalent decorrelation mechanism, when I think this
mechanism becomes extremely powerful.

> - Potential fee savings for larger payments, contingent on there being a
> super-linear component to routed fees. It's possible that with
> modifications to the fee schedule, it's actually *cheaper* to send
> payments over multiple flows rather than one giant flow.

This is a stretch. I'd stick with the increased reliability/privacy
arguments which are overwhelmingly compelling IMHO.

If I have any important feedback on deeper reading (and after a sccond
coffee), I'll send a separate email.

Thanks!
Rusty.
______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]

______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180208/edbfbd41/attachment-0001.html>;

📅 Original date posted:2018-02-08 📝 Original message: An ...

2023-06-09T12:49:00Z

In reply to nevent1q…cdlf
_________________________

📅 Original date posted:2018-02-08
📝 Original message:
An obvious way to make this compatible with proof-of-payment would be to
require two hashes to claim the HTLC: the presage from the invoice payment
hash (as today) + the new hash introduced here. This would give the sender
a receipt after only one of the HTLCs was claimed. Would require changes to
the scripts of course.
With Schnorr/EC operations this could probably be made more elegant, as
mentioned.

- Johan
On Wed, Feb 7, 2018 at 18:21, Rusty Russell <rusty at rustcorp.com.au> wrote:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Hi Y'all,
>
> A common question I've seen concerning Lightning is: "I have five $2
> channels, is it possible for me to *atomically* send $6 to fulfill a
> payment?". The answer to this question is "yes", provided that the
receiver

This is awesome! I'm kicking myself for not proposing it :)

Unfortunately, your proposal defines a way to make multipath donations,
not multipath payments :(

In other words, you've lost proof of payment, which IMHO is critical.

Fortunately, this can be fairly trivially fixed when we go to scriptless
scripts or other equivalent decorrelation mechanism, when I think this
mechanism becomes extremely powerful.

> - Potential fee savings for larger payments, contingent on there being a
> super-linear component to routed fees. It's possible that with
> modifications to the fee schedule, it's actually *cheaper* to send
> payments over multiple flows rather than one giant flow.

This is a stretch. I'd stick with the increased reliability/privacy
arguments which are overwhelmingly compelling IMHO.

If I have any important feedback on deeper reading (and after a sccond
coffee), I'll send a separate email.

Thanks!
Rusty.
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180208/ec4e6b34/attachment.html>;

📅 Original date posted:2018-01-16 📝 Original message: Hi ...

2023-06-09T12:48:34Z

In reply to nevent1q…sjxq
_________________________

📅 Original date posted:2018-01-16
📝 Original message:
Hi Rusty,
This is something I’ve been thinking a bit about, as I’ve stumbled into some of the edge cases you mention. Just to get on the same page: does the other side (non-funder) pay any fees in the current implementation? [1] suggests that the funder pays everything atm (on both sides’ commitment), so I reckon you are talking about dual-funder from here on.
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment
Problem#1 If we can make each side pay the fee for the HTLCs they are adding (on both commitments!), in addition to your suggestion of having them set fees independently, we get a nice bonus: Any update Alice makes, can only decrease *her* balance, not Bob’s. She can add HTLCs (she must pay HTLC+fee), do a fee update (potentially increasing the fees she must pay), or settle/fail HTLCs (can not decrease her balance). This is in contrast to the current spec, where an added HTLC can make Bob pay the fee (if he’s funder), and a fee update can make Bob not afford the new fee (the race you mentioned).
I think this will work without the check (2) you mention, since if Alice sends a fee update, then it will apply only to her HTLCs, and as mentioned can only decrease her balance. It doesn’t matter if Bob adds `max_accepted_htlcs` at the same time, since those fees will then be subtracted from his balance, and is not affected by the fee update.
This would make a lot of the edge cases go away, and would make it a lot easier to verify that a node is not violating its channel reserve. Let me know if I’m missing something.
- Johan

On Tue, Jan 16, 2018 at 0:55, Rusty Russell <rusty at rustcorp.com.au> wrote:
Hi all,

Wanted to post some thinking on this for everyone to mull over,
though I know we're all busy.

Your consideration and feedback gratefully accepted!

Problem #1
==========
For simplicity, one side (funder) sets fees, but other side
needs to check they're sufficient, and not insanely high (as *they* end
up paying for HTLC txs). If they disagree, they close channel; this
happens a fair bit on testnet, for example, and will be worse with
different backends (eg. different bitcoind versions, or btcd, etc).

Solution
--------
Have both sides set fees independently. I specify what fees my
commitment tx and HTLC txs will have, you do the same. This works in
well with dual-funder proposals.

Implementation:
--------------
c-lightning did something similar pre-spec. The way it works is both
sides set an initial fee in `open_channel`: this is the only point at
which the counterparty checks it's reasonable.

You send an `update_fee` message like now, but it has no effect on the
other side: it's applied to *you* when they 'revoke_and_ack', like any
other change.

You disallow any `update_fee` which the other side could not afford with
(1) all their current HTLCs, AND (2) the `max_accepted_htlcs` from you.
That covers the race where one side sets fees and the other adds a heap
of HTLCs and the two cross over.

Also disallow any new HTLCs you can't pay fees for (given same
worst-case calculation as above), and if the one side can't afford fees,
pull from its reserve and other side as necessary (this can only happen
during initial phase, and is the same logic as now).

Problem #2
==========
Predicting the future is hard. Today's sufficient fee may be a gross
overpayment or insufficient tomorrow.

Solution
--------
Allow multiple simultaneous fee levels.

Implementation:
---------------
This means multiple signatures in each `commitment_signed` message,
which is more work and more storage. But since our nSequence is <
0xFFFFFFFE anyway, all transactions are RBF-ready except
closing_transaction. We might want to change that; we already allow
re-negotiation of closing tx by reconnecting anyway.
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/bebe4a64/attachment.html>;

📅 Original date posted:2018-01-16 📝 Original message: Hi ...

2023-06-09T12:48:33Z

In reply to nevent1q…6tfr
_________________________

📅 Original date posted:2018-01-16
📝 Original message:
Hi Jonathan,
This is definitely a problem! I have a mainnet channel I force closed 2 weeks ago that is still not mined :(
With current spec I guess it is not much that can be done other than crossing fingers. For future specs maybe someone could come up with some SIGHASH flag magic to either (1) allow adding an extra input that could go to fees, or (2) add both a new input and output, where the difference goes to fees. I believe this would change the TXID of the commitment transaction, but not sure if that’s a problem? (Watchtowers comes to mind).
If keeping the TXID intact is important, one solution would be to always add a small (1 satoshi?) output to every commitment transaction, that anyone can spend. So if the commitment transaction has a fee too low, you could do CPFP on this small output, making it confirm. You could even make a batch sweep of many such outputs, and they would be (un)fairly cheap since they don’t need a signature. Do you think this would work?
- Johan

On Sun, Jan 14, 2018 at 2:30, Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
Hey everybody.
Say that the last time we updated channel state, we assumed 40 satoshi/byte was enough to get confirmed, then I leave the channel for a few weeks, come back to find my partner fell off the face of the internet.
I perform unilateral close with my output on CSV timelock... but it turns out there’s 500 MB of txes at around 100 satoshi/byte and lets say my transaction will never get confirmed at 40 sat/byte.
What course of action can I take?
1. to_local output can't be redeemed until the commitment transaction (which will "never confirm") is confirmed + the CSV timeout.
2. to_remote output probably won't be redeemed as the other person is offline.
The only remedy I can think of is hope that the other person comes back online and CPFPs your to_remote output for you... but at that point it would be better for them to just amicably close with normal outputs... so basically your only hope is wait for other person to come online.

Since CSV will cause script verification to fail, a CPFP transaction will not be propagated.
If we can't CPFP, the CSV timer won't start (it starts once the CSV containing output is confirmed).
Seems like a problem.
Anyone have any solutions?
Thanks, Jon
--
-----------------
Jonathan Underwood ビットバンク社チーフビットコインオフィサー -----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180117/1a4ee0f6/attachment.html>;

📅 Original date posted:2018-01-12 📝 Original message: Hi ...

2023-06-09T12:48:32Z

In reply to nevent1q…6enz
_________________________

📅 Original date posted:2018-01-12
📝 Original message:
Hi Pierre,
You’re right, that looks very much like the same kind of situation!
I agree, it looks from [2] that a node may fail the channel in this case, and that it probably should to not risk end up with all funds in an unpublishable tx. Seems like something that could be used as a DOS attack vector by a malicious counter party otherwise.

Relevant to this: We use a node’s resulting output (that is, after subtracting fees) when checking that the channel_reserve is met. In these cases we can therefore end up violating the reserve, even though none of the nodes are actually violating the protocol. When this happens we don’t really end up with an unpublishable tx, as the fees are still high enough, and I guess each node can choose what to do. I think we will just fail the channel to not have to deal with this as a special case.
Anyway, I think these are cases that are not very likely to occur, especially with the right choice of parameters as you mention. And because of this it might be less error-prone to just fail the channel instead of trying to recover from it.
Thanks! - Johan
On Fri, Jan 12, 2018 at 12:56, Pierre <pm+lists at acinq.fr> wrote:
Hi Johan,

That's an interesting corner case. I think it shares some similarities
with the race condition described in BOLT 2 [1], which handling is
specified in BOLT 3 [2].

Note that what matters really is the timing of the
`commit_sig`/`revoke_and_ack` messages, not the `update_add_htlc`s,
because of the acknowledgment logic that excludes remote's unsigned
updates. A side effect is that there can be multiple HTLCs on each
side.

Each party will end up receiving a commitment tx which has
insufficient (possibly zero) fees. At that point according to [2] it
may decide to fail the channel, using its previous commitment (which
it hasn't yet revoked). Currently eclair won't fail the channel, but I
think we probably should, especially if we are the fundee and would
end up with all funds in an unpublishable tx. The funder could face
the same situation if the pending htlcs have a high value (at this
point its main output is zero anyway).

An appropriate choice of channel parameters (`mainly
max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`,
`max_accepted_htlcs`) could probably reduce the probability of this
happening.

Hope that helps,

Pierre

[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee
[2] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180112/c18884a0/attachment.html>;

📅 Original date posted:2018-01-12 📝 Original message: Hi ...

2023-06-09T12:48:31Z

In reply to nevent1q…5f76
_________________________

📅 Original date posted:2018-01-12
📝 Original message:
Hi all,
I am wondering how Eclair and c-lightning is handling the following case, as I wasn’t able to derive exactly how to handle it from the BOLTs. If it is described somewhere, please point me to it, if not, let’s agree on a strategy, and get it in :)
Let's say Alice is the funder of the channel (meaning she is paying all fees) between Alice and Bob. She wants to add an HTLC, and has just enough balance available for the HTLC + the extra fee for adding it to the commitment transaction. At the same time Bob wants to add an HTLC, and sees that Alice has enough balance to be able to pay the fee for receiving this HTLC (add it to her commitment tx).
They both send the AddHTLC at the same time, thinking Alice has enough balance available, but she doesn't have enough to cover her own HTLC+fee, in addition to the fee for adding Bob's. Adding both the HTLCs to her commitment transaction will either 1) violate the channel reserve requirement, or 2) deplete her channel completely if the channel reserve is set to 0.
What is the expected way of handling this case, from both Alice and Bob’s point of view?
Cheers, Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180112/8844551f/attachment.html>;

📅 Original date posted:2018-01-11 📝 Original message: Hi, ...

2023-06-09T12:48:25Z

In reply to nevent1q…jmep
_________________________

📅 Original date posted:2018-01-11
📝 Original message:
Hi, Cezary,
I initially read the issue you created as a bug filing, my bad. I’ve updated it to reflect that it is a feature request.
Cheers! Johan

On Thu, Jan 11, 2018 at 18:16, Cezary Dziemian <cezary.dziemian at gmail.com> wrote:
I made issue 5 days ago: https://github.com/lightningnetwork/lnd/issues/564 [https://github.com/lightningnetwork/lnd/issues/564]
2018-01-11 0:21 GMT+01:00 Olaoluwa Osuntokun < laolu32 at gmail.com [laolu32 at gmail.com] > :

Hi Cezary,
I invite you to make an issue on lnd's issue tracker: https://github.com/ lightningnetwork/lnd/issues [https://github.com/lightningnetwork/lnd/issues] . This list isn't the place for support requests/features for individual implementations.
On Tue, Jan 9, 2018 at 5:21 AM Cezary Dziemian < cezary.dziemian at gmail.com [cezary.dziemian at gmail.com] > wrote:
Good news, thanks.

Do Lightning Labs also have plan to introduce this soon? I prefer to stay with lnd, as we already know this implementation better, but if this option will not be introduced soon, we have to switch to use c-lightning.

Cheers,
Cezary
2018-01-09 5:31 GMT+01:00 Rusty Russell < rusty at rustcorp.com.au [rusty at rustcorp.com.au] > :
ZmnSCPxj via Lightning-dev < lightning-dev at lists. linuxfoundation.org [lightning-dev at lists.linuxfoundation.org] > writes:

> Good morning Cezary,
>
> Currently, c-lightning can PAY amountless invoices via the "pay" command, but cannot CREATE them via the c-lightning "invoice" command.

Good point, I've filed an issue for this, so we don't lose it:

https://github.com/ ElementsProject/lightning/ issues/534 [https://github.com/ElementsProject/lightning/issues/534]

> To pay an amountless invoice lntb... 4 satoshis in c-lightning: lightning-cli pay lntb.. 4000

Note that I'd prefer the "msatoshi" field to be a magic string
(eg. "any") rather than omitting the parameter, since it's too easy for
a bug to omit the parameter.

Cheers,
Rusty.

______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]

_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/36620dd6/attachment-0001.html>;

📅 Original date posted:2018-01-02 📝 Original message: ...

2023-06-09T12:48:21Z

In reply to nevent1q…7ff9
_________________________

📅 Original date posted:2018-01-02
📝 Original message:
That’s correct :)

On Tue, Jan 2, 2018 at 15:34, Praveen Baratam <praveen.baratam at gmail.com> wrote:
Thank you for explaining @Hafeez & @Johan
Now that all the BIPs necessary for LN including SegWit (Softfork) are active on the mainnet, are we just waiting for the LN implementation to mature or are there any other issues? ᐧ
On Tue, Jan 2, 2018 at 8:01 PM, Johan Torås Halseth < johanth at gmail.com [johanth at gmail.com] > wrote:
Hi,
Before you can safely broadcast the funding transaction, the two parties involved in a channel must have signed a commitment transaction spending the output from the funding transaction. Without segwit, the funding transaction can be malleated, leaving the commitment transaction invalid, and funds locked up if one of the parties stops cooperating.

Cheers, Johan
On Tue, Jan 2, 2018 at 15:11, Hafeez Bana < hafeez.bana at gmail.com [hafeez.bana at gmail.com] > wrote:
to fix transaction malleability

On Tue, Jan 2, 2018 at 1:53 PM, Praveen Baratam < praveen.baratam at gmail.com [praveen.baratam at gmail.com] > wrote:
Why is SegWit required for LN? If we wait for the funding transaction to be confirmed , we can then safely create and update unconfirmed commitment transactions...
I don't see how SegWit is important here... Am I missing something?

--
Dr. Praveen Baratam
about.me [http://about.me/praveen.baratam] ᐧ
______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfound ation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/lightning -dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]

______________________________ _________________ Lightning-dev mailing list Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org] https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]

--
Dr. Praveen Baratam
about.me [http://about.me/praveen.baratam]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180102/bbc8938a/attachment-0001.html>;

📅 Original date posted:2018-01-02 📝 Original message: Hi, ...

2023-06-09T12:48:20Z

In reply to nevent1q…dnne
_________________________

📅 Original date posted:2018-01-02
📝 Original message:
Hi,
Before you can safely broadcast the funding transaction, the two parties involved in a channel must have signed a commitment transaction spending the output from the funding transaction. Without segwit, the funding transaction can be malleated, leaving the commitment transaction invalid, and funds locked up if one of the parties stops cooperating.

Cheers, Johan
On Tue, Jan 2, 2018 at 15:11, Hafeez Bana <hafeez.bana at gmail.com> wrote:
to fix transaction malleability

On Tue, Jan 2, 2018 at 1:53 PM, Praveen Baratam < praveen.baratam at gmail.com [praveen.baratam at gmail.com] > wrote:
Why is SegWit required for LN? If we wait for the funding transaction to be confirmed , we can then safely create and update unconfirmed commitment transactions...
I don't see how SegWit is important here... Am I missing something?

--
Dr. Praveen Baratam
about.me [http://about.me/praveen.baratam] ᐧ
______________________________ _________________
Lightning-dev mailing list
Lightning-dev at lists. linuxfoundation.org [Lightning-dev at lists.linuxfoundation.org]
https://lists.linuxfoundation. org/mailman/listinfo/ lightning-dev [https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev]

_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180102/f5facf90/attachment.html>;

📅 Original date posted:2017-12-12 📝 Original message: Just ...

2023-06-09T12:47:58Z

In reply to nevent1q…fq7r
_________________________

📅 Original date posted:2017-12-12
📝 Original message:
Just a few quick comments, as any improvements to BOLT#11 are very much appreciated :)

* I think we should set a reasonable max length for invoices, that MUST be met. This would simplify internal database logic (since you don’t have to plan for invoices infinitely big), and could make sure the error detection is fair for all supported lengths. Not sure if 1023 is enough, considering possibly multiple `r` tags and a juicy description. * Agree with UTF-8 support, and up to 640 bytes length ( this can be made explicit in the Bolt, as now it is limited by the 5 bit length field) :) * Why must the description hash URL be part of the invoice? I always imagined this would be used between clients that already had agreed on payment for some kind of data, and that this hash would just ensure you were paying the correct one.
- Johan (please explain the Japanese lightning meme plz)
On Tue, Dec 12, 2017 at 6:15, Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
I made a payment request using UTF-8 description here: lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp

using this code: (I just separated encode from sign)
ln.sign(ln.encode({ tags:[ { tagName:'payment_hash', data:'0001020304050607080900010203040506070809000102030405060708090102' }, { tagName:'description', data:'ナンセンス 1杯' } ] }, false), Buffer.from('e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734', 'hex')).paymentRequest

Full results:
{ "coinType": "testnet", "payeeNodeKey": "03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad", "paymentRequest": "lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp", "recoveryFlag": 1, "satoshis": null, "signature": "cd3ea92522d777c9184756d7d437275358795b8a9771e2d9e434e5b1bff14d49433e465d74cde0787f2c2bfbe52b1bbb6450cad6970ea804ef054da63b9a0426", "tags": [ { "tagName": "payment_hash", "data": "0001020304050607080900010203040506070809000102030405060708090102" }, { "tagName": "description", "data": "ナンセンス 1杯" } ], "timestamp": 1513055417, "timestampString": "2017-12-12T05:10:17.000Z" }

_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/35cb4bc6/attachment.html>;

📅 Original date posted:2017-12-07 📝 Original message: Hi, ...

2023-06-09T12:47:54Z

In reply to nevent1q…ga7a
_________________________

📅 Original date posted:2017-12-07
📝 Original message:
Hi, Edward! Welcome to the mailing list :)
The fees can indeed be set for each direction of the channel, check out https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message [https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message]
Basically each node in the channel can announce the fee til will take to route a payment in the direction leading “away” from it. We also have something called “channel reserves” ensuring that each node always has some balance at stake in case an old state is broadcast.
Cheers! Johan

On Wed, Dec 6, 2017 at 12:04, Edziu Marynarz <edziumarynarz at gmail.com> wrote:
I tried to find this information in the BOLT documents but I couldn't find it. Is it possible to set up the channel so that the fee depends on the direction, i.e. a different fee on the receive direction and different on the send one? Why such functionality?
Imagine that you start with a bidirectional channel to Alice and a channel to Bob with 1000 satoshi each. For some reasons, the network routes most of the transactions from Alice to you and then to Bob and you end up with 1900 satoshi in the Alice channel and only 100 satoshi in the Bob one. The route will stop working and if there is little traffic in the other direction you will have to close the channels to rebalance them or wait a very long time for the rebalancing.
If the fee could depend on the direction, one could start to ramp up fees on the receiving end of the channel that is getting large and lower the one that is empty to prevent the imbalance.
There is also a risk factor involved. The lightning network channels get riskier on the receive side the more the channel value deviates from the original state since the counterparty may try to broadcast the old state so you may want to regulate this imbalance with fees. It would be best if the LN applications could do it automatically.
Regards,
Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171207/df6d2847/attachment.html>;

📅 Original date posted:2017-11-03 📝 Original message: I ...

2023-06-09T12:47:36Z

In reply to nevent1q…fa8w
_________________________

📅 Original date posted:2017-11-03
📝 Original message:
I think this might have been discussed somewhere, sometime before: couldn’t we add an lightning parameter to the bitcoin: url, making the QR codes backwards compatible?
- Johan

On Fri, Nov 3, 2017 at 2:20, Rusty Russell <rusty at rustcorp.com.au> wrote:
Hi Cezary,

This is indeed the right place for such questions at the moment.

Cezary Dziemian <cezary.dziemian at gmail.com> writes:
> 1. After LN starts, some group of users will use it, other not. If for
> example, I would like to receive payment for coffee from some user, I don't
> know if user uses LN or not. So, when someone buy something from me, do I
> need to ask him what kind of payment he would like to use (LN or on-chain)?
> The best would be, if I show him some qr code contains both public address
> and LN invoice and his wallet could choose how to pay. But this cannot be
> done this way, right?

Yes, the transition is kind of painful. You can use a BOLT 11 QR code,
which can contain a fallback address, but that still requires their app
understand BOLT11 enough to extract it.

If they understand the BIP70 payment protocol, it could include an
alternate payment mechanism, but it seems nobody actually uses this.

> 2. Lets imagine, that someone send me invoice. I send payment and someone
> in the middle doesn't cooperate fast. My payment is waiting and until time
> lock period lapse I don't know if my payment will be processed or not. What
> to do then?

This is the worst case, yes. It's actually two cases: one where the
payment has failed, and one where it has succeeded and you don't know
yet.

If it's succeeded you'll get your goods (the recipient sees nothing
wrong), so you don't care that you have to wait for the money to be
deducted.

If it hasn't, it's almost certainly going to fail, and you can either
wait or try again with a new invoice (your wallet won't let to pay the
same one twice unless it's definitely failed). For 1.1 you'd be able to
reuse the same invoice safely, as long as the merchant was honest if it
received two payments and rejects the second.

> 3. Am I right that this decremental time lock is strongly related with
> block confirmation time? If there would be currency that have very fast
> confirmation time (like 5 seconds) then time lock period could be short
> what can potentially solve problem described in paragraph 2?

Somewhat, but not that low, because you still need a margin to turn
around payments. In practice, if payments are so unreliable that you
have to worry about this case, then something's horribly wrong!

Cheers,
Rusty.
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171103/381678d3/attachment.html>;

📅 Original date posted:2017-09-04 📝 Original message: I ...

2023-06-09T12:47:31Z

In reply to nevent1q…8lje
_________________________

📅 Original date posted:2017-09-04
📝 Original message:
I haven’t looked too closely at your proposal, but the first thing that hit me (2 weeks ago, sorry for not answering right away), is that instead of the basic flood-the-network-about-channels algorithm that currently is being used, this makes each route discovery request behave more or less like flooding (ask everybody within your local topology)?
Also it will be interesting to see when the network starts developing, I suspect that if you keep every node within 3 hops in your local topology, you end up storing most of the network anyway. So I think the routing algorithms will be far easier to optimize and analyze after some real world data :)
That being said, interesting idea, I’m not dismissing it :D

On Tue, Aug 22, 2017 at 3:08, Billy Tetrud <billy.tetrud at gmail.com> wrote:
Hey Guys,
I'm testing this mailing list out for the first time, so I'm probably gonna be doing it wrong.
I want to talk about route discovery and route generation in the lightning network. It seems there's a couple types of things going on with routing: * Super basic flood-the-network style routing to get things up and running, as I believe is implicitly proposed here: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md [https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md]

* More involved research projects that may not reach fruition any time soon. Eg this: http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf [http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf]

I'd like to discuss a near-term approach that can replace the basic flood-the-network style route discovery, but isn't so complicated that it needs a ton of study and work. This won't be the end-all solution to route discovery, but should take us a lot further than flood-the-network.
I propose a protocol where each node knows about its own local network topology, and to find a final route, a transaction originator queries a number of its connections for routes to the intended destination. By doing this, it means that nodes are *not* receiving or storing the entire network topology, which makes route discovery a lot less taxing on the network (in terms of bandwidth and storage space).
To go into more detail...
When a node joins the network: 1. it broadcasts its information to all its channels (pretty much as proposed here [https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md] ) announcing its relevant channel information 2. it requests local network topology information from all its channels for information about channels 1 hop beyond its direct connection (ie it will receive information about which addresses those channels are connected to, and their related fee info / etc) 3. it then requests topology information for channels 2 hops beyond, etc until it has filled its cache to its satisfaction (the user can choose some amount of megabytes as its limit of network topology data to store) 4. it also subscribes to topology changes for nodes at those distances (eg if a node has requested information from 3 hops away, it will receive info about any new channels or removed channels that fall within that distance)
When a node receives an announcement message from a node joining the network: 1. it will store that node's info in its cache 2. it will also forward that info to any node that's subscribed to topology changes that fall within the relevant distance
When a node wants to construct a route for a transaction: 1. It checks to see if it has a path to that node in its cache. If it does, it finds the cost of the cheapest path it has. 2. It asks all the channels on the edge of its cached local view for their cheapest path (however you want to define cheapest), specifying that it only care about paths with a maximum cost of the cheapest path it has already found in its cache. For example, if the node has nodes up to 3 hops away in its cache, it will *only* ask the nodes 3 hops away (it will not ask its direct connections, nor nodes 2 hops away, since it already has enough information to ignore them) 3. When it gets all its responses, it constructs a path
When a node receives a path request from a node: 1. It checks its cache for its cheapest cache-only path 2. It asks nodes on the edge of its cached local view for their cheapest path, specifying that it only cares about paths with a maximum cost of either its cheapest cache-only path or the max-cost specified by the requesting node minus the channel cost between it and the requesting node (whichever is cheaper). A node on the edge of its cached local view is *not* asked for route information if the cost to that node exceeds the max-cost this relay node would specify. 3. It reports the results that satisfy the max-cost requirements of the requesting node
And that's it. All the route information can be encrypted and signed so relaying nodes can't read the information inside, and so the requesting source node can verify which nodes sent that information.
This protocol should keep both node-announcement messages *and* route request messages highly localized.
Thoughts?
~BT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170904/66bc1247/attachment-0001.html>;

📅 Original date posted:2023-06-02 🗒️ Summary of this ...

2023-06-07T23:22:06Z

In reply to nevent1q…dwg2
_________________________

📅 Original date posted:2023-06-02
🗒️ Summary of this message: COCV can be used as an alternative to CTV, simplifying the process of embedding data in the next output and deciding its script.
📝 Original message:Hi,

It was briefly mentioned in the original post, but wanted to show how
simple it is to use COCV as an alternative to CTV, removing that
dependency.

> In particular, it also inherits the choice of using OP_CTV as a primitive,
> building on top of the bitcoin-inquisition's current branch that has already
> merged OP_CTV. Reasonable vaults would be possible without CTV, but they
> would be less efficient, particularly in the case of sending to many addresses
> in a single unvaulting flow.

Instead of specifying a CTV hash as embedded data, one could embed the
(commitment to the) outputs of the withdrawal transaction. Then
instead of a single OP_CTV, one OP_COCV per output to match against
the embedded data. Less efficient in case of many outputs as you
mention, but simple enough to be interesting.

Here's an example how to use MATT as a CTV replacement:
https://github.com/halseth/tapsim/blob/b07f29804cf32dce0168ab5bb40558cbb18f2e76/examples/matt/ctv2/README.md

Cheers,
Johan

On Tue, May 2, 2023 at 10:22 AM Salvatore Ingala via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Michael,
>
> I can't make any claim of expertise on the field (especially on the
> other proposals that you mentioned), so this post necessarily includes
> my opinions − and possibly my biases.
>
> The core functionality of MATT is quite simple, and could be adapted
> to any version of the scripting system: basically, COCV allows to
> "embed" some data in the next output, and decide its script; CICV
> allows "reading" this data.
> The design I proposed on taproot is surely not the only possible way,
> but it's the most simple/elegant I could come up with. Moreover, it
> doesn't seem very useful to spend time trying to get it to work on
> pre-taproot Script, due to the obvious advantages of those ideas when
> deployed on taproot (like having taptrees, and all the nice properties
> of Schnorr signatures).
>
> CICV/COCV can certainly be considered an additional form of
> introspection: you're checking that the script of an input/output
> equals a certain value, which is not possible in today's Script.
> I think that's generally true for all covenant proposals.
>
> Unlike some other proposals, MATT is not yet fully formalized, so I
> generally call "MATT" the combination of CICV+COCV, plus some other
> small set of opcodes that is yet to be defined exactly. I would say it
> fits in the same family as APO/OP_CTV/OP_VAULT, per your bucketization.
>
> The previous posts about MATT, fraud proofs, etc. are an exploration of
> the deeper things that are enabled by the MATT opcodes. The claim is
> that a set of changes that is (arguably) quite small and easy to analyze
> is enough to express general smart contracts − thanks to fraud proofs.
> However, fraud proofs themselves are a quite advanced application of
> the new opcodes, and are not needed for most/all of the things that
> people are trying to build today with the other covenant proposals.
>
>
> Since you mention Simplicity: my current understanding is that its
> endeavour of replacing Script with a better language is orthogonal to
> the discussion about what features (e.g.: introspection, covenants)
> should be in the language.
>
> All the covenant proposals listed above are technically a lot smaller
> and easier to audit than both the SegWit and the Taproot soft forks,
> both in terms of code and conceptual complexity.
>
> Therefore, if we _do_ want the features that they enable, the required
> engineering for a soft-fork is relatively straightforward, and there is
> not much of a reason to wait for Simplicity. It will be trivial to "port" any
> constructions we might create today with covenants to Simplicity scripts.
>
> If we _do not_ want those features, then the decision would rather be
> guided by other considerations, like potential risks to bitcoin caused
> by the effect of those features on miners' incentives. These
> concerns are not answered by Simplicity, as far as I understand:
> you would then want to implement Simplicity _without_ those features.
>
> Best,
> Salvatore
>
> On Mon, 1 May 2023 at 16:18, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>>
>> Hi Salvatore
>>
>> Can you clarify for me which bucket this proposal sits? We have APO, CTV, OP_VAULT etc that are proposals to add additional functionality to SegWit version 1, Tapleaf version 0 scripts. We have Simplicity that would need a new Tapleaf version (e.g. Tapleaf version 1). And then there are CISA like proposals that would need a new SegWit version (e.g. SegWit version 2). It looks to me like your proposal is in the first bucket (same as APO, CTV etc) as it is just introducing new opcode functionality to existing script with no deeper introspection needed but previous and current discussion of fraud proofs, MATT frameworks etc made me initially think it was going to require more than that.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Monday, April 24th, 2023 at 20:37, Salvatore Ingala via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hello list,
>>
>> TL;DR: the core opcodes of MATT can build vaults with a very similar design
>> to OP_VAULT. Code example here:
>>
>> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
>>
>>
>> In my previous emails about the MATT proposal for smart contracts in
>> bitcoin [1], I mostly focused on proving its generality; that is, it
>> allows arbitrary smart contracts thanks to fraud proofs.
>>
>> While I still find this "completeness" result compelling, I spent more time
>> thinking about the framework itself; the construction is not very interesting
>> if it turns simple things into complicated ones. Luckily, this is not the case.
>> In particular, in this email we will not merkleize anything (other than taptrees).
>>
>> This post describes some progress into formalizing the semantics of the core
>> opcodes, and demonstrates how they could be used to create vaults that seem
>> comparable to the ones built with OP_VAULT [2], despite using general purpose
>> opcodes.
>>
>> An implementation and some minimal tests matching the content of this
>> e-mail can be found in the link above, using the bitcoin-inquisition as the
>> base branch.
>>
>> Note that the linked code is not well tested and is only intended for
>> exploratory and demonstrative purposes; therefore, bugs are likely at this
>> stage.
>>
>>
>> ##########################
>> # PART 1: MATT's core
>> ##########################
>>
>> In this section, I will discuss plausible semantics for the core opcodes for MATT.
>>
>> The two core opcodes are defined below as OP_CHECKINPUTCONTRACTVERIFY and
>> OP_CHECKOUTPUTCONTRACTVERIFY.
>>
>> (the initial posts named them OP_CHECK{INPUT,OUTPUT}COVENANTVERIFY)
>>
>> They enhance Script with the following capabilities:
>> - decide the taptree of the output
>> - embed some (dynamically computed) data in the output
>> - access the embedded data in the current UTXO (if any)
>>
>> The opcodes below are incomplete, as they only control the output's Script and
>> not the amounts; more on that below.
>>
>> Other than that, the semantics should be quite close to the "right" one for
>> the MATT framework.
>>
>>
>> ### The opcodes
>>
>> case OP_CHECKINPUTCONTRACTVERIFY:
>> {
>> // OP_CHECKINPUTCONTRACTVERIFY is only available in Tapscript
>> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>> // (x d -- )
>> if (stack.size() < 2)
>> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> valtype& x = stacktop(-2);
>> valtype& d = stacktop(-1);
>> if (x.size() != 32 || d.size() != 32)
>> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
>> const uint256 data(d);
>> if (!execdata.m_internal_key.has_value())
>> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
>> // Verify that tweak(lift_x(x), d) equals the internal pubkey
>> if (!execdata.m_internal_key.value().CheckDoubleTweak(nakedXOnlyKey, &data, nullptr))
>> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
>> popstack(stack);
>> popstack(stack);
>> }
>> break;
>> case OP_CHECKOUTPUTCONTRACTVERIFY:
>> {
>> // OP_CHECKOUTPUTCONTRACTVERIFY is only available in Tapscript
>> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
>> // (out_i x taptree d -- )
>> if (stack.size() < 4)
>> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> int out_i = CScriptNum(stacktop(-4), fRequireMinimal).getint();
>> valtype& x = stacktop(-3);
>> valtype& taptree = stacktop(-2);
>> valtype& d = stacktop(-1);
>> auto outps = checker.GetTxvOut();
>> // Return error if the evaluation context is unavailable
>> if (!outps)
>> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
>> if (x.size() != 32 || taptree.size() != 32 || (d.size() != 0 && d.size() != 32))
>> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> if (out_i < 0 || out_i >= (int)outps->size())
>> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
>> const uint256 data(d);
>> const uint256 *data_ptr = (d.size() == 0 ? nullptr : &data);
>> const uint256 merkle_tree(taptree);
>> CScript scriptPubKey = outps->at(out_i).scriptPubKey;
>> if (scriptPubKey.size() != 1 + 1 + 32 || scriptPubKey[0] != OP_1 || scriptPubKey[1] != 32)
>> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
>> const XOnlyPubKey outputXOnlyKey{Span<const unsigned char>{scriptPubKey.data() + 2, scriptPubKey.data() + 34}};
>> // Verify that taptweak(tweak(lift_x(x), d), taptree) equals the internal pubkey
>> if (!outputXOnlyKey.CheckDoubleTweak(nakedXOnlyKey, data_ptr, &merkle_tree))
>> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
>> popstack(stack);
>> popstack(stack);
>> popstack(stack);
>> popstack(stack);
>> }
>> break;
>>
>> ### Commentary
>>
>> CheckDoubleTweak function (implemented in the branch) gets an x-only pubkey,
>> optionally some data, and optionally taptree's merkle root.
>> It verifies that the x-only pubkey being tested equals the given naked pubkey,
>> optionally tweaked with the embedded data, optionally tweaked with the tagged
>> hash of the merkle tree per BIP-0341 [3].
>> Making both the tweaks optional allows to simplify the code, and also to obtain
>> more compact scripts in some spending paths.
>>
>> In words:
>>
>> - OP_CHECKINPUTCONTRACTVERIFY: verify that the current input's internal key
>> contains some embedded data (which would typically be passed through the
>> witness stack)
>> - OP_CHECKOUTPUTCONTRACTVERIFY: verify that a given output is a certain P2TR
>> output script containing the desired embedded data.
>>
>> TBD if the tweaking used for the embedded data tweak should use a tagged hash;
>> omitted for simplicity in this demo implementation.
>>
>> ### Amount preservation
>>
>> In the code above and in the linked demo implementation, the opcodes only
>> operate on the scriptPubkey; a complete implementation would want to make sure
>> that amounts are correctly preserved.
>>
>> The most direct and general way to address this would be to allow direct
>> introspection on the output amounts. This has the complication that output
>> amounts require 64-bits arithmetics, as discussed in the context of other
>> proposals, for example: [4].
>>
>> One more limited approach that works well for many interesting contracts
>> is that of the deferred checks, implemented in OP_VAULT [2].
>> The idea is that all the amounts of the inputs that commit to the same output
>> script with OP_CHECKOUTPUTCONTRACTVERIFY are added together, and the script
>> interpreter requires that the amount of that output is not smaller than the
>> total amount of those inputs. This check is therefore transaction-wide rather
>> than being tested during the input's script evaluation.
>>
>> This behaviour is adequate for vaults and likely suitable for many other
>> applications; however, it's not the most general approach. I didn't try to
>> implement it yet, and defer the decision on the best approach to a later time.
>>
>> ### Extensions
>>
>> The opcodes above are not enough for the full generality of MATT: one would
>> need to add an opcode like OP_SHA256CAT to allow the data embedding to commit
>> to multiple pieces of data.
>> This is not used in today's post, therefore I left it out of these code examples.
>>
>> It would be easy to extend OP_CHECKOUTPUTCONTRACTVERIFY to also apply for
>> an arbitrary input (typically, different from the currently executed one); there
>> are likely use cases for that, allowing to define contracts with more complex
>> cross-input semantics, but I preferred to keep things simple.
>>
>> Of course, one could also entirely replace CICV/COCV with generic full
>> introspection on inputs/output's program, plus opcodes for elliptic curve math
>> and tagged hashes.
>>
>>
>> ##########################
>> # PART 2: Vaults with MATT
>> ##########################
>>
>> In the rest of this post, I will document the first attempt at creating a vault
>> using the opcodes described.
>>
>> While not an attempt at cloning exactly the functionality of OP_VAULT [2],
>> it borrows heavily from the excellent work that was done there.
>>
>> In particular, it also inherits the choice of using OP_CTV as a primitive,
>> building on top of the bitcoin-inquisition's current branch that has already
>> merged OP_CTV. Reasonable vaults would be possible without CTV, but they
>> would be less efficient, particularly in the case of sending to many addresses
>> in a single unvaulting flow.
>>
>> ### Distilling OP_VAULT
>>
>> Abstracting from the implementation details, I mentally model a vault as a
>> simple state machine with 2 states: [V] and [U]:
>>
>> [V]: the initial vault UTXO(s);
>> [U]: the utxo produced by the "trigger transaction" during unvaulting.
>>
>> On the typical path: one or more [V] UTXOs are sent to the [U] state, and after
>> a timelock set on [U] expires, [U] is spent to one or several destinations.
>> Crucially, the destination outputs and amounts are already decided when [V] is
>> spent into [U].
>>
>> At any time before the funds are spent from [U], they can always be spent by
>> sending them to some specified recovery path.
>>
>> There are two key elements that are part of OP_VAULT's semantics, and could be
>> generalized:
>>
>> − Forcing the script/amount of the next stepon
>> − Storing some data for future Script's access (in the vault's case, a hash
>> that commits to the final withdrawal transaction).
>>
>> CICV/COCV generalize both to arbitrary scripts (taptrees) and state machines,
>> and to dynamical and witness-dependent data embedded in the pubkey of a P2TR
>> output.
>>
>> ### Vault parameters
>>
>> A contract that represents a vault has the following parameters (hardcoded in
>> the script when the vault is created):
>>
>> - alternate_pk: a key that can be used any time.
>> - spend_delay: the relative timelock before the withdrawal can be finalized;
>> - recover_pk: a pubkey for a P2TR output where funds can be sent at any time.
>>
>> The alternate_pk is a pubkey that can optionally be used as the key-path
>> spending condition for both states [V] and [U]. If such a spending condition is not
>> desired, it can be replaced with a NUMS point, making the key-path unspendable.
>>
>> The spend_delay is the number of blocks that must be mined before the final
>> withdrawal transaction
>>
>> In this example we also use an unvault_pk needed to authorize the unvaulting
>> process (that is, spend [V] into [U]); this could be replaced with any miniscript
>> or other conditions expressible in Script.
>>
>> ### P2TR structure for [V] (vault)
>>
>> internal key: alternate_pk
>>
>> Script 1: "trigger"
>> # witness: <out_i> <ctv-hash>
>> {
>> <alternate_pk>,
>> <merkle root of U's taptree>,
>> 2, OP_ROLL,
>> OP_CHECKOUTPUTCONTRACTVERIFY,
>>
>> <unvault_pk>
>> OP_CHECKSIG
>> }
>>
>> Script 2: "recover"
>> # witness: <out_i>
>> {
>> recover_pk,
>> OP_0, # no data tweak
>> OP_0, # no taptweak
>> OP_CHECKOUTPUTCONTRACTVERIFY,
>> OP_TRUE
>> }
>>
>> The "trigger" script requires in the witness an output index and the ctv-hash
>> that describes the withdrawal transaction.
>> COCV forces the output to contain the ctv-hash as embedded data.
>> That's followed by the unvaulting condition − in this example, a simple
>> signature check.
>>
>> The "recover" script doesn't require any signature, and it simply forces
>> the output specified in the witness to be a P2TR output with recover_pk as its
>> pubkey.
>>
>> (Omitting the "recover" script in [V] would reduce the size of the witness by
>> 32 bytes in the expected case, and might be preferred for some users)
>>
>> ### P2TR structure for [U] (unvaulting state)
>>
>> internal key: alternate_pk (tweaked with ctv_hash)
>>
>> Script 1: "withdrawal"
>> # witness: <ctv_hash>
>> {
>> OP_DUP,
>>
>> # check that the top of the stack is the
>> # embedded data in the current input
>> <alternate_pk>, OP_SWAP,
>> OP_CHECKINPUTCONTRACTVERIFY,
>>
>> # Check timelock
>> <spend_delay>,
>> OP_CHECKSEQUENCEVERIFY,
>> OP_DROP,
>>
>> # Check that the transaction output is as expected
>> OP_CHECKTEMPLATEVERIFY
>> }
>>
>> Script 2: "recover"
>> # witness: <out_i>
>> {
>> <recover_pk>,
>> OP_0,
>> OP_0,
>> OP_CHECKOUTPUTCONTRACTVERIFY,
>> OP_TRUE
>> }
>>
>> The "withdrawal" finalizes the transaction, by checking that the timelock expired and
>> the outputs satisfy the CTV hash that was committed to in the previous transaction.
>>
>> The "recover" script is identical as before.
>>
>>
>> ### Differences with OP_VAULT vaults
>>
>> Here I refer to the latest version of OP_VAULT at the time of writing. [5]
>> It is not a thorough analysis.
>>
>> Unlike the implementation based on OP_VAULT, the [V] utxos don't have an option
>> to add an additional output that is sent back to the same exact vault.
>> Supporting this use case seems to require a more general way of handling the
>> distribution of amounts than what I discussed in the section above: that would
>> in fact need to be generalized to the case of multiple
>> OP_CHECKOUTPUTCONTRACTVERIFY opcodes executed for the same input.
>>
>> By separating the ctv-hash (which is considered "data") from the scripts in the
>> taptree, one entirely avoids the need to dynamically create taptrees and
>> replace leaves in the covenant-encumbered UTXOs; in fact, the taptrees of [V]
>> and [U] are already set in stone when [V] utxos are created, and only the
>> "data" portion of [U]'s scriptPubKey is dynamically computed. In my opinion,
>> this makes it substantially easier to program "state machines" that control the
>> behavior of coins, of which vaults are a special case.
>>
>> I hope you'll find this interesting, and look forward to your comments.
>>
>> Salvatore Ingala
>>
>>
>> [1] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021223.html
>> [2] - https://github.com/bitcoin/bips/pull/1421
>> [3] - https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
>> [4] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html
>> [5] - https://github.com/bitcoin/bips/blob/7112f308b356cdf0c51d917dbdc1b98e30621f80/bip-0345.mediawiki
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2023-05-26 🗒️ Summary of this ...

2023-06-07T23:21:09Z

In reply to nevent1q…pgyn
_________________________

📅 Original date posted:2023-05-26
🗒️ Summary of this message: OP_CICV and OP_COCV, along with OP_CAT, enable interesting use cases such as CoinPools, allowing easy checking of input data and enforcing new commitments on output. Suggestions for further extension are proposed.
📝 Original message:Hi, Salvatore.

As a further exploration of this idea, I implemented a
proof-of-concept of OP_CICV and OP_COCV in btcd[1] that together with
OP_CAT enables a set of interesting use cases.

One such use case is, as mentioned earlier, CoinPools[2]. The opcodes
let you easily check the "dynamically committed data" of an input you
are spending, and enforce a new commitment on the output. The idea is
to have the set of participants in the pool, and their balances, be
the UTXOs committed data, and use this to validate the legitimacy of
a transaction, determining whether it permits a peer to exit with a
portion of the pooled funds.

Doing what you suggested above, having the input and output commit to
a merkle tree of participants and balances, we are able to quite
elegantly verify the coin pool exit clause. Here is a working example
of how that could look like: [3]. Obviously this lacks a lot before it
is a working CoinPool implementation, but it demonstrates how
OP_C[I/O]V introduces "memory" to Bitcoin script.

Having done this exercise, I have a few suggestions on how one could
further extend the proposal:

1. In the current proposal for OP_CHECKOUTPUTCONTRACTVERIFY, the
opcodes check whether the output key Q is key X tweaked with data D
and taproot T: Q == tweak(tweak(X,D), T).

OP_CHECKINPUTCONTRACTVERIFY on the other hand, works on the input
internal key, and does not care about the taptree on the input: P ==
tweak(X,D), where Q = tweak(P, T). In most cases this is probably good
enough, since you are already executing the current script and that
way know the spender has provided the correct taproot.

However, in the coin pool script mentioned above, I found that I
wanted to re-use the same taproot for the output (recursively). I
believe this would be a quite common use case. To solve this I
committed the taproot as part of the data itself: D' = hash(T+D),
which was then verified by OP_CICV. If you are aware of more efficient
alternatives, I am eager to hear them.

A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical:
Have OP_CICV take an optional taproot and do the same check as is done
for the output: Q == tweak(tweak(X,D), T).

2.To make fully functioning CoinPools, one would need functionality
similar to OP_MERKLESUB[4]: remove some data from the merkle tree, and
remove a key from the aggregated internal key.This suggestion may
surpass the intended scope of this proposal, and would likely
necessitate the availability of multiple EC operations to accommodate
various key schemes. If we had opcodes for adding and removing keys
from the internal key this would be even more powerful.

I look forward to hearing your thoughts on these suggestions and
further exploring the possibilities of the proposal!

Cheers,
Johan

[1] https://github.com/halseth/btcd/pull/1/commits/90a4065bdcd8029fe3325514a250490cba66fddd
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[3] https://github.com/halseth/tapsim/tree/matt-demo/examples/matt/coinpool
[4] https://github.com/ariard/bips/blob/coinpool-bips/bip-merklesub.mediawiki

On Fri, May 5, 2023 at 11:18 PM Salvatore Ingala
<salvatore.ingala at gmail.com> wrote:
>
> On Thu, 4 May 2023 at 10:34, Johan Torås Halseth <johanth at gmail.com> wrote:
> >
> > It sounds like we can generalize the description of the construct to:
> > Access to (the hash of) embedded data of inputs and outputs, and the
> > enforcement of output keys and (static) taptrees. In other words, as
> > long as you can dynamically compute the output embedded data in
> > Script, you can enforce more or less anything (since you can make the
> > output script enforce presenting a witness "satisfying" the embedded
> > data).
> >
> > Does that sound about right?
>
> Yes. Fraud proofs allow us to extend beyond what Script can do (with the
> necessary tradeoffs), but there is plenty that can be done without them.
>
>
> > For instance, I believe you could simulate coin pools pretty easily:
> > Commit to the set of pubkeys and amounts owned by the participants in
> > the pool, and an output taptree where each participant has their own
> > spending path. Now, to exit the pool unilaterally, the participant
> > must present a proof that their pubkey+amount is committed to in the
> > input and an output where it is no longer committed.
>
> I don't think one would want to have a tapleaf for each participant:
> that would make you pay log n hashes just to reveal the tapleaf, and
> then you still need to pay log n hashes to access the embedded data.
>
> Instead, the "unilateral withdrawal Script" can be the same for all the
> participants. The witness would be the Merkle proof, plus perhaps some
> additional information to identify the leaf in the tree (depending on
> how the Merkle tree is implemented). In a complete Merkle tree for
> N = 2^n participants, the witness could contain the n hashes that allow
> to prove the value of the leaf, plus n bits to identify the path to the
> leaf (0/1 for 'left/right" child), since Script doesn't have enough
> opcodes to extract the bits from the leaf index.
>
> The data in the leaf can contain a commitment to all the information
> relevant for that participant (e.g.: their balance and pubkey, in a
> CoinPool construction).
>
> Then, the same witness can easily be reused to compute the new Merkle
> root after the data in the leaf is modified (for example, setting the
> amount to 0 for one participant).
>
>
> > A question that arises is how one would efficiently (in Script) prove
> > the inclusion/exclusion of the data in the commitment. One could
> > naively hash all the data twice during script execution (once for the
> > input, once for the output), but that is costly. It would be natural
> > to show merkle tree inclusion/exclusion in script, but perhaps there
> > are more efficient ways to prove it?
>
> A Merkle tree as described above commits to an entire vector that you
> can index positionally. That's quite versatile, and easier to handle
> than more complex constructions like accumulators with exclusion proofs.
>
> A Merkle proof for 2^7 = 128 participants requires about 8 hashes, so
> around 250 bytes in total of witness size; 2^10 = 1024 should bring that
> to the ballpark of 350 bytes.
>
> Best,
> Salvatore Ingala

📅 Original date posted:2023-05-30 🗒️ Summary of this ...

2023-06-07T23:21:09Z

In reply to nevent1q…tz9j
_________________________

📅 Original date posted:2023-05-30
🗒️ Summary of this message: The proposal for coin pools achieves the first part of removing data from the merkle tree, but removal of a public key from the taproot internal key is out of scope. Falling back to "old style multisig" can provide some benefits. There may be reasonable CoinPools designs without additional opcodes.
📝 Original message:I should clarify: the current proposal already achieves the first part
needed for coin pools: removing some data from the merkle tree (I was
indeed referring to the embedded data, not the taptree).

The thing that is missing is removal of a public key from the taproot
internal key, but as mentioned I do agree that this is out of scope
for this proposal.

I believe you can get many of the benefits by falling back to "old
style multisig" in case someone exits the pool, by having a tap leaf
defining a multisig check amongst the remaining pubkeys.

Cheers,
Johan

> It seems likely that efficient use of the taproot internal pubkey with
> "dynamic key aggregation" is not possible with the current semantics
> (unless one ventures into the fraud proof machinery, which seems
> overkill!).
>
> However, in constructions with MATT opcodes, I would never expect the
> need for data to be stored in the taptree. In particular, for the case
> of CoinPools, the pubkeys of the members could also be stored in the
> embedded data, having a single "unilateral withdrawal" tapleaf.
> Removing a key would then amount to replacing it with a fixed NUMS key
> and computing the new root (re-using the same Merkle proof).
> Note that this is not a lot costlier than using a tapleaf per user:
> instead of paying the cost for the Merkle proof in the control block,
> you pay for it explicitly in the Script witness.
>
> Therefore, I would expect there to be reasonable CoinPools designs
> without additional opcodes − but I am only moderately confident as
> this is beyond the level of sophistication I've been exploring so far.

On Sun, May 28, 2023 at 12:24 PM Salvatore Ingala
<salvatore.ingala at gmail.com> wrote:
>
> Hi Johan,
>
> Exciting to finally see some merkleization, which was only confined
> within the meme, up to this point!
>
> > A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical:
> > Have OP_CICV take an optional taproot and do the same check as is
> > done for the output: Q == tweak(tweak(X,D), T).
>
> I think that's an excellent suggestion, which I was already exploring
> for a different purpose: bringing externally signed data onto the
> stack. My goal there was to allow eltoo-style replacement.
>
> Until recently, I thought that a clean/efficient version of eltoo
> would require OP_CHECKSIGFROMSTACK or ANYPREVOUT. However, extending
> OP_CHECKINPUTCONTRACTVERIFY to enable introspection of other inputs
> allows a reasonable workaround: producing a separate UTXO signed with
> ANYONECANPAY, with the required data embedded as usual. Spending that
> UTXO together with the channel's UTXO allows one to get that data
> on the stack (with its signature already checked by consensus rules).
> I drafted this idea in a gist [1].
>
> Remark: it still seems easier (and probably slightly more efficient)
> to build eltoo replacement with CSFS or APO in addition to MATT
> opcodes.
>
> A possible semantics for OP_CHECKINPUTCONTRACTVERIFY could then be
> exactly symmetrical to that of OP_CHECKOUTPUTCONTRACTVERIFY, with
> the exception that the special input index -1 would represent the
> current input.
>
> Pushing this further, another option that could be be worth exploring
> is to have a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode, with the
> same semantics as OP_CHECKOUTPUTCONTRACTVERIFY from [2], but with an
> additional `flags` argument, which is a bitmap where:
> - the lowest-significant bit determines if the index refers to inputs
> or outputs (where input index -1 refers to the current input)
> - the second bit specifies if amounts should be preserved with
> deferred checks as described in [2] (only applicable to outputs)
> - other bits are OP_SUCCESS and reserved for future behaviors.
>
> This would make the opcodes 1-2 bytes larger, but might allow greater
> flexibility, and keep some room for future extensions.
>
> > 2.To make fully functioning CoinPools, one would need functionality
> > similar to OP_MERKLESUB[4]: remove some data from the merkle tree,
> > and remove a key from the aggregated internal key.
>
> It seems likely that efficient use of the taproot internal pubkey with
> "dynamic key aggregation" is not possible with the current semantics
> (unless one ventures into the fraud proof machinery, which seems
> overkill!).
>
> However, in constructions with MATT opcodes, I would never expect the
> need for data to be stored in the taptree. In particular, for the case
> of CoinPools, the pubkeys of the members could also be stored in the
> embedded data, having a single "unilateral withdrawal" tapleaf.
> Removing a key would then amount to replacing it with a fixed NUMS key
> and computing the new root (re-using the same Merkle proof).
> Note that this is not a lot costlier than using a tapleaf per user:
> instead of paying the cost for the Merkle proof in the control block,
> you pay for it explicitly in the Script witness.
>
> Therefore, I would expect there to be reasonable CoinPools designs
> without additional opcodes − but I am only moderately confident as
> this is beyond the level of sophistication I've been exploring so far.
>
> Best,
> Salvatore
>
> [1] - https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63
> [2] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html

📅 Original date posted:2023-05-04 🗒️ Summary of this ...

2023-06-07T23:21:08Z

In reply to nevent1q…d3ta
_________________________

📅 Original date posted:2023-05-04
🗒️ Summary of this message: The construct allows access to embedded data of inputs and outputs, and enforcement of output keys and static taptrees. Merkle tree inclusion/exclusion in script could be used for efficient proof.
📝 Original message:Thank you for the example.

It sounds like we can generalize the description of the construct to:
Access to (the hash of) embedded data of inputs and outputs, and the
enforcement of output keys and (static) taptrees. In other words, as
long as you can dynamically compute the output embedded data in
Script, you can enforce more or less anything (since you can make the
output script enforce presenting a witness "satisfying" the embedded
data).

Does that sound about right?

For instance, I believe you could simulate coin pools pretty easily:
Commit to the set of pubkeys and amounts owned by the participants in
the pool, and an output taptree where each participant has their own
spending path. Now, to exit the pool unilaterally, the participant
must present a proof that their pubkey+amount is committed to in the
input and an output where it is no longer committed.

A question that arises is how one would efficiently (in Script) prove
the inclusion/exclusion of the data in the commitment. One could
naively hash all the data twice during script execution (once for the
input, once for the output), but that is costly. It would be natural
to show merkle tree inclusion/exclusion in script, but perhaps there
are more efficient ways to prove it?

- Johan

On Tue, May 2, 2023 at 12:44 AM Salvatore Ingala via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> I apologize for a couple of oversights in my last e-mail.
>
> The first is that m_B can't be committed as-is in the contract's
> embedded data, with the current semantics of OP_COCV, which
> only allows 32-byte values. A solution could be to store its
> hash SHA256(m_B), instead.
>
> (I didn't test the Scripts, so there could be other bugs − hopefully the
> general idea is clear, anyway)
>
> On Mon, 1 May 2023 at 15:11, Salvatore Ingala <salvatore.ingala at gmail.com> wrote:
>>
>> If the internal_pubkey is a musig-aggregated key of Alice and Bob,
>> the game can be settled entirely offline after the first transaction.
>> Simply, Bob communicates his move to Alice, Alice reveals her move to
>> Bob, and they can settle the bet. The game would be played without
>> any script being executed, therefore all transactions could look like
>> any other P2TR, with the only possible fingerprinting being due to the
>> input amounts.
>
>
> This is incomplete: Alice can't trust Bob by revealing her move, as
> he could then cheat on-chain and play a different move.
>
> The fix should be straightforward, after adding the requirement that the
> internal pubkey of [S1] is a musig2 of both players.
> After Bob reveals his move (say, Rock), Alice will only agree to continue
> the game off-chain if Bob pre-signs transactions for the state [S1] (where
> m_B = Paper, and m_B = Scissors) that send all the money to Alice.
> This guarantees that a cheating Bob is punished.
>
> Best,
> Salvatore Ingala
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2023-04-28 🗒️ Summary of this ...

2023-06-07T23:20:59Z

In reply to nevent1q…cjva
_________________________

📅 Original date posted:2023-04-28
🗒️ Summary of this message: A person is interested in a proposal for powerful capabilities using simple opcodes. They ask for an example of encoding a state transition in Bitcoin script for a simple game.
📝 Original message:Hi, Salvatore.

I find this proposal very interesting. Especially since you seemingly
can achieve such powerful capabilities by such simple opcodes.

I'm still trying to grok how this would look like on-chain (forget
about the off-chain part for now), if we were to play out such a
computation.

Let's say you have a simple game like "one player tic-tac-toe" with
only two tiles: [ _ | _ ]. The player wins if he can get two in a row
(pretty easy game tbh).

Could you give a complete example how you would encode one such state
transition (going from [ X, _ ] -> [ X, X ] for instance) in Bitcoin
script?

Feel free to choose a different game or program if you prefer :)

Thanks!
Johan

On Tue, Dec 13, 2022 at 2:08 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Re Verkle trees, that's a very interesting construction that would be super useful as a tool for something like Utreexo. A potentially substantial downside is that it seems the cryptography used to get those nice properties of Verkle trees isn't quantum safe. While a lot of things in Bitcoin seems to be going down the path of quantum-unsafe (I'm looking at you, taproot), there are still a lot of people who think quantum safety is important in a lot of contexts.
>
> On Thu, Dec 1, 2022 at 5:52 AM Salvatore Ingala via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hello Rijndael,
>>
>>
>>
>> On Wed, 30 Nov 2022 at 23:09, Rijndael <rot13maxi at protonmail.com> wrote:
>>>
>>> Hello Salvatore,
>>>
>>> I found my answer re-reading your original post:
>>> > During the arbitration phase (say at the i-th leaf node of M_T), any party can win the challenge by providing correct values for tr_i = (st_i, op_i, st_{i + 1}). Crucially, only one party is able to provide correct values, and Script can verify that indeed the state moves from st_i to st_{i + 1} by executing op_i. The challenge is over.
>>
>> You are correct, the computation step encoded in a leaf needs to be simple enough for Script to verify it.
>>
>> For the academic purpose of proving completeness (that is, any computation can be successfully "proved" by the availability of the corresponding fraud proof), one can imagine reducing the computation all the way down to a circuit, where each step (leaf) is as simple as what can be checked with {OP_NOT, OP_BOOLAND, OP_BOOLOR, OP_EQUAL}.
>>
>> In practice, you would want to utilize Script to its fullest, so for example you wouldn't compile a SHA256 computation to something else – you'd rather use OP_SHA256 directly.
>>
>>>
>>> That raises leads to a different question: Alice initially posts a commitment to an execution trace of `f(x) = y`, `x`, and `y`. Bob Disagrees with `y` so starts the challenge protocol. Is there a commitment to `f`? In other words, the dispute protocol (as I read it) finds the leftmost step in Alice and Bob's execution traces that differ, and then rewards the coins to the participant who's "after-value" is computed by the step's operation applied to the "before value". But if the participants each present valid steps but with different operations, who wins? In other words, Alice could present [64, DECREMENT, 63] and Bob could present [64, INCREMENT, 65]. Those steps don't match, but both are valid. Is there something to ensure that before the challenge protocol starts, that the execution trace that Alice posts is for the right computation and not a different computation that yields a favorable result for her (and for which she can generate a valid merkle tree)?
>>
>>
>> The function f is already hard-coded in the contract itself, by means of the tree of scripts − that already commits to the possible futures. Therefore, once you are at state S14, you know that you are verifying the 6th step of the computation; and the operation in the 6th step of the computation depends solely on f, not its inputs. In fact, you made me realize that I could drop op_i from the i-th leaf commitment, and just embed the information in the Script of that corresponding state.
>>
>> Note that the states S0 to S14 of the 256x game are not _all_ the possible states, but only the ones that occurred in that execution of the contract (corresponding to a path from the root to the leaf of the Merkle tree of the computation trace), and therefore the ones that materialized in a UTXO. Different choices made by the parties (by providing different data, and therefore choosing different branches) would lead to a different leaf, and therefore to different (but in a certain sense "symmetric") states.
>>
>> ========
>>
>> Since we are talking about the fact that f is committed to in the contract, I'll take the chance to extend on this a bit with a fun construction on top.
>> It is well-known in the academic literature of state channels that you can create contracts where even the function ("program", or "contract") is not decided when the channel is created.
>>
>> Since f is generic, we can choose f itself to be a universal Turing machine. That is, we can imagine a function f(code, data) that executes a program ("code") on the "data" given to it as input.
>> Since we can do fraud proofs on statements "f(code, data) == output", we could build contracts where the "code" itself is chosen later.
>>
>> For example, one could build a universal state channel, where parties can enter any contract among themselves (e.g.: start playing a chess game) entirely inside the channel. The state of this universal channel would contain all the states of the individual contracts that are currently open in the channel, and even starting/closing contracts can happen entirely off-chain.
>>
>> I believe these constructions are practical (the code of universal Turing machines is not really complicated), so it might be worth exploring further to figure out useful applications of this approach (supercharging lightning?).
>>
>> We should probably start by implementing testnet rock-paper-scissors in MATT, though :)
>>
>> Best,
>> Salvatore Ingala
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-11-07 📝 Original message:Hi ...

2023-06-07T23:16:39Z

In reply to nevent1q…fdgm
_________________________

📅 Original date posted:2022-11-07
📝 Original message:Hi Laolu,

Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.

And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems indeed to be a prerequisite for
making the scheme safe in terms of re-orgs and asynchronicity.

I do think the scheme itself is sound though (maybe not off-chain, see
below): it prevents double spending and as long as the clients adhere
to the "rule" of not sending to a spent UTXO you'll be fine (if not
your tokens will be burned, the same way as if you don't satisfy the
Taro script when spending).

Thinking more about the examples you gave, I think you are right it
won't easily be compatible with LN channels though:
If you want to refill an existing channel with tokens, you need the
channel counterparties to start signing new commitments that include
spending the newly sent tokens. A problem arises however, if the
channel is force-closed with a pre-existing commitment from before the
token transfer took place. Since this commitment will be spending the
funding UTXO, but not the new tokens, the tokens will be burned. And
that seems to be harder to deal with (Eltoo style channels could be an
avenue to explore, if one could override the broadcasted commitment).

Tl;dr: I think you're right, the scheme is not compatible with LN.

- Johan

On Sat, Nov 5, 2022 at 1:36 AM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Hi Johan,
>
> I haven't really been able to find a precise technical explanation of the
> "utxo teleport" scheme, but after thinking about your example use cases a
> bit, I don't think the scheme is actually sound. Consider that the scheme
> attempts to target transmitting "ownership" to a UTXO. However, by the time
> that transaction hits the chain, the UTXO may no longer exist. At that
> point, what happens to the asset? Is it burned? Can you retry it again? Does
> it go back to the sender?
>
> As a concrete example, imagine I have a channel open, and give you an
> address to "teleport" some additional assets to it. You take that addr, then
> make a transaction to commit to the transfer. However, the block before you
> commit to the transfer, my channel closes for w/e reason. As a result, when
> the transaction committing to the UTXO (blinded or not), hits the chain, the
> UTXO no longer exists. Alternatively, imagine the things happen in the
> expected order, but then a re-org occurs, and my channel close is mined in a
> block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
> used as a serialization point, the scheme seems to lack a necessary total
> ordering to ensure safety.
>
> If we look at Taro's state transition model in contrast, everything is fully
> bound to a single synchronization point: a normal Bitcoin transaction with
> inputs consumed and outputs created. All transfers, just like Bitcoin
> transactions, end up consuming assets from the set of inputs, and
> re-creating them with a different distribution with the set of outputs. As a
> result, Taro transfers inherit the same re-org safety traits as regular
> Bitcoin transactions. It also isn't possible to send to something that won't
> ultimately exist, as sends create new outputs just like Bitcoin
> transactions.
>
> Taro's state transition model also means anything you can do today with
> Bitcoin/LN also apply. As an example, it would be possible for you to
> withdrawn from your exchange into a Loop In address (on chain to off chain
> swap), and have everything work as expected, with you topping off your
> channel. Stuff like splicing, and other interactive transaction construction
> schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.
>
> Ignoring the ordering issue I mentioned above, I don't think this is a great
> model for anchoring assets in channels either. With Taro, when you make the
> channel, you know how many assets are committed since they're all committed
> to in the funding output when the channel is created. However, let's say we
> do teleporting instead: at which point would we recognize the new asset
> "deposits"? What if we close before a pending deposits confirms, how can one
> regain those funds? Once again you lose the serialization of events/actions
> the blockchain provides. I think you'd also run into similar issues when you
> start to think about how these would even be advertised on a hypothetical
> gossip network.
>
> I think one other drawback of the teleport model iiuc is that: it either
> requires an OP_RETURN, or additional out of band synchronization to complete
> the transfer. Since it needs to commit to w/e hash description of the
> teleport, it either needs to use an OP_RETURN (so the receiver can see the
> on chain action), or the sender needs to contact the receiver to initiate
> the resolution of the transfer (details committed to in a change addr or
> w/e).
>
> With Taro, sending to an address creates an on-chain taproot output just
> like sending to a P2TR address. The creation of the output directly creates
> the new asset anchor/output as well, which allows the receiver to look for
> that address on chain just like a normal on chain transaction. To 3rd party
> observers, it just looks like a normal P2TR transfer. In order to finalize
> the receipt of the asset, the receiver needs to obtain the relevant
> provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
> service keyed by the input outpoint and output index. In short, the send
> process is fully async, with the sender and receiver using the blockchain
> itself as a synchronization point like a normal Bitcoin wallet.
>
> -- Laolu

📅 Original date posted:2022-11-03 📝 Original message:Hi, I ...

2023-06-07T23:16:37Z

In reply to nevent1q…qvj4
_________________________

📅 Original date posted:2022-11-03
📝 Original message:Hi,

I wanted to chime in on the "teleport" feature explained by Ruben, as I
think exploring something similar for Taro could be super useful in an LN
setting.

In today's Taro, to transfer tokens you have to spend a UTXO, and present a
proof showing that there are tokens committed to in the output you are
spending. Let's say this UTXO is 'utxo:0'.

In contrast, to spend teleported tokens, you would still spend utxo:0, but
you would only have to present a proof that _some txout_ on-chain have
committed tokens to utxo:0.

As Ruben points out, this makes it possible to send tokens to an already
spent TXO, essentially burning the tokens.

However, it opens up some exciting possibilities IMO. You can in essence
use this to "re-fill" UTXOs with tokens, which is very interesting for LN
channels:

- You could "add" tokens to your already open channels. The only thing
needed is for the channel participants to be presented the proof that
tokens were sent to the funding output, and they can update their
commitment transaction to start spending these tokens.
- You can "top-up" all your channels in a single on-chain tx. Since a
single output can commit tokens to several UTXOs, you could with a single
on-chain transaction add tokens to many channels without opening and
closing them.

RGB also has the ability to "blind" the UTXO that tokens get teleported to,
hiding the recipient UTXO. This is cool, since I could withdraw tokens from
an exchange directly into my LN channel, without revealing my channel UTXO.

I found the explanation of the teleport feature in this blog post pretty
good:
https://medium.com/@FedericoTenga/understanding-rgb-protocol-7dc7819d3059

- Johan

On Sun, Apr 10, 2022 at 6:52 PM Ruben Somsen <rsomsen at gmail.com> wrote:

> Hi Laolu,
>
> >happy to hear that someone was actually able to extract enough details
> from the RGB devs/docs to be able to analyze it properly
>
> Actually, even though I eventually puzzled everything together, this did
> not go well for me either. There is a ton of documentation, but it's a maze
> of unhelpful details, and none of it clearly maps out the fundamental
> design. I was also disappointed by the poor response I received when asking
> questions, and I ended up getting chastised for helping others understand
> it and pointing out potential flaws[1][2][3].Given my experience, I think
> the project is not in great shape, so the decision to rebuild from scratch
> seems right to me.
>
> That said, in my opinion the above should not factor into the decision of
> whether RGB should be credited in the Taro documentation. The design
> clearly precedes (and seems to have inspired) Taro, so in my opinion this
> should be acknowledged. Also, the people that are responsible for the
> current shape of RGB aren't the people who originated the idea, so it would
> not be fair to the originators either (Peter Todd, Alekos Filini, Giacomo
> Zucco).
>
> >assets can be burnt if a user doesn't supply a valid witness
>
> I am in agreement with what you said, but it is not clear to me whether we
> are on the same page. What I tried to say was that it does not make sense
> to build scripting support into Taro, because you can't actually do
> anything interesting with it due to this limitation. The only type of smart
> contract you can build is one where you limit what the owner (as defined by
> Bitcoin's script) can do with their own Taro tokens, or else he will burn
> them – not very useful. Anything involving a conditional transfer of
> ownership to either A or B (i.e. any meaningful type of script) won't work.
> Do you see what I mean, or should I elaborate further?
>
> >TAPLEAF_UPDATE_VERIFY can actually be used to further _bind_ Taro transitions
> at the Bitcoin level, without Bitcoin explicitly needing to be aware
>
> That is conceptually quite interesting. So theoretically you could get
> Bitcoin covenants to enforce certain spending conditions on Taro assets.
> Not sure how practical that ends up being, but intriguing to consider.
>
> >asset issuer to do a "re-genesis"
>
> Yes, RGB suggested the same thing, and this can work under some
> circumstances, but note that this won't help for tokens that aim to have a
> publicly audited supply, as the proof that a token was legitimately
> re-issued is the history of the previous token (so you'd actually be making
> things worse, as now everyone has to verify it). And of course the idea
> also requires the issuer to be active, which may not always be the case.
>
> >I'm not familiar with how the RGB "teleport" technique works [...] Can
> you point me to a coherent explanation of the technique
>
> To my knowledge no good explanation exists. "Teleporting" is just what I
> thought was a good way of describing it. Basically, in your design when
> Alice wants to send a Taro token to Bob, Alice has to spend her own output,
> make a new output for Bob, and make a change output for herself. Inside the
> Taro tree you'll then point to the index of Bob's output in order to assign
> the tokens to his new output. Instead of pointing to the index, you could
> point to the outpoint (txid, index) of an existing UTXO owned by Bob, thus
> "teleporting" the Taro tokens to this UTXO. This saves on-chain space, as
> now you don't have to create a new output for Bob (but now you have to
> ensure Bob doesn't spend from this output while you're simultaneously
> sending tokens to it, as I mentioned in my previous post, as this would
> destroy the tokens).
>
> The above also reminds me of another potential issue which you need to be
> aware of, if you're not already. Similar to my comment about how the
> location of the Taro tree inside the taproot tree needs to be deterministic
> for the verifier, the output in which you place the Taro tree also needs to
> be. If it's not, then you can commit to a different Taro tree in each
> output of the transaction, allowing you to secretly fork the history.
>
> Hope this helps.
>
> Cheers,
> Ruben
>
> [1] https://twitter.com/SomsenRuben/status/1397267261619064836
> [2] https://twitter.com/SomsenRuben/status/1397559406565462017
> [3] https://twitter.com/afilini/status/1397484341236797441
>
> On Fri, Apr 8, 2022 at 7:48 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> (this might be a double post as it ran into the size limit)
>>
>> Hi Ruben,
>>
>> Thanks! I don't really consider things final until we have a good set of
>> test
>> vectors in the final set, after which we'd start to transition the set of
>> documents beyond the draft state.
>>
>> > Seeing as there's a large amount of overlap with RGB, a protocol which
>> I have
>> > examined quite extensively, I believe some of the issues I uncovered in
>> that
>> > project also apply here.
>>
>> I'm happy to hear that someone was actually able to extract enough
>> details from
>> the RGB devs/docs to be able to analyze it properly! In the past I tried
>> to ask
>> their developers questions about how things like transfers worked[1][2],
>> but it
>> seemed either people didn't know, or they hadn't finished the core design
>> (large TBD sections) as they were working on adding other components to
>> create
>> a "new new Internet".
>>
>> > Furthermore, the Taro script is not enforced by Bitcoin, meaning those
>> who
>> > control the Bitcoin script can always choose to ignore the Taro script
>> and
>> > destroy the Taro assets as a result.
>>
>> This is correct, as a result in most contexts, an incentive exists for the
>> holder of an asset to observe the Taro validation rules as otherwise,
>> their
>> assets are burnt in the process from the PoV of asset verifiers. In the
>> single
>> party case things are pretty straight forward, but more care needs to be
>> taken
>> in cases where one attempts to express partial application and permits
>> anyone
>> to spend a UTXO in question.
>>
>> By strongly binding all assets to Bitcoin UTXOs, we resolve issues
>> related to
>> double spending or duplicate assets, but needs to mind the fact that
>> assets can
>> be burnt if a user doesn't supply a valid witness. There're likely ways
>> to get
>> around this by lessening the binding to Bitcoin UTXO's, but then the
>> system
>> would need to be able to collect, retain and order all the set of possible
>> spends, essentially requiring a parallel network. The core of the system
>> as it
>> stands today is pretty simple (which was an explicit design goal to avoid
>> getting forever distracted by the large design space), with a minimal
>> implementation being relatively compact given all the Bitcoin
>> context/design
>> re-use.
>>
>> Also one cool trait of the way commitments are designed is that the Taro
>> commitment impact the final derived taproot output key. As a result,
>> potential
>> Script extensions like TAPLEAF_UPDATE_VERIFY can actually be used to
>> further
>> _bind_ Taro transitions at the Bitcoin level, without Bitcoin explicitly
>> needing to be aware of the Taro rules. In short, covenants can allow
>> Bitcoin
>> Script to bind Taro state transitions, without any of the logic bleeding
>> over,
>> as the covenant just checks for a certain output key, which is a function
>> of
>> the Taro commitment being present.
>>
>> > There are two possible designs here: a.) The token history remains
>> separate –
>> > Dave receives Alice's 2 tokens, Bob's tokens are split and he receives
>> 2 (or
>> > 3 from Bob 1 from Alice). b.) The token history gets merged – Dave
>> receives
>> > 4 tokens (linking the new output with both Alice and Bob's history).
>>
>> Mechanically, with respect to the way the change/UTXOs work in the
>> system, both
>> are expressible: Dave can chose to merge them into a single UTXO (with the
>> appropriate witnesses included for each of them), or Dave can keep them
>> distinct in the asset tree. You're correct in that asset issuers may opt
>> to
>> issue assets in denominations vs allowing them to be fully divisible.
>> Ultimately, the compatibility with the LN layer will be the primary way
>> to keep
>> asset histories compressed, without relying on another trust model, or
>> relying
>> on the incentive of an asset issuer to do a "re-genesis" which would
>> effectively re-create assets in a supply-preserving manner (burn N units,
>> then
>> produce a new genesis outpoint for N units). Alternatively,
>> implementations can
>> also chose to utilize a checkpointing system similar to what some Bitcoin
>> full
>> node clients do today.
>>
>> > is that you end up with a linked transaction graph, just like in
>> Bitcoin
>>
>> This is correct, the protocol doesn't claim to achieve better privacy
>> guarantees than the base chain. However inheriting this transaction graph
>> model
>> imo makes it easier for existing Bitcoin developers to interact with the
>> system, and all the data structures are very familiar tooling wise.
>> However any
>> privacy enhancing protocol used for on-chain top-level Bitcoin UTXOs can
>> also
>> be applied to Taro, so people can use things like coinswap and coinjoin,
>> along
>> with LN to shed prior coin lineages.
>>
>> > This implies the location of the Taro tree inside the taproot tree is
>> not
>> > fixed. What needs to be prevented here is that a taproot tree contains
>> more
>> > than one Taro tree, as that would enable the owner of the commitment to
>> show
>> > different histories to different people.
>>
>> Great observation, I patched a similar issue much earlier in the design
>> process
>> by strongly binding all signatures to a prevOut super-set (so the outpoint
>> along with the unique key apth down into the tree), which prevents
>> duplicating
>> the asset across outputs, as signature verification would fail.
>>
>> In terms of achieving this level of binding within the Taro tree itself,
>> I can
>> think of three options:
>>
>> 1. Require the Taro commitment to be in the first/last position within
>> the
>> (fully sorted?) Tapscript tree, and also require its sibling to be the
>> hash
>> of some set string (all zeroes or w/e). We'd require the sibling to the
>> empty
>> as the tapscript hashes are sorted before hashing so you sort of lose
>> that
>> final ordering information.
>>
>> 2. Include the position of the Taro commitment within the tapscript tree
>> within the sighash digest (basically the way the single input in the
>> virtual
>> transaction is created from the TLV structure).
>>
>> 3. Include the position of the Taro commitment within the tapscript
>> tree as
>> part of the message that's hashed to derive asset IDs.
>>
>> AFAICT, #1 resolves the issue entirely, #2 renders transfers outside of
>> the
>> canonical history invalid, and #2 minds hte asset ID to the initial
>> position
>> meaning you can track a canonical lineage from the very start.
>>
>> > Finally, let me conclude with two questions. Could you clarify the
>> purpose of
>> > the sparse merkle tree in your design?
>>
>> Sure, it does a few things:
>>
>> * Non-inclusion proofs so I can do things like prove to your I'm no
>> longer
>> committing to my 1-of-1 holographic beefzard card when we swap.
>>
>> * The key/tree structure means that the tree is history independent,
>> meaning
>> that if you and I insert the same things into the tree in a different
>> order, we'll get the same root hash. This is useful for things like
>> tracking all the issuance events for a given asset, or allowing two
>> entities to sync their knowledge/history of a single asset, or a set
>> of
>> assets.
>>
>> * Each asset/script mapping to a unique location within the tree means
>> it's
>> easy to ensure uniqueness of certain items/commitments (not possible
>> to
>> commit to the same asset ID twice in the tree as an example).
>>
>> * The merkle-sum trait means I that validation is made simpler, as you
>> just
>> check that the input+output commitment sum to the same value, and I
>> can
>> also verify that if we're swapping, then you aren't committing to more
>> units that exist (so I make sure I don't get an invalid split).
>>
>> > And the second question – when transferring Taro token ownership from
>> one
>> > Bitcoin UTXO to another, do you generate a new UTXO for the recipient
>> or do
>> > you support the ability to "teleport" the tokens to an existing UTXO
>> like how
>> > RGB does it? If the latter, have you given consideration to timing
>> issues
>> > that might occur when someone sends tokens to an existing UTXO that
>> > simultaneously happens to get spent by the owner?
>>
>> So for interactive transfers, the UTXOs generated as just the ones part
>> of the
>> MIMO transaction. When sending via the address format, a new non-dust
>> output is
>> created which holds the new commitment, and uses an internal key provided
>> by
>> the receiver, so only they can move the UTXO. Admittedly, I'm not
>> familiar with
>> how the RGB "teleport" technique works, I checked out some slide decks a
>> while
>> back, but they were mostly about all the new components they were
>> creating and
>> their milestone of 1 million lines of code. Can you point me to a coherent
>> explanation of the technique? I'd love to compare/contrast so we can
>> analyze
>> the diff tradeoffs being made here.
>>
>> Thanks for an initial round of feedback/analysis, I'll be updating the
>> draft
>> over the next few days to better spell things out and particularly that
>> commitment/sighash uniqueness trait.
>>
>> -- Laolu
>>
>> [1]:
>> https://twitter.com/roasbeef/status/1330654936074371073?s=20&t=feV0kWAjJ6MTQlFm06tSxA
>> [2]:
>> https://twitter.com/roasbeef/status/1330692571736117249?s=20&t=feV0kWAjJ6MTQlFm06tSxA
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/a53b523d/attachment-0001.html>;

📅 Original date posted:2022-10-27 📝 Original message:Hi, ...

2023-06-07T23:15:36Z

In reply to nevent1q…43wg
_________________________

📅 Original date posted:2022-10-27
📝 Original message:Hi, Greg.

I find this proposal super interesting, and IIUC something that seems
fairly "safe" to allow (assuming V3).

For LN having the commitment transaction pay a non-zero fee is a cause for
a lot of complexity in the channel state machine. Something like this would
remove a lot of edge cases and add more flexibility around adding HTLCs.

Thanks!

- Johan

On Thu, Oct 20, 2022 at 3:42 PM Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> So it doesn't look like I'm ignoring a good question:
>
> No solid noninteractive ideas, unless we get some very flexible sighash
> softfork. Interactively, I think you can get collaborative fee bumps under
> the current consensus regime and ephemeral anchors. The child will just be
> built with inputs from different people.
>
> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne <james.obeirne at gmail.com>
> wrote:
>
>> I'm also very happy to see this proposal, since it gets us closer to
>> having a mechanism that allows the contribution to feerate in an
>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>> and other contracting protocols.
>>
>> One possible advantage of the sponsors interface -- and I'm curious for
>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>> collaboratively bump a tx's feerate. A simple example would be a batch
>> withdrawal from an exchange could be created with a low feerate, and then
>> multiple users with a vested interest of expedited confirmation could all
>> "chip in" to raise the feerate with multiple sponsor transactions.
>>
>> Having a single ephemeral output seems to create a situation where a
>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>> way we could (possibly later) amend the ephemeral anchor interface to allow
>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>> ephemeral anchors that would allow this?
>>
>>
>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Excellent proposal and I agree it does capture much of the spirit of
>>> sponsors w.r.t. how they might be used for V3 protocols.
>>>
>>> The only drawbacks I see is they don't work for lower tx version
>>> contracts, so there's still something to be desired there, and that the
>>> requirement to sweep the output must be incentive compatible for the miner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>> The Ephemeral UTXO concept can be a consensus rule (see
>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate
>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>> a cleanup one can punt.
>>>
>>> One question I have is if V3 is designed for lightning, and this is
>>> designed for lightning, is there any sense in requiring these outputs for
>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>> the v3 surface smaller.
>>>
>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> > does that effectively mark output B as unspendable once the child
>>>> gets confirmed?
>>>>
>>>> Not at all. It's a normal spend like before, since the parent has been
>>>> confirmed. It's completely unrestricted, not being bound to any
>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>>
>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Thank you very much for sharing your proposal!
>>>>>
>>>>> I think there's one thing about the second part of your proposal that
>>>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>>>> unspendable once the child gets confirmed? If so, isn't the implication
>>>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>>>> outputs must be spent? Thanks!
>>>>>
>>>>> Best,
>>>>> Arik
>>>>>
>>>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>>>
>>>>> Hello Everyone,
>>>>>
>>>>> Following up on the "V3 Transaction" discussion here
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
>>>>> , I would like to elaborate a bit further on some potential follow-on work
>>>>> that would make pinning severely constrained in many setups].
>>>>>
>>>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
>>>>> under some constraints[0]. This means that when a replacement is to be made
>>>>> and propagated, it costs the expected amount of fees to do so. This is a
>>>>> great start. What's left in this subset of pinning is *package limit*
>>>>> pinning. In other words, a fee-paying transaction cannot enter the mempool
>>>>> due to the existing mempool package it is being added to already being too
>>>>> large in count or vsize.
>>>>>
>>>>> Zooming into the V3 simplified scenario for sake of discussion, though
>>>>> this problem exists in general today:
>>>>>
>>>>> V3 transactions restrict the package limit of a V3 package to one
>>>>> parent and one child. If the parent transaction includes two outputs which
>>>>> can be immediately spent by separate parties, this allows one party to
>>>>> disallow a spend from the other. In Gloria's proposal for ln-penalty, this
>>>>> is worked around by reducing the number of anchors per commitment
>>>>> transaction to 1, and each version of the commitment transaction has a
>>>>> unique party's key on it. The honest participant can spend their version
>>>>> with their anchor and package RBF the other commitment transaction safely.
>>>>>
>>>>> What if there's only one version of the commitment transaction, such
>>>>> as in other protocols like duplex payment channels, eltoo? What about multi
>>>>> party payments?
>>>>>
>>>>> In the package RBF proposal, if the parent transaction is identical to
>>>>> an existing transaction in the mempool, the parent will be detected and
>>>>> removed from the package proposal. You are then left with a single V3 child
>>>>> transaction, which is then proposed for entry into the mempool. In the case
>>>>> of another parent output already being spent, this is simply rejected,
>>>>> regardless of feerate of the new child.
>>>>>
>>>>> I have two proposed solutions, of which I strongly prefer the latter:
>>>>>
>>>>> 1) Expand a carveout for "sibling eviction", where if the new child is
>>>>> paying "enough" to bump spends from the same parent, it knocks its sibling
>>>>> out of the mempool and takes the one child slot. This would solve it, but
>>>>> is a new eviction paradigm that would need to be carefully worked through.
>>>>>
>>>>> 2) Ephemeral Anchors (my real policy-only proposal)
>>>>>
>>>>> Ephemeral Anchors is a term which means an output is watermarked as an
>>>>> output that MUST be spent in a V3 package. We mark this anchor by being the
>>>>> bare script `OP_TRUE` and of course make these outputs standard to relay
>>>>> and spend with empty witness data.
>>>>>
>>>>> Also as a simplifying assumption, we require the parent transaction
>>>>> with such an output to be 0-fee. This makes mempool reasoning simpler in
>>>>> case the child-spend is somehow evicted, guaranteeing the parent will be as
>>>>> well.
>>>>>
>>>>> Implications:
>>>>>
>>>>> a) If the ephemeral anchor MUST be spent, we can allow *any* value,
>>>>> even dust, even 0, without worrying about bloating the utxo set. We relax
>>>>> this policy for maximum smart contract flexibility and specification
>>>>> simplicity..
>>>>>
>>>>> b) Since this anchor MUST be spent, any spending of other outputs in
>>>>> the same parent transaction MUST directly double-spend prior spends of the
>>>>> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
>>>>> removed in these situations. This greatly magnifies composability of smart
>>>>> contracts, as now we can do things like safely splice directly into new
>>>>> channels, into statechains, your custodial wallet account, your cold
>>>>> wallet, wherever, without requiring other wallets to support arbitrary
>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be miniscript
>>>>> compatible to begin with...
>>>>>
>>>>> c) *Anyone* can bump the transaction, without any transaction key
>>>>> material. This is essentially achieving Jeremy's Transaction Sponsors (
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html)
>>>>> proposal without consensus changes. As long as someone gets a fully signed
>>>>> parent, they can execute a bump with minimal wallet tooling. If a
>>>>> transaction author doesn’t want a “sponsor”, do not include the output.
>>>>>
>>>>> d) Lightning Carve-out(
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html)
>>>>> is superseded by this logic, as we are not restricted to two immediately
>>>>> spendable output scenarios. In its place, robust multi-party fee bumping is
>>>>> possible.
>>>>>
>>>>> e) This also benefits more traditional wallet scenarios, as change
>>>>> outputs can no longer be pinned, and RBF/CPFP becomes robust. Payees in
>>>>> simple spends cannot pin you. Batched payouts become a lot less painful.
>>>>> This was one of the motivating use cases that created the term “pinning” in
>>>>> the first place(
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html),
>>>>> even if LN/L2 discussion has largely overtaken it due to HTLC theft risks.
>>>>>
>>>>> Open Question(s):
>>>>>
>>>>>
>>>>> 1.
>>>>>
>>>>> If we allow non-zero value in ephemeral outputs, does this open up
>>>>> a MEV we are worried about? Wallets should toss all the value directly to
>>>>> fees, and add their own additional fees on top, otherwise miners have
>>>>> incentive to make the smallest utxo burn transaction to claim those funds.
>>>>> They just confirmed your parent transaction anyways, so do we care?
>>>>> 2.
>>>>>
>>>>> SIGHASH_GROUP like constructs would allow uncommitted ephemeral
>>>>> anchors to be added at spend time, depending on spending requirements.
>>>>> SIGHASH_SINGLE already allows this.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hopefully this gives people something to consider as we move forward
>>>>> in thinking about mempool design within the constraints we have today.
>>>>>
>>>>>
>>>>> Greg
>>>>>
>>>>> 0: With V3 transactions where you have "veto power" over all the
>>>>> inputs in that transaction. Therefore something like ANYONECANPAY is still
>>>>> broken. We need a more complex solution, which I’m punting for the sake of
>>>>> progress.
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/c66de0f3/attachment-0001.html>;

📅 Original date posted:2019-10-30 📝 Original message:On ...

2023-06-07T18:21:27Z

In reply to nevent1q…su2n
_________________________

📅 Original date posted:2019-10-30
📝 Original message:On Mon, Oct 28, 2019 at 6:16 PM David A. Harding <dave at dtrt.org> wrote:

> A parent transaction near the limit of 100,000 vbytes could have almost
> 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
> were limited to 10,000 vbytes each (the current max carve-out size),
> that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
> than the default maximum mempool size in Bitcoin Core).
>

Thanks, Dave, I wasn't aware the limits would allow this many outputs. And
as your calculation shows, this opens up the potential for free relay of
large amounts of data.

We could start special casing to only allow this for "LN commitment-like"
transactions, but this would be application specific changes, and your
calculation shows that even with the BOLT2 numbers there still exists cases
with a large number of children.

We are moving forward with adding a 1 block delay to all outputs to utilize
the current carve-out rule, and the changes aren't that bad. See Joost's
post in "[PATCH] First draft of option_simplfied_commitment"

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191030/bc2a90f3/attachment.html>;

📅 Original date posted:2019-10-28 📝 Original message:> ...

2023-06-07T18:21:26Z

In reply to nevent1q…7x3g
_________________________

📅 Original date posted:2019-10-28
📝 Original message:>
>
> I don’te see how? Let’s imagine Party A has two spendable outputs, now
> they stuff the package size on one of their spendable outlets until it is
> right at the limit, add one more on their other output (to meet the
> Carve-Out), and now Party B can’t do anything.

Matt: With the proposed change, party B would always be able to add a child
to its output, regardless of what games party A is playing.

Thanks for the explanation, Jeremy!

> In terms of relay cost, if an ancestor can be replaced, it will invalidate
> all it's children, meaning that no one paid for that broadcasting. This can
> be fixed by appropriately assessing Replace By Fee update fees to
> encapsulate all descendants, but there are some tricky edge cases that make
> this non-obvious to do.

Relay cost is the obvious problem with just naively removing all limits.
Relaxing the current rules by allowing to add a child to each output as
long as it has a single unconfirmed parent would still only allow free
relay of O(size of parent) extra data (which might not be that bad? Similar
to the carve-out rule we could put limits on the child size). This would be
enough for the current LN use case (increasing fee of commitment tx), but
not for OP_SECURETHEBAG I guess, as you need the tree of children, as you
mention.

I imagine walking the mempool wouldn't change much, as you would only have
one extra child per output. But here I'm just speculating, as I don't know
the code well enough know what the diff would look like.

> OP_SECURETHEBAG can help with the LN issue by putting all HTLCS into a
> tree where they are individualized leaf nodes with a preceding CSV. Then,
> the above fix would ensure each HTLC always has time to close properly as
> they would have individualized lockpoints. This is desirable for some
> additional reasons and not for others, but it should "work".

This is interesting for an LN commitment! You could really hide every
output of the commitment within OP_STB, which could either allow bypassing
the fee-pinning attack entirely (if the output cannot be spent unconfirmed)
or adding fees to the commitment using SIGHASH_SINGLE|ANYONECANPAY.

- Johan

On Sun, Oct 27, 2019 at 8:13 PM Jeremy <jlrubin at mit.edu> wrote:

> Johan,
>
> The issues with mempool limits for OP_SECURETHEBAG are related, but have
> distinct solutions.
>
> There are two main categories of mempool issues at stake. One is relay
> cost, the other is mempool walking.
>
> In terms of relay cost, if an ancestor can be replaced, it will invalidate
> all it's children, meaning that no one paid for that broadcasting. This can
> be fixed by appropriately assessing Replace By Fee update fees to
> encapsulate all descendants, but there are some tricky edge cases that make
> this non-obvious to do.
>
> The other issue is walking the mempool -- many of the algorithms we use in
> the mempool can be N log N or N^2 in the number of descendants. (simple
> example: an input chain of length N to a fan out of N outputs that are all
> spent, is O(N^2) to look up ancestors per-child, unless we're caching).
>
> The other sort of walking issue is where the indegree or outdegree for a
> transaction is high. Then when we are computing descendants or ancestors we
> will need to visit it multiple times. To avoid re-expanding a node, we
> currently cache it with a set. This uses O(N) extra memory and makes O(N
> Log N) (we use std::set not unordered_set) comparisons.
>
> I just opened a PR which should help with some of the walking issues by
> allowing us to cheaply cache which nodes we've visited on a run. It makes a
> lot of previously O(N log N) stuff O(N) and doesn't allocate as much new
> memory. See: https://github.com/bitcoin/bitcoin/pull/17268.
>
>
> Now, for OP_SECURETHEBAG we want a particular property that is very
> different from with lightning htlcs (as is). We want that an unlimited
> number of child OP_SECURETHEBAG txns may extend from a confirmed
> OP_SECURETHEBAG, and then at the leaf nodes, we want the same rule as
> lightning (one dangling unconfirmed to permit channels).
>
> OP_SECURETHEBAG can help with the LN issue by putting all HTLCS into a
> tree where they are individualized leaf nodes with a preceding CSV. Then,
> the above fix would ensure each HTLC always has time to close properly as
> they would have individualized lockpoints. This is desirable for some
> additional reasons and not for others, but it should "work".
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
>
>
> On Fri, Oct 25, 2019 at 10:31 AM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> I don’te see how? Let’s imagine Party A has two spendable outputs, now
>> they stuff the package size on one of their spendable outlets until it is
>> right at the limit, add one more on their other output (to meet the
>> Carve-Out), and now Party B can’t do anything.
>>
>> On Oct 24, 2019, at 21:05, Johan Torås Halseth <johanth at gmail.com> wrote:
>>
>>
>> It essentially changes the rule to always allow CPFP-ing the commitment
>> as long as there is an output available without any descendants. It changes
>> the commitment from "you always need at least, and exactly, one non-CSV
>> output per party. " to "you always need at least one non-CSV output per
>> party. "
>>
>> I realize these limits are there for a reason though, but I'm wondering
>> if could relax them. Also now that jeremyrubin has expressed problems with
>> the current mempool limits.
>>
>> On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists at mattcorallo.com>
>> wrote:
>>
>>> I may be missing something, but I'm not sure how this changes anything?
>>>
>>> If you have a commitment transaction, you always need at least, and
>>> exactly, one non-CSV output per party. The fact that there is a size
>>> limitation on the transaction that spends for carve-out purposes only
>>> effects how many other inputs/outputs you can add, but somehow I doubt
>>> its ever going to be a large enough number to matter.
>>>
>>> Matt
>>>
>>> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
>>> > Reviving this old thread now that the recently released RC for bitcoind
>>> > 0.19 includes the above mentioned carve-out rule.
>>> >
>>> > In an attempt to pave the way for more robust CPFP of on-chain
>>> contracts
>>> > (Lightning commitment transactions), the carve-out rule was added in
>>> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked
>>> on
>>> > an implementation of a new commitment format for utilizing the Bring
>>> > Your Own Fees strategy using CPFP, I’m wondering if the special case
>>> > rule should have been relaxed a bit, to avoid the need for adding a 1
>>> > CSV to all outputs (in case of Lightning this means HTLC scripts would
>>> > need to be changed to add the CSV delay).
>>> >
>>> > Instead, what about letting the rule be
>>> >
>>> > The last transaction which is added to a package of dependent
>>> > transactions in the mempool must:
>>> > * Have no more than one unconfirmed parent.
>>> >
>>> > This would of course allow adding a large transaction to each output of
>>> > the unconfirmed parent, which in effect would allow an attacker to
>>> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
>>> > this a problem with the current mempool acceptance code in bitcoind? I
>>> > would imagine evicting transactions based on feerate when the max
>>> > mempool size is met handles this, but I’m asking since it seems like
>>> > there has been several changes to the acceptance code and eviction
>>> > policy since the limit was first introduced.
>>> >
>>> > - Johan
>>> >
>>> >
>>> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au
>>> > <mailto:rusty at rustcorp.com.au>> wrote:
>>> >
>>> > Matt Corallo <lf-lists at mattcorallo.com
>>> > <mailto:lf-lists at mattcorallo.com>> writes:
>>> > >>> Thus, even if you imagine a steady-state mempool growth,
>>> unless the
>>> > >>> "near the top of the mempool" criteria is "near the top of the
>>> next
>>> > >>> block" (which is obviously *not* incentive-compatible)
>>> > >>
>>> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
>>> next
>>> > >> block, and assumed you'd only allow RBF if the old package
>>> wasn't
>>> > in the
>>> > >> top and the replacement would be. That seems incentive
>>> > compatible; more
>>> > >> than the current scheme?
>>> > >
>>> > > My point was, because of block time variance, even that criteria
>>> > doesn't hold up. If you assume a steady flow of new transactions
>>> and
>>> > one or two blocks come in "late", suddenly "top 4MWeight" isn't
>>> > likely to get confirmed until a few blocks come in "early". Given
>>> > block variance within a 12 block window, this is a relatively
>>> likely
>>> > scenario.
>>> >
>>> > [ Digging through old mail. ]
>>> >
>>> > Doesn't really matter. Lightning close algorithm would be:
>>> >
>>> > 1. Give bitcoind unileratal close.
>>> > 2. Ask bitcoind what current expidited fee is (or survey your
>>> mempool).
>>> > 3. Give bitcoind child "push" tx at that total feerate.
>>> > 4. If next block doesn't contain unilateral close tx, goto 2.
>>> >
>>> > In this case, if you allow a simpified RBF where 'you can replace
>>> if
>>> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
>>> > old tx isnt',
>>> > it works.
>>> >
>>> > It allows someone 100k of free tx spam, sure. But it's simple.
>>> >
>>> > We could further restrict it by marking the unilateral close
>>> somehow to
>>> > say "gonna be pushed" and further limiting the child tx weight
>>> (say,
>>> > 5kSipa?) in that case.
>>> >
>>> > Cheers,
>>> > Rusty.
>>> > _______________________________________________
>>> > Lightning-dev mailing list
>>> > Lightning-dev at lists.linuxfoundation.org
>>> > <mailto:Lightning-dev at lists.linuxfoundation.org>
>>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>> >
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191028/92777d7b/attachment-0001.html>;

📅 Original date posted:2019-10-25 📝 Original message:It ...

2023-06-07T18:21:24Z

In reply to nevent1q…6yep
_________________________

📅 Original date posted:2019-10-25
📝 Original message:It essentially changes the rule to always allow CPFP-ing the commitment as
long as there is an output available without any descendants. It changes
the commitment from "you always need at least, and exactly, one non-CSV
output per party. " to "you always need at least one non-CSV output per
party. "

I realize these limits are there for a reason though, but I'm wondering if
could relax them. Also now that jeremyrubin has expressed problems with the
current mempool limits.

On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> I may be missing something, but I'm not sure how this changes anything?
>
> If you have a commitment transaction, you always need at least, and
> exactly, one non-CSV output per party. The fact that there is a size
> limitation on the transaction that spends for carve-out purposes only
> effects how many other inputs/outputs you can add, but somehow I doubt
> its ever going to be a large enough number to matter.
>
> Matt
>
> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
> > Reviving this old thread now that the recently released RC for bitcoind
> > 0.19 includes the above mentioned carve-out rule.
> >
> > In an attempt to pave the way for more robust CPFP of on-chain contracts
> > (Lightning commitment transactions), the carve-out rule was added in
> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on
> > an implementation of a new commitment format for utilizing the Bring
> > Your Own Fees strategy using CPFP, I’m wondering if the special case
> > rule should have been relaxed a bit, to avoid the need for adding a 1
> > CSV to all outputs (in case of Lightning this means HTLC scripts would
> > need to be changed to add the CSV delay).
> >
> > Instead, what about letting the rule be
> >
> > The last transaction which is added to a package of dependent
> > transactions in the mempool must:
> > * Have no more than one unconfirmed parent.
> >
> > This would of course allow adding a large transaction to each output of
> > the unconfirmed parent, which in effect would allow an attacker to
> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
> > this a problem with the current mempool acceptance code in bitcoind? I
> > would imagine evicting transactions based on feerate when the max
> > mempool size is met handles this, but I’m asking since it seems like
> > there has been several changes to the acceptance code and eviction
> > policy since the limit was first introduced.
> >
> > - Johan
> >
> >
> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au
> > <mailto:rusty at rustcorp.com.au>> wrote:
> >
> > Matt Corallo <lf-lists at mattcorallo.com
> > <mailto:lf-lists at mattcorallo.com>> writes:
> > >>> Thus, even if you imagine a steady-state mempool growth, unless
> the
> > >>> "near the top of the mempool" criteria is "near the top of the
> next
> > >>> block" (which is obviously *not* incentive-compatible)
> > >>
> > >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
> next
> > >> block, and assumed you'd only allow RBF if the old package wasn't
> > in the
> > >> top and the replacement would be. That seems incentive
> > compatible; more
> > >> than the current scheme?
> > >
> > > My point was, because of block time variance, even that criteria
> > doesn't hold up. If you assume a steady flow of new transactions and
> > one or two blocks come in "late", suddenly "top 4MWeight" isn't
> > likely to get confirmed until a few blocks come in "early". Given
> > block variance within a 12 block window, this is a relatively likely
> > scenario.
> >
> > [ Digging through old mail. ]
> >
> > Doesn't really matter. Lightning close algorithm would be:
> >
> > 1. Give bitcoind unileratal close.
> > 2. Ask bitcoind what current expidited fee is (or survey your
> mempool).
> > 3. Give bitcoind child "push" tx at that total feerate.
> > 4. If next block doesn't contain unilateral close tx, goto 2.
> >
> > In this case, if you allow a simpified RBF where 'you can replace if
> > 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
> > old tx isnt',
> > it works.
> >
> > It allows someone 100k of free tx spam, sure. But it's simple.
> >
> > We could further restrict it by marking the unilateral close somehow
> to
> > say "gonna be pushed" and further limiting the child tx weight (say,
> > 5kSipa?) in that case.
> >
> > Cheers,
> > Rusty.
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191025/58a3d7b8/attachment-0001.html>;

📅 Original date posted:2019-10-24 📝 Original ...

2023-06-07T18:21:23Z

In reply to nevent1q…zw35
_________________________

📅 Original date posted:2019-10-24
📝 Original message:Reviving this old thread now that the recently released RC for bitcoind
0.19 includes the above mentioned carve-out rule.

In an attempt to pave the way for more robust CPFP of on-chain contracts
(Lightning commitment transactions), the carve-out rule was added in
https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on an
implementation of a new commitment format for utilizing the Bring Your Own
Fees strategy using CPFP, I’m wondering if the special case rule should
have been relaxed a bit, to avoid the need for adding a 1 CSV to all
outputs (in case of Lightning this means HTLC scripts would need to be
changed to add the CSV delay).

Instead, what about letting the rule be

The last transaction which is added to a package of dependent
transactions in the mempool must:
* Have no more than one unconfirmed parent.

This would of course allow adding a large transaction to each output of the
unconfirmed parent, which in effect would allow an attacker to exceed the
MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is this a problem
with the current mempool acceptance code in bitcoind? I would imagine
evicting transactions based on feerate when the max mempool size is met
handles this, but I’m asking since it seems like there has been several
changes to the acceptance code and eviction policy since the limit was
first introduced.

- Johan

On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Matt Corallo <lf-lists at mattcorallo.com> writes:
> >>> Thus, even if you imagine a steady-state mempool growth, unless the
> >>> "near the top of the mempool" criteria is "near the top of the next
> >>> block" (which is obviously *not* incentive-compatible)
> >>
> >> I was defining "top of mempool" as "in the first 4 MSipa", ie. next
> >> block, and assumed you'd only allow RBF if the old package wasn't in the
> >> top and the replacement would be. That seems incentive compatible; more
> >> than the current scheme?
> >
> > My point was, because of block time variance, even that criteria doesn't
> hold up. If you assume a steady flow of new transactions and one or two
> blocks come in "late", suddenly "top 4MWeight" isn't likely to get
> confirmed until a few blocks come in "early". Given block variance within a
> 12 block window, this is a relatively likely scenario.
>
> [ Digging through old mail. ]
>
> Doesn't really matter. Lightning close algorithm would be:
>
> 1. Give bitcoind unileratal close.
> 2. Ask bitcoind what current expidited fee is (or survey your mempool).
> 3. Give bitcoind child "push" tx at that total feerate.
> 4. If next block doesn't contain unilateral close tx, goto 2.
>
> In this case, if you allow a simpified RBF where 'you can replace if
> 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3. old tx
> isnt',
> it works.
>
> It allows someone 100k of free tx spam, sure. But it's simple.
>
> We could further restrict it by marking the unilateral close somehow to
> say "gonna be pushed" and further limiting the child tx weight (say,
> 5kSipa?) in that case.
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191024/065e650f/attachment.html>;

📅 Original date posted:2018-05-23 📝 Original ...

2023-06-07T18:12:15Z

In reply to nevent1q…etpk
_________________________

📅 Original date posted:2018-05-23
📝 Original message:Thanks, Jimpo!

This is very encouraging, I think. I sorta assumed that separating the
elements into their own sub-filters would hurt the compression a lot more.
Can the compression ratio/false positive rate be tweaked with the
sub-filters in mind?

With the total size of the separated filters being no larger than the
combined filters, I see no benefit of combined filters? Committing to them
all in the headers would also save space, and we could ensure nodes are
serving all sub-filters.

- Johan

On Wed, May 23, 2018 at 9:38 AM, Jim Posen <jim.posen at gmail.com> wrote:

> So I checked filter sizes (as a proportion of block size) for each of the
> sub-filters. The graph is attached.
>
> As interpretation, the first ~120,000 blocks are so small that the
> Golomb-Rice coding can't compress the filters that well, which is why the
> filter sizes are so high proportional to the block size. Except for the
> input filter, because the coinbase input is skipped, so many of them have 0
> elements. But after block 120,000 or so, the filter compression converges
> pretty quickly to near the optimal value. The encouraging thing here is
> that if you look at the ratio of the combined size of the separated filters
> vs the size of a filter containing all of them (currently known as the
> basic filter), they are pretty much the same size. The mean of the ratio
> between them after block 150,000 is 99.4%. So basically, not much
> compression efficiently is lost by separating the basic filter into
> sub-filters.
>
> On Tue, May 22, 2018 at 5:42 PM, Jim Posen <jim.posen at gmail.com> wrote:
>
>> My suggestion was to advertise a bitfield for each filter type the node
>>> serves,
>>> where the bitfield indicates what elements are part of the filters. This
>>> essentially
>>> removes the notion of decided filter types and instead leaves the
>>> decision to
>>> full-nodes.
>>>
>>
>> I think it makes more sense to construct entirely separate filters for
>> the different types of elements and allow clients to download only the ones
>> they care about. If there are enough elements per filter, the compression
>> ratio shouldn't be much worse by splitting them up. This prevents the
>> exponential blowup in the number of filters that you mention, Johan, and it
>> works nicely with service bits for advertising different filter types
>> independently.
>>
>> So if we created three separate filter types, one for output scripts, one
>> for input outpoints, and one for TXIDs, each signaled with a separate
>> service bit, are people good with that? Or do you think there shouldn't be
>> a TXID filter at all, Matt? I didn't include the option of a prev output
>> script filter or rolling that into the block output script filter because
>> it changes the security model (cannot be proven to be correct/incorrect
>> succinctly).
>>
>> Then there's the question of whether to separate or combine the headers.
>> I'd lean towards keeping them separate because it's simpler that way.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180523/7df6715a/attachment.html>;

📅 Original date posted:2018-05-22 📝 Original message:Maybe ...

2023-06-07T18:12:14Z

In reply to nevent1q…gmyq
_________________________

📅 Original date posted:2018-05-22
📝 Original message:Maybe I didn't make it clear, but the distinction is that the current track
allocates
one service bit for each "filter type", where it has to be agreed upon up
front what
elements such a filter type contains.

My suggestion was to advertise a bitfield for each filter type the node
serves,
where the bitfield indicates what elements are part of the filters. This
essentially
removes the notion of decided filter types and instead leaves the decision
to
full-nodes.

This would require a "getcftypes" message, of course.

- Johan

On Tue, May 22, 2018 at 3:16 AM, Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:

> > What if instead of trying to decide up front which subset of elements
> will
> > be most useful to include in the filters, and the size tradeoff, we let
> the
> > full-node decide which subsets of elements it serves filters for?
>
> This is already the case. The current "track" is to add new service bits
> (while we're in the uncommitted phase) to introduce new fitler types. Light
> clients can then filter out nodes before even connecting to them.
>
> -- Laolu
>
> On Mon, May 21, 2018 at 1:35 AM Johan Torås Halseth <johanth at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Most light wallets will want to download the minimum amount of data
>> required to operate, which means they would ideally download the smallest
>> possible filters containing the subset of elements they need.
>>
>> What if instead of trying to decide up front which subset of elements
>> will be most useful to include in the filters, and the size tradeoff, we
>> let the full-node decide which subsets of elements it serves filters for?
>>
>> For instance, a full node would advertise that it could serve filters for
>> the subsets 110 (txid+script+outpoint), 100 (txid only), 011 (script+outpoint)
>> etc. A light client could then choose to download the minimal filter type
>> covering its needs.
>>
>> The obvious benefit of this would be minimal bandwidth usage for the
>> light client, but there are also some less obvious ones. We wouldn’t have
>> to decide up front what each filter type should contain, only the possible
>> elements a filter can contain (more can be added later without breaking
>> existing clients). This, I think, would let the most served filter types
>> grow organically, with full-node implementations coming with sane defaults
>> for served filter types (maybe even all possible types as long as the
>> number of elements is small), letting their operator add/remove types at
>> will.
>>
>> The main disadvantage of this as I see it, is that there’s an exponential
>> blowup in the number of possible filter types in the number of element
>> types. However, this would let us start out small with only the elements we
>> need, and in the worst case the node operators just choose to serve the
>> subsets corresponding to what now is called “regular” + “extended” filters
>> anyway, requiring no more resources.
>>
>> This would also give us some data on what is the most widely used filter
>> types, which could be useful in making the decision on what should be part
>> of filters to eventually commit to in blocks.
>>
>> - Johan
>> On Sat, May 19, 2018 at 5:12, Olaoluwa Osuntokun via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin-
>>
>>> Monitoring inputs by scriptPubkey vs input-txid also has a massive
>>>> advantage for parallel filtering: You can usually known your pubkeys
>>>> well in advance, but if you have to change what you're watching block
>>>> N+1 for based on the txids that paid you in N you can't filter them
>>>> in parallel.
>>>>
>>>
>>> Yes, I'll grant that this is a benefit of your suggestion.
>>>
>>
>> Yeah parallel filtering would be pretty nice. We've implemented a serial
>> filtering for btcwallet [1] for the use-case of rescanning after a seed
>> phrase import. Parallel filtering would help here, but also we don't yet
>> take advantage of batch querying for the filters themselves. This would
>> speed up the scanning by quite a bit.
>>
>> I really like the filtering model though, it really simplifies the code,
>> and we can leverage identical logic for btcd (which has RPCs to fetch the
>> filters) as well.
>>
>> [1]: https://github.com/Roasbeef/btcwallet/blob/master/chain/
>> neutrino.go#L180
>>
>> _______________________________________________ bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.
>> org/mailman/listinfo/bitcoin-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180522/cdeb1da6/attachment.html>;

📅 Original date posted:2018-05-21 📝 Original message:Hi ...

2023-06-07T18:12:13Z

In reply to nevent1q…6y0t
_________________________

📅 Original date posted:2018-05-21
📝 Original message:Hi all,
Most light wallets will want to download the minimum amount of data required to operate, which means they would ideally download the smallest possible filters containing the subset of elements they need.
What if instead of trying to decide up front which subset of elements will be most useful to include in the filters, and the size tradeoff, we let the full-node decide which subsets of elements it serves filters for?

For instance, a full node would advertise that it could serve filters for the subsets 110 (txid+script+outpoint), 100 (txid only), 011 ( script+outpoint) etc. A light client could then choose to download the minimal filter type covering its needs.
The obvious benefit of this would be minimal bandwidth usage for the light client, but there are also some less obvious ones. We wouldn’t have to decide up front what each filter type should contain, only the possible elements a filter can contain (more can be added later without breaking existing clients). This, I think, would let the most served filter types grow organically, with full-node implementations coming with sane defaults for served filter types (maybe even all possible types as long as the number of elements is small), letting their operator add/remove types at will.
The main disadvantage of this as I see it, is that there’s an exponential blowup in the number of possible filter types in the number of element types. However, this would let us start out small with only the elements we need, and in the worst case the node operators just choose to serve the subsets corresponding to what now is called “regular” + “extended” filters anyway, requiring no more resources.
This would also give us some data on what is the most widely used filter types, which could be useful in making the decision on what should be part of filters to eventually commit to in blocks.
- Johan On Sat, May 19, 2018 at 5:12, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin- Monitoring inputs by scriptPubkey vs input-txid also has a massive
advantage for parallel filtering: You can usually known your pubkeys
well in advance, but if you have to change what you're watching block
N+1 for based on the txids that paid you in N you can't filter them
in parallel.

Yes, I'll grant that this is a benefit of your suggestion.
Yeah parallel filtering would be pretty nice. We've implemented a serial filtering for btcwallet [1] for the use-case of rescanning after a seed phrase import. Parallel filtering would help here, but also we don't yet take advantage of batch querying for the filters themselves. This would speed up the scanning by quite a bit.
I really like the filtering model though, it really simplifies the code, and we can leverage identical logic for btcd (which has RPCs to fetch the filters) as well.
[1]: https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180 [https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180]
_______________________________________________ bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180521/d4626f97/attachment.html>;