Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Greg Sanders via bitcoin-dev]

Transaction analysis tools do take the signal into account, but I'm unsure
if retail, non-custodial wallets use this information.

Historically the biggest pushback has been from services like Bitrefill
which have had quite a bit of success with 0-conf payments, but perhaps LN
adoption is at a point where it's less of an impact?

On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Russel O'Connor recently opined
> 
> that RBF should be standard treatment of all transactions, rather than as a
> transaction opt-in/out. I agree with that. Any configuration in a
> transaction that has not been committed into a block yet simply can't be
> relied upon. Miners also have a clear incentive to ignore RBF rules and
> mine anything that passes consensus. At best opting out of RBF is a weak
> defense, and at worst it's simply a false sense of security that is likely
> to actively lead to theft events.
>
> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).
>
> One question I have is: how does software generally inform the user about
> 0-conf payment detection? Does software generally tell the user something
> along the lines of "This payment has not been finalized yet. All recipients
> should wait until the transaction has at least 1 confirmation, and most
> recipients should wait for 6 confirmations" ? I think unless we pressure
> software to be very explicit about what counts as finality, users will
> simply continue to do what they've always done. Rolling out this policy
> change over the course of a year or two seems fine, no need to rush. But I
> suppose it would depend on how often 0-conf is used in the bitcoin
> ecosystem at this point, which I don't have any data on.
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment phase
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attacker
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild for
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those DoS
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
>> a preliminary stage where batch participants are locked-in their funds
>> within an account witnessScript shared with the orchestrer.
>>
>> Of course, even assuming full-rbf, propagation of the multi-party funded
>> transactions can still be interfered with by an attacker, simply
>> broadcasting a double-spend with a feerate equivalent to the honest
>> transaction. However, it tightens the attack scenario to a scorched earth
>> approach, where the attacker has to commit equivalent fee-bumping reserve
>> to maintain the pinning and might lose the "competing" fees to miners.
>>
>> # RBF opt-out as a Mempools Partitions Vector
>>
>> A longer-term issue is the risk of mempools malicious partitions, where
>> an attacker exploits network topology or divergence in mempools policies to
>> partition network mempools in different subsets. From then a wide range of
>> attacks can be envisioned such as package pinning [1], artificial
>> congestion to provoke LN channels closure or 

[bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support

[Michael Folkson via bitcoin-dev]

The workshop was previously announced by ariard on the bitcoin-dev
mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html

A reminder was posted to the bitcoin-dev mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html

The conversation log for the workshop is here:
https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4

I’ll summarize what was discussed during the meeting but please refer
to the L2 zoology repo ariard has set up for background context and
additional notes: https://github.com/ariard/L2-zoology

General considerations

I think it is worth first reiterating the obvious that there will
never be perfect security guarantees on network transaction fee rates
or transaction relay. Network fee rates can in theory go up to
anything (upper limit of infinity) and will always to some degree be
inherently unpredictable. In addition transaction acceptance can never
be guaranteed even if you attempt a direct connection to a miner. At
the same time L2 protocols (e.g. Lightning and DLCs) elevate
transaction propagation and inclusion in a time sensitive mined block
to a security assumption from what used to just be a usability
assumption (BlueMatt). Within those confines these workshops are
attempting to strengthen that security assumption knowing that
guaranteeing it is out of reach.

There are considerations that blocked transaction propagation isn’t
necessarily a problem for the victim if it is also blocked for the
attacker. In addition some successful attacks present an opportunity
for the victim to divert their funds to miner fees (e.g. scorched
earth) ensuring the attacker doesn’t financially benefit from the
attack (harding). Personally I would argue neither of these present
much assurance to the victim. Out of conservatism one should assume
that the attacker has greater resources than the victim (e.g. a direct
line to a miner) and knowing a victim’s lost funds went to the miner
instead of the attacker isn’t of much comfort to the victim (other
than potentially presenting a disincentive for the attack in the first
place). This is obviously further complicated if the miner is the
attacker. In addition any incentive for miners to not mine
transactions to wait for a potential pay-all-to-fee are troubling
(t-bast).

New(ish) ideas

RubenSomsen brought up the idea of fee sensitive timelocks, they would
need a soft fork. ariard briefly discussed the idea of a transaction
relay overlay network. harding stated his opinion that we should be
leaning more on miners’ profit incentive rather than attempting to
normalize mempool policy (e.g.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html).
t-bast raised the prospect of mining pools exposing public APIs to
push them transactions directly.

The impact of changes to Bitcoin Core on L2 protocols

Some changes to Core (e.g. some privacy improvements) can conflict
with the goal of minimizing transaction propagation times.
Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2
developers a way to write regression tests against the latest builds
of bitcoind. He added that L2 devs should write automated regression
test suites against bitcoind exposed RPC commands. t-bast would like a
bitcoind “evicttx” RPC to remove a transaction from the mempool on
regtest.

Full RBF

In advance of the workshop ariard posted to the mailing list a
proposal for full RBF in a future version of Bitcoin Core:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html

Progress in this direction has been attempted in the past (e.g.
https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out
that even with full RBF it is trivial to create mempool partitions. As
long as RBF has a fee rate increase minimum an attacker can trivially
split the mempool by broadcasting two conflicting transactions with
the same fee.

ariard plans to contact businesses (e.g. Lightning onboarding services
relying on zero confirmations) to check that this possible eventual
move to full RBF doesn’t present a problem for them. There could well
be engineering work required in advance of the possible change being
made.

Next week’s meeting

Next week’s meeting (Tuesday 22nd June, 19:00 UTC,
#l2-onchain-support, Libera) will be on fee bumping and package relay
that glozow has recently been working to advance in Bitcoin Core.

-- 
Michael Folkson
Email: michaelfolk...@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Cloud Strife via bitcoin-dev]

Barrier to entry in PoW is matter for hardware and energy is permissionless
and exist all over the universe, permissionless cost which exists for
everyone no matter who because it's unforgeable.

Barrier to entry in PoS is being given permission by the previous owner of
a token for you to have it via transfer or sale, both choices they never
have to make since there are no continuous costs with producing blocks
forcing it. A permission is an infinitely high barrier to entry if the
previous owner, like the premining party, refuses to give up the token they
control.

You're skipping the part where you depend on a permission of a central
party in control of the authority token before you can produce blocks on
your rasberry Pi.

Proof of stake is not in any possible way relevant to permissionless
protocols, and thus not possibly relevant to decentralized protocols where
control must be distributed to independent (i.e. permissionless) parties.

There's nothing of relevance to discuss and this has been figured out long
long ago.

https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy

https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca




On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> @Lloyd wrote:
>
> Of course in reality no one wants to keep their coin holding keys online
>> so in Alogorand you can authorize a set of "participation keys"[1] that
>> will be used to create blocks on your coin holding key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a nice
>> website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>>
>
> I believe we are talking about a comparison to PoW, correct? If you want
> to mine PoW, you need to buy expensive hardware and configure it to work,
> and wait a long time to get any return by solo mining. Or you can join a
> mining pool, which might use your hashing power for nefarious purposes. Or
> you might skip the hardware all together and fall for some "cloud mining"
> scheme with a pretty website and a high rate of advertised return. So as
> you can see, Proof-of-SquareSpace exists in PoW as well!
>
> The PoS equivalent of buying mining hardware is setting up your own
> validator and not outsourcing that to anyone else. So both PoW and PoS have
> the professional/expert way of participating, and the fraud-prone, amateur
> way of participating. The only difference is, with PoS the
> professional/expert way is accessible to anyone with a raspberry Pi and a
> web connection, which is a much lower barrier to entry than PoW.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Lloyd Fournier via bitcoin-dev]

@James wrote:

On Tue, 15 Jun 2021 at 21:13, James MacWhyte  wrote:

>
> @Lloyd wrote:
>
> Of course in reality no one wants to keep their coin holding keys online
>> so in Alogorand you can authorize a set of "participation keys"[1] that
>> will be used to create blocks on your coin holding key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a nice
>> website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>>
>
> I believe we are talking about a comparison to PoW, correct? If you want
> to mine PoW, you need to buy expensive hardware and configure it to work,
> and wait a long time to get any return by solo mining. Or you can join a
> mining pool, which might use your hashing power for nefarious purposes.
>

A mining pool using your hashrate for nefarious purposes can easily be
observed since they send you the contents of the block you are mining
before your hardware starts working on it. This difference is crucial.
Mining pools exist just to reduce income variance.


> Or you might skip the hardware all together and fall for some "cloud
> mining" scheme with a pretty website and a high rate of advertised return.
> So as you can see, Proof-of-SquareSpace exists in PoW as well!
>

I'd agree that "cloud mining" pretty much is Proof-of-SquareSpace for PoW.
Fortunately these services make up a tiny fraction of hashrate.


> The PoS equivalent of buying mining hardware is setting up your own
> validator and not outsourcing that to anyone else. So both PoW and PoS have
> the professional/expert way of participating, and the fraud-prone, amateur
> way of participating. The only difference is, with PoS the
> professional/expert way is accessible to anyone with a raspberry Pi and a
> web connection, which is a much lower barrier to entry than PoW.
>

And yet despite this, the fraud-prone amteur way of participating accounts
for the majority of stake in PoS systems while the professional/expert way
of participating accounts for the overwhelming majority of hashpower in
Bitcoin. It looks like you have elegantly proved my point!

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

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

[Billy Tetrud via bitcoin-dev]

Russel O'Connor recently opined

that RBF should be standard treatment of all transactions, rather than as a
transaction opt-in/out. I agree with that. Any configuration in a
transaction that has not been committed into a block yet simply can't be
relied upon. Miners also have a clear incentive to ignore RBF rules and
mine anything that passes consensus. At best opting out of RBF is a weak
defense, and at worst it's simply a false sense of security that is likely
to actively lead to theft events.

Do we as a community want to support 0-conf payments in any way at this
point? It seems rather silly to make software design decisions to
accommodate 0-conf payments when there are better mechanisms for fast
payments (ie lightning).

One question I have is: how does software generally inform the user about
0-conf payment detection? Does software generally tell the user something
along the lines of "This payment has not been finalized yet. All recipients
should wait until the transaction has at least 1 confirmation, and most
recipients should wait for 6 confirmations" ? I think unless we pressure
software to be very explicit about what counts as finality, users will
simply continue to do what they've always done. Rolling out this policy
change over the course of a year or two seems fine, no need to rush. But I
suppose it would depend on how often 0-conf is used in the bitcoin
ecosystem at this point, which I don't have any data on.

On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
> the Bitcoin Core's default replacement policy in version 24.0. As a
> reminder, the next release is 22.0, aimed for August 1st, assuming
> agreement is reached, this policy change would enter into deployment phase
> a year from now.
>
> Even if this replacement policy has been deemed as highly controversial a
> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem are
> motivating this proposal.
>
> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>
> As explained in "On Mempool Funny Games against Multi-Party Funded
> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
> funded transactions by propagating an RBF opt-out double-spend of its
> contributed input before the honest transaction is broadcasted by the
> protocol orchester. DoSes are qualified in the sense of either an attacker
> wasting timevalue of victim's inputs or forcing exhaustion of the
> fee-bumping  reserve.
>
> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs
> and dual-funded LN channels. As those protocols are still in the early
> phase of deployment, it doesn't seem to have been executed in the wild for
> now.  That said, considering that dual-funded are more efficient from a
> liquidity standpoint, we can expect them to be widely relied on, once
> Lightning enters in a more mature phase. At that point, it should become
> economically rational for liquidity service providers to launch those DoS
> attacks against their competitors to hijack user traffic.
>
> Beyond that, presence of those DoSes will complicate the design and
> deployment of multi-party Bitcoin protocols such as payment
> pools/multi-party channels. Note, Lightning Pool isn't affected as there is
> a preliminary stage where batch participants are locked-in their funds
> within an account witnessScript shared with the orchestrer.
>
> Of course, even assuming full-rbf, propagation of the multi-party funded
> transactions can still be interfered with by an attacker, simply
> broadcasting a double-spend with a feerate equivalent to the honest
> transaction. However, it tightens the attack scenario to a scorched earth
> approach, where the attacker has to commit equivalent fee-bumping reserve
> to maintain the pinning and might lose the "competing" fees to miners.
>
> # RBF opt-out as a Mempools Partitions Vector
>
> A longer-term issue is the risk of mempools malicious partitions, where an
> attacker exploits network topology or divergence in mempools policies to
> partition network mempools in different subsets. From then a wide range of
> attacks can be envisioned such as package pinning [1], artificial
> congestion to provoke LN channels closure or manipulation of
> fee-estimator's feerate (the Core's one wouldn't be affected as it relies
> on block confirmation, though other fee estimators designs deployed across
> the ecosystem are likely going to be affected).
>
> Traditionally, mempools partitions have been gauged as a spontaneous
> outcome of a distributed systems like Bitcoin p2p network and I'm not aware
> it has been studied in-depth for adversarial purposes. Though, deployment
> of second-layer
> protocols, heavily relying on sanity of a local mempool for fee-estimation
> and robust 

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

[raymo via bitcoin-dev]

Hi,
I have a proposal for improve Bitcoin TPS and privacy, here is the post.
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
https://bitcointalk.org/index.php?topic=5344020.0
Can you please read it and share your idea about it.

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