On Tue, Jun 19, 2018 at 04:46:32PM +0200, Christian Decker wrote:
> That is true, we can't prevent S_2 to make it into the blockchain, but
> we can make sure it doesn't have any effect (aside from wasting some
> fees), by simply binding S_3 to it immediately afterwards.
Right, but I'm picking on
On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote:
> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
> transaction containing the settlement is expected to have (at least) two
> inputs, with the second one originating the fees. That second input's
&g
On Wed, Nov 07, 2018 at 10:30:12PM +, ZmnSCPxj via Lightning-dev wrote:
> However, SIGHASH_NOINPUT would allow Lightning implementations to be
> "walletless".
Maybe I'm misunderstanding, but wouldn't this require comitting to the
transaction fees for the various delayed-broadcast
On Sat, Jan 05, 2019 at 07:01:18AM +, ZmnSCPxj wrote:
> Good morning David,
>
> What happens if the exchange node only sends its preimage towards the
> payer and not towards the payee?
>
> If the payer and payee do not coordinate, then it becomes possible for
> the exchange node to take the
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote:
> I'm also starting to implement this, to see what I missed!
>
> - Feerate is fixed at 253 [satoshis per 1,000 weight]
IIUC, this is just over Bitcoin Core's default minimum relay fee of
0.1000 BTC/vByte. That works right now,
On Thu, Dec 27, 2018 at 05:43:51AM +, ZmnSCPxj via Lightning-dev wrote:
> We can try to mitigate this, but the solutions below all have significant
> drawbacks.
An alternative is to give the person making the exchange the ability to
cancel the payment if they think the exchange rate has
On Fri, Jul 05, 2019 at 03:36:37AM +, ZmnSCPxj via Lightning-dev wrote:
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
Is this an actual concern? Assuming this protocol is used with web
On Thu, Sep 05, 2019 at 11:29:35AM +, ZmnSCPxj via Lightning-dev wrote:
> Good morning list,
>
> I do not see much point in using miniscript for Lightning unless we
> decide to support transporting arbitrary contracts, as here:
>
On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote:
> Time-Dilation Attacks on Offchain Protocols
> ===
What is the advantage of these sophisticated attacks over the eclipse
attacker simply not relaying the honest user's commitment or penality
On Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:
> With Phoenix [1], we've been experimenting with pay-to-open [2].
>
> That works well in practice and provides a great UX for newcomers, but
> it requires temporary trust between the user and our node (until the
> funding tx
On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:
> If well executed, attacks described stay stealth until it's too late
> to react.
I suspect the attacks you described are pretty easy to detect (assuming
block relay is significantly delayed) by simply comparing the time of
the
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] 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.
> [... subsequent email ...]
> I
On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:
> 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
On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote:
> Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is
> `dustRelayFee` really never going to change? It even is a (hidden) cmd line
> parameter that can be set easily.
>
> If the fee market would rise and stay high for an
On Tue, Jan 07, 2020 at 12:26:05AM +, ZmnSCPxj wrote:
> For `nSequence` relative-locktime transactions that protect the
> security of the channel mechanism, these are used in unilateral
> closes. The issue is that a unilateral close might occur far, far in
> the future. Thus, any non-0
On Sun, Jan 12, 2020 at 03:01:06PM +, ZmnSCPxj wrote:
> Basically, on every Poon-Dryja commitment transaction [...]
>
> * one output will be directly spendable by the remote side.
> * one output will be spendable by the local side [...] after a
> relative locktime [...]
>
> So if the
On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
> Hi ZmnSCPxj and Aj,
>
> Thanks for starting this discussion ZmnSCPxj. Although transactions with
> relative lock times are easily distinguishable today, couldn't this
> situation be improved? Even just a few wallets changing their
On Fri, Apr 03, 2020 at 02:51:15AM +, ZmnSCPxj via Lightning-dev wrote:
> Ah, right, E knows the revocation for the unilateral close of EE,
> because it is a self-channel, sigh. And by this revocation clause it
> can claim the money immediately and put it into a channel as well.
If it's a
On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
> if you focus on sending the pinning transaction to miner nodes
> directly (which isn't trivial, but also not nearly as hard as it
> sounds), you could still pull off the attack.
If the problem is that miners might have information
On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
> A lightning counterparty (C, who received the HTLC from B, who
> received it from A) today could, if B broadcasts the commitment
> transaction, spend an HTLC using the preimage with a low-fee,
> RBF-disabled
On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?
>
> That's an interesting idea, but an attacker can create a local conflict
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be broadc
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev
wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Quoted text below is from the gist:
>
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.
The problem I have with that approach is that the incentive is to
connect
On Sun, Jun 21, 2020 at 06:09:28PM -0700, Olaoluwa Osuntokun wrote:
> IMO this is mostly mitigated by anchor commitments. The impact of this
> attack is predicated on the "victim" paying 5x on-chain fees (for their
> confirmation target) to sweep all their HTLCs.
I think the attack is more
On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
> If c = 1 (i.e. the node is fine and it wants to continue the channel) then
> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes
> it sends the commitment blinding y back to prove that it doesn't have the
>
On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> SIGHASH_ANYPREVOUT
>
> For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
> solve the pre-signed feerate issue [3]
>
> [...]
>
> [3] I don't
On Fri, Jul 02, 2021 at 02:20:51PM -0400, Antoine Riard wrote:
> More personally, I feel it would be better if such a new specification
> process doesn't completely share the same communication infrastructure as
> the BOLTs, like [avoiding] having them in the same repository.
In addition to
On Mon, Dec 07, 2020 at 11:32:27AM +1100, Lloyd Fournier wrote:
> I've been considering the problem of recovering lightning channels after
> losing channel state in a boating accident. The modern way of doing this
> seems to be "static channel backups" -- these are essentially lists of
> channel
On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote:
> 2. It is not easy to figure out whether it worked or not
Good point.
> 3. This is incompatible with covert recovery schemes like in [1] [...]
> (3) is also a problem with just doing encrypted backups -- going around
> looking for
On 22.03.2022 15:10, Olaoluwa Osuntokun wrote:
### Should the proof+verification strongly bind to the LN context?
Today, nodes use the two bitcoin keys and construct a p2wsh
multi-sig script and then verify that the script matches what has been
confirmed on chain. With taproot, the output is
Hi Laolu,
[Dropping the CC to Bitcoin-Dev as my questions below are LN focused.]
Thank your for the detailed proposed BIPs. One question I have is
whether anything about Taro or the way you plan to implement support for
transferring fungible assets via asset-aware LN endpoints[1] will
address
On 2023-09-17 18:14, ZmnSCPxj via bitcoin-dev wrote:
Let A_1 ... A_n denote a large number of casual users, let B be a
dedicated user, and let E denote some fixed time in the future.
User B creates a timeout-tree with expiry E where:
* leaf i has an output that funds a Lightning channel owned
On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote:
The basic problem here is after the HTLC-timeout path becomes
spendable, the
HTLC-preimage path remains spendable. That's bad, because in this case
we want
spending the HTLC-preimage - if possible - to have an urgency attached
to it to
On 2023-10-21 18:49, Nadav Ivgi via bitcoin-dev wrote:
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode
that requires _all_ inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the
On 2023-10-17 03:03, Bastien TEINTURIER via bitcoin-dev wrote:
Good morning list,
I've been trying to design a protocol to let users withdraw funds from
exchanges directly into their lightning wallet in an efficient way
(with the smallest on-chain footprint possible).
Hi, Bastien.
Is
On 2023-08-20 16:25, Atomic Mr Nuclear wrote:
Dear community,
In the attachment you will find a new proposal for Lightning multipeer
payment channels
Hi,
Thanks for working on multiparty channel design. Quoting from the
paper:
in case some of the peers become unresponsive, the channel
On 2022-09-22 16:08, ZmnSCPxj wrote:
Basically, you can model a rate card as four separate channels between
the same two nodes, with different costs each.
If the path at the lowest cost fails, you just try at another route
that may have more hops but lower effective cost, or else try the same
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.
Am I understanding correctly that this
On 2022-10-03 06:55, jlspc via Lightning-dev wrote:
The WF Protocol
===
Hi John,
I had difficulty understanding your proposal description here and in
your paper[1]. I wonder if others are having the same the same
difficulty, so I've tried to reduce it down to just the essential
On 2023-01-03 03:57, ZmnSCPxj via Lightning-dev wrote:
The contract has two participants: Alice the funds owner, and
Bob its potential swap partner.
[...]
The contract has only 2 branches:
* Onchain/channel branch: Alice and Bob.
* Timelock branch: Alice plus a relative timelock (`OP_CSV`)
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 node, which I then jam up.
This reduces the reputation of my competitor
On 2022-11-21 14:26, Antoine Riard wrote:
Clara Shikhelman wrote:
4. How would these tokens work with blinded paths and other
privacy-preserving suggestions?
Primarily, the tokens could use the new onion messages and blinded
paths for the dissemination and renewal rounds. Current design
Hi John,
Thank you for another innovative application of your tunable penalties.
I see two key benefits being described by your paper[1]:
- **Offchain channel resizes:** in state 0, Alice and Bob share control
over an offchain UTXO valued at x satoshis; in state 1, the value of
the offchain
On 2023-06-19 05:26, callebtc via Lightning-dev wrote:
Our team at LNbits discovered a rather interesting
exploit which which would enable an attacker to create balances out of
thin air by abusing a quirk in how invoices are handled internally.
Hi Calle,
If I understand correctly from some
On 2023-06-12 22:10, Thomas Voegtlin wrote:
The semantics of bundled payments is as follows:
- 1. the BOLT-11 invoice contains two preimages and two amounts:
prepayment and main payment.
- 2. the receiver should wait until all the HTLCs of both payments
have arrived, before they fulfill the
On 2023-12-28 08:06, jlspc via bitcoin-dev wrote:
On Friday, December 22nd, 2023 at 8:36 AM, Nagaev Boris
wrote:
To validate a transaction with FDT [...]
a light client would have to determine the median fee
rate of the recent blocks. To do that without involving trust, it has
to download the
On Mon, Aug 09, 2021 at 09:22:28AM -0400, Antoine Riard wrote:
> I'm pretty conservative about increasing the standard dust limit in any
> way. This would convert a higher percentage of LN channels capacity into
> dust, which is coming with a lowering of funds safety [0].
I think that reasoning
On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions
On Mon, Nov 15, 2021 at 04:25:26PM +0100, Joost Jager wrote:
> Reliability is a property of a route that can
> be expressed as a probability. The probability that a route will be
> successful.
I don't think users care about the abstract concept of reliability
that's being returned by the
50 matches
Mail list logo
