Good morning aj,
> On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
>
> > A transaction is required, but I believe it is not necessary to put it
> > onchain (at the cost of implementation complexity in the drop-onchain case).
>
> The trick with that is that if you don't put it on chain,
On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote:
> A transaction is required, but I believe it is not necessary to put it
> *onchain* (at the cost of implementation complexity in the drop-onchain case).
The trick with that is that if you don't put it on chain, you need
to calculate the f
Good morning aj,
> In order to transition from BOLT#3 format to this proposal, an onchain
> transaction is required, as the "revocable signatures" arrangement cannot
> be mimicked via the existing 2-of-2 CHECKMULTISIG output.
A transaction is required, but I believe it is not necessar
Hi all,
Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
taproot and implement PTLCs.
It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and
some of his and Lloyd Fournier's posts since then (which are listed in
references) -- in particular, I think those
Good morning Pieter,
> Indeed - UTXO set size is an externality that unfortunately Bitcoin's
> consensus rules fail to account
> for. Having a relay policy that avoids at the very least economically
> irrational behavior makes
> perfect sense to me.
>
> It's also not obvious how consensus rules
Hello,
When you navigate to https://github.com/lightningnetwork/ you find
- the Lightning Network white paper
- the Lightning Network specifications
- and ... the source code for lnd!
This has been an anomaly for years, which has created some confusion
between Lightning the open-source protocol a
Good morning shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by some
> nodes.
Is this supposed to be consensus change or not?
Why "some" nodes and not all?
I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is import
The suggested idea I was replying to is to make all dust TXs invalid by
some nodes. I suggested a compromise by keeping them in secondary storage
for full nodes, and in a separate Merkle Tree for bridge servers.
-In bridge servers they won't increase any worstcase, on the contrary this
will enhance
