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

[David A. Harding via bitcoin-dev]

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 is incomplete.  There are two related things here:

- **Uneconomical outputs:** outputs that would cost more to spend than
  the value they contain.

- **Dust limit:** an output amount below which Bitcoin Core (and other
  nodes) will not relay the transaction containing that output.

Although raising the dust limit can have the effect you describe, 
increases in the minimum necessary feerate to get a transaction
confirmed in an appropriate amount of time also "converts a higher
percentage of LN channel capacity into dust".  As developers, we have no
control over prevailing feerates, so this is a problem LN needs to deal
with regardless of Bitcoin Core's dust limit.

(Related to your linked thread, that seems to be about the risk of
"burning funds" by paying them to a miner who may be a party to the
attack.  There's plenty of other alternative ways to burn funds that can
change the risk profile.)

> the standard dust limit [...] introduces a trust vector 

My point above is that any trust vector is introduced not by the dust
limit but by the economics of outputs being worth less than they cost to
spend.

> LN node operators might be willingly to compensate this "dust" trust vector
> by relying on side-trust model

They could also use trustless probabalistic payments, which have been
discussed in the context of LN for handling the problem of payments too
small to be represented onchain since early 2016:
https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_178

(Probabalistic payments were discussed in the general context of Bitcoin
well before LN was proposed, and Elements even includes an opcode for
creating them.)

> smarter engineering such as utreexo on the base-layer side 

Utreexo doesn't solve this problem.  Many nodes (such as miners) will
still want to store the full UTXO set and access it quickly,  Utreexo
proofs will grow in size with UTXO set size (though, at best, only
log(n)), so full node operators will still not want their bandwidth
wasted by people who create UTXOs they have no reason to spend.

> I think the status quo is good enough for now

I agree.

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jeremy via bitcoin-dev]

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.


>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

[ZmnSCPxj via bitcoin-dev]

 fromGood morning Zac,


With some work, what you want can be implemented, to some extent, today, 
without changes to consensus.

The point you want, I believe, is to have two sets of keys:

* A long-term-storage keyset, in "cold" storage.
* A short-term-spending keyset, in "warm" storage, controlling only a small 
amount of funds.

What you can do would be:

* Put all your funds in a single UTXO, with an k-of-n of your cold keys 
(ideally P2TR, or some P2WSH k-of-n).
* Put your cold keys online, and sign a transaction spending the above UTXO, 
and spending most of it to a new address that is a tweaked k-of-n of your cold 
keys, and a smaller output (up to the limit you want) controlled by the k-of-n 
of your warm keys.
  * Keep this transaction offchain, in your warm storage.
* Put your cold keys back offline.
* When you need to spend using your warm keys, bring the above transaction 
onchain, then spend from the budget as needed.


If you need to have some estimated amount of usable funds for every future unit 
of time, just create a chain of transactions with future `nLockTime`.

  nLocktime +1day  nLockTime +2day
  ++   ++   ++
 cold UTXO -->|cold TXO|-->|cold TXO|-->|cold TXO|--> etc.
  ||   ||   ||
  |warm TXO|   |warm TXO|   |warm TXO|
  ++   ++   ++

Pre-sign the above transactions, store the pre-signed transactions in warm 
storage together with your warm keys.
Then put the cold keys back offline.

Then from today to tomorrow, you can spend only the first warm TXO.
>From tomorrow to the day after, you can spend only the first two warm TXOs.
And so on.

If tomorrow your warm keys are stolen, you can bring the cold keys online to 
claim the second cold TXO and limit your fund loss to only just the first two 
warm TXOs.

The above is bulky, but it has the advantage of not using any special opcodes 
or features (improving privacy, especially with P2TR which would in theory 
allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using just 
`nLockTime`, which is much easier to hide since most modern wallets will set 
`nLockTime` to recent block heights.

Regards,
ZmnSCPxj

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

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[raymo via bitcoin-dev]

Hi Chris,

Thanks for your detailed answer. So, as you answered there is an
uncertainty about this case. For me, even this uncertainty would be a
good point to start. Because if the miners realize the potentiality for
increasing revenue under Sabu protocol, very soon they will want to
update their transaction selecting mechanism priorities, even before
occurring the first real attack on the protocol in “production
software”. This upgrade in Bitcoin protocol will eliminate uncertainty
totally.

How hard do you think it will be this upgrade on protocol?
IMO the most important thing will be the consensus on the implementation
of these changes, while the code upgrading won't be a difficult
technical issue.
If it were difficult to agree on a Bitcoin core protocol change, we
might be able to achieve our goals by changing the Stratum protocol.
Unlike miners who would welcome that offer, full-nodes without hash
power would probably not be interested in upgrading the software. Maybe
because they do not want to disrupt the broadcasting of transactions by
relying double-spend transactions.
I'm not sure if the normal full nodes (without hash power) use the same
software that miners use. If not, we have to fight on two fronts to
upgrade the software.

Again, thanks for your fast and flourish reply :-)
Raymo


On 2021-08-09 18:03, Chris Riley wrote:
>> I'm not sure how miners will react to the two double-spend
> transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or will
> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
> transaction selection mechanism.  If miners
>> prefer the highest fee my scenario still is valid. But if miners
> always keep the first transaction received
>> and drop subsequent transactions,
> Hi,
> 
> Miners have the incentive to accept the highest fee transaction
> whenever they see it.  That does not imply that miners _will_ accept
> the highest fee transaction they see for a variety of reasons.  If a
> transaction does not signal RBF (BIP 125) then in general a "first
> seen" rule is applied, if a transaction does signal RBF, then in
> general the highest fee is prefered.  Since this is an untrusted
> network, a miner could use RBF even for transactions that don't signal
> it, since she could claim she saw it first, assuming the miner was
> aware of it which might imply it was submitted directly since the
> network might not relay a higher fee transaction for a non-RBF
> transaction.  Or a miner could see the first transaction and include
> it in a block just after the RBF transaction is broadcast but before
> the block is propagated. etc
> 
> So there is only a question of probabilities:  in general miners
> prefer the highest fee for RBF transactions and in general, miners
> will not replace a non-RBF transaction with a later one.  However,
> nothing is guaranteed given it is an untrusted network and people
> could use non-standard rules for selection of what transactions are
> included in a block.
> 
> :-)
> 
> On Mon, Aug 9, 2021 at 12:57 PM raymo via bitcoin-dev
>  wrote:
> 
>> Hi s7r,
>> I already answered to ZmnSCPxj's comments.
>> 
>> Let’s go to yours.
>> 
>>> If it is a child transaction of the Main Transaction
>> Sorry for my shortcoming in English, because it caused the
>> misunderstanding of proposal.
>> There is not any relation between Main Transaction and Guarantee
>> transaction. when I said “the Guarantee Transaction is created
>> based on
>> Main Transaction” I was intended only the numbers. I mean the
>> output
>> amounts of Guarantee Transaction are calculated relatively based on
>> Main
>> Transaction output amounts, in order to make a Guarantee Transaction
>> with relatively higher transaction fee. So, either of MT or GT can
>> be
>> broadcasted or toke place in next block independently.
>> 
>>> When Bob tries to broadcast the "guarantee transaction" he will
>> get an error:
>>> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
>> Here is the part which I am not sure you are right about it. I do
>> not
>> know in detail and I'm not sure how miners will react to the two
>> double-spend transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or
>> will
>> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
>> transaction
>> selection mechanism.
>> If miners prefer the highest fee my scenario still is valid. But if
>> miners always keep the first transaction received and drop
>> subsequent
>> transactions, I have three different solution to solve that I will
>> explain in later posts.
>> 
>>> 2. The creditor (Bob) has to leave his wallet running 24x7 and
>> ensure he is connected
>>> to the internet, otherwise if he loses connection to the internet
>> or energy supply,
>>> Alice attack will succeed entirely with 100% chances.
>>> So this means

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[raymo via bitcoin-dev]

Hi s7r,
I already answered to ZmnSCPxj's comments.

Let’s go to yours.

> If it is a child transaction of the Main Transaction
Sorry for my shortcoming in English, because it caused the
misunderstanding of proposal.
There is not any relation between Main Transaction and Guarantee
transaction. when I said “the Guarantee Transaction is created based on
Main Transaction” I was intended only the numbers. I mean the output
amounts of Guarantee Transaction are calculated relatively based on Main
Transaction output amounts, in order to make a Guarantee Transaction
with relatively higher transaction fee. So, either of MT or GT can be
broadcasted or toke place in next block independently.  

> When Bob tries to broadcast the "guarantee transaction" he will get an error: 
> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
Here is the part which I am not sure you are right about it. I do not
know in detail and I'm not sure how miners will react to the two
double-spend transactions and which one they will prefer.
Will they use the first seen transaction for block pre-image, or will
use the transaction with higher transaction fee?
We need the help of Bitcoin core developers to clarify this transaction
selection mechanism. 
If miners prefer the highest fee my scenario still is valid. But if
miners always keep the first transaction received and drop subsequent
transactions, I have three different solution to solve that I will
explain in later posts.

> 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he is 
> connected 
> to the internet, otherwise if he loses connection to the internet or energy 
> supply, 
> Alice attack will succeed entirely with 100% chances. 
> So this means Bob needs to always be online like forever and ever.
Somehow you are right. Definitely Bob can delegate this task to a
doc-watcher, pretty much like watch-tower in Lightning, but due to the
small amount of creditor's credits and the fact that this amount is
scattered among many different issuers, I removed this part from the
original design of Sabu architecture.
BTW major creditors, such as stores that receives debt-documents worth
thousands of dollars a day, should (and better say must) always be
online to protect their money. This job also creates a safe margin for
other creditors.
IMHO at the moment the protocol is good enough to start, but we can
always talk about improving the protocol.

> The 3rd one is hypothetical and you don't even have to answer it:
> 3. How does Bob (first creditor) spend the coins received / 
> how does Bob become an issuer himself in relation to Dave (another creditor)? 
> What happens if Alice tries to fraud Bob after Bob spent its Sabu credit to 
> Dave? 
> Dave has to hold all parent "guarantee transactions" and watch the network 
> for 
> any potential fraudulent transactions that cancels his credit?
I already explained it in response of Billy here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html

just look for “how normal transactions happen in their entirety.”

Looking forward to hear from core developers about “how miners will
react to the two double-spend transactions and which one they will
prefer”.

Regards
Raymo


On 2021-08-09 00:03, s7r wrote:
> raymo via bitcoin-dev wrote:
> 
> TL,DR: you were explained by ZmnSCPxj why this protocol will not work.
> The possibility for just one party to sign will not work. I will
> explain again why but in much more simpler description.
> 
> 
>> Check out this simple transaction to learn more about how the system
>> works.
>> Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So,
>> she can spend it by create a transaction and sign it and broadcast it to
>> Bitcoin network.
>> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000
>> Satoshi from Alice in exchange.
>> Alice gets this 5$ and prepare a Main transaction that represents this
>> liability of Alice to Bob.
>>
>> Main Transaction (20,000 Sat input):
>> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob
>> has to pay 3,000 as BTC fee)
>> * Alice (issuer): 6,000 Sat
>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
>> This is a valid transaction and both Bob and/or Alice can send it to
>> Bitcoin network, but none of them are interested in doing so. Because
>> they will lose 5,000 Satoshi of their own money as Bitcoin transaction
>> fee.
>>
>> Alongside this transaction Alice (the issuer) has to create the
>> Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will
>> not consider the deal completed. The Guarantee Transaction is another
>> valid Bitcoin transaction. It is created based on Main Transaction and
>> will cut a part of Bob and Alice money in favor of transaction fee.
>>
>> Guarantee Transaction (20,000 Sat input):
>> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat
>> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat
>> * BTC Fee: 5,000 Sat

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

[Antoine Riard via bitcoin-dev]

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 reasons I'm aware of not allow dust creation is that:
>
> 1) dust is spam
> 2) dust fingerprinting attacks
>
> 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by
> well behaved wallets to not redeem outputs that cost more in fees than they
> are worth.
>
> cheers,
>
> jeremy
>
> --
> @JeremyRubin 
> 
> ___
> Lightning-dev mailing list
> lightning-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

[Karl via bitcoin-dev]

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

Re: [bitcoin-dev] Removing the Dust Limit

[Prayank via bitcoin-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

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