Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good morning e, > mostly thinking out loud > > suppose there is a "lightweight" node: > > 1. ignores utxo's below the dust limit > 2. doesn't validate dust tx > 3. still validates POW, other tx, etc. > > these nodes could possibly get forked - accepting a series of valid, > mined blocks where there is an invalid but ignored dust tx, however > this attack seems every bit as expensive as a 51% attack How would such a node treat a transaction that spends multiple dust UTXOs and creates a single non-dust UTXO out of them (after fees)? Is it valid (to such a node) or not? I presume from #1 it never stores dust UTXOs, so the node cannot know if the UTXO being spent by such a tx is spending dust, or trying to spend an already-spent TXO, or even inventing a TXO out of `/dev/random`. Regards, ZmnSCPxj ___ 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
Jumping in late to this thread. I very much agree with how David Harding presents things, with a few comments inline. ‐‐‐ Original Message ‐‐‐ On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev wrote: > > 1. it's not our business what outputs people want to create > > Every additional output added to the UTXO set increases the amount of > work full nodes need to do to validate new transactions. For miners > for whom fast validation of new blocks can significantly affect their > revenue, larger UTXO sets increase their costs and so contributes > towards centralization of mining. > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > UTXO set during periods of low feerates. > If your stuff is going to slow down my node and possibly reduce my > censorship resistance, how is that not my business? 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 could deal with this, as you don't want consensus rules with hardcoded prices/feerates. There are possibilities with designs like transactions getting a size/weight bonus/penalty, but that's both very hardforky, and hard to get right without introducing bad incentives. > > 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 > > > 4. thinly divisible colored coin protocols might make use of sats as value > > markers for transactions. My personal, and possibly controversial, opinion is that colored coin protocols have no business being on the Bitcoin chain, possibly beyond committing to an occasional batched state update or so. Both because there is little benefit for tokens with a trusted issuer already, and because it competes with using Bitcoin for BTC - the token that pays for its security (at least as long as the subsidy doesn't run out). Of course, personal opinions are no reason to dictate what people should or can use the chain for, but I do think it's reason to voice hesitancy to worsening the system's scalability properties only to benefit what I consider misguided use. > > 5. should we ever do confidential transactions we can't prevent it without > > compromising privacy / allowed transfers > > I'm not an expert, but it seems to me that you can do that with range > proofs. The range proof for >dust doesn't need to become part of the > block chain, it can be relay only. Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, which could be required as part of a relay policy. Cheers, -- Pieter ___ 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
mostly thinking out loud suppose there is a "lightweight" node: 1. ignores utxo's below the dust limit 2. doesn't validate dust tx 3. still validates POW, other tx, etc. these nodes could possibly get forked - accepting a series of valid, mined blocks where there is an invalid but ignored dust tx, however this attack seems every bit as expensive as a 51% attack On Fri, Oct 1, 2021 at 3:45 AM Pieter Wuille via bitcoin-dev wrote: > > Jumping in late to this thread. > > I very much agree with how David Harding presents things, with a few comments > inline. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev > wrote: > > > > 1. it's not our business what outputs people want to create > > > > Every additional output added to the UTXO set increases the amount of > > work full nodes need to do to validate new transactions. For miners > > for whom fast validation of new blocks can significantly affect their > > revenue, larger UTXO sets increase their costs and so contributes > > towards centralization of mining. > > Allowing 0-value or 1-sat outputs minimizes the cost for polluting the > > UTXO set during periods of low feerates. > > If your stuff is going to slow down my node and possibly reduce my > > censorship resistance, how is that not my business? > > 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 could deal with this, as you don't > want consensus rules > with hardcoded prices/feerates. There are possibilities with designs like > transactions getting > a size/weight bonus/penalty, but that's both very hardforky, and hard to get > right without > introducing bad incentives. > > > > 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 > > > > > 4. thinly divisible colored coin protocols might make use of sats as > > > value > > > markers for transactions. > > My personal, and possibly controversial, opinion is that colored coin > protocols have no business being on the Bitcoin chain, possibly > beyond committing to an occasional batched state update or so. Both because > there is little benefit for tokens with a trusted > issuer already, and because it competes with using Bitcoin for BTC - the > token that pays for its security (at least as long as > the subsidy doesn't run out). > > Of course, personal opinions are no reason to dictate what people should or > can use the chain for, but I do think it's reason to > voice hesitancy to worsening the system's scalability properties only to > benefit what I consider misguided use. > > > > 5. should we ever do confidential transactions we can't prevent it > > > without > > > compromising privacy / allowed transfers > > > > I'm not an expert, but it seems to me that you can do that with range > > proofs. The range proof for >dust doesn't need to become part of the > > block chain, it can be relay only. > > Yeah, range proofs have a non-hidden range; the lower bound can be nonzero, > which could be required as part of a relay policy. > > Cheers, > > -- > Pieter > > ___ > 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] Opening balanced channels using PSBT
Hi Olaoluwa
Thank you for your reply!
Good point that channel state is transitory, my thinking was that opening
balanced channels simplifies things for new routing nodes, rather than
having to balance them out through fee adjustments when most channels are
lopsided. But I clearly need to learn more about this.
--
Ole Henrik Skogstrøm
Mobile: (+47) 97 42 74 44
On Thu, Sep 23, 2021 at 1:31 AM Olaoluwa Osuntokun
wrote:
> Hi Ole,
>
> It's generally known that one can use out of band transaction construction,
> and the push_amt feature in the base funding protocol to simulate dual
> funded channels.
>
> The popular 'balanceofsatoshis' tool has a command that packages up the
> interaction (`open-balanced-channel`) into an easier to use format, IIRC it
> uses key send to ask a peer if they'll accept one and negotiate some of the
> params.
>
> The one thing you need to take mind of when doing this manually is that by
> default lnd will only lock the UTXOs allocated for the funding attempt for
> a
> few minutes. As a result, you need to make sure the process is finalized
> during that interval or the UTXOs will be unlocked and you risk
> accidentally
> double spending yourself.
>
> Lightning Pool also uses this little trick to allows users to purchase
> channels that are 50/50 balanced, and also purchase channel leases _for_ a
> third party (called sidecar channels) to help on board them onto Lightning:
> https://lightning.engineering/posts/2021-05-26-sidecar-channels/. Compared
> to the above approaches, the process can be automatically batched w/ other
> channels created in that epoch, and uses traits of the Pool account system
> to make things atomic.
>
> Ultimately, the balanced-ness of a channel is a transitory state (for
> routing nodes, it's great for on-boarding end-users) and opening channels
> like these only serves to allow the channel to _start_ in the state. If
> your
> fees and channel policies aren't set accordingly, then it's possible that a
> normal payment or balance flow shifts the channel away from equilibrium
> shortly after the channel is open.
>
> -- Laolu
>
> On Tue, Sep 21, 2021 at 10:30 PM Ole Henrik Skogstrøm <
> oleskogst...@gmail.com> wrote:
>
>> Hi
>>
>> I have found a way of opening balanced channels using LND's psbt option
>> when opening channels. What I'm doing is essentially just joining funded
>> PSBTs before signing and submitting them. This makes it possible to open a
>> balanced channel between two nodes or open a ring of balanced channels
>> between multiple nodes (ROF).
>>
>> I found this interesting, however I don't know if this is somehow unsafe
>> or for some other reason a bad idea. If not, then it could be an
>> interesting alternative to only being able to open unbalanced channels.
>>
>> To do this efficiently, nodes need to collaborate by sending PSBTs back
>> and forth to each other and doing this manually is a pain, so if this makes
>> sense to do, it would be best to automate it through a client.
>>
>> --
>> --- Here is an example of the complete flow for a single channel:
>> --
>>
>> ** Node A: generates a new address and sends address to Node B *(lncli
>> newaddress p2wkh)
>>
>> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
>> (lncli openchannel --psbt 200 100)
>>
>> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B funds the refund transaction to Node A and sends PSBT back to
>> Node A (*bitcoin-cli walletcreatefundedpsbt []
>> '[{"":0.01}]')
>>
>> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
>> joinpsbts '["", ""]')
>>
>> ** Node B verifies the content and signs the joined PSBT before sending
>> it back to Node A *(bitcoin-cli walletprocesspsbt )
>>
>> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
>> walletprocesspsbt )
>>
>> ** Node A: Completes channel open by publishing the fully signed PSBT*
>>
>>
>> --
>> --- Here is an example of the complete flow for a ring of channels
>> between multiple nodes:
>> --
>>
>> ** Node A starts an Interactive open channel to Node B using psbt*
>> (lncli openchannel --psbt --no_publish 200 100)
>> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B starts an Interactive open channel to Node C using psbt*
>> (lncli openchannel --psbt --no_publish 200 100)
>> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node C starts an Interactive open channel to Node A using psbt*
>> (lncli openchannel --psbt 200 100)
>> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B and C sends Node A their PSBTs*
>>
>> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
>> '["", "",
>> ""]')
>>
>> Using (bitcoin-cli
Re: [Lightning-dev] Opening balanced channels using PSBT
Thank you Bastien
Didn't know about this PR. Should have searched more thoroughly next time.
But good to see this feature is underway.
--
Ole Henrik Skogstrøm
Mobile: (+47) 97 42 74 44
On Wed, Sep 22, 2021 at 8:58 AM Bastien TEINTURIER wrote:
> Hi,
>
> This is exactly what the dual funding proposal provides:
> https://github.com/lightningnetwork/lightning-rfc/pull/851
>
> Cheers,
> Bastien
>
> Le mer. 22 sept. 2021 à 07:29, Ole Henrik Skogstrøm <
> oleskogst...@gmail.com> a écrit :
>
>> Hi
>>
>> I have found a way of opening balanced channels using LND's psbt option
>> when opening channels. What I'm doing is essentially just joining funded
>> PSBTs before signing and submitting them. This makes it possible to open a
>> balanced channel between two nodes or open a ring of balanced channels
>> between multiple nodes (ROF).
>>
>> I found this interesting, however I don't know if this is somehow unsafe
>> or for some other reason a bad idea. If not, then it could be an
>> interesting alternative to only being able to open unbalanced channels.
>>
>> To do this efficiently, nodes need to collaborate by sending PSBTs back
>> and forth to each other and doing this manually is a pain, so if this makes
>> sense to do, it would be best to automate it through a client.
>>
>> --
>> --- Here is an example of the complete flow for a single channel:
>> --
>>
>> ** Node A: generates a new address and sends address to Node B *(lncli
>> newaddress p2wkh)
>>
>> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
>> (lncli openchannel --psbt 200 100)
>>
>> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B funds the refund transaction to Node A and sends PSBT back to
>> Node A (*bitcoin-cli walletcreatefundedpsbt []
>> '[{"":0.01}]')
>>
>> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
>> joinpsbts '["", ""]')
>>
>> ** Node B verifies the content and signs the joined PSBT before sending
>> it back to Node A *(bitcoin-cli walletprocesspsbt )
>>
>> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
>> walletprocesspsbt )
>>
>> ** Node A: Completes channel open by publishing the fully signed PSBT*
>>
>>
>> --
>> --- Here is an example of the complete flow for a ring of channels
>> between multiple nodes:
>> --
>>
>> ** Node A starts an Interactive open channel to Node B using psbt*
>> (lncli openchannel --psbt --no_publish 200 100)
>> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B starts an Interactive open channel to Node C using psbt*
>> (lncli openchannel --psbt --no_publish 200 100)
>> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node C starts an Interactive open channel to Node A using psbt*
>> (lncli openchannel --psbt 200 100)
>> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
>> [] '[{"":0.02}]')
>>
>> ** Node B and C sends Node A their PSBTs*
>>
>> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
>> '["", "",
>> ""]')
>>
>> Using (bitcoin-cli walletprocesspsbt ):
>>
>>
>>
>> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
>> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
>> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
>> sending it to Node A and B.*
>>
>>
>> ** Node A completes channel open (no_publish)* Node B completes channel
>> open (no_publish)* Node C completes channel open and publishes the
>> transaction.*
>>
>> --
>> Ole Henrik Skogstrøm
>>
>> ___
>> 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
