Re: [Lightning-dev] Turbo channels spec?

[Rusty Russell]

Sorry this took so long.

https://github.com/lightningnetwork/lightning-rfc/pull/895

This changed quite a bit, based on discussion here and more coherent
thinking.

1. You can simply send funding_locked early, no feature needed.
2. It's a bit useless unless you are the (sole) funder or you trust the
   other side.  Without that, you can neither accept payments nor route
   them; in theory if they used push_msat you could send payments out,
   but that seems a niche case.
3. We do want to know the short_channel_id they're going to use for the
   channel, so we can add it to routehints for incoming payments.

Adding the scid is nice anyway, for chainsplit scenarios.

Here is the new text, a little formatted:

1. `tlv_stream`: `funding_locked_tlvs`
2. types:
1. type: 1 (`short_channel_id`)
2. data:
* [`short_channel_id`:`short_channel_id`]
 
 Requirements

The sender:
...
 - SHOULD set `short_channel_id`

 - if it is the sole contributor to the funding transaction, or
   has reason to trust the peer:

- MAY send `funding_locked` before the funding transaction
  has reached `minimum_depth`
- MAY set `short_channel_id` to a fake value, if it will
  route payments to that `short_channel_id`.
  - otherwise:
- MUST wait until the funding transaction has reached
  `minimum_depth` before sending this message.

  - SHOULD re-transmit `funding_locked` if the
`short_channel_id` for this chanel has changed.
...
The receiver:
  - SHOULD ignore the `funding_locked` if it knows the
`short_channel_id` of the channel and it differs from the
value in `funding_locked`.

...

Nodes which have funded the channel or trust their peers to have done,
can simply start using the channel instantly by sending
`funding_locked`.  This raises the problem of how to use this new
channel in route hints, since it does not yet have a block number.
For this reason, a convincing fake number can be use; when the real
funding transaction is finally mined, it can re-send `funding_locked`
with the real value.

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

For sure, CT can be done with computational soundness. The advantage of
unhidden amounts (as with current bitcoin) is that you get unconditional
soundness. My understanding is that there is a fundamental tradeoff between
unconditional soundness and unconditional privacy. I believe Monero has
taken this alternate tradeoff path with unconditional privacy but only
computational soundness

.

> old things that never move more or less naturally "fall leftward"

Ah yes, something like that would definitely be interesting to basically
make dust a moot point. Sounds like the tradeoff mentioned is that proofs
would be twice as big? Except newer UTXOs would have substantially shorter
proofs. It sounds like the kind of thing where there's some point where
there would be so many old UTXOs that proofs would be smaller on average in
the swap tree version vs the dead-leaf version. Maybe someone smarter than
me could estimate where that point is.

On Mon, Aug 9, 2021 at 10:04 PM Jeremy  wrote:

> You might be interested in https://eprint.iacr.org/2017/1066.pdf which
> claims that you can make CT computationally hiding and binding, see section
> 4.6.
>
> with respect to utreexo, you might review
> https://github.com/mit-dci/utreexo/discussions/249?sort=new which
> discusses tradeoffs between different accumulator designs. With a swap
> tree, old things that never move more or less naturally "fall leftward",
> although there are reasons to prefer alternative designs.
>
>
>>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Charlie Lee]

ZmnSCPxj, what you are describing is pretty much what Litecoin is doing
with MWEB. Basically MimbleWimble (which has CT) with extension blocks. If
you are interested:
https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki
https://github.com/litecoin-project/lips/blob/master/lip-0003.mediawiki

Sorry to derail the conversation with non-Bitcoin stuff. 

- Charlie


On Tue, Aug 10, 2021 at 5:38 AM ZmnSCPxj via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> wrote:

> Good morning Billy, et al.,
>
> > For sure, CT can be done with computational soundness. The advantage of
> unhidden amounts (as with current bitcoin) is that you get unconditional
> soundness.
>
> My understanding is that it should be possible to have unconditional
> soundness with the use of El-Gamal commitment scheme, am I wrong?
>
> Alternately, one possible softforkable design would be for Bitcoin to
> maintain a non-CT block (the current scheme) and a separately-committed CT
> block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that
> includes witnesses).
> When transferring funds from the legacy non-CT block, on the legacy block
> you put it into a "burn" transaction that magically causes the same amount
> to be created (with a trivial/publicly known salt) in the CT block.
> Then to move from the CT block back to legacy non-CT you would match one
> of those "burn" TXOs and spend it, with a proof that the amount you are
> removing from the CT block is exactly the same value as the "burn" TXO you
> are now spending.
>
> (for additional privacy, the values of the "burn" TXOs might be made into
> some fixed single allowed value, so that transfers passing through the CT
> portion would have fewer identifying features)
>
> The "burn" TXOs would be some trivial anyone-can-spend, such as
> ` <0> OP_EQUAL OP_NOT` with `` being what is used in
> the CT to cover the value, and knowledge of the scalar behind this point
> would allow the CT output to be spent (assuming something very much like
> MimbleWimble is used; otherwise it could be the hash of some P2WSH or
> similar analogue on the CT side).
>
> Basically, this is "CT as a 'sidechainlike' that every fullnode runs".
>
> In the legacy non-CT block, the total amount of funds that are in all CT
> outputs is known (it would be the sum total of all the "burn" TXOs) and
> will have a known upper limit, that cannot be higher than the supply limit
> of the legacy non-CT block, i.e. 21 million BTC.
> At the same time, *individual* CT-block TXOs cannot have their values
> known; what is learnable is only how many BTC are in all CT block TXOs,
> which should be sufficient privacy if there are a large enough number of
> users of the CT block.
>
> This allows the CT block to use an unconditional privacy and computational
> soundness scheme, and if somehow the computational soundness is broken then
> the first one to break it would be able to steal all the CT coins, but not
> *all* Bitcoin coins, as there would not be enough "burn" TXOs on the legacy
> non-CT blockchain.
>
> This may be sufficient for practical privacy.
>
>
> On the other hand, I think the dust limit still makes sense to keep for
> now, though.
>
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Billy Tetrud]

> 5) should we ever do confidential transactions we can't prevent it without 
> compromising
privacy / allowed transfers

I wanted to mention the dubiousness of adding confidential transactions to
bitcoin. Because adding CT would eliminate the ability for users to audit
the supply of Bitcoin, I think its incredibly unlikely to ever happen. I'm
in the camp that we shouldn't do anything that prevents people from
auditing the supply. I think that camp is probably pretty large. Regardless
of what I think should happen there, and even if CT were to eventually
happen in bitcoin, I don't think that future possibility is a good reason
to change the dust limit today.

It seems like dust is a scalability problem regardless of whether we use
Utreexo eventually or not, tho an accumulator would help a ton. One idea
would be to destroy/delete dust at some point in the future. However, even
if we were to plan to do this, I still don't think the dust limit should be
removed. But the dust limit should probably be lowered a bit, given that
the 546 sats limit is about 7 cents and its very doable to send 1 sat/vbyte
transactions, so lowering it to 200 sats seems reasonable.


On Mon, Aug 9, 2021 at 6:24 AM Antoine Riard via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> 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]. Of course, we
> can adjust the LN security model around dust handling to mitigate the
> safety risk in case of adversarial settings, but ultimately the standard
> dust limit creates a  "hard" bound, and as such it introduces a trust
> vector in the reliability of your peer to not goes
> onchain with a commitment heavily-loaded with dust-HTLC you own.
>
> LN node operators might be willingly to compensate this "dust" trust
> vector by relying on side-trust model, such as PKI to authenticate their
> peers or API tokens (LSATs, PoW tokens), probably not free from
> consequences for the "openness" of the LN topology...
>
> Further, I think any authoritative setting of the dust limit presents the
> risk of becoming ill-adjusted  w.r.t to market realities after a few months
> or years, and would need periodic reevaluations. Those reevaluations, if
> not automated, would become a vector of endless dramas and bikeshedding as
> the L2s ecosystems grow bigger...
>
> Note, this would also constrain the design space of newer fee schemes.
> Such as negotiated-with-mining-pool and discounted consolidation during low
> feerate periods deployed by such producers of low-value outputs.
> `
> Moreover as an operational point, if we proceed to such an increase on the
> base-layer, e.g to 20 sat/vb, we're going to severely damage the
> propagation of any LN transaction, where a commitment transaction is built
> with less than 20 sat/vb outputs. Of course, core's policy deployment on
> the base layer is gradual, but we should first give a time window for the
> LN ecosystem to upgrade and as of today we're still devoid of the mechanism
> to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence
> protocol [1]).
>
> That said, as raised by other commentators, I don't deny we have a
> long-term tension between L2 nodes and full-nodes operators about the UTXO
> set growth, but for now I would rather solve this with smarter engineering
> such as utreexo on the base-layer side or multi-party shared-utxo or
> compressed colored coins/authentication smart contracts (e.g
> opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than
> altering the current equilibrium.
>
> I think the status quo is good enough for now, and I believe we would be
> better off to learn from another development cycle before tweaking the dust
> limit in any sense.
>
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html
> [1] https://github.com/lightningnetwork/lightning-rfc/pull/869
>
> Le dim. 8 août 2021 à 14:53, Jeremy  a écrit :
>
>> We should remove the dust limit from Bitcoin. Five reasons:
>>
>> 1) it's not our business what outputs people want to create
>> 2) dust outputs can be used in various authentication/delegation smart
>> contracts
>> 3) dust sized htlcs in lightning (
>> https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light)
>> force channels to operate in a semi-trusted mode which has implications
>> (AFAIU) for the regulatory classification of channels in various
>> jurisdictions; agnostic treatment of fund transfers would simplify this
>> (like getting a 0.01 cent dividend check in the mail)
>> 4) thinly divisible colored coin protocols might make use of sats as
>> value markers for transactions.
>> 5) should we ever do confidential transactions we can't prevent it
>> without compromising privacy / allowed transfers
>>
>> The main 

Re: [Lightning-dev] v0.10.1: "eltoo: Ethereum Layer Too"

[Prayank via Lightning-dev]

Hi Lisa,

> lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
> We're pleased to announce the 0.10.1 release of c-lightning
> , named
> by @nalinbhardwaj.
I am confused about the subject of this email. Is this an Ethereum project? 
What exactly is Ethereum layer and how is it related to this release?

-- 
Prayank

A3B1 E430 2298 178F
 

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Karl]

Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Prayank via Lightning-dev]

> As feerates have gone up over time, and as we expect them to go up further, 
>we should be considering drastically increasing the 3 sat/vByte basis to 
>something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are 
not going up. Yes, we expect them to go up and miners revenue from fees as 
well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. 
Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly 
reset to 1-5 sat/vByte and very low since long time now except when hash rate 
went down.

Fees per MB since 2016: https://i.imgur.com/XEkkf99.png 

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

-- 
Prayank
 
A3B1 E430 2298 178F

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Oleg Andreev]

I agree with Jeremy. Dust limit works due to design accident: that outputs are 
not encrypted. But outputs are private business and the real issue is only the 
cost of utxo set storage born by every user. There are two ways to address this:

1) either make ppl pay for renting that storage (which creates a ton of 
problems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is 
perfectly solved by Utreexo.

But looking at the private data because you can is a hack that creates issues 
of its own.

> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> If it weren't for the implications in changing standardness here, I think we 
> should consider increasing the dust limit instead.
> 
> The size of the UTXO set is a fundamental scalability constraint of the 
> system. In fact, with proposals like assume-utxo/background history sync it 
> is arguably *the* fundamental scalability constraint of the system. Today's 
> dust limit is incredibly low - its based on a feerate of only 3 sat/vByte in 
> order for claiming the UTXO to have *any* value, not just having enough value 
> to be worth bothering. As feerates have gone up over time, and as we expect 
> them to go up further, we should be considering drastically increasing the 3 
> sat/vByte basis to something more like 20 sat/vB.
> 
> Matt
> 
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
> 
> It is precisely our business - the costs are born by us, not the creator. If 
> someone wants to create outputs which don't make sense to spend, they can do 
> so using OP_RETURN, since they won't spend it anyway.
> 
>> 2) dust outputs can be used in various authentication/delegation smart 
>> contracts
> 
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-them 
> outputs.
> 
>> 3) dust sized htlcs in lightning 
>> (https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light
>>  
>> )
>>  force channels to operate in a semi-trusted mode which has implications 
>> (AFAIU) for the regulatory classification of channels in various 
>> jurisdictions; agnostic treatment of fund transfers would simplify this 
>> (like getting a 0.01 cent dividend check in the mail)
> 
> This is unrelated to the consensus dust limit. This is related to the 
> practical question about the value of claiming an output. Again, the 
> appropriate way to solve this instead of including spendable dust outputs 
> would be an OP_RETURN output (though I believe this particular problem is 
> actually better solved elsewhere in the lightning protocol).
> 
>> 4) thinly divisible colored coin protocols might make use of sats as value 
>> markers for transactions.
> 
> These schemes can and should use values which make them economical to spend. 
> The whole *point* of the dust limit is to encourage people to use values 
> which make sense economically to "clean up" after they're done with them. If 
> people want to use outputs which they will not spend/"clean up" later, they 
> should be using OP_RETURN.
> 
>> 5) should we ever do confidential transactions we can't prevent it without 
>> compromising privacy / allowed transfers
> 
> This is the reason the dust limit is not a *consensus* limit. If and when CT 
> were to happen we can and would relax the standardness rules around the dust 
> limit to allow for CT.
> 
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
> 
> 3) The significant costs to every miner and full node operator.
> ___
> bitcoin-dev mailing list
> bitcoin-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev