Re: [Lightning-dev] Lightning Mints
Good afternoon ZmnSCPxj, Thank you for your thoughtful reply! I agree with many of your points. One thing I wanted to say regarding the forces that act on banks: > It is helpful to remember that banks have, historically, been federations: > they are typically implemented as corporations, which are basically a bunch > of people pooling their money and skill together to start a business. > Thus, I argue that banks already *are* federations that take custody of your > money and manage it for you. > > To my mind, any system that is a federation that takes custody of user money > *will* face the same social, political, and economic forces that the legacy > banking system faced in the past. I actually think that banks operating on top of bitcoin may be subject to different forces. A major factor in the misbehavior of legacy banks has been lack of competition due to artificial barriers to entry due to regulation. I think in the absence of regulation, with competitors being able to enter the market at little cost, and without needing a license, we would see much less bad behavior from banks. I don't think that, aside from regulation, there is anything inherent to the business of banking that makes banks behave badly. If federated chaumian banks that interface exclusively with the Bitcoin and Lightning networks are able to evade regulators, the market for such banking services will hopefully see healthy competition between participants. This would be enhanced by the fact that such banks would be able to serve a global audience, and not be closely tied to a country, national currency, legacy settlement network, or region. > In addition, ti seems to me that the node management problem can be solved in > software, by something similar in purpose to CLBOSS. I think projects like CLBOSS are great, but I share elsirion's pessimism that LN node UX not be a fully soluble problem, no matter how good management software gets. Users will be choosing between services like Wallet of Satoshi, which are completely seamless, and it might not be possible for management software to fully abstract over things like high fees, uptime requirements, and unexpected fund unavailability due to channel closure. Best regards, Casey ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Bastien TEINTURIER writes: > Hi Rusty, > > On the eclair side, we instead send `funding_locked` as soon as we > see the funding tx in the mempool. > > But I think your proposal would work as well. This would be backward compatible, I think. Eclair would send `funding_locked`, which is perfectly legal, but a normal peer would still wait for confirms before also sending `funding_locked`; it's just that option_zeroconf_channels would mean it doesn't have to wait for that before sending HTLCs? > We may want to defer sending `announcement_signatures` until > after the funding tx has been confirmed? What `min_depth` should > we use here? Should we keep a non-zero value in `accept_channel` > or should it be zero? You can't send it before you know the channel_id, so it has to be at least 1. Spec says: - MUST NOT send `announcement_signatures` messages until `funding_locked` has been sent and received AND the funding transaction has at least six confirmations. So still compliant there? Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
Hi Lisa, First of all great work on dual-funding and I appreciate this write up too. A couple thoughts I had. > Assuming that all the UTXOs in your wallet will, at some point, end up in a > lightning channel, all of your UTXOs will be *publicly* associated with your > node at some point > Given the assumption that all of your node funds will, at some point, be used > to open a lightning channel, a single attacker discovering a subset of your > UTXOs is simply a 'fast-forward' of what will eventually become public > information. I think there’s still enough 50-50 doubt. With careful consideration to coin selection, you can keep that 50-50 across all your channels too. With a determined enough prober, they can get 100% proof of your funds for future channels. That would be what my main concern is, going from doubt to certainty. That said, I think what’s important here is that the whole world doesn’t know, unless of course the bad actor publishes to the whole world out of band. But it can’t be figured out after the fact. I do think combining a picky acceptor with your idea that you keep using the same UTXO until it gets used is a nice approach. I am not aware of how PoDLE works yet, but I do know with other coinjoining protocols, there’s a coordinator involved to handle bans, bad actors, etc. Perhaps eventually we can see a sort of coordinator(s) develop here as well. One that can be used to help facilitate multi openings via dual-funding and/or handle the bad actors that might be probing. For instance, say someone has proof that another node backed out with a specific UTXO they were offering up. They could post that information to a coordinator that keeps track of others as well. Whenever a new dual-funding request comes in, the coordinator can be queried (perhaps for a small fee), to check it’s DB of bad actors/UTXOs. It would be centralized, but could be distributed to multiple coordinators, or even just your own if you have multiple nodes you’d like to share that logic between. This wouldn’t be on the protocol level, just a thought I had that could help solve the problem. In either case, I should probably look at how PoDLE/JoinMarket solves this at all given like you said, it’s a problem amongst a way more privacy minded context. Even the fact that dual-funding exists in the world is a net positive alone to help give some doubt to all channel openings from now on. Regards, Anthony On 28 Jun 2021, at 21:21, lisa neigut wrote: > Hey all, > > The dual-funding proposal has been up for a while now, and while we've had > some really great reviews from a few people (@ariard + @rustyrussell thanks > for > your comments in particular). > > As a refresher, the PR is available here: > https://github.com/lightningnetwork/lightning-rfc/pull/851. > > I wanted to make a quick summary of some of the biggest objections to > the protocol. Most of these were made during the course of the 2018 spec > meeting in Adelaide and while we've done a decent job of architecting around > them, > I wanted to make them explicit. > > If there's more to add, please do. > > ## Point One > One: dual-funding (really the collaborative transaction protocol) requires > you to share your UTXO set with the channel peer. > > This is true, in a 'limited' sense, where 'UTXO set' is actually constricted > to 'UTXOs you're using for funding transactions'. > > On the face of it, this seems to be quite concerning to folks. Here's a few > things > that I think make this less concerning than it might appear at the outset. > > First, let's consider the current opening case. You (or your channel peer) > constructs a transaction and shares the TXID and outpoint that the funding > output can be found at. This transaction is published and mined, > after the transaction is at sufficient depth a gossip announcement > is broadcast to the entire network, explaining where the transaction can be > found. > > Under the current protocol, it's reasonable\* to conclude that > every UTXO in the funding transaction belongs to a single party, the opener. > > Assuming that all the UTXOs in your wallet will, at some point, end up > in a lightning channel, all of your UTXOs will be *publicly* associated with > your node at some point (in the current model). Your UTXO set is only > private in the present, given a long enough time period (and channel opens) > they will all be tied to your node. > > For this reason, it's probably not a great idea to fund wallets using a > separate wallet that hasn't been coinjoined or otherwise obfuscated. In > fact, I think you can make a fairly decent argument (under the existing UTXO > model) for not mixing lightning funds with any funds you wish to remain truly > private/unassociated to an 'entity'. > > Given that you're currently telling everyone what UTXOs your node owns > (or at least has a 50/50 chance of owning..) let's consider the interactive > transaction protocol. > Assuming a 2-party
Re: [Lightning-dev] Lightning Mints
Good morning elsirion, > Hi ZmnSCPxj, > > let me chime in here, I've been working on federated mint for quite some time > now but only recently began talking about it more publicly. > > > WabiSabi "simply" replaces blinded signatures with blinded credentials. > > Blinded signatures are fairly low-bandwidth either you have a blinded > > signature, or you do not. > > Credentials, however, also include a blinded homomorphic value. > > This is a very intriguing idea Casey actually mentioned to me (at least I > think it's about the same problem): > > In traditional mints we use tokens of the same denomination. For efficiency > reasons amount tiers are introduced, reducing the anonymity set per tier. If > we had blind signatures not only on random tokens but they also committed to > a separately blinded amount with a range proof that would allow one big > anonymity set over all tokens instead. Such tokens could then be combined > similarly to Liquid transaction inputs. > > I think the concept is very interesting, but for now I see a few obstacles: > > - WabiSabi uses KVACs which afaik do not allow client side validation. > While I can't say if it will be a big problem it makes detecting certain > failure scenarios harder imo. > - The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme > afaik, undermining the central premise of federated mints. If I got that > wrong this would be awesome! > - Building such an enhanced threshold blind signature scheme is more > complex and probably needs further research. A naive implementation would be > more interactive which in a federated context means waiting for consensus > rounds for each round trip which is unappealing. Well, WabiSabi is effectively n-of-n signing, as the produced transaction has to be signed by all clients of the coordinator, so threshold federated signatures are not necessary. So yes, the use of credentials seems not possible to the federated mints project. (note: I am not a mathist and have no idea what the hell credentials are, I only know how to use them) > > So while I'm very sympathetic to the idea and want to pursue it in the > future, threshold blind signatures seem like the more efficient way to get to > a working implementation with still adequate performance and privacy in time. > > > > Now, let us consider the "nodelets" idea as well. > > The "nodelets" system allows for a coordinator (which can be a separate > > entity, or, for the reduction of needed entities, any nodelet of the node). > > I didn't know of nodelets so far and went back to your 2019 post about it. It > seems that blind multisig or threshold credentials (the idea seems to be > m-of-m, so doesn't nee a general threshold scheme I guess) would improve the > privacy of the system. I think the nodelets idea is very interesting for > technical people that would otherwise be priced out of running a LN node in a > high-fee future. But the complexity of the protocol and online requirements > seem to make it suboptimal for non-technical, disinterested users. While > automating a lot of the complexity away is possible (big fan of clboss) it's > also a lot of work and probably will take a while if ever to get to a point > where the experience is plug-and-play as most non-technical users have come > to expect. > > In that sense both systems just have different target audiences. I think of > federated mints mostly as a replacement for Banks and other custodial > services that are used for their superior UX. It is fundamentally a > compromise. E.g. Bitcoin Beach currently uses Galoy [2], a centralized hosted > LN wallet without much privacy. I don't see a future where everyone there is > technical enough to run their own node or nodelet client reliably enough. But > if we can allow community driven federations with privacy built-in we can > mitigate most of the risks inherent to custodial wallets imo. >From my PoV, any "bank-replacement" that is inherently custodial will >eventually become a bank, with all the problems that implies. It is helpful to remember that banks have, historically, been federations: they are typically implemented as corporations, which are basically a bunch of people pooling their money and skill together to start a business. Thus, I argue that banks already *are* federations that take custody of your money and manage it for you. To my mind, any system that is a federation that takes custody of user money *will* face the same social, political, and economic forces that the legacy banking system faced in the past. You puny humans simply do not evolve as fast as you think, you know --- your instincts still demand that your body stock up on fat and salt and sugar in a modern era where such things are available in too much abundance that it is killing you, so I imagine that a modern federated system (like Liquid or your federated mints) will face similar forces as past successful
Re: [Lightning-dev] Lightning Mints
Hi, > * WabiSabi uses KVACs which afaik do not allow client side validation. While > I can't say if it will be a big problem it makes detecting certain failure > scenarios harder imo. > * The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme > afaik, undermining the central premise of federated mints. If I got that > wrong this would be awesome! Correct on both counts. Furthermore, WabiSabi is deliberately designed for short lived credentials, since the entire nullifier set can be discarded once a CoinJoin round terminates (successfully or unsuccessfully). For longer lived tokens a generational/epoch based approach is likely to be more practical. Alternative credential schemes can be applied in a similar way, with fairly minor differences in how attribute commitments are handled (e.g. in the balance proofs) - The ACL scheme[1] is publicly verifiable, but still relies on a single issuer. see [2] for a wallet based on thereof, as well as the cited works for some variations which rely on more general zero knowledge proofs. - The Coconut scheme [3] provides threshold issuance. I have not studied this scheme in detail, but IIRC it only supports scalar attributes (as opposed the KVACs used in WabiSabi, which also support group elements. See also Danake [4] which relies on scalar attributes only and uses epoch schemes. Another related project is zkChannels (formerly and confusingly known as BOLT) [5], the website hints at dropping the requirement for a new opcode but no details appear to be available on the website yet. [1] https://cs.brown.edu/people/fbaldimt/papers/CCS13.pdf [2] https://eprint.iacr.org/2020/382.pdf [3] https://arxiv.org/pdf/1802.07344.pdf [4] https://lightweight.money [5] https://boltlabs.tech/research ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts
Good morning lisa,
> A dedicated attacker could probably figure out your UTXO set, but that's not
> much different from the current system; the only difference is the span of
> time
> it takes them to figure it out.
>
> ## Things We've Done to Counter This:
> I had the pleasure of finally meeting Nadav of SuredBits and DLC fame in Miami
> a few weeks ago. The DLC team has adopted a version of the interactive
> transaction protocol for their own purposes. Nadav pointed out that the
> protocol we landed on for lightning interactive construction transactions
> is *quite* interactive; the DLC version modified it to use batching to
> transmit the input/output sets (the interactive protocol is one-by-one).
>
> The rationale for doing the addition of inputs and outputs in a non-batched
> fashion is that this allows for you to interleave UTXOs from a variety
> of sources, for example multiple channel opens in the same tx. With the
> current
> protocol, you can initiate a dual-funded open with many peers at the same
> time,
> each of which may contribute UTXOs and outputs for their own respective
> channel opens or UTXO consolidations etc.
>
> This gives us the real possibility of doing multiparty coinjoins on lightning.
> In fact, this is currently possible with c-lightning *today* using
> the multifundchannel command (h/t to ZmnSCPjx for the original framework
> for multifund opens).
>
> As written, the interactive transaction protocol is exceedingly flexible.
> We traded off succinctness for some plausible deniablity wrt
> any UTXOs you send to any peer -- are they yours or are they
> some third party's? How to tell?
>
> I think it's interesting to point out that "succinctness" in rounds
> of required interaction is typically a *highly* desirable trait for
> any cryptographic protocol. The establishment of a lightning channel
> relationship,
> however, isn't a cryptographic signature. A lightning channel, by its very
> nature, is typically a highly interactive relationship between two peers.
> Increasing the rounds of messaging required to establish the channel doesn't
> change the overall interactivity profile of a channel's operation, thus
> adding rounds of comms to channel open is generally a no-op in terms of
> performance/uptime requirements of a node's operations.
Possibly, a difference between the DLC use-case and the Lightning use-case is
that the DLC use-case has a definite deadline when the contract expires,
whereas the Lightning use-case has no definite end termination for the channel.
In addition, DLC requires transmitting significant amounts of data measurable
in megabytes, whereas Lightning transmits little 32-byte blobs (well not really
mostly 1366-byte onion-wrapped packages but still much tinier than the
megabytes of adaptor signatures in DLCs).
So the DLC setup stage getting hit with the optimization hammer (as a
collateral damage from the optimization hammer being used on the actual core
DLC) seems like a reasonably thing happening in the DLC use-case.
Finally, there is a big enough directory of Lightning nodes that you can
reasonably pick up this directory in lots of places, pick some random number of
them to channel to, and then make channels to them, and making them in a single
tx is always a good thing.
Whereas I imagine that the DLC use-cases (even in the future) are more limited
userbase (and with payment points on Lightning I believe the smaller and
shorter-term DLCs can run on top of Lightning), so the opportunity to aggregate
may be much rarer in DLCs than in Lightning channel opens.
> ## How important is UTXO privacy on lightning?
> Obviously important. But given that the real transactions happen inside
> of channels, invisibly, and that your public channels really truly
> are public via the gossip protocol the much more important "thing" in the
> lightning arena isn't your UTXO privacy so much as *not* associating your
> identity with your node.
I broadly agree here --- published channels trade off onchain privacy (marking
"hey this UTXO is totally owned by these two peeps!") but gain offchain privacy
("no, that is not my payment, somebody else asked me to forward it, promise!")
>
> ## Does Taproot fix this?
> I'm not up to date enough on the progress of Taproot scripts, however,
> assuming the current requirement that every routing node is able to
> independently
> verify the opening output script via the signatures provided
> in the channel_announcement, it seems reasonable that on-chain transactions
> will still be assignable to a node given gossip data. (Purely on-chain
> analysis
> will be stymied, however.)
Hmm wait Taproot fixes this?
We can drop/reinterpret `short_channel_id` post-Taproot?
Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning Mints
Hi ZmnSCPxj, let me chime in here, I've been working on federated mint for quite some time now but only recently began talking about it more publicly. > WabiSabi "simply" replaces blinded signatures with blinded credentials. > Blinded signatures are fairly low-bandwidth either you have a blinded > signature, or you do not. > Credentials, however, also include a blinded homomorphic value. This is a very intriguing idea Casey actually mentioned to me (at least I think it's about the same problem): In traditional mints we use tokens of the same denomination. For efficiency reasons amount tiers are introduced, reducing the anonymity set per tier. If we had blind signatures not only on random tokens but they also committed to a separately blinded amount with a range proof that would allow one big anonymity set over all tokens instead. Such tokens could then be combined similarly to Liquid transaction inputs. I think the concept is very interesting, but for now I see a few obstacles: * WabiSabi uses KVACs which afaik do not allow client side validation. While I can't say if it will be a big problem it makes detecting certain failure scenarios harder imo. * The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme afaik, undermining the central premise of federated mints. If I got that wrong this would be awesome! * Building such an enhanced threshold blind signature scheme is more complex and probably needs further research. A naive implementation would be more interactive which in a federated context means waiting for consensus rounds for each round trip which is unappealing. So while I'm very sympathetic to the idea and want to pursue it in the future, threshold blind signatures seem like the more efficient way to get to a working implementation with still adequate performance and privacy in time. > Now, let us consider the "nodelets" idea as well. > The "nodelets" system allows for a coordinator (which can be a separate > entity, or, for the reduction of needed entities, any nodelet of the node). I didn't know of nodelets so far and went back to your 2019 post about it. It seems that blind multisig or threshold credentials (the idea seems to be m-of-m, so doesn't nee a general threshold scheme I guess) would improve the privacy of the system. I think the nodelets idea is very interesting for technical people that would otherwise be priced out of running a LN node in a high-fee future. But the complexity of the protocol and online requirements seem to make it suboptimal for non-technical, disinterested users. While automating a lot of the complexity away is possible (big fan of clboss) it's also a lot of work and probably will take a while if ever to get to a point where the experience is plug-and-play as most non-technical users have come to expect. In that sense both systems just have different target audiences. I think of federated mints mostly as a replacement for Banks and other custodial services that are used for their superior UX. It is fundamentally a compromise. E.g. Bitcoin Beach currently uses Galoy [2], a centralized hosted LN wallet without much privacy. I don't see a future where everyone there is technical enough to run their own node or nodelet client reliably enough. But if we can allow community driven federations with privacy built-in we can mitigate most of the risks inherent to custodial wallets imo. I really hope that I'm too pessimistic here, but if not I'd rather have a backup plan in the form of federated mints than letting banks eat our lunch. The idea is still early, but I hope some can agree with my reasoning. If so, come and help build this future with me [3]! Regards, elsirion [1] https://eprint.iacr.org/2019/1416 [2] https://github.com/GaloyMoney/galoy [3] https://fedimint.org/ publickey - elsirion@protonmail.com - 0xB3CDFF6F.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Last week's second IRC workshop on L2 onchain support and wrap up
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
The conversation log for the second workshop is here:
https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
Package relay background
Package relay is potentially useful for L2 protocols to address the
inherent unpredictability of future fees. CPFP (child-pays-for-parent)
seeks to ensure say a justice transaction, in Lightning’s case, with a
lower fee, gets confirmed in a more timely manner because miners are
incentivized to include the child transaction in a block. To do so
they must include the parent transaction in that block or a preceding
block. By “packaging” the parent and the child the initiator of the
transaction(s) can ensure the miner’s mempool doesn’t initially reject
the parent transaction for having a too low fee.
There has been prior work done in previous years on package relay,
mainly by Suhas Daftuar.
Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
Package relay design questions: https://github.com/bitcoin/bitcoin/issues/14895
Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
Package relay implementation
Attendees seemed in agreement that enabling 2 transaction packages
would be sufficient (at least for now) for Lightning and DLCs. A L2
protocol should always be able to design a two step process where the
first transaction has an effective zero fee rate and the second
transaction sets the fee. Restricting the size of the package to 2 may
have the cost of slightly longer confirmation times and/or slightly
higher fees (t-bast) but it compares well to the increased
implementation complexity of larger package sizes. Two generation:
multi parent, single child shouldn’t introduce material implementation
complexity over two generation: single parent, single child (glozow).
Package RBF (replace-by-fee) is possible where there are two competing
packages with competing Lightning commitment transactions in them and
the second package is given a higher fee to attempt to get it
confirmed before the first package. However, supporting RBF within a
package (ie replacing a transaction in a package with a higher fee
transaction) increases implementation complexity and makes it harder
to reason about (glozow).
rgrant raised the possibility of using two packages {A,B} and {B,C} if
three transaction packages e.g. {A,B,C} weren’t supported but it was
suggested it is perhaps better to just broadcast a high fee CPFP
transaction for the {A,B} package rather than creating two packages.
If the first package has been evicted from the mempool the {B,C}
package wouldn’t propagate because it would be an orphan package
(t-bast).
glozow suggested that only hints (wtxids of transactions you think
should be package validated) could be communicated rather than
relaying the transaction themselves but there were concerns from
others on whether these hints would successfully propagate across the
network. Instead fee rate hints could be sent to inform a peer’s
decision on whether it makes sense to fetch the rest of the package
(t-bast).
darosior suggested the idea of a package based CBlockPolicyEstimator
in Bitcoin Core if CPFP is going to be increasingly used on the
network.
Witness replacement and Taproot
Tapscripts can be unlimited in size so with current Taproot rules you
could in theory go from a 100,000 vbyte witness to an empty witness.
L2 protocols may have a UTXO shared by two parties where Alice’s
witness for her branch is say 1,000 vbytes and Bob’s witness is only
say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller
witness could reduce transaction fees. For Lightning the best case is
a Taproot key path spend (16 vbyte witness) and the worst case is
going to be a 150 vbyte witness. Miniscript can tell you your worst
case transaction size and this can be used to assess the transaction
pinning risk of a bloated witness (all harding).
A future soft fork could give meaning to the annex in Taproot
(darosior) which could be used for inflating the fee rate of a
witness. Then you could have a same-txid-different-wtxid coming after
with a lower fee rate but higher vbytes size to override package
limits (ariard). But fee rate is purely a policy concept and the annex
operates at the consensus level. In addition the annex can only
increase the weight of a transaction, it cannot decrease it (harding).
Wrap up and initial goals
With regards to the goals of the workshops that were initially
announced here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
1) 2 transactions packages sounds enough to support currently deployed
L2
Re: [Lightning-dev] Turbo channels spec?
Thanks for instigating this, Rusty! 0conf/turbo channels have been hackable for a long time, and we would love to unlock new user experiences for our platforms with it, formally if possible. 0conf is desired by every wallet, every LN exchange, and truly shows off something only LN can uniquely offer as a UX. We are happy to support how we can, and answer any questions from the trenches. On Tue, Jun 29, 2021 at 8:34 AM Rusty Russell wrote: > Hi all! > > John Carvalo recently pointed out that not every implementation > accepts zero-conf channels, but they are useful. Roasbeef also recently > noted that they're not spec'd. > > How do you all do it? Here's a strawman proposal: > > 1. Assign a new feature bit "I accept zeroconf channels". > 2. If both negotiate this, you can send update_add_htlc (etc) *before* >funding_locked without the peer getting upset. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel >unless they have explicit reason to trust that node (they can still >send *out* that channel, because that's not their problem!). > > It's a pretty simple change, TBH (this zeroconf feature would also > create a new set of channel_types, altering that PR). > > I can draft something this week? > > Thanks! > Rusty. > -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Hi Rusty, On the eclair side, we instead send `funding_locked` as soon as we see the funding tx in the mempool. But I think your proposal would work as well. We may want to defer sending `announcement_signatures` until after the funding tx has been confirmed? What `min_depth` should we use here? Should we keep a non-zero value in `accept_channel` or should it be zero? Cheers, Bastien Le mar. 29 juin 2021 à 07:34, Rusty Russell a écrit : > Hi all! > > John Carvalo recently pointed out that not every implementation > accepts zero-conf channels, but they are useful. Roasbeef also recently > noted that they're not spec'd. > > How do you all do it? Here's a strawman proposal: > > 1. Assign a new feature bit "I accept zeroconf channels". > 2. If both negotiate this, you can send update_add_htlc (etc) *before* >funding_locked without the peer getting upset. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel >unless they have explicit reason to trust that node (they can still >send *out* that channel, because that's not their problem!). > > It's a pretty simple change, TBH (this zeroconf feature would also > create a new set of channel_types, altering that PR). > > I can draft something this week? > > Thanks! > Rusty. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
