Sent with Proton Mail secure email.
On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd
wrote:
> On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote:
>
> > Peter Todd proposes to sign multiple versions of offchain transactions at
> > varying feerates.
> > However, this proposal
> I should note that under Decker-Russell-Osuntokun the expectation is that
> both counterparties hold the same offchain transactions (hence why it is
> sometimes called "LN-symmetry").
> However, there are two ways to get around this:
>
> 1. Split the fee between them in some "fair" way.
>
Good morning Michael et al,
>
> I assume that a CTV based LN-Symmetry also has this drawback when compared to
> an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry could
> change the fees in every channel update based on what the current market fee
> rate was at the time of
Halfway through, I thought "is it not possible to have two Bob-owned outputs
that sum up to the total Bob-owned amount, with a CLTV on up to the amount that
was purchased and the rest (if above dust limit) without a CLTV?"
so e.g. if the purchased amount is 2 units but the total channel
Good morning Antoine,
> Once the HTLC is committed on the Bob-Caroll link, Caroll releases the
> preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob
> does _not_ send back his signature for the updated channel state.
>
> Some blocks before 100, Caroll goes on-chain to
Hi all,
This was discussed partially on the platform formerly known as twitter, but an
alternate design goes like this:
* Add an `nExpiryTime` field in taproot annex.
* This indicates that the transaction MUST NOT exist in a block at or above
the height specified.
* Mempool should put txes
Good morning Greg,
> > I do not know if existing splice implementations actually perform such a
> > check.
> Unless all splice implementations do this, then any kind of batched splicing
> is risky.
> As long as the implementation decides to splice again at some point when a
> prior
> splice
Good morning Bastien,
I have not gotten around to posting it yet, but I have a write-up in my
computer with the title:
> Batched Splicing Considered Risky
The core of the risk is that if:
* I have no funds right now in a channel (e.g. the LSP allowed me to have 0
reserve, or this is a
Good morning Antoine et al.,
Let me try to rephrase the core of the attack.
There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==`
are channels):
A = B = C
`A` routes `A->B->C`.
The timelocks, for example, could be:
A->B timeelock = 144
B->C timelock
Good morning again list, particularly cdecker who is the "Decker" in
Decker-Wattenhofer,
Below is some numbers for implementing a sidepool using Decker-Wattenhofer, in
case `SIGHASH_NOINPUT` so we can do Decker-Russell-Osuntokun takes two more
years.
First, I should note that ***if*** we
Good morning Erik,
> > replacing CTV usage with Musig2
>
>
> this changes the trust model to a federated one vs trustless and also
> increases the on-chain footprint of failure, correct?
As I understand it, no.
MuSig and MuSig2 are n-of-n signing algorithms.
The implied usage is that all
Good morning John,
> On the other hand, if the consensus rules are changed to allow even simple
> covenants, this scaling bottleneck is eliminated.
> The key observation is that with covenants, a casual user can co-own an
> off-chain Lightning channel without having to sign all (or any) of the
Introduction: On The Difficulty Of Predicting The Future
What company will have the largest gross earnings next year?
If you could predict that consistently, you would likely be able to succeed at
stock-picking and already have
Good morning t-bast,
CLN already has something similar in standard CLN distrib:
https://docs.corelightning.org/docs/commando
However it is tied specifically to the CLN command set.
Nevertheless, it is largely the same idea, just CLN-specific.
Regards,
ZmnSCPxj
Sent with Proton Mail secure
Dear Mr Nucleus, and list,
Some more points:
* Miners in existing Bitcoin are only given the ability to reorder
transactions, but not to outright spend funds.
This is why drivechains --- and recursive covenants, which, with some
additional covenant features (that are more useful in general
Good morning Mr Nuclear,
> You are correct that the design relies on the honest majority assumption.
> However, I disagree that it restricts the usability of the proposal,
> due to the following considerations.
>
> 1. Any distributed system consensus, including bitcoin PoW consensus,
> relies
Good morning list,
I would like to share a simple scheme for creating a `keysend` protocol that
allows for multipath payments.
In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.
In the multipath case, we want the receiver to only be able to claim the
payment once all
> > - For taproot/musig2 we need nonces:
> > - Today we store the commitment signature from the remote party. We don’t
> > need to store our own signature - we can sign at time of broadcast.
> > - To be able to sign you need the verification nonce - you could remember
> > it, or you could use
Good morning Bastien,
> Hey Zman,
>
> I'm a bit confused because you use a different mechanism than the one
> specified in the latest schnorr multi-hop locks proposal that I know of,
> which can be found in [1].
It seems to me that my proposal is simply a restatement of the same scheme.
>
> If
Good morning all,
Recently, it has been pointed out that even with Noise encryption, a
third-party eavesdropper can make a good guess of what messages are being sent
between LN nodes by checking the sizes of IP packets transmitted between them.
This potentially allows an eavesdropper to figure
Good morning list,
Here is a simple mathematical demonstration of a particular way to compute
blinding factors such that:
* All non-Trampoline intermediate nodes only need to know one blinding factor.
* The receiver only needs to know one blinding factor.
* Trampoline nodes can provide the
Good morning mailing list, et al.,
Let me explain the various possible mitigations and their drawbacks.
Many of these are either "LSP trusts client" or "client trusts LSP", in the
sense that it is possible for the second mover (client in "LSP trusts client";
LSP in "client trusts LSP") to
Good morning Matt, and t-bast,
Your proposal basically means "do not dual-fund 0-conf".
You might as well use the much simpler openv1 flow in that case, just because
it is simpler.
Regards,
ZmnSCPxj
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, May 9th,
Good morning benthecarman and SomberNight,
As noted by SomberNight, PTLCs does not quite fix this, as the client can still
wait out the inbound PTLC of the LSP and force the LSP to perform an onchain
action to ensure it does not give a channel for free.
Another wrinkle here is that the LSP can
Good morning t-bast, and list,
Dual-funded 0-conf can be made safe in the following case:
* If the initiator uses swap-in-potentiam addresses (with initiator as Alice,
acceptor as Bob).
If the initiator stalls, then the acceptor can retaliate by refusing to sign
the swap-in-potentiam UTXOs
Good morning list,
I would like to point out that one of the main issues with LSPs is that most of
them are designed to lock in their customers to their platform.
Hopefully, with a common open specification like this, it becomes significantly
more feasible for Lightning end-user clients to
Good morning again ariard and t-bast,
>
> For cases where the one doing splice-in is an LSP and the other side is a
> client of that LSP, also consider this proposal:
> https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
>
> While it is designed for 0-conf channel funding, the actual
Hi ariard and t-bast,
I would like to point out that spends from swap-in-potentiam addresses are
safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.
On the other hand swap-in-potentiam is arguably cheating, since sending to a
swap-in-potentiam address is actually a
Good morning 10k1,
> The use case is related to my work on Indranet, where channel sizes are going
> to be a lot lower than normal because they only have to transport very small
> payments (in the hundreds of sats at a time) and maintaining balance of the
> channels to keep them as much
Good morning 10k1,
> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard
> people talk about opening channels in more complex transactions than 2 of 2
> multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think
> that if channels were
Good morning all,
> > First of all let's see what types of reputation system exist (and yes,
> > this is my very informal categorization):
> >
> > - First hand experience
> > - Inferred experience
> > - Hearsay
> >
> > The first two are likely the setup we all are comfortable with: we ourselves
Good morning Laolu,
> Hi Z,
>
> > * Submarine swap/peerswap: Requires confirmation before the swap service
> > will send out the HTLC on Lightning.
>
> I might be missing something, but I don't see how this is different from a
> normal on-chain to off-chain swap (calling this Loop In for
Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning
by Jesse Posner, ZmnSCPxj
Introduction
Moving funds from an onchain-only address to Lightning Network is slow,
especially if you desire trust-minimization (which removes solutions
relying on 0-conf).
Good morning Antoine,
> About secondary-markets, the credentials themselves are subject to the
> classic double-spend problem. E.g, Alice can transfer her "Ned" credentials
> both to Bob and Caroll, without any of them getting knowledge of the
> duplication. So it could be expected secondary
Good morning Antoin, Dave, et al.,
> Hi Dave,
>
> I think the issue you're describing about credential tampering by
> intermediary nodes is correct. If Alice controls Y along the path
> W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
> issue generalizes for any
Good morning David,
> On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
>
> > If I am an LSP, and I know my competitor LSP distributes their
> > credentials, then I can simply apply to be a spoke on my competitor
> > and then make several payments to my n
Good morning Antoine,
> It should be noted, this current reputation-credential architectural
> framework assumes credentials distribution at the endpoint of the network.
> However, the framework should be flexible enough for the credentials to be
> harvested by the LSPs, and then distributed
Good morning list,
I saw elsewhere that there are plans to move peerswap to *two* hops, but no
further, as reliability is a concern.
The logic behind allowing up to two hops distance is that the two endpoints
know the state of the channels to the intermediate node.
But we should also consider
Good morning Joe,
> > Unfortunately, only the first sub-protocol (onchain-to-offchain)
> > is actually forwardable.
>
>
>
> I think it's possible to forward offchain-to-onchain swap as well, by
> just making a payjoin tx by net receiver (initiator) and net sender.
>
> Let me explain it in a
Good morning list,
I have also seen elsewhere someone expressing the idea that "rebalancing is not
exploitative, as the low-fee nodes are freely allowing use of their capacity at
low feerates".
First, let me make the strong claim that I am in fact a 100% human being, and
very specifically
Good morning list,
I saw elsewhere that there are plans to move peerswap to *two* hops, but no
further, as reliability is a concern.
The logic behind allowing up to two hops distance is that the two endpoints
know the state of the channels to the intermediate node.
But we should also consider
Good morning Joe,
> > Unfortunately, only the first sub-protocol (onchain-to-offchain)
> > is actually forwardable.
>
>
>
> I think it's possible to forward offchain-to-onchain swap as well, by
> just making a payjoin tx by net receiver (initiator) and net sender.
>
> Let me explain it in a
Introduction
First, a joke:
> Once upon a time, an economist and its friend, both of
> them being 100% human and not at all AIs out to take
> over the Bitcoin world, were walking on a street using
> 100% meat legs.
>
> They spotted a 1 Bitcoin Casascius coin on the street,
> and
Subject: Forwardable Peerswaps
Introduction
[Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds
and offchain in-Lightning funds.
The intent of this protocol is to allow managing the inbound and outbound
capacities of your node without having to perform
Good morning aj,
> > Forwarding nodes sell liquidity.
> > If a forwarding node runs out of stock of liquidity (i.e. their channel is
> > unbalanced against the direction a payment request fails) they earn 0
> > profit.
>
>
> I get what you're saying, but I don't think a "stock of liquidity"
>
Good morning aj, Rene, and all,
So let me discuss a little more about how I model the forwarding nodes.
Forwarding nodes want to maximize profit.
Forwarding nodes sell liquidity.
If a forwarding node runs out of stock of liquidity (i.e. their channel is
unbalanced against the direction a
Good morning aj,
> > Basically, the intuition "small decrease in `htlc_max_msat` == small
> > decrease in payment volume" inherently assumes that HTLC sizes have a flat
> > distribution across all possible sizes.
>
>
> The intuition is really the other way around: if you want a stable,
>
Good morning again aj, and Rene,
> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> >
Good morning aj, and Rene,
> * you're providing a way of throttling payment traffic independent of
> fees -- since fees are competitive, they can have discontinuous effects
> where a small change to fee can cause a large change to traffic volume;
> but this seems like it should mostly have a
Good morning Dave,
> On 2022-09-13 11:15, lisa neigut wrote:
>
> > Hi all,
>
>
> Hi Lisa,
>
> Thank you for describing this idea in detail on the mailing list.
>
> > A ratecard is a set of four values, positive or negative, that price
> > different bands of available liquidity for a channel.
Good morning Martin,
> Hi folks,
>
> I think I've seen wallets supporting "send max" when a zero-amount invoice
> was used. So isn't it a problem with the custodial service not supporting it?
> Whatever idea we figure out they can just refuse to implement it so we can't
> force them into
Good morning Rene,
> Dear fellow Lightning Developers,
>
> I was recently on an event where the visitors have been gifted 10k sats on a
> custodial wallet. They could spend those sats via some web interface and an
> NFC card. During the event I was contacted by several plebs who were confused
Good morning Michael,
> Hey ZmnSCPxj
>
> It is an interesting topic. Alex Bosworth did a presentation at the Lightning
> Hack Day last year with a similar attempt at categorizing the different
> strategies for a routing/forwarding node (Ping Pong, Liquidity Battery,
> Inbound Sourcing,
Good morning aj,
> On Wed, Jun 29, 2022 at 12:38:17PM +, ZmnSCPxj wrote:
>
> > > > ### Inverting The Filter: Feerate Cards
> > > > Basically, a feerate card is a mapping between a probability-of-success
> > > > range and a feerate.
> > > > * 00%->25%: -10ppm
> > > > * 26%->50%: 1ppm
> > > >
Good morning aj,
> On Sun, Jun 05, 2022 at 02:29:28PM +0000, ZmnSCPxj via Lightning-dev wrote:
>
> Just sharing my thoughts on this.
>
> > Introduction
> >
> > Optimize for reliability+
&g
Good morning list,
This is a short (relative to my typical crap) writeup on some strategies that
Lightning forwarding nodes might utilize.
I have been thinking of various strategies that actual node operators (as I
understood from discussing with a few of them) use:
* Passive rebalance /
> ## Lightning Gossip
>
> # Gossip V2: Now Or Later?
> A proposal for the "re-design the entire thing" was floated in the past by
> Rusty [6]. It does away with the strict coupling of channels to channel
> announcements, and instead moves them to the _node_ level. Each node would
> then
Introduction
Bell Curve Meme (LEET ASCII ART SKILLZ)
Optimize for reliability+
uncertainty+fee+drain+uptime...
.--~~--.
/\
/ \
/\
/ \
Good morning devrandom,
It seems to me that a true validating Lightning signer would need to be a
Bitcoin node with active mitigation against eclipse attacks, the ability to
monitor the blockheight, and the ability to broadcast transactions.
Otherwise, a compromised node can lie and tell the
Good morning John,
Thank you for clarifying.
> Zman,
> I was not arguing for moving things from the edge, nor was I arguing to make
> Taro a BOLT. Laolu is misinterpreting my message.
> I was explaining that the capabilities that would allow Taro to interact with
> LN have no special
Good morning John, and Laolu,
> > but instead the requirement to add several feature concepts to LN that
> > would allow tokens to interact with LN nodes and LN routing:
>
> From this list of items, I gather that your vision is actually pretty
> different from ours. Rather than update the core
Good morning pushd,
> > Source routing means that Boltz Exchange can report your onchain address,
> > but cannot correlate it with your published node.
>
> I used boltz onion link:
> http://tboltzzrsoc3npe6sydcrh37mtnfhnbrilqi45nao6cgc6dr7n2eo3id.onion however
> I still need to trust boltz
Good morning pushd,
> Good morning,
>
> Things that affect privacy particularly when large sums of money are involved
> in bitcoin:
>
> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime
> and Version
>
> I have left out things that aren't part of bitcoin protocol or
Good morning Rene, sorry for the lateness,
> Last but not least, please allow me to make a short remark on the (still to
> me very surprisingly controversial) base fee discussion: For simplicity I did
> not include any fee considerations to the published code (besides a fee
> report on how
Good morning Paul,
> I don't think I can stop people from being ignorant about Drivechain. But I
> can at least allow the Drivechain-knowledgable to identify each other.
>
> So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand
Good morning lightning-dev and bitcoin-dev,
Recently, some dumb idiot, desperate to prove that recursive covenants are
somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused
Paul Sztorc to [revive][1] and make the following statement:
> As is well known, it is easy for
Good morning Jeremy,
> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit key
> required means you have to pre-plan suppose you're building a vault meant
> to distribute funds over many years, do you
Good morning DA,
> Agreed, you cannot rely on a replacement transaction would somehow
> invalidate a previous version of it, it has been spoken into the gossip
> and exists there in mempools somewhere if it does, there is no guarantee
> that anyone has ever heard of the replacement transaction
Good morning Peter and Jeremy,
> Good morning Peter and Jeremy,
>
> > On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote:
> >
> > > > Necromancing might be a reasonable name for attacks that work by
> > > > getting an
> > > > out-of-date version of a tx mined.
> > >
> > > It's not an
Good morning Peter and Jeremy,
> On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote:
>
> > > Necromancing might be a reasonable name for attacks that work by getting
> > > an
> > > out-of-date version of a tx mined.
> >
> > It's not an "attack"? There is no such thing as an out-of-date
Good morning shymaa,
> I just want to add an alarming info to this thread...
>
> There are at least 5.7m UTXOs≤1000 Sat (~7%),
> 8.04 m ≤1$ (10%),
> 13.5m ≤ 0.0001BTC (17%)
>
> It seems that bitInfoCharts took my enquiry seriously and added a main link
> for dust analysis:
>
Channel Eviction From Channel Factories By New Covenant Operations
==
N-of-N channel factories have an important advantage compared to N-of-N
offchain CoinPools or statechains: even if one participant in the channel
factory is
Good morning rusty,
If we are going to switch to a new gossip version, should we prepare now for
published channels that are backed by channel factories?
Instead of a UTXO serving as a bond to allow advertisement of a *single*
channel, allow it to advertise *multiple* channels.
This does not
Good morning Ronan,
> If there is a payment to go from party A to be split between parties B & C,
> is it possible that only one of B or C would need a plugin?
>
> If all receiving parties need a plugin that is quite limiting. Thanks, Ronan
Given N payees, only N - 1 need the plugin.
The last
Good morning cdecker,
> I was looking into the docs [1] and stumbled over `createinvoice` which does
> almost what you need. However it requires the preimage, and stores the
> invoice in the database which you don't want.
Indeed, that is precisely the issue, we need a `signfakeinvoice`
Good morning William,
> Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
> it be, could it be done with a clightning plugin perhaps?
Probably not *yet*; it needs each intermediate payee (i.e. the one that is not
the last one) to sign an invoice for which it does not know
Good morning Bastien,
> * it's impossible for a node to prove that it did *not* receive a message:
> you can prove knowledge,
> but proving lack of knowledge is much harder (impossible?)
Yes, it is impossible.
If there could exist a proof-of-lack-of-knowledge, then even if I personally
Good morning t-bast,
> I believe these new transactions may require an additional round-trip.
> Let's take a very simple example, where we have one pending PTLC in each
> direction: PTLC_AB was offered by A to B and PTLC_BA was offered by B to A.
>
> Now A makes some unrelated updates and wants
Good morning LL, and t-bast,
> > Basically, if my memory and understanding are accurate, in the above, it is
> > the *PTLC-offerrer* which provides an adaptor signature.
> > That adaptor signature would be included in the `update_add_ptlc` message.
>
> Isn't it the case that all previous PTLC
Good morning t-bast,
Long ago:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002385.html
And I quote:
>> A potential issue with MuSig is the increased number of communication rounds
>> needed to generate signatures.
>
>I think you can reduce this via an alternative
Good morning Jeremy,
> Just a minor curiosity I figured was worth mentioning on the composition of
> delegations and anyprevout...
>
> DA: Let full delegation be a script S such that I can sign script R and then
> R may sign for a transaction T.
> DB: Let partial delegation be a script S such
Good morning x raid,
> We are talkin interoperability among impl not individual node operators
> version management of chosen impl.
>
> where Pierre of Acinq says
> "So we eat our own dog food and will experience force closes before our users
> do.."
> hahaha made my day ...
>
> a node operator
Good morning x-raid,
> so You propose Acinq / Blockstream / Lightning Labs do not have funds to run
> a box or 2 ?
Not at all, I am proposing that these people, who have already done the effort
to release working Lightning Network Node implementations free of charge to
you, are not obligated
Good morning x-raid,
> what i can imagine is each team should provide boxes and channel liquidity as
> stake on mainnet for tests before announce a public realise as to feel the
> pain first hand instead of having several K´s of plebs confused and at worst
> have funds in channelclosed etc.
Good morning again x-raid,
Are you proposing as well to provide the hardware and Internet connection for
these boxes?
I know of one person at least who runs a node that tracks the C-Lightning
master (I think they do a nightly build?), and I run a node that I update every
release of
Good morning x-raid,
> I propose a dialog of the below joint effort ...
>
> thanks
> /xraid
>
> ***
> A decentralised integration lab where CL Eclair LDK LND (++ ?) runs each the
> latest release on "one box" rBOX and master.rc on "another box" rcBOX.
I believe Electrum also has its own bespoke
Good morning Dave,
> If LN software speculatively chooses a series of attempts with a similar
> 95%, accounting for things like the probability of a stuck payment (made
> worse by longer CLTV timeouts on some paths), it could present users
> with the same sort of options:
>
> ~1 second, x fee
>
Good morning Joost,
> What I did in lnd is to work with so called 'payment attempt cost'. A virtual
> satoshi amount that represents the cost of a failed attempt.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003191.html
And I quote:
> Introduction
>
>
>
Good morning again list,
>
> > We could use an identicon, we do that with the lightningnetwork repository.
> > An official logo is probably better - give the project a real symbol.
>
> I attached an SVG file I have been working on for some time, for the
> amusement of all.
>
> It is
Good morning list,
> We could use an identicon, we do that with the lightningnetwork repository.
> An official logo is probably better - give the project a real symbol.
I attached an SVG file I have been working on for some time, for the amusement
of all.
It is unfortunately not square, and
Good morning Joost,
> On Thu, Oct 21, 2021 at 12:00 PM ZmnSCPxj wrote:
>
> > Good morning Joost,
> >
> > > A potential downside of a dedicated probe message is that it could be
> > > used for free messaging on lightning by including additional data in the
> > > payload for the recipient. Free
Good morning Joost,
> A potential downside of a dedicated probe message is that it could be used
> for free messaging on lightning by including additional data in the payload
> for the recipient. Free messaging is already possible today via htlcs, but a
> probe message would lower the cost to
Good morning Joost,
> There could be some corners where the incentives may not work out 100%, but I
> doubt that any routing node would bother exploiting this. Especially because
> there could always be that reputation scheme at the sender side which may
> cost the routing node a lot more in
Good morning Owen,
> C now notes that B is lying, but is faced with the dilemma:
>
> "I could either say 'no' because I can plainly see that B is lying, or
> I could say 'yes' and get some free sats from the failed payment (or
> via the hope of a successful payment from a capacity increase in the
Good morning Prayank,
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
>
> Still trying to understand this problem and possible solutions. Interesting
> email though (TIL), thanks for sharing the link. Found related things
> explained Suredbits blog as
Good morning Owen,
> On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
>
> > So how would things work out with a combination of both of the
> > proposals described in this mail? First we make probing free (free as
> > in no liquidity locked up) and then we'll require senders to pay for
Good morning Matt,
> On 10/13/21 02:58, ZmnSCPxj wrote:
>
> > Good morning Matt,
> >
> > > The Obvious (tm) solution here is PTLCs - just have the sender
> > > always add some random nonce * G to
> > > the PTLC they're paying and send the recipient a random nonce in the
> > > onion.
Good morning Matt,
> The Obvious (tm) solution here is PTLCs - just have the sender always add
> some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the
> onion. I'd generally suggest we
> just go ahead and do this for every PTLC payment,
Good morning Prayank,
> Hello everyone,
>
> I wanted to know few things related to asset issuance on lightning:
>
> 1.Is it possible to issue assets on LN right now? If yes, what's the process
> and is it as easy as few commands in liquid:
>
Good morning aj,
> On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote:
>
> > ### Scorched earth punishment
> >
> > Another thing that I'd like to mention is that using revocable signatures
> > enables scorched earth punishments [2].
>
> I kind-of think it'd be more interesting to
1 - 100 of 600 matches
Mail list logo
