David A. Harding [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-05-21 to 2023-06-03
💬 Posted a total of 168 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP-draft, PROPOSAL, Lightning-dev, Pre-BIP, Opt-in full-RBF, PATCH
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd

Profile Code

nprofile1qqsdx462yssg7n3apqsmkjnf5rp6appqg02yf7juf2xynsmfjx9xlvspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsmar4eu

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd

Show more details

Last Notes

2023-09-19 12:29:43

- reply

📅 Original date posted:2023-09-17
🗒️ Summary of this message: The author raises concerns about the possibility of participant A and M, who are part of a group of thieves, double-spending the transaction and manipulating the system. They suggest that the mechanism may collapse into reputational trust in M.
📝 Original message:
On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Now, suppose that participant A wants B to be assured that
>A will not double-spend the transaction.
>Then A solicits a single-spend signature from the actuary,
>getting a signature M:
>
> current state +--------+----------------+
> ---------+-------------+ | | (M||CSV) && A2 |
> |(M||CSV) && A| ----> | M,A +----------------+
> +-------------+ | | (M||CSV) && B2 |
> |(M||CSV) && B| +--------+----------------+
> +-------------+
> |(M||CSV) && C|
> ---------+-------------+
>
>The above is now a confirmed transaction.
Good morning, ZmnSCPxj.
What happens if A and M are both members of a group of thieves that control a moderate amount of hash rate? Can A provide the "confirmed transaction" containing M's sign-only-once signature to B and then, sometime[1] before the CSV expiry, generate a block that contains A's and M's signature over a different transaction that does not pay B? Either the same transaction or a different transaction in the block also spends M's fidelity bond to a new address exclusively controlled by M, preventing it from being spent by another party unless they reorg the block chain.
If the CSV is a significant amount of time in the future, as we would probably want it to be for efficiency, then the thieving group A and M are part of would not need to control a large amount of hash rate to have a high probability of being successful (and, if they were unsuccessful at the attempted theft, they might not even lose anything and their theft attempt would be invisible to anyone outside of their group).
If A is able to double spend back to herself funds that were previously intended to B, and if cut through transactions were created where B allocated those same funds to C, I think that the double spend invalidates the cut-through even if APO is used, so I think the entire mechanism collapses into reputational trust in M similar to the historic GreenAddress.it co-signing mechanim.
Thanks,
-Dave
[1] Including in the past, via a Finney attack or an extended Finney attack supported by selfish mining.

2023-09-07 13:17:26

- reply

📅 Original date posted:2023-08-24
🗒️ Summary of this message: The author responds to a proposal for Lightning multipeer payment channels, expressing concerns about safety and efficiency compared to existing designs.
📝 Original message:
On 2023-08-20 16:25, Atomic Mr Nuclear wrote:
> Dear community,
>
> In the attachment you will find a new proposal for Lightning multipeer
> payment channels
Hi,
Thanks for working on multiparty channel design. Quoting from the
paper:
> in case some of the peers become unresponsive, the channel starts
> operating with partial state updates
> [...]
> outputs in the [sub-]graph can be double-spend by their owners with
> cooperation from the majority
> [...]
> this state is only temporary, since the channel security can be reset
> to the fully trustless level by excluding uncooperative peers from the
> channel.
I think it's worth mentioning two points:
1. That any construction dependent on an honest majority is not safe
when that majority can consist of untrusted peers. If Alice is in a
multiparty channel consisting of random peers, she cannot safely
accept payments in your construction without signatures from all
other participants in the channel ("full state updates").
2. The exclusion of uncooperative peers requires getting confirmed three
onchain transactions, one of which has one output for every original
participant and one which has one input for every cooperative
participant; that sounds like a lot of onchain data to me. Until
those transactions have confirmed to a sufficient depth, Alice cannot
safely accept payments in a channel with uncooperative peers (where
she does not trust a majority of all peers). That sounds too
expensive and too slow for an alternative to Lightning.
Given those two points, I don't think anyone desiring trustless payments
can use "partial state updates". Without partial updates, your
proposal requires participants go onchain in an expensive way any time
even one participant becomes uncooperative, which feels to me to be
inferior to the existing designs for channel factories and multiparty
channels that you cite.
I would love to learn if I'm missing something and I appreciate the
obvious effort you put into your paper. If you continue to innovate in
the field, I would highly encourage you to review the work posted to the
Lightning-Dev mailing list over the past year or so by John Law as I
feel you might find his own solutions for some of the same problems
inspiring (some links to his work are collected and summarized here[1]).
Thanks,
-Dave
[1]
https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories

2023-08-13 16:32:58

- reply

📅 Original date posted:2023-08-13
🗒️ Summary of this message: The sender is concerned about the security of sharing the secret key in the payment URI and suggests using a different method. Another person raises the issue of potential security risks when posting payment URIs in public.
📝 Original message:
On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi Dan,
>A couple more more thoughts:
>
>> Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key.
>
>You're sending the symmetric secret key out of band; but isn't this obscuring the question of securely sharing the secret key? Did you consider DH-ing this as other protocols do? At the very least I would claim that it's likely that implementers might be sloppy here; at the most I would claim this is just insecure full stop.
Hi Dan,
After reading Adam's comments above and re-reading your draft BIP where it says the secret key is also used as the session identifier and that outputs can be modified, I'm wondering about the security of posting payment URIs anywhere someone can see them.
For example, if Alice posts her BIP21 URI for Bob to pay where Eve can see it, such as in a shared chatroom or via email or any cleartext protocol that gets relayed, can Eve establish her own session to the relay and frontrun Alice on receiving Bob's PSBT, modify the returned PSBT to include her (Eve's) output, and submit it for Bob to sign and broadcast?
The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, posting them where evesdroppers can see them poses a privacy risk but not a risk of loss of funds, so many users don't treat them as especially hazardous material. I don't think it would be practical to change that expectation, and I think a protocol where evesdropping didn't create a risk of funds loss would be much better than one where that risk was created.
(Apologies to Adam is this is exactly what he was saying with more subtly.)
-Dave

2023-08-07 01:37:36

- reply

📅 Original date posted:2023-08-06
🗒️ Summary of this message: Salvatore Ingala has created a proposal for the core opcodes of MATT, making them functionally complete and improving implementation.
📝 Original message:
On July 30, 2023 11:37:49 AM HST, Salvatore Ingala via bitcoin-dev
>I have put together a first complete proposal for the core opcodes of
>MATT [1][2].
>The changes make the opcode functionally complete, and the
>implementation is revised and improved.
> [...]
>[1] - https://merkle.fun/
>[2] -
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
Hi Salvatore,
Where exactly is the proposal? Merkle.fun links to a "WIP" comment that seems to specify OP_CHECKCONTRACTVERIFY but your text above says "core opcodes" (plural) so I feel like I'm missing something. Also, it being "WIP" makes me wonder if that actually is the "complete proposal" I should be looking for.
When I read "complete proposal", I was expecting a draft BIP.
-Dave

2023-07-14 15:02:28

- reply

📅 Original date posted:2023-07-12
🗒️ Summary of this message: LNBits discovered an exploit allowing attackers to create balances by abusing a quirk in how invoices are handled. A suggestion was made to support self-payment of invoices.
📝 Original message:
On 2023-06-19 05:26, callebtc via Lightning-dev wrote:
> Our team at LNbits discovered a rather interesting
> exploit which which would enable an attacker to create balances out of
> thin air by abusing a quirk in how invoices are handled internally.
Hi Calle,
If I understand correctly from some quick research, LNBits allows its
users to request payments from both external users and other internal
users of the same instance via the same interface, BOLT11 invoices.
Users may also generate payments to both external users and other
internal users via the same interface where they agree to the details in
a BOLT11 invoice.
To make this possible, LNBits essentially short circuits payment
attempts it believes are being made from one internal user to another
internal user. Instead of passing those through an underlying LN
implementation, LNBits attempts to handle them on its own.
The problem here is that the the short-circuit version didn't implement
all the checks specified in BOLT4, e.g. "[...] the _final node_ [...]
if the amount paid is less than the amount expected: MUST fail the HTLC"
My question is whether you think it would be worthwhile to ask
developers of the underlying LN node implementations you use to support
self-payment of their own invoices (if they don't already). I see this
having several advantages:
1. LNBits and similar systems no longer need any short circuit logic.
When user Alice requests a payment, LNBits simply calls the
underlying LN implementation's standard `requestpayment` API. When
user Bob wants to review and pay the invoice, LNBits simply call the
underlying implementation's `pay` API. Whatever the result of the
payment (success or failure), the underlying API returns that result
to LNBits so it can make the appropriate account updates.
2. As the LN protocol grows and changes, fewer changes will be needed to
LNBits and similar systems as they can continue to simply call the
appropriate APIs. For example, support for BOLT12 offers could
become trivial to add.
3. Even for people not using LNBits, being able to pay yourself is a
nice tool for experimentation with an API, especially if it doesn't
cost any fees.
The downside is that it might be a bit more complex for LN
implementations. However, if there are lots of services using LNBits
and similar systems, and I can see how that might come to be the case, I
think there's a strong argument to avoid repetition of security
essential payment processing logic in both an underlying implementation
and account management software.
Thanks for your security disclosure!,
-Dave

2023-06-20 13:15:34

- reply

📅 Original date posted:2023-06-19
🗒️ Summary of this message: Thomas Voegtlin explains the semantics of bundled payments, which involves a BOLT-11 invoice containing two preimages and two amounts.
📝 Original message:
On 2023-06-12 22:10, Thomas Voegtlin wrote:
> The semantics of bundled payments is as follows:
> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> prepayment and main payment.
> - 2. the receiver should wait until all the HTLCs of both payments
> have arrived, before they fulfill the HTLCs of the pre-payment. If the
> main payment does not arrive, they should fail the pre-payment with a
> MPP timeout.
> - 3. once the HTLCs of both payments have arrived, the receiver
> fulfills the HTLCs of the prepayment, and they broadcast their
> on-chain transaction. Note that the main payment can still fail if the
> sender never reveal the preimage of the main payment.
Hi Thomas,
Do you actually require a BOLT11 invoice to contain a payment hash for
the prepayment, or would it be acceptable for the prepayment to use a
keysend payment with the onion message payload for the receiver
indicating what payment hash to associate with the prepayment (e.g.,
Alice wants to receive 1 BTC to hash 0123...cdef with a prepayment of
10k sats, so the 10k sats is sent via keysend with metadata indicating
the receiver shouldn't claim it until they receive the 1 BTC HTLC to
0123...cdef).
If so, I think then you'd only need BOLT11 invoices to be extended with
an extra_fee_via_keysend field. That would be significantly smaller and
it also allows encoding the extra_fee_via_keysend field in an existing
BOLT11 field like (d) description or the relatively new (m) metadata
field, which may allow immediate implementation until an updated version
of BOLT11 (or an alternative using offers) becomes widely deployed.
Thanks,
-Dave

2023-06-19 20:19:56

- reply

📅 Original date posted:2023-06-13
🗒️ Summary of this message: A proposal for a bitcoin-native solution to leverage bitcoin's security properties for vaults was discussed, with considerations for scalability and privacy. The need for an alternative way to relay transactions to miners besides the p2p network was also mentioned.
📝 Original message:
On 2023-06-11 09:25, Joost Jager wrote:
> Isn't it the case that that op-dropped partial signature for the
> ephemeral key isn't committed to and thus can be modified by anyone
> before it is mined
That's correct; I hadn't thought of that, sorry.
> I am really looking for a bitcoin-native solution to leverage
> bitcoin's robustness and security properties.
I understand. I would briefly point out that there are other advantages
to not storing a signature for an ephemeral key in the annex. For
example, if you want to generate multiple different potential spending
transactions, you need to store one signature for each potential
transaction. The more data you store in the annex, the less scalable
the vault protocol becomes; by comparison, it's possible to cheaply
store a very large amount of data offchain with high robustness.
Also, depending on construction of the vault, a possible advantage of a
presigned vault (without using the annex) over a solution like OP_VAULT
is that all actions might be able to use keypath spends. That would be
highly efficient, increasing the usability of vaults. It would also be
more private, which may be important to certain classes of vault users.
Even if OP_VAULT was added to Bitcoin, it would be interesting to have
an alternative vault protocol that offered different tradeoffs.
> That years-long timeline that you sketch for witness replacement (or
> any other policy change I presume?) to become effective is perhaps
> indicative of the need to have an alternative way to relay
> transactions to miners besides the p2p network?
The speed depends on the policy change. In this case, I think there's a
reasonable argument to be made that a mitigation for the problems of
annex relay should be widely deployed before we enable annex relay.
Bitcoin Core's policy is designed to both prevent the abuse of relay
node resources and also serve the transaction selection needs of miners.
Any alternative relay system will need to solve the same general
problems: how to prevent abuse of the relayers and help miners choose
the best transactions. Ideas for alternative relay like those
previously proposed on this list[1] avoid certain problems but also
(AFAICT) create new problems.
To be specific towards this proposal, if an alternative relay network
naively implemented annex relay, any miners who used that network could
receive a coinjoin-style transaction with a large annex that
significantly reduced the transaction's feerate. By comparison, any
miners who continued to only receive transactions from the P2P network
of Bitcoin Core (or similar) nodes would have received the transaction
without an annex at its original (higher) feerate, allowing them to to
receive greater revenue if they mined it. If, instead, the alternative
relay network implemented the witness replacement proposal you've linked
to, those miners could still receive up to 4.99% less revenue than
Bitcoin Core-based miners and the operators of the alternative relay
network might have had to pay extra costs for the replacement relays.
You can tweak the proposal to tweak those ratios, but I'm not sure
there's a case where an alternative relay network comes up as a clear
winner over the existing network for general purpose transactions.
Instead, like many things, it's a matter of tradeoffs.
> I agree though that it would be ideal if there is a good solution that
> doesn't require any protocol changes or upgrade path.
Apologies for the salt, but there is a good solution: don't use the
block chain to store backup data.
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html

2023-06-19 20:19:54

- reply

📅 Original date posted:2023-06-10
🗒️ Summary of this message: A proposal has been made to improve the safety of time-locked vaults by using a scriptpath solution that avoids the circular reference problem. Additionally, a decentralized protocol could be used to store data without putting it on the blockchain.
📝 Original message:
On 2023-06-09 21:43, Joost Jager via bitcoin-dev wrote:
> The most critical application in this category, for me, involves
> time-locked vaults.
> [...]
> Backing up the ephemeral signatures of the pre-signed transactions on
> the blockchain itself is an excellent way to ensure that the vault can
> always be 'opened'. However, without the annex, this is not as safe as
> it could be. Due to the described circular reference problem, the
> vault creation and signature backup can't be executed in one atomic
> operation.
Hi Joost,
For the purpose of experimenting with vaults, I don't think you need the
most efficient construction---instead, anything that works without too
much overhead is probably ok. In that case, I don't think you need the
annex at all:
1. Alice can receive new payments to tr(<key>, raw(OP_DROP <key>
OP_CHECKSIG))
2. Later, Alice creates tr(MuSig2(<key-from-HD-wallet>,
<ephemeral-key>))
3. When paying the script in #2, Alice chooses the scriptpath spend from
#1 and pushes a serialized partial signature for the ephemeral key
from #2 onto the stack, where it's immediately dropped by the
interpreter (but is permanently stored on the block chain). She also
attaches a regular signature for the OP_CHECKSIG opcode.
Alternatively, if Alice decides she doesn't want to pay into a vault,
she uses the keypath spend from #1 with no loss in efficiency.
The scriptpath solution requires some extra preparation on Alice's part
and costs about a dozen vbytes extra over using the annex, which feels
acceptable to me to avoid the problems identified with using the annex.
Even better, I think you can achieve nearly the same safety without
putting any data on the chain. All you need is a widely used
decentralized protocol that allows anyone who can prove ownership of a
UTXO to store some data. You can think of LN gossip as being a version
of this: anyone who proves ownership of a P2WSH 2-of-2 script is allowed
to store data in a certain format on every LN routing node. Rusty
Russell's v2 gossip proposal makes this a bit more generic, but I think
you could make it even more generic by creating a simple server that
stores and forwards a single BIP322 signed message up to size x for any
entry in the current UTXO set, with periodic replacement of the signed
message allowed. The signed data could be LN routing information or it
could be arbitrary data like a signature from an ephemeral key (or it
could even be a JPEG or other data irrelevant to processing payments).
Any full node (including pruned and utreexo nodes) can trustlessly
provide UTXO lookup for such a server and a decentralized network of
such servers could be useful by a large number of protocols, encouraging
hundreds or thousands of servers to be operated---providing similar data
availability guarantees to committing data on the block chain, but
without the permanent footprint (i.e., once a UTXO is spent, the
associated data can be deleted). Many vault designs already effectively
require watchtowers, so it'd be easy to make this simple server part of
the watchtower.
> Regarding the potential payload extension attack, I believe that the
> changes proposed in the [3] to allow tx replacement by smaller witness
> would provide a viable solution?
> [...]
> [3] https://github.com/bitcoin/bitcoin/pull/24007
The two solutions identified above (OP_DROP and decentralized storage
for UTXO owners) can be implemented immediately. By comparison, rolling
out relay of the annex and witness replacement may take months of review
and years for >90% deployment among nodes, would allow an attacker to
lower the feerate of coinjoin-style transactions by up to 4.99%, would
allow an attacker to waste 8 million bytes of bandwidth per relay node
for the same cost they'd have to pay to today to waste 400 thousand
bytes, and might limit the flexibility and efficiency of future
consensus changes that want to use the annex.
-Dave

2023-06-19 20:19:50

- reply

📅 Original date posted:2023-06-02
🗒️ Summary of this message: The taproot annex can be utilized by developers without delay, providing immediate benefits, including the ability to put arbitrary data into a witness.
📝 Original message:
On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing
> developers to utilize the taproot annex without delay, we can take
> advantage of its features today,
Hi Joost,
Out of curiosity, what features and benefits are available today? I
know Greg Sanders wants to use annex data with LN-Symmetry[1], but
that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you
mention that it could allow putting arbitrary data into a witness
without having to commit to that data beforehand, but that would only
increase the efficiency of witness stuffing like ordinal inscriptions by
only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
required to create an output in order to spend it.
Is there some other way to use the annex today that would be beneficial
to users of Bitcoin?
-Dave
[1]
https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119

2023-06-15 02:54:55

- reply

📅 Original date posted:2023-06-07
🗒️ Summary of this message: A proposed scenario for double-spending in Bitcoin transactions is questioned due to the lack of clarity on the identity of the parties involved.
📝 Original message:
On 2023-06-07 03:30, Burak Keceli wrote:
> If the service provider double-spends a transaction that enforces a
> one-time signature where Bob is the vendor, Bob can forge the service
> provider’s signature from the 2-of-2 and can immediately claim his
> previously-spent vTXO(s).
Hi Burak,
I'm confused. Bob owns some bitcoins that are timelocked against
immediate withdrawal, but where he can spend immediately with the
cooperation of service provider Sally. Bob transfers some bitcoins to
Sally contingent on her spending an equal amount of bitcoins (minus a
fee) to Carol. You already have a mechanism to enforce this contingency
(tx outpoints), so if Carol doesn't receive the bitcoins from Sally,
then Sally also doesn't receive the bitcoins from Bob. In other words,
you already have atomicity for a single transfer.
Are you describing the effect over multiple transfers? For example, Bob
previously transferred bitcoins to Sally and she paid users X, Y, and Z
in transactions that are now confirmed onchain, although she hasn't yet
swept Bob's funds. Now when Sally double spends the payment to Carol,
Bob can not only reclaim the funds he gave Sally to pay to Carol (which
was guaranteed by the atomicity), he can also reclaim the unswept funds
he gave Sally to pay X, Y, and Z.
If so, I don't think that works. In a private protocol, Carol can't be
sure that Bob and Sally are separate individuals. If they're the same
entity, then any forfeit that Sally needs to pay Bob is just an internal
transfer, not a penalty.
I'd appreciate any clarification you can offer. Thanks!,
-Dave

2023-06-09 15:12:53

- reply

📅 Original date posted:2023-03-24
🗒️ Summary of this message: The proposed tunable penalties for offchain channel resizes and liquidity multiplexing in hierarchical channels are discussed, with the latter being a significant advance.
📝 Original message:
Hi John,
Thank you for another innovative application of your tunable penalties.
I see two key benefits being described by your paper[1]:
- **Offchain channel resizes:** in state 0, Alice and Bob share control
over an offchain UTXO valued at x satoshis; in state 1, the value of
the offchain UTXO is y satoshis.
- **Liquidity multiplexing:** Alice, Bob, Carol, and Dan each rightfully
own some portion of a UTXO. Alice and Bob expect to always be
available; Carol and Dan may sometimes be unavailable. The proposal
allows Carol and Dan to spend/receive in combination with Alice and
Bob, but also ensures Alice and Bob can spend back and forth the
entirety their portions of the UTXO even if Carol, Dan, or both of
them are unavailable.
For the Offchain Channel Resizes, I don't see how your proposal
functionally differs from a classic channel factory. In section 3, you
show the set {A, B, C, D} with the subset {A,B} where A reduces its
balance in {A,B} by transfering it to {C,D} via an HTLC to another of
its
nodes (A').
Your description uses hierarchical channels (which may have >2
participants per channel). In a classic pair-producing channel factory,
each channel only has two participants, e.g. the factory {A, B, C, D}
produces the channels,
{A,B}
{A,C}
{A,D}
{B,C}
{B,D}
{C,D}
However, the same thing is possible, A as part of {A,B} can pay through
{B,C} out of the factory to A'. After the HTLCs are settled, the
offchain channel setup transactions inside the factory can be
regenerated with the cooperation of all {A, B, C, D}.
Am I missing something, or is this first key benefit something that was
already possible (in theory) with pair-producing channel factories?
For the Liquidity Multiplexing, this does feel like a significant
advance. In a pair-producing channel factory, any funds A has in {A, C}
or {A, D} can't be spent when C or D are unavailable. In your proposal,
{A, B} form one half of {{A,B},C} and {{A,B},D}, allowing {A,B} to
redistribute their portion of the funds when C and D are unavailable.
That's not an advantage of multiparty channels that I've seen described
before, and not something I've been able to think how to functionally
reproduce with pair-producing channel factories.
Given that it took me a while to understand the Liquidity Multiplexing,
I wanted to double check to see if I had missed something about the
Offchain Channel Resizes?
Thanks again,
-Dave
[1] https://github.com/JohnLaw2/ln-hierarchical-channels

2023-06-09 15:12:25

- reply

📅 Original date posted:2023-01-03
🗒️ Summary of this message: A proposal for a contract protocol between two parties, Alice and Bob, with two branches: on-chain/channel and timelock, for instant LN payments.
📝 Original message:
On 2023-01-03 03:57, ZmnSCPxj via Lightning-dev wrote:
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
> [...]
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
Good morning Jesse and ZmnSCPxj,
Is the following an accurate summary of the proposal's benefits and
costs? At some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob. At any
time, with Bob's cooperation, she can send an onchain transaction. Or,
after the contract protocol deposit transaction gets x confirmations,
Alice can instantly fund a fully initialized LN channel with Bob's
cooperation, from which she can immediately send LN payments.
If the above is accurate, how does that compare to splice outs? For
example: at some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob by opening
an LN channel. At any time, with Bob's cooperation, she can send an
onchain transaction using a splice out. Or, after the contract protocol
(LN) deposit transaction gets x confirmations, Alice now has a funded
fully initialized LN channel with Bob's participation as counterparty,
from which she can immediately send LN payments.
If the value for x blocks is the same in both cases, those two scenarios
look very similar to me.
The only advantages I see of your proposal are:
1. It allows Alice's LN wallet to remain offline indefinitely---but only
if Alice doesn't have any other funds in open channels.
2. It's easier to implement than splice-outs (I would guess)---but it
also only provides the benefits of sending onchain payments at the time
before the first LN transaction is made, whereas actual splice out can
be used any time in a channel's lifetime to immediately send onchain
payments.
Am I missing something?
-Dave

2023-06-09 15:07:47

- reply

📅 Original date posted:2023-01-03
📝 Original message:
On 2023-01-03 03:57, ZmnSCPxj via Lightning-dev wrote:
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
> [...]
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
Good morning Jesse and ZmnSCPxj,
Is the following an accurate summary of the proposal's benefits and
costs? At some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob. At any
time, with Bob's cooperation, she can send an onchain transaction. Or,
after the contract protocol deposit transaction gets x confirmations,
Alice can instantly fund a fully initialized LN channel with Bob's
cooperation, from which she can immediately send LN payments.
If the above is accurate, how does that compare to splice outs? For
example: at some point x blocks before Alice expects she might want to
spend her funds on LN (but also wants the option to quickly spend her
funds onchain), she enters into a contract protocol with Bob by opening
an LN channel. At any time, with Bob's cooperation, she can send an
onchain transaction using a splice out. Or, after the contract protocol
(LN) deposit transaction gets x confirmations, Alice now has a funded
fully initialized LN channel with Bob's participation as counterparty,
from which she can immediately send LN payments.
If the value for x blocks is the same in both cases, those two scenarios
look very similar to me.
The only advantages I see of your proposal are:
1. It allows Alice's LN wallet to remain offline indefinitely---but only
if Alice doesn't have any other funds in open channels.
2. It's easier to implement than splice-outs (I would guess)---but it
also only provides the benefits of sending onchain payments at the time
before the first LN transaction is made, whereas actual splice out can
be used any time in a channel's lifetime to immediately send onchain
payments.
Am I missing something?
-Dave

2023-06-09 15:07:27

- reply

📅 Original date posted:2022-11-27
📝 Original message:
On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
> If I am an LSP, and I know my competitor LSP distributes their
> credentials, then I can simply apply to be a spoke on my competitor
> and then make several payments to my node, which I then jam up.
> This reduces the reputation of my competitor LSP.
I don't think this how Riard's credentials work. The credential tokens
are blinded, so forwarding nodes can't use them to determine the origin
of the payment---thus they can't assign blame.
As I understand them, credential tokens prevent DoS by each token only
allowing the one-time creation of a single HTLC, so any failed payment
reduces the sender's supply of tokens. That means, if Mallory becomes a
client of Bob's and Bob lets Mallory use some of his tokens, Mallory can
destroy those tokens. Although that's bad for Bob, he can easily limit
the damage by not giving Mallory more tokens after too many failures.
If Bob obtained his tokens at a low cost (e.g. by sending many payments
that were successful and receiving back >100% of the tokens he used to
make those payments) and if Alice has to pay a similar or greater cost
to become a client of Bob's (e.g. onchain channel open costs), then the
attack should not be economically rational.
> This is even worse if my competitor LSP attaches their credentials on
> trampolines, I do not even need to apply to be a spoke on my
> competitor that way.
I think the analysis for trampolines is the same: as long as Bob only
attaches credential tokens to trampoline payments where he knows the
origin has paid a cost (or will need to pay a cost) to abuse his
service, he can prevent any attack from becoming economically rational.
> Thus all reputation still rests with ultimate senders, who have to
> convince LSPs to sell their reputation to them, because they might
> secretly be competitor LSPs who have incentive to drain their
> reputation.
>
> If the price of sold reputation is too high, then it is no different
> from upfront fees.
>
> If the price of sold reputation is too low, then I can drain the
> reputation of competitor LSPs.
I think the statement at the top about reputation resting with ultimate
senders is true but two conditionals below it are not quite right. If
an LSP helps many clients make successful payments, those clients may
(at no additional cost to them beyond the forwarding fees they already
paid) receive more credential tokens than they'll ever need. By
allowing the LSP to instead use those tokens for other clients
("harvesting" them), it's possible for those later clients to avoid
paying for credential tokens---this is equivalent to free upfront fees.
As long as the LSP can prevent a client from using too many tokens, and
requires the client pay other inescapable costs, then it shouldn't be
possible for a competitor to substantially drain the token capital of a
LSP without losing a substantial amount of its own money.
-Dave

2023-06-09 15:07:26

- reply

📅 Original date posted:2022-11-26
📝 Original message:
On 2022-11-21 14:26, Antoine Riard wrote:
>> Clara Shikhelman wrote:
>> 4. How would these tokens work with blinded paths and other
>> privacy-preserving suggestions?
>
> Primarily, the tokens could use the new onion messages and blinded
> paths for the dissemination and renewal rounds. Current design assumes
> they're attached to the HTLC during forward along the payment path,
> though I think one design alternative could be completely detached,
> and the HTLC onion just contains a ref to the tokens.
I'm not sure I understand this answer, so I'll explain in my own words
and kindly ask that you tell me if I'm wrong or missing something
important.
If Alice wants to pay Zed using a blinded path where Zed chooses
terminal channels W->X->Y->Zed, then Zed will need to provide to Alice
the encrypted credential tokens for X, and Y. In theory, if Alice
controls node Y, she can prevent the HTLC from settling and so waste the
value of Zed's provided tokens for node X. However, Alice shouldn't
know where Zed's node is in the LN topography and can't be assured that
he'll forward through her secondary node, so the attack is uncertain to
work. The attack may also have a cost---Alice may need to buy
credential tokens for node W and the hops leading to it from her primary
node---with that cost mitigating the chance of the attack and the
likelihood that it would be profitable.
Thank you both for the interesting proposal and the insightful
questions!,
-Dave

2023-06-09 15:06:58

- reply

📅 Original date posted:2022-10-07
📝 Original message:
On 2022-10-03 06:55, jlspc via Lightning-dev wrote:
> The WF Protocol
> ===============
Hi John,
I had difficulty understanding your proposal description here and in
your paper[1]. I wonder if others are having the same the same
difficulty, so I've tried to reduce it down to just the essential idea
so you can tell me if I'm understanding correctly and others can
evaluate it more quickly. Here I go:
In a traditional HTLC, the agreement is essentially:
- Setup: Alice has x BTC, an unpublished value y, and the hash digest z
which is hash(y)
- HTLC success: Alice offers Bob the x BTC, which he can claim at any
time if he publishes y satisfying the equation hash(y) == z
- HTLC failure: Alice can spend the x BTC back to her wallet after some
time t has elapsed
If I understand your modified protocol correctly, the essential modified
agreement is:
- [Setup the same]
- [HTLC success the same]
- HTLC failure: Alice can spend the x BTC back to her wallet by first
getting a trigger[2] transaction confirmed onchain, waiting b blocks,
then getting the actual spend-back-to-wallet transaction confirmed
Because the trigger transaction needs to be confirmed for b blocks
before Alice can can spend the money back to her wallet, Bob doesn't
need to take any action to lock-in an HTLC Success unless he sees the
trigger transaction appear onchain or he expects to be offline for more
than b blocks. This allows Alice to stay offline for as long as Bob can
tolerate (which goes towards your point of Alice prepaying Bob for that
tolerance).
[1]
https://raw.githubusercontent.com/JohnLaw2/ln-watchtower-free/main/watchtowerfree10.pdf
[2] "Trigger" transaction is the name given to that type of transaction
in section 4.2 of the Eltoo paper: https://blockstream.com/eltoo.pdf
> One-Shot Receives
> =================
I understand the essence of this idea to be simply encumbering dedicated
user Bob's commitment transaction with a timelock so that he can't
publish it until near the time when any HTLCs in it would expire.
Alice's version of commitment would be unencumbered, so she could
publish it any time.
> when a user receives a payment and
> their channel partner is unresponsive, the user must submit their
> Commitment and HTLC-success transactions to the blockchain. However, if
> their partner's conflicting Commitment transaction wins the race and is
> included in the blockchain, the user then has to submit a different
> transaction that reveals the HTLC's secret and spends the HTLC output
> in
> their partner's Commitment transaction. The requirement to wait and
> check
> the blockchain for the winning Commitment transaction (which might not
> be
> determined until multiple blocks have been added to the blockchain) is
> awkward for a casual user.
Although your proposal may address this in the normal case, I think it
doesn't address the pathological case where honest casual user Alice
broadcasts the latest commitment transaction but her channel partner,
malicious dedicated user Mallory, broadcasts an older revoked commitment
transaction. Because Mallory's revoked commitment transaction is older,
its timelock has expired, so it can win the race against Alice's latest
commitment transaction.
To become aware of this situation and to broadcast a penalty transaction
within the necessary time limit, Alice still needs to monitor the block
chain. If Alice still needs to monitor the block chain in any case,
this proposed change doesn't eliminate the underlying problem of onerous
monitoring as far as I can tell.
Thanks as always for the innovative thinking!,
-Dave

2023-06-09 15:06:49

- reply

📅 Original date posted:2022-09-23
📝 Original message:
On 2022-09-22 16:08, ZmnSCPxj wrote:
> Basically, you can model a rate card as four separate channels between
> the same two nodes, with different costs each.
> If the path at the lowest cost fails, you just try at another route
> that may have more hops but lower effective cost, or else try the same
> channel at a higher cost.
That's a very easy to understand explanation of how to use the system,
thanks!
> If your concern is valid, one wonders why it would not already exist
> now in the current network where try-and-try-again is the standard
> overall algorithm for payments.
My concern is about pathfinding algorithms which depend on unscalable
data collection (e.g. frequent whole network probing). If such an
algorithm performs much better than those algorithms which depend on
scalable data collection (e.g. receiving gossip), then the network may
grow to depend on the centralized entities performing the data
collection to the detriment of its robustness and its participants'
independence.
Try-and-try-another-path is somewhat problematic in this regard since,
even with no additional action like probing, entities which send many
payments will likely perform significantly better than entities which
send few payments owing to the high-frequency spenders gaining more
knowledge about which channels and amounts recently worked or did not.
It seems to me that a more idealized system would only rarely have
forwarding failures so that high frequency spenders wouldn't receive
much more information than low frequency spenders. To that regard, fee
ratecards feels like a small step in the wrong direction because
modeling one channel as four separate channels further normalizes
failure and so further moves the system towards centralized dependency.
That said, as you mentioned in a previous post[1], I agree ratecards is
better than frequently issuing new channel updates with modified fees.
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html

2023-06-09 15:06:48

- reply

📅 Original date posted:2022-09-22
📝 Original message:
On 2022-09-13 11:15, lisa neigut wrote:
> Hi all,
Hi Lisa,
Thank you for describing this idea in detail on the mailing list.
> A ratecard is a set of four values, positive or negative, that price
> different bands of available liquidity for a channel.
Am I understanding correctly that this implies spenders wanting to send
an LN payment will either need to estimate the current division of funds
for every hop along their projected path or will need to pay the highest
ratecard for each hop? How are spenders supposed to make those
estimates about the division of funds in distant channels?
If there's no easy and network-friendly way for spenders to gather that
information, I would worry that will lead to the creation of services
which do collect the info and which become central to LN's operation.
> For example, if a payment moves 50k through a 100k channel which is
> currently at a total available capacity of 75k sats (which means it'll
> move the
> capacity from 75k to 25k), that payment will be expected to pay a rate
> equal to
> the 0-25% band, as it'll push the available capacity into the 0-25%
> range.
Shouldn't this be pro rata? If it's not expected to be proportional at
the protocol level, then spender Alice can still get almost proportional
rates by sequentially sending Bob's forwarding node fifty 1k payments
and have 24 of them pay the 51-75 rate, 25 pay the 26-50 rate, and only
1 pay the 0-25 rate. Since base fees are disallowed, this costs Alice
nothing extra but reduces network capacity by consuming HTLC slots for
her, Bob, and every other forwarding channel.
However, for Alice to pay proportional fees either way, she'd need a
fairly precise estimate of the current division of funds in one of Bob's
channels, which brings me back to my earlier question about how Alice is
supposed to obtain that information in a way that's easy and friendly to
the network (and therefore resistant to centralization).
Thanks,
-Dave

2023-06-09 15:05:36

- reply

📅 Original date posted:2022-03-23
📝 Original message:
On 22.03.2022 15:10, Olaoluwa Osuntokun wrote:
> ### Should the proof+verification strongly bind to the LN context?
> Today, nodes use the two bitcoin keys and construct a p2wsh
> multi-sig script and then verify that the script matches what has been
> confirmed on chain. With taproot, the output is actually just a single
> key. So if we want to maintain the same level of binding (which makes
> it
> harder to advertise fake channels using just a change output have or
> something), then we'd specify that nodes reconstruct the aggregated
> bitcoin public
> key
I think there's a significant difference between P2WSH and P2TR that's
not being considered here. With P2WSH, if I want to fake the creation
of a channel by making my change outputs OP_CMS(2-of-2) with myself, I
pay for that deception by incurring extra fee costs at spend time due to
the need to provide more witness data over plain single-sig. With
P2TR/MuSig2,
I can make my change outputs MuSig2(2-of-2) with myself without
incurring
any additional onchain spend costs.
In short, I don't believe that you can maintain the same level of
binding-to-LN-usage currently provided by P2WSH when P2TR keypath
spends are allowed.
Thanks,
-Dave

2023-06-09 15:04:26

- reply

📅 Original date posted:2021-11-20
📝 Original message:
On Mon, Nov 15, 2021 at 04:25:26PM +0100, Joost Jager wrote:
> Reliability is a property of a route that can
> be expressed as a probability. The probability that a route will be
> successful.
I don't think users care about the abstract concept of reliability
that's being returned by the pathfinding code here. What users care
about is "how long will it take for my payment to make the point-of-sale
terminal turn green so I can walk away with my warm beverage?"
This is basically analogous to the fee optimization question that
onchain wallets have been asking users for years: how many blocks do you
want to wait for [the first] confirmation? The way that's presented to
users in software like Bitcoin Core is,
2 blocks (~20 minutes), x fee
6 blocks (~60 minutes), y fee
36 blocks (~6 hours), z fee
etc...
The onchain estimates in Bitcoin Core are based[1] on a 95% threshold.
If LN software speculatively chooses a series of attempts with a similar
95%, accounting for things like the probability of a stuck payment (made
worse by longer CLTV timeouts on some paths), it could present users
with the same sort of options:
~1 second, x fee
~3 seconds, y fee
~10 seconds, z fee
This allows the software to use its reliability scoring efficiently in
choosing what series of payment attempts to make and presents to the
user the information they need to make a choice appropriate for their
situation. As a bonus, it makes it easier for wallet software to move
towards a world where there is no user-visible difference between
onchain and offchain payments, e.g.:
~1 second, w fee
~15 seconds, x fee
~10 minutes, y fee
~60 minutes, z fee
-Dave
[1] https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211120/dbb8d3d7/attachment.sig>

2023-06-09 15:03:15

- reply

📅 Original date posted:2021-08-10
📝 Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210809/24595273/attachment.sig>

2023-06-09 15:03:14

- reply

📅 Original date posted:2021-08-08
📝 Original message:
On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions with outputs below a certain
amount. If nodes or miners running with non-default policy choose to
relay or mine those transactions, they are not penalized (not directly,
at least; there's BIP152 to consider).
Question for Jeremy: would you also allow zero-value outputs? Or would
you just move the dust limit down to a fixed 1-sat?
I think the dust limit is worth keeping:
> 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?
> 2) dust outputs can be used in various authentication/delegation smart
> contracts
All of which can also use amounts that are economically rational to
spend on their own. If you're gonna use the chain for something besides
value transfer, and you're already wiling to pay X in fees per onchain
use, why is it not reasonable for us to ask you to put up something on
the order of X as a bond that you'll actually clean up your mess when
you're no longer interested in your thing?
> 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
Nope, nothing is forced. Any LN node can simply refuse to accept/route
HTLCs below the dust limit.
> which has implications
> (AFAIU) for the regulatory classification of channels in various
> jurisdictions
Sucks for the people living there. They should change their laws. If
they can't do that, they should change their LN node policies not to
route uneconomic HTLCs. We shouldn't make Bitcoin worse to make
complying with regulations easier.
I also doubt your proposed solution fixes the problem. Any LN node that
accepts an uneconomic HTLC cannot recover that value, so the money is
lost either way. Any sane regulation would treat losing value to
transaction fees the same as losing value to uneconomical conditions.
Finally, if LN nodes start polluting the UTXO set with no economic way
to clean up their mess, I think that's going to cause tension between
full node operators and LN node operators.
> agnostic treatment of fund transfers would simplify this
> (like getting a 0.01 cent dividend check in the mail)
I'm not sure I understand this point. It sounds to me like you're
comparing receiving an uneconomic output to receiving a check that isn't
worth the time to cash. But the costs of checks are borne only by the
people who send, receive, and process them. The costs of uneconomic
outputs polluting the UTXO set are borne by every full node forever (or
for every archival full node forever if non-archival nodes end up using
something like utreexo).
> 4) thinly divisible colored coin protocols might make use of sats as value
> markers for transactions.
I'm not exactly sure what you're talking about, but if Alice wants to
communicate the number n onchain, she can do:
if n < dust:
nSequence = 0x0000 + n # should probably check endianess
else:
nValue = n
There's at least 15 bits of nSequence currently without consensus or
policy meaning, and the dust limits are currently in the hundreds of
sat, so there's plenty of space.
Alice could probably also communicate the same thing by grinding her
output script's hash or pubkey; again, with dust limits just being
hundreds of sats, that's not too much grinding.
> 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.
I haven't looked since they upgraded to bulletproofs, but ISTR the
original CT implementation leaked the most significant digits or
something (that kept down the byte size of the proofs), so maybe it was
already possible to know what was certainly not dust and what might be
dust.
In short, it's my opinion that the dust limit is not creating any real
problems, so it should be kept for its contribution to keeping full
nodes faster, cheaper, and more efficient.
-Dave
P.S. As I prepared to send this, Matt's email arrived about "If it
weren't for the implications in changing standardness here, I think we
should consider increasing the dust limit instead." I'm in agreement
with both parts of that statement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210808/3feb232d/attachment-0001.sig>

2023-06-09 15:02:55

- reply

📅 Original date posted:2021-07-09
📝 Original message:
On Fri, Jul 02, 2021 at 02:20:51PM -0400, Antoine Riard wrote:
> More personally, I feel it would be better if such a new specification
> process doesn't completely share the same communication infrastructure as
> the BOLTs, like [avoiding] having them in the same repository.
In addition to Antoine's perception-based concern, I think an additional
problem with keeping both BOLTs and BLIPs in the same repository is that
there's no easy way for contributors to subscribe to only a subset of
issues and PRs. E.g., if Alice is only interested in BOLTs and she
clicks the GitHub Watch Repository button, she'll receive notifications
for issues and PRs about BLIPs that she's not interested in; vice-versa
for Bob who's only interested in BLIPs.
If you still think it's desirable to keep BOLTs and BLIPs in the same
source tree, you could maybe consider the monotree approach that
originated with the Linux kernel project (AFAIK) and which the Bitcoin
Core project began experimenting with about a year ago[1] (to moderate
success AFAICT).
-Dave
[1] https://bitcoinops.org/en/newsletters/2020/06/24/#bitcoin-core-19071
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210709/ed66f453/attachment.sig>

2023-06-09 15:01:44

- reply

📅 Original date posted:2020-12-14
📝 Original message:
On Mon, Dec 14, 2020 at 04:31:23PM +1100, Lloyd Fournier wrote:
> To be clear: The goal is to offer a cooperative settlement transaction up
> front to the (possibly) recovering party -- *not a commitment transaction*.
Ah, what BOLT0 calls a "mutual close". That makes a lot more sense and
makes the protocol even cooler than I thought. Thanks for clarifying!
> The idea I'm working with in revocable signature based channels [1] is
> to make the node lose its static secret key if it posts a revoked
> commitment tx. This means they could lose ALL funds from ALL their
> channels with ALL their peers if they ever broadcast a single revoked
> commitment transaction. This would be a very bad thing to happen while
> you're trying to recover funds.
Yikes! A very bad thing indeed. I'll have to re-read about witness
asymmetric channels; I don't think I realized that was a consequence of
using them.
> What is the story with option_static_remotekey? I am interested to know how
> the negotiation of that option has a security issue but I don't see how it
> could.
Whoops, I got myself confused. I meant option_data_loss_protect, which
LND calls "static channel backups". I just git greped the bolts for
"static" and copied the first plausible seeming result. :facepalm:
On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote:
> I don't think it's so clear that any party refusing to go go first can
> be assumed to have lost data.
Oh, I agree, it's definitely not clear. I just said they could "be
*suspected* of having lost data".
On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote:
> If the rule is that the party receiving the connection is the one that
> must send the oblivious signatures then a party that has both lost
> data and is receiving a connection can just ignore the connection
> request.
>
> There is plausible denyability because knowingly not answering a
> request can't be distinguished from just having connection issues or
> distinguished from a machine is just turned off.
In many cases, the network does behave differently in different
cases:
$ nmap -p 80 dtrt.org ## online and port available
80/tcp open http
$ nmap -p 80 newmail.dtrt.org ## online but no service listening
80/tcp closed http
$ nmap -p 22 10.0.0.1 ## online but connection refused
22/tcp filtered ssh
$ nmap -p 80 10.0.0.200 ## not online
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Moreover, there's the case where Bob tries to open a connection with
Mallory, but Mallory immediately turns around and tries to open a
connection with Bob. In that case, Bob's unavailability might look
suspicious (although it could just be NAT or something else innocuous).
However, beyond IP network activity, there's potentially a lot of
evidence a dishonest counterparty can gather about a
recently-reconnected node to evaluate the probability that it suffered a
data loss. Perhaps most persuasive would be seeing what happened to
that node's other channels. Were they all closed? Did the node fail to
promptly broadcast a transaction with preimages trying to claim any
pending HTLCs (which can be especially strong evidence if the dishonest
counterparty was along the routing path for any of those HTLCs and so
knows that the preimage was disclosed).
The reason option_data_loss_protects works in theory is that the only
way attacker Mallory can test her hypothesis that victim Bob lost data
is by Mallory broadcasting an old state that Bob, if he didn't actually
lose data, can use to penalize Mallory in a way that may profit Bob. In
an ideal world, for every victim node that actually lost data there'd be
several honeypot nodes that faked losing data in order to profit from
dishonest counterparties. Unfortunately, I doubt that's the case, for
two reasons:
1. You can only operate a data loss honeypot by causing a channel to
be closed onchain, which is going to waste someone's fees.
2. A dishonest node may only try broadcasting an old state when their
channel balance is low, near the minimum allowed by the channel
reserve. The guidelines for channel reserve amounts were chosen
(I believe) under the assumption that Mallory can be highly
confident that Bob has the latest state, so the reserve is just
the bare amount needed to prevent some annoying griefing. The
reserve is probably not large enough to compensate for the work and
fee-paying costs of operating data loss honeypots.
That said, most nodes seem to be honest and hopefully the nodes playing
with high-value channels are using some sort of live replication, so I
don't think there have been any issues so far.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/9ee971e1/attachment.sig>

2023-06-09 15:01:43

- reply

📅 Original date posted:2020-12-13
📝 Original message:
On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
> If c = 1 (i.e. the node is fine and it wants to continue the channel) then
> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes
> it sends the commitment blinding y back to prove that it doesn't have the
> signature (i.e. prove c = 1). If verification fails then the node is
> malicious and it fails the channel.
This is really cool! However, I don't understand why it's needed. Your
goal seems to be for the sender to provide the commitment transaction
and signatures before he learns whether the receiver actually needs
them. That's just as easily accomplished by sending the data upfront in
plain text. For example, it seems to me that both of the following
protocols provide identical utility:
1. On every reconnection, request the plain text unsigned commitment
transaction, send a pedersen commitment, and receive the encrypted
signature(s). If c=1, verify the encrypted signature(s) and (on
success) send the blinding factor or (on failure) fail the channel
and ban the peer. If c=0, decrypt the signature(s), apply them to
the commitment transaction, and broadcast.
2. On every reconnection, request the plain text unsigned commitment
transaction with all of its signatures, also in plain text. If our
database is intact, verify the commitment transaction and its
signatures are valid and (on success) continue or (on failure) fail
and ban. If we lost data, broadcast the commitment transaction.
Unless I'm forgetting something, there's no reason a node shouldn't send
its latest commitment transaction to its counterparty in plain text
(over the regular BOLT8 P2P encrypted and authenticated link).
I think the challenge in either protocol above is deciding which peer
goes first, because whoever sends the commitment transaction reveals
what they think the current state is. Any node that refuses to go first
can then be suspected of having lost data. BOLT2
option_static_remotekey has this same problem, which is reasonably
mitigated IMO by LN's penalty mechanism forcing any would-be thief to
risk their own funds; this doesn't work for basic eltoo, though.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201213/778f3af7/attachment.sig>

2023-06-09 15:01:35

- reply

📅 Original date posted:2020-11-28
📝 Original message:
On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote:
>
> Hello list,
Gleb and Antoine,
This is an interesting idea! Thank you for working on it.
I had difficulty with one part of the proposal:
> #### Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
>
> [...] we believe that allowing any UTXO would give an attacker more
> opportunities to use their cold funds for this attack, or even have a
> secondary market where holders sell their proofs (they have nothing to
> loose).
Can't a malicious user get around this restriction by opening channels
with themself? (Also, aren't current channel open outputs just P2WSH
2-of-2 multisigs, and in the future won't they be generic P2TR outputs?
How would a stake certificate prove that the UTXO was generated for LN
rather than just belonging to a user with a 2-of-2 multisig wallet or
any key-path-spendable taproot wallet?)
According to some random website, the current total channel balance of
the public LN is about 1,000 BTC. Although I'm sure this will grow with
time, it seems to me that an attacker who can rent access to stake
certificates for a one-week attack at, say, a 5% annual interest rate
would only need to pay 1 BTC to acquire stake certificates equal to all
honest users at present. That cost doesn't seem high enough to me to
effectively prevent attacks. Am I missing something?
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201128/9e9c7884/attachment.sig>

2023-06-09 15:00:28

- reply

📅 Original date posted:2020-06-22
📝 Original message:
On Sun, Jun 21, 2020 at 06:09:28PM -0700, Olaoluwa Osuntokun wrote:
> IMO this is mostly mitigated by anchor commitments. The impact of this
> attack is predicated on the "victim" paying 5x on-chain fees (for their
> confirmation target) to sweep all their HTLCs.
I think the attack is more clearly stated in absolute terms. An
attacker can force a victim to pay for 483 P2WSH outputs (each 43
vbytes), or a total of about 20,000 vbytes (plus regular overhead).
20769 = 43 * 483
During the post-halving feerate spike just a few weeks ago, paying 100
base units ("satoshis") per vbyte was plausible to ensure the commitment
transaction confirmed quickly. At $9,500 USD/BTC, that's almost $200
USD.
197.3055 = 20769 * 100 / 1e8 * 9500
With a 5x multiplier, that's horrible, but even with no multiplier, it's
not good. Moreover, a patient attacker can wait for a fee spike and
then attack multiple channels at once so that they compete against each
other for block space, potentially raising feerates even higher.
> In addition to being able to pay much lower fees ("just enough" to get into
> the chain), anchor commitments allow second-level HTLC _aggregation_, This
> means that for HTLCs with the same expiry height, a peer is able to _batch_
> them all into a single transaction, further saving on fees.
(I was initially confused by this, so for anyone else confused by this,
the batching being described here is sort of the inverse of normal
payment batching. Normally when you batch together multiple payments,
you use one input to pay more outputs than you would with separate
transactions. Here, you still need to use the same number of inputs you
would to resolve HTLCs in separate ransactions (because each HTLC is a
separate UTXO), but you pay a single output. This works and is indeed a
nice optimization.)
> Alternatively, they could use something like Lightning Loop to gain the
> _outbound_ bandwidth (Loop In)
I don't think the attacker needs outbound bandwidth. As implied in
René's post ("achieved with circular onions"), if the attacker is
Mallory and the victim is Bob, there just needs to be a circuit like:
Mallory → Alice → Bob → Mallory
Mallory can always settle with Alice offchain after Bob's timeout,
preventing Mallory from losing any money in the attack or from having to
pay for liquidity. IIUC, Mallory's only cost would be paying for LN
routing fees and the time value of locking up her money until the
settlement.
> No, the attacker is the one that needs to sweep these HTLCs, since they
> offered them. This adds to their costs.
As described above, the attacker doesn't need to offer the HTLCs, they
can simply route a payment through any of the victim's other channels.
If the attacker does that, then the victim needs to pay onchain fees to
recover any remaining value in those HTLCs, potentially making this
attack two or three times more costly for the victim.
> > 1. The current solution is to just not use up the max value of htlc's.
> > Eclaire and c-lightning by default only use up to 30 htlcs.
>
> IMO, this isn't a solution. Lowering the max number of HTLCs in-flight just
> makes it easier (lowers the capital costs) to jam a channel.
It looks to me like an easy and effective solution to turn a ~$200
downside into a ~$20 downside (at 100 base units/vbyte). It's certainly
has other downsides too, but I'm personally more concerned about losing
money than I am about having my channel jammed (and if jamming at 483
HTLCs is an issue, then hopefully the mitigation for that (e.g. upfront
fees) will make jamming at HTLCs a non-issue as well).
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/77824e91/attachment.sig>

2023-06-09 14:59:51

- reply

📅 Original date posted:2020-04-22
📝 Original message:
On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?
>
> That's an interesting idea, but an attacker can create a local conflict in
> your mempool
You don't need a mempool to send a transaction. You can just open
connections to random Bitcoin nodes directly and try sending your
transaction. That's what a lite client is going to do anyway. If the
pinned transaction is in the mempools of a significant number of Bitcoin
nodes, then it should take just a few random connections to find one of
those nodes, learn about the conflict, and download the pinned
transaction.
If that's not acceptable, you could find some other way to poll a
significant number of people with mempools, e.g. BIP35 mempool messages
or reusing the payment hash in a bunch of 1 msat probes to LN nodes who
opt-in to scanning their bitcoind's mempools for a corresponding
preimage.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/2f72c33e/attachment.sig>

2023-06-09 14:59:39

- reply

📅 Original date posted:2020-04-22
📝 Original message:
On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
> A lightning counterparty (C, who received the HTLC from B, who
> received it from A) today could, if B broadcasts the commitment
> transaction, spend an HTLC using the preimage with a low-fee,
> RBF-disabled transaction. After a few blocks, A could claim the HTLC
> from B via the timeout mechanism, and then after a few days, C could
> get the HTLC-claiming transaction mined via some out-of-band agreement
> with a small miner. This leaves B short the HTLC value.
IIUC, the main problem is honest Bob will broadcast a transaction
without realizing it conflicts with a pinned transaction that's already
in most node's mempools. If Bob knew about the pinned transaction and
could get a copy of it, he'd be fine.
In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts? For example, when Bob connects to a bunch of Bitcoin nodes
and sends his conflicting transaction, the nodes would reply with
something like "rejected: code 123: conflicts with txid 0123...cdef".
Bob could then reply with a a getdata('tx', '0123...cdef') to get the
pinned transaction, parse out its preimage, and resolve the HTLC.
This approach isn't perfect (if it even makes sense at all---I could be
misunderstanding the problem) because one of the problems that caused
BIP61 to be disabled in Bitcoin Core was its unreliability, but I think
if Bob had at least one honest peer that had the pinned transaction in
its mempool and which implemented reject-with-conflicting-txid, Bob
might be ok.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/aa4c89f0/attachment.sig>

2023-06-09 14:59:38

- reply

📅 Original date posted:2020-04-22
📝 Original message:
On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
> > While this is somewhat unintuitive, there are any number of good anti-DoS
> > reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this limitation
> [...]
> In the end, the simplest heuristic (accept the higher fee rate
> package) side steps all these issues and is also the most economically
> rationale from a miner's perspective.
I think it's important to remember than mempool behavior affects not
just miners but also relay nodes. Miner costs, such as bandwidth usage,
can be directly offset by their earned block rewards, so miners can be
much more tolerant of wasted bandwidth than relay nodes who receive no
direct financial compensation for the processing and relay of
unconfirmed transactions.[1]
> Why would one prefer a higher absolute fee package (which could be
> very large) over another package with a higher total _fee rate_?
To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
require each replacement pay a feerate of 10 nBTC/vbyte over an existing
transaction or package, and the defaults also allow transactions or
packages up to 100,000 vbytes in size (~400,000 bytes). So, without
enforcement of BIP125 rule 3, an attacker starting at the minimum
default relay fee also of 10 nBTC/vbyte could do the following:
- Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total
fee)
- Replace that transaction with 400,000 new bytes at a feerate of 20
nBTC/vbyte (2 mBTC total fee)
- Perform 998 additional replacements, each increasing the feerate by 10
nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes
(including the original transaction and first replacement) to
ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte
(1 BTC total fee)
- Perform one final replacement of the latest 400,000 byte transaction
with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays
a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
Assuming 50,000 active relay nodes and today's BTC price of ~$7,000
USD/BTC, the above scenario would allow an attacker to waste a
collective 20 terabytes of network bandwidth for a total fee cost of
$10.50. And, of course, the attacker could run multiple attacks of this
sort in parallel, quickly swamping the network.
To use the above concrete example to repeat the point made at the
beginning of this email: miners might be willing to accept the waste of
400 MB of bandwidth in order to gain a $10.50 fee, but I think very few
relay nodes could function for long under an onslaught of such behavior.
-Dave
[1] The reward to relay nodes of maintaining the public relay network is
that it helps protect against miner centralization. If there was no
public relay network, users would need to submit transactions
directly to miners or via a privately-controlled relay network.
Users desiring timely confirmation (and operators of private relay
networks) would have a large incentive to get transactions to the
largest miners but only a small incentive to get the transaction to
the smaller miners, increasing the economies of scale in mining and
furthering centralization.
Although users of Bitcoin benefit by reducing mining centralization
pressure, I don't think we can expect most users to be willing to
bear large costs in defense of benefits which are largely intangible
(until they're gone), so we must try to keep the cost of operating a
relay node within a reasonable margin of the cost of operating a
minimal-bandwidth blocks-only node.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/cbf63335/attachment.sig>

2023-06-09 14:57:57

- reply

📅 Original date posted:2020-01-10
📝 Original message:
On Tue, Jan 07, 2020 at 12:26:05AM +0000, ZmnSCPxj wrote:
> For `nSequence` relative-locktime transactions that protect the
> security of the channel mechanism, these are used in unilateral
> closes. The issue is that a unilateral close might occur far, far in
> the future. Thus, any non-0 `nLockTime` you signed up for at the time
> the commitment transaction was signed, will likely be obsolete.
As long as there's no conflict created by using both relative and
absolute locktimes in the same transaction, I don't think there's any
problem. Multiple versions of a commitment transaction may be signed,
each with different nLockTimes but all other parts of the transaction
the same (including any relative timelocks). This obviously requires a
tiny bit of extra CPU plus modest amounts of extra bandwidth and
storage, but it seems within reason for people who want better privacy.
> Instead, what Bitcoin Core would have to do would be something like:
>
> * Toss a coin:
> * If it is heads, use a non-relative-locktime `nSequence` and an `nLockTime` of the next block (i.e. current behavior).
> * If it is tails, use a relative-locktime `nSequence` equal to the confirmations of the output being spent, and an `nLockTime` of 0.
>
> Then we would hide the Lightning relative-locktime transactions with an `nLockTime` of 0.
Commitment transactions for current two-party LN have at least two
outputs; the chance of both outputs being spent with an nLockTime of 0
is 25% (assuming every non-LN onchain transaction uses the above
scheme). That's a fairly significant bias that can be combined with
other indicators to identify LN transactions for analytics or censorship.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200110/1ae4f757/attachment.sig>

2023-06-09 14:57:55

- reply

📅 Original date posted:2020-01-05
📝 Original message:
On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
> Hi ZmnSCPxj and Aj,
>
> Thanks for starting this discussion ZmnSCPxj. Although transactions with
> relative lock times are easily distinguishable today, couldn't this
> situation be improved? Even just a few wallets changing their behaviour to
> set relative time locks on normal payments would weaken the heuristic.
As mentioned in ZmnSCPxj's post, some wallets (most notably Bitcoin
Core) provide partial anti-fee-sniping protection by setting their
nLockTime to the next-block height[1]. In line with your idea to do the
same with nSequence, I think it would be possible to suggest to the
Bitcoin Core project that they also set nSequence to the block age of
the UTXO being spent (if possible[2]). I think this could slightly
enhance existing anti-fee-sniping by limiting a sniper's ability to
rearrange ancestor transactions. For example, imagine we have two
transactions both created by Bitcoin Core on the best block chain:
tx0 tx1
| |
[ ]---------[ ]-------[ ]-----[ ]----
Block 600,000 ..01 ..02 ..03
Let's assume tx0 and tx1 were both confirmed quickly, so their nLockTime
equals their block height. That means a fee sniper's reorg can't move
either transaction further back in the chain, burying them under
addition PoW. Let's also assume that tx1 is a child of tx0 and sets its
nSequence to 2 blocks. Now tx0 also can't be moved further forward in
the chain without also moving tx1 further forward, meaning any reduction
in the amount of PoW covering one transaction would also reduce the
amount of PoW covering any of its descendant transactions (if they
opt-in to this scheme).
Bitcoin Core obviously has the information necessary to add an
appropriate nSequence to its transactions because it has a copy of the
UTXO set, but *every* wallet should be keeping track of its transaction's
confirmation scores, so every wallet should know the nSequence delta to
use to allow its transactions to be confirmed in the next block but no
earlier block.
My question here would be whether this change would be useful in providing
privacy for the scheme ZmnSCPxj described. IIUC, the pre-signed
transactions Zmn described wouldn't need to use both relative locktime
(nSequence) and absolute locktime (nLockTime) at the same time, so it
would be possible to set nLockTime to an appropriate value when using
nSequence for security. This might not blend in perfectly with
anti-fee-sniping (especially to relay nodes) but perhaps Bitcoin Core's
fuzzing[1] could be increased to help compensate.
-Dave
[1] I think Bitcoin Core implements low-probability fuzzing of the
nLockTime to help cover for wallets that send transactions while still
syncing to the tip. E.g. an instance fully synced to the current chain
tip might set 1-in-100 of its transactions nLockTime to some past block
height so that spy nodes can't tell whether that transaction was
transmitted by a fuzzing node or one of the nodes that just happened to
be IBD syncing from them at that moment.
[2] nSequence can only encode up to a max of 65,535 for the block
distance; see BIP68. Also, obviously, if the parent transaction is
unconfirmed at the time one of its outputs is spent, the child can't
have a relative lock-height unless you want to delay its confirmation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200105/42a10c0d/attachment.sig>

2023-06-09 14:57:39

- reply

📅 Original date posted:2019-12-14
📝 Original message:
On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote:
> Time-Dilation Attacks on Offchain Protocols
> ===================================
What is the advantage of these sophisticated attacks over the eclipse
attacker simply not relaying the honest user's commitment or penality
transactions to miners?
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191214/6842ef3a/attachment.sig>

2023-06-09 14:57:02

- reply

📅 Original date posted:2019-11-14
📝 Original message:
On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote:
> Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is
> `dustRelayFee` really never going to change? It even is a (hidden) cmd line
> parameter that can be set easily.
>
> If the fee market would rise and stay high for an extended period of time,
> why wouldn't people use this flag to raise the dust relay fee?
If feerates are reliably high, then there's less need for the dust limit
and I wouldn't expect it to be increased.
The dust limit exists to prevent people from filling the UTXO set with
non-economical UTXOs when feerates are low. For example, at the current
minimum relay fee of 1 sat/vbyte and price of $8,500 USD/BTC, the cost
to create a zero-value[1] P2WPKH output is about 30 vbytes = 30 sat =
$0.0025 (1/4 cent). The current UTXO set has about 64 million entries,
so the cost to double its size would be $160,000---a tidy sum, but
probably less than some people spend spreading anti-Bitcoin propaganda
on a regular basis.
The dust limit helps prevent that by making the minimum cost per created
P2WPKH UTXO 30 sat + 294 sat = $0.0275, or about $1,760,000 per UTXO set
doubling.
If feerates increase, the cost of a UTXO-filling attack rises
proportionally. Somewhere around sustained minimum feerates of 11
sat/vbyte, feerates alone become more expensive than the current level
of protection provided by the dust limit at 1 sat/vbyte.
Additionally, it's worth noting that the dust limit is not
incentive-aligned with short-term miner interests. If there's actual
legitimate demand to create transactions paying reasonable feerates and
containing uneconomical-to-spend outputs, then miners are going to start
accepting those transactions no matter what policies are implemented on
the P2P transaction relay network.
In short, I don't expect dust limits to rise unless the BTC/fiat price
drops so far that UTXO-filling attacks become much more affordable than
they are with today's limits. Dust limits may instead decrease (or be
removed), but I don't think that's a problem for anchor outputs.
That said, I think it'd be a nice thing for LN implementations to strive
to create anchor outputs that are economical to spend and that may
require using a negotiable output amount to compensate for rises in
feerates making small-value outputs less economical, especially if
you're using different anchor outputs for each channel party.
-Dave
[1] I believe consensus rules allow creating zero-value outputs. If
not, making this a 1 sat output doesn't significantly change any
calculations.
P.S. Perhaps see also Gregory Maxwell's take:
> I suspect that if feerates hadn't tanked after the introduction of
> segwit, implementations probably would have removed the dust limit
> policy rules in any case: they're a kludge that compensates for fees
> being too low to dissuade various antisocial behaviors like spamming
> for advertising purposes or de-anonymizing users and don't serve much
> purpose if feerates are consistently high enough to discourage these
> attacks.
Source: https://bitcoin.stackexchange.com/a/85696/21052

2023-06-09 14:57:00

- reply

📅 Original date posted:2019-11-04
📝 Original message:
On Thu, Oct 31, 2019 at 10:47:56AM +1030, Rusty Russell wrote:
> If we need two anchor outputs, and want the other to turn into an
> anyone-can-spend after it's mined, it's possible by gratuitously
> mentioning the other key in the script, I think:
Why not reuse each party's funding_pubkey, i.e. the key that the party
is signing for in the commitment transaction and which is already being
revealed in the commitment transaction's input witness script?
-Dave

2023-06-09 14:56:49

- reply

📅 Original date posted:2019-10-27
📝 Original message:
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize these limits are there for a reason though, but I'm wondering if
> we could relax them.
Johan,
I'm not sure any of the other replies to this thread addressed your
request for a reason behind the limits related to your proposal, so I
thought I'd point out that---subsequent to your posting here---a
document[1] was added to the Bitcoin Core developer wiki that I think
describes the risk of the approach you proposed:
> Free relay attack:
>
> - Create a low feerate transaction T.
>
> - Send zillions of child transactions that are slightly higher feerate
> than T until mempool is full.
>
> - Create one small transaction with feerate just higher than T’s, and
> watch T and all its children get evicted. Total fees in mempool drops
> dramatically!
>
> - Attacker just relayed (say) 300MB of data across the whole network
> but only pays small feerate on one small transaction.
The document goes on to describe at a high level how Bitcoin Core
attempts to mitigate this problem as well as other ways it tries to
optimize the mempool in order to maximize miner profit (and so ensure
that miners continue to use public transaction relay).
I hope that's helpful to you and to others in both understanding the
current state and in thinking about ways in which it might be improved.
-Dave
[1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining
Content adapted from slides by Suhas Daftuar, uploaded and formatted
by Gregory Sanders and Marco Falke.

2023-06-09 14:56:48

- reply

📅 Original date posted:2019-10-28
📝 Original message:
On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:
> Relay cost is the obvious problem with just naively removing all limits.
> Relaxing the current rules by allowing to add a child to each output as
> long as it has a single unconfirmed parent would still only allow free
> relay of O(size of parent) extra data (which might not be that bad? Similar
> to the carve-out rule we could put limits on the child size).
A parent transaction near the limit of 100,000 vbytes could have almost
10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
were limited to 10,000 vbytes each (the current max carve-out size),
that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
than the default maximum mempool size in Bitcoin Core).
As Matt noted in discussion on #lightning-dev about this issue, it's
possible to increase second-child carve-out to nth-child carve-out but
we'd need to be careful about choosing an appropriately low value for n.
For example, BOLT2 limits the number of HTLCs to 483 on each side of the
channel (so 966 + 2 outputs total), which means the worst case free
relay to support the current LN protocol would be approximately:
(100000 + 968 * 10000) * 4 = ~39 MB
Even if the mempool was empty (as it sometimes is these days), it would
only cost an attacker about 1.5 BTC to fill it at the default minimum
relay feerate[1] so that they could execute this attack at the minimal
cost per iteration of paying for a few hundred or a few thousand vbytes
at slightly higher than the current mempool minimum fee.
Instead, with the existing rules (including second-child carve-out),
they'd have to iterate (39 MB / 400 kB = ~100) times more often to
achieve an equivalent waste of bandwidth, costing them proportionally
more in fees.
So, I think these rough numbers clearly back what Matt said about us
being able to raise the limits a bit if we need to, but that we have to
be careful not to raise them so far that attackers can make it
significantly more bandwidth expensive for people to run relaying full
nodes.
-Dave
[1] Several developers are working on lowering the default minimum in
Bitcoin Core, which would of course make this attack proportionally
cheaper.

2023-06-09 14:53:03

- reply

📅 Original date posted:2018-11-25
📝 Original message:
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote:
> I'm also starting to implement this, to see what I missed!
>
> - Feerate is fixed at 253 [satoshis per 1,000 weight]
IIUC, this is just over Bitcoin Core's default minimum relay fee of
0.00001000 BTC/vByte. That works right now, as mempools are nowhere
near full, but if they fill up again and the BIP133 feefilters are
increased by any amount, nodes will no longer relay transactions with
minimum feerates.
In that case, how does the commitment transaction get relayed in order
for its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1]
There's currently some text in the PR about using
sighash_single|sighash_anyonecanpay for use with RBF, but I don't think
that can apply to spending the commitment transaction, as that would
allow not just adding new inputs and outputs, but also removing all but
the 'singled' output (allowing theft of its value).
-Dave
[1] I don't think Bitcoin Core currently relays transaction packages
consisting of parents below the relay fee limit and children
sufficiently above the limit to pay for their parents. This has
certainly been discussed, so maybe I'm wrong and it is available or
maybe it'll be available in the future.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181125/c4adf28a/attachment.sig>

2023-06-09 14:52:22

- reply

📅 Original date posted:2018-11-10
📝 Original message:
On Wed, Nov 07, 2018 at 10:30:12PM +0000, ZmnSCPxj via Lightning-dev wrote:
> However, SIGHASH_NOINPUT would allow Lightning implementations to be "walletless".
Maybe I'm misunderstanding, but wouldn't this require comitting to the
transaction fees for the various delayed-broadcast transactions (e.g.
the Eltoo trigger transaction) because, without a wallet, you can't RBF
additional fees by adding additional inputs?
Having to set the final fees during setup for a channel that could be
open for weeks or months, but which would need to be closed within a
relatively short window to prevent fraud, could mean committing to an
undesireable high feerate.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181110/60768f04/attachment.sig>

2023-06-09 14:50:53

- reply

📅 Original date posted:2018-06-19
📝 Original message:
On Tue, Jun 19, 2018 at 04:46:32PM +0200, Christian Decker wrote:
> That is true, we can't prevent S_2 to make it into the blockchain, but
> we can make sure it doesn't have any effect (aside from wasting some
> fees), by simply binding S_3 to it immediately afterwards.
Right, but I'm picking on the phrasing in the paper here, which seems to
imply that once the final settlement transaction enters the mempool with
a reasonable fee, its confirmation---and the safe close of the
channel---is "certain." I don't think that's the case and I think the
phrasing might be accidentally misleading to readers who don't have a
good grasp of mempool behavior.
> It should be noted that anyone can perform the rewriting, and it's easy
> to do so, by just following the funding output and knowing the final
> update.
Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
transaction containing the settlement is expected to have (at least) two
inputs, with the second one originating the fees. That second input's
signature is (I assume) using SIGHASH_ALL to commit to all outpoints in
the transaction, so it can't be arbitrarily rewritten by a third-party
to apply to a different state outpoint---and so I think we're dependent
on a motivated person (e.g. one of the channel participants) performing
the rewrite so that the rewritten final settlement transaction pays
fees.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/7bde3561/attachment.sig>

2023-06-09 14:50:52

- reply

📅 Original date posted:2018-06-19
📝 Original message:
Hi,
I finished a re-read of y'alls excellent paper describing Eltoo, and
there was something that confused me:
> If the update transaction represents the last agreed upon state it can
> use relatively low fees being certain that it will not be replaced.
I don't understand why this is "certain"? State_2 can't replace State_3
on the block chain (ignoring reorgs) because S_2's nLockTime of n+2
doesn't satisify S_3's CLTV-enforced minimum state number/locktime of
n+4. But in the mempool this constraint doesn't hold: if S_3 is in the
mempool, S_2 can simply pay more fees than S_3 for RBF replacement.
A mempool replacement of S_3 with S_2 also invalidates the transaction
containing S_3 until one of the participants rewrites it from binding to
State_1's outpoint to binding to S_2's outpoint.
Unless I'm misunderstanding, this could perhaps be clarified to make
clear that, even in the case of a cooperative close, monitoring for old
states needs to continue until the final state has whatever number of
confirmations a participant deems sufficient to make it immutable.
Thanks,
-Dave
P.S.: The paper I re-read was the version (as of yesterday) at blockstream.com/eltoo.pdf
$ grep -a CreationDate eltoo.pdf
/CreationDate (D:20180502232831+02'00')
$ sha256sum eltoo.pdf
aa630d637e4e1aedd91249d52609ab75b2eef2da8e4146e74f30e63c96fb7c26 eltoo.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180619/1c533520/attachment.sig>

2023-06-09 14:46:03

- reply

📅 Original date posted:2016-03-28
📝 Original message:
On Mon, Mar 28, 2016 at 11:19:42AM +0200, Jérôme Legoupil wrote:
> miners have a strong financial incentive to wait and hope to
> include Alice’s 25BTC offer instead of including Bob’s
> worthless breach tx.
I think you're treating miners here as a single actor when they should
be treated as multiple independent actors competing against each other.
Bob can have his breach transaction included in a block immediately but
the sequence lock on the 50 BTC Alice stole prevents her from spending
it for perhaps hundreds of blocks (I believe the paper uses a value of
1,500 blocks).
This means each miner on the network has a choice:
1. Attempt to mine Bob's transaction immediately to claim its modest fee
before some other miner claims that fee.
2. Hope no one else mines Bob's transaction for several hundred blocks
and then compete with all other miners to attempt to mine Alice's
high-fee transaction.
If the network is functioning correctly (e.g. no miner or mining cartel
has a majority of hash rate) then all miners should consider option #1
to be the more profitable option for them on average.
-Dave

2023-06-09 14:40:28

- reply

2023-06-09 14:40:02

- reply

📅 Original date posted:2021-05-03
📝 Original message:
On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote:
> 2. It is not easy to figure out whether it worked or not
Good point.
> 3. This is incompatible with covert recovery schemes like in [1] [...]
> (3) is also a problem with just doing encrypted backups -- going around
> looking for backups means you tell everyone that you are in recovery mode.
Eh, I assume nodes using the backup commons would, each time they're
restarted, go through the steps of downloading some number of backups
even if they haven't lost any data. This tests that the backups are
being stored faithfully (essential to any backup process) and provides
cover for cases where a node does lose data.
Thus encrypted backups seem fully compatible to me with covert recovery.
Sorry, I didn't realize that compatibility was one of your design goals
for seed-based peer rediscovery.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210503/104ee3c0/attachment.sig>

2023-06-09 14:39:55

- reply

📅 Original date posted:2021-04-28
📝 Original message:
On Mon, Dec 07, 2020 at 11:32:27AM +1100, Lloyd Fournier wrote:
> I've been considering the problem of recovering lightning channels after
> losing channel state in a boating accident. The modern way of doing this
> seems to be "static channel backups" -- these are essentially lists of
> channel ids and the nodes you had the channels with.
>
> The idea is that with this backup you can remember who you had channels
> with, connect to them and ask them to force close the channel (can someone
> link me the concrete protocol messages you send to do this?).
>
> It occurred to me that if the lightning protocol were changed slightly you
> could do this without the channel backup at all.
I was re-reading this OP after seeing some of Rusty's concerns later in
the thread and I was wondering why we need to alter funding at all.
We're assuming that when Alice recovers from her backup, she knows her
node_id and has the private key necessary to sign messages for it, so
why can't she sign a message that gets gossiped across the network that
says, "if you have a channel with node_id 0xa11ce, please close it now"?
Maybe the message also includes a signed timestamp or block height so
only channels with funding transactions confirmed before that
time/height get closed, preventing future replays of the message from
closing Alice's later channels opened with the same seed/node_id.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210428/14422f93/attachment.sig>

2023-06-08 01:22:07

- reply

📅 Original date posted:2023-06-02
🗒️ Summary of this message: The taproot annex can be utilized by developers without delay, providing immediate benefits and features, such as arbitrary data insertion into a witness.
📝 Original message:On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> the benefits of making the annex available in a
> non-structured form are both evident and immediate. By allowing
> developers to utilize the taproot annex without delay, we can take
> advantage of its features today,
Hi Joost,
Out of curiosity, what features and benefits are available today? I
know Greg Sanders wants to use annex data with LN-Symmetry[1], but
that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you
mention that it could allow putting arbitrary data into a witness
without having to commit to that data beforehand, but that would only
increase the efficiency of witness stuffing like ordinal inscriptions by
only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
required to create an output in order to spend it.
Is there some other way to use the annex today that would be beneficial
to users of Bitcoin?
-Dave
[1]
https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119

2023-06-08 01:22:01

- reply

📅 Original date posted:2023-05-27
🗒️ Summary of this message: A proposal suggests relaying block templates and weak blocks to improve DoS resistance and offer useful features, delegating responsibility to relays to mitigate concerns.
📝 Original message:On 2023-05-22 21:19, Joost Jager via bitcoin-dev wrote:
> A notable advantage of this approach is that it delegates the
> responsibility of dealing with Denial-of-Service (DoS) threats to the
> relays themselves. They could, for example, require a payment to
> mitigate such concerns.
Hi Joost,
Thanks for working on this! One quick thought I had was that a possibly
interesting avenue for exploration would be that, in addition to
relaying individual transactions or packages, it might be worth relaying
block templates and weak blocks as both of those provide inherent DoS
resistance and can offer useful features.
A block template is an ordered list of raw transactions that can all be
included in the next block (with some space reserved for a coinbase
transaction). A full node can validate those transactions and calculate
how much fee they pay. A Nostr relay can simply relay almost[1] any
template that pays more fees than the previous best template it saw for
the next block. That can be more flexible than the current
implementation of submitblock with package relay which still enforces a
lot of the rules that helps keep a regular relay node safe from DoS and
a miner node able to select mineable transactions quickly.
A weak block is a block whose header doesn't quite hash to low enough of
a value to be included on the chain. It still takes an extraordinary
amount of hashrate to produce, so it's inherently DoS resistant. If
miners are producing block that include transactions not seen by typical
relay nodes, that can reduce the efficiency and effectiveness of BIP152
compact block relay, which hurts the profitability of miners of custom
blocks. To compensate, miners could relay weak blocks through Nostr to
full nodes and other miners so that they could quickly relay and accept
complete blocks that later included the same custom transactions. This
would also help fee estimation and provide valuable insights to those
trying to get their transactions included into the next block.
Regarding size, the block template and weak block could both be sent in
BIP152 compact block format as a diff against the expected contents of a
typical node, allowing Alice to send just a small amount of additional
data for relay over what she'd have to send anyway for each transaction
in a package. (Although it's quite possible that BetterHash or Stratum
v2 have even better solutions, possibly already implemented.)
If nothing else, I think Nostr could provide an interesting playground
for experimenting with various relay and mining ideas we've talked about
for years, so thanks again for working on this!
-Dave
[1] In addition to validating transactions, a relay would probably want
to reject templates that contained transactions that took
excessively long to validate (which could cause a block including
them to become stale) or that included features reserved for
upgrades (as a soft fork that happened before the relay's node was
upgraded might make that block invalid).

2023-06-08 01:21:55

- reply

📅 Original date posted:2023-05-27
🗒️ Summary of this message: Financial analysis of Alice's capital requirements for various activities, including lightning payments and internal transfers. Instant settlement requires OP_XOR or OP_CAT on the base layer.
📝 Original message:Hi Burak,
Thanks for your response! I found it very helpful. I'm going to reply
to your email a bit out of order.
> 4. Alice places one input to her one-in, three-out transaction to
> supply funds to commitment output, connectors output, change
> output, and transaction fees.
You don't mention it in your reply, but was I correct in my earlier
email in assuming that Alice can claim any funds paid to a commitment
output after four weeks if its commitments haven't been published
onchain? E.g., that in the best case this allows a ~50 vbyte commitment
output that pays an arbitrary number of users to be spent as a ~100
vbyte input (P2TR scriptpath for pk(A) && older(4 weeks))?
> 1. Mixing coins.
> 2. Paying lightning invoices
> 3. Making internal transfers
If commitment outputs can't normally be spent by Alice for four weeks,
then Alice needs to keep enough capital on hand to pay out all amounts
involved in the activities listed above. I've seen many people make
this point, but I wanted to run some rough numbers to estimate the
extent of that capital load.
Let's say Alice has a million customers who each receive all of their
income and pay all of their expenses with her. In my country, the
median income is a bit less than $36,000 USD, or about $3,000 a month.
I imagine spending is not evenly distributed over time, so let's say
Alice needs to hold 3x the average to be prepared for a busy period.
That implies Alice's capital requirements are about $9 billion USD (3 *
3000 * 1e6).
At a hypothetical risk-free interest rate of 1.5% annual, that's about
$135 that will need to be recovered from each user per year (9e9 * 0.015
/ 1e6).
Additionally, if we assume the cost of an onchain transaction is $100
and the service creates one transaction per five seconds, that's $630 in
fee costs that will need to be recovered from each user per year ((60 /
5) * 60 * 24 * 365 * 100 / 1e6).
I'll come back to this financial analysis later.
> If we want to enable Lightning-style instant settlement assurances for
> the internal transfers, we need OP_XOR or OP_CAT on the base layer
> [...] https://eprint.iacr.org/2017/394.pdf
What do you mean by "instant"? Do you mean "settlement as soon as the
next onchain pool transaction is published"? For example, within 5
seconds if the coinjoining completes on time? That's significantly
slower than LN today, at least in the typical case for a well-connected
node.[1]
I think 5 seconds is fine for a lot of purposes (at both point-of-sale
terminals and on websites, I very often need to wait >5 seconds for a
credit card transaction to process), but I think it's worth noting the
speed difference in a technical discussion.
Additionally, I think the idea described significantly predates that
paper's publication, e.g.:
"Well while you can't prevent it you could render it insecure enabling
miners to take funds. That could work via a one-show signature
[...]"[2]
A problem with the idea of using one-show signatures as double-spend
protection is that miner-claimable fidelity bonds don't work as well
against adversaries that are not just counterparties but also miners
themselves. This same problem has been described for other ideas[3],
but to summarize:
Bob has something valuable. Alice offers him the output of an
unconfirmed transaction in exchange for that thing. She also provides a
bond that will pay its amount to any miner who can prove that Alice
double spent her input to the unconfirmed transaction.
If Alice is miner, she can privately create candidate blocks that double
spend the payment to Bob and which also claim the bond. If she fails to
find a PoW solution for those candidate blocks, she lets Bob have his
money. If she does find a PoW solution, she publishes the block, taking
Bob's money, securing her bond, and also receiving all the regular block
rewards (sans the fees from whatever space she used for her
transaction).
I haven't exactly[4] seen this mentioned before, but I think it's
possible to weaken Alice's position by putting a timelock on the
spending of the bond, preventing it from being spent in the same block
as the double-spend. For example, a one-block timelock (AKA: 1 CSV)
would mean that she would need to mine both the block containing her
unconfirmed transactions (to double spend them) and the next block (to
pay the fidelity bonds back to herself).
Ignoring fee-sniping (bond-sniping in this case), selfish mining, and
51% attacks, her chance of success at claiming the fidelity bond is
equal to her portion of the network hashrate, e.g. if she has 33%, she's
33% likely to succeed at double spending without paying a penalty. The
value of the fidelity bond can be scaled to compensate for that, e.g. if
you're worried about Alice controlling up to 50% of hashrate, you make
the fidelity bond at least 2x the base amount (1 / 50%). Let's again
assume that Alice has a million users making $3,000 USD of payments per
month (28 days), or about on average $75,000 per minute (1e6 * 3000 / 28
/ 24 / 60). If Alice bonds 2x the payment value and her bonds don't
expire for 6 blocks (which might take 3 hours), she needs an additional
$27 million worth of BTC on hand (75000 * 2 * (3 * 60)), which I admit
is trivial compared to the other capital requirements mentioned above.
* * *
Taken all together, it seems to me that Alice might need to keep several
billion dollars worth of BTC in a hot wallet in order to serve a million
users. The per-user cost in fees and capital service would be around
$1,000 per year. If we assume onchain transaction costs are about $100,
that would be equal to 10 channels that could be opened or closed by
each user for the same amount (i.e. an average of 5 channel rotations
per year).
Did I miss something in my analysis that would indicate the capital
costs would be significantly lower or that there wouldn't be other
tradeoffs (slower settlement than LN and a need to use a timelocked
fidelity bond)?
Thanks!,
-Dave
[1] https://twitter.com/Leishman/status/1661138737009442818
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018010.html
[4] Years ago, I think I saw a reply by Peter Todd to some idea about
paying money to miners in a fair way and he noted that it was
critical to pay miners far enough in the future that the current set
of miners wouldn't be incentivized to manipulate who got the money
by choosing which block to include the transaction in now. I wasn't
able to quickly find that post, but it definitely influenced my
thinking here.

2023-06-08 01:21:54

- reply

📅 Original date posted:2023-05-24
🗒️ Summary of this message: The Ark protocol involves an Ark service provider broadcasting a new unconfirmed on-chain transaction every 5 seconds, with three outputs. Bob can deposit 1 BTC with Alice and they both sign the PSBT, which is broadcast. Bob can unilaterally withdraw or collaboratively withdraw the funds.
📝 Original message:Hi Burak,
Thanks for this really interesting protocol! I tend to analyze
complicated ideas like this by writing about them in my own words, so
I've pasted my summary of your idea to the end of this email in case
it's useful, either to other people or to you in helping understand my
one concern.
My concern is the same one I think Olaoluwa Osuntokun mentioned on
Twitter[1] and (less clear to me) might be related to ZmnSCPxj's
concern[2]:
It seems to me that receiving a payment on the protocol, including
conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting
for the transaction containing that payment to confirm to a sufficient
depth (e.g., I'd wait 6 blocks for small payments and longer for huge
payments). Am I missing something?
My summary of how I think that part of the protocol works is in the
sections labeled "Make an unconditioned payment" and "Make a conditional
payment" below. In short, it's clear to me how the service provider and
the customer can make instant atomic swaps with each other---they can
either spend instantly cooperatively, or they have to wait for a
timeout. But how can a receiver of funds be assured that they will
actually get those funds unless there's already a timelock and
cooperative spend path placed on those funds?
-Dave
Rough initial summary of Ark protocol:
Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
new unconfirmed onchain transaction that pays three outputs (the
three Cs):
1. *Change Output:* money not used for the other two Cs that gets sent
back to the the transaction creator.
2. *Connector Output:* an output that will be used in a future
transaction created by Alice as protection against double spends.
3. *Commitment Output:* a CTV-style commitment to a set of outputs that
can be published later in a descendant transaction (alternatively,
the commitment output may be spent unilaterally by Alice after 4
weeks).
Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT
with an input of his and a change output. She updates the PSBT with a
commitment output that refunds Bob the 1 BTC and a connector output with
some minimum value. They both sign the PBST and it is broadcast. We'll
ignore fees in our examples, both onchain transaction fees and fees paid
to Alice.
From here, there are several things that Bob can do:
- *Unilaterally withdraw:* Bob can spend from the commitment output to
put his refund onchain. The refund can only be spent after a 24-hour
time delay, allowing Bob to optionally come to an agreement with Alice
about how to spend the funds before Bob can spend them unilaterally
(as we'll see in a moment). For example, the script might be[3]:
pk(B) && (older(1 day) || pk(A))
- *Collaboratively withdraw:* as seen above, Bob has the ability to come
to a trustless agreement with Alice about how to spend his funds.
They can use that ability to allow Bob to trade his (unpublished) UTXO
for a UTXO that Alice funds and broadcasts. For example:
- Alice creates an unsigned PSBT that uses as one of its inputs the
connector from Bob's deposit transaction. This will ensure that
any attempt by Bob to double-spend his deposit transaction will
invalidate this withdrawal transaction, preventing Bob from being
able to steal any of Alice's funds.
Also included in Alice's unsigned PSBT is another connector
output plus the output that pays Bob his 1 BTC.
- Bob receives Alice's unsigned PSBT and creates a separate PSBT
that includes his unpublished UTXO as an input, giving its value
to Alice in an output. The PSBT also includes as an input the
connector output from Alice's PSBT. This will ensure that any
attempt by Alice to double spend her transaction paying him will
invalidate his transaction paying her.
- Bob signs his PSBT and gives it to Alice. After verifying it,
Alice signs her PSBT and broadcasts it.
- *Collaboratively trade commitments:* as mentioned, the commitment
output that pays Bob may be claimed instead by Alice after 4 weeks, so
Bob will need to either withdraw or obtain a new commitment within
that
time. To trade his existing commitment for a new commitment looks
similar to the collaborative withdrawal procedure but without the
creation of an immediately-spendable onchain output:
- Alice creates an unsigned PSBT that uses as one of its inputs the
connector from Bob's deposit transaction, again preventing double
spending by Bob. Alice also includes a new connector and a new
commitment that again allows Bob to later claim 1 BTC.
- Bob receives Alice's PSBT and creates a PSBT transferring his
existing commitment to her, with the new connector again being
included as an input to ensure atomicity.
- Bob signs; Alice signs and broadcasts.
- *Make an unconditioned payment:* using the mechanisms described above,
it's possible to make either an onchain payment or an offchain
payment---just have Carol receive the new output or commitment rather
than Bob. That payment would have no conditions (except its
atomicity).
- *Make a conditional payment:* imagine that Carol knows a secret (e.g.
a preimage) that Bob is willing to pay for.
- Alice creates an unsigned PSBT depending on the connector from
Bob's deposit transaction and creating a new connector. The PSBT
includes an output paying Carol (either onchain or via a
commitment) with an HTLC, allowing Carol to claim the funds if
she
reveals the secret or allowing Bob to claim the funds after a
timeout.
- Bob receives Alice's PSBT and creates a PSBT transferring his
existing commitment to her with the HTLC condition attached and,
again, with connectors being used to ensure atomicity.
- Bob signs; Alice signs and broadcasts.
- Carol can settle her HTLC by either revealing the secret onchain
or by trading her commitment containing the HTLC clause for a
commitment from Alice that doesn't contain the clause (which
Alice will only accept by learning the secret, since Alice has
to settle with Bob). Alice can then either settle onchain or
trade commitments with Bob after giving him the secret.
- *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice
can claim the funds from the commitment output (i.e., takes his
money).
If Bob did actually do something, and if every other user who also
had an unpublished output in the commitment transaction did
something, then they all exchanged their portion of the funds in
this output to Alice, so Alice can now claim all of those funds
onchain in a highly efficient manner.
Regarding the connector outputs, although all of the examples above show
Alice directly spending from the connector output in Bob's deposit
transaction, atomicity is also ensured if Alice spends from any output
descended from Bob's connector output. Connector outputs from different
deposits can be used as inputs into the same transaction, merging their
histories. This allows all operations made by Alice to be fully atomic,
ensuring that she doesn't lose any money during a reorg of any length.
Users are not so well protected during reorgs, e.g. if Bob double-spends
a transaction whose funds were later used in a payment to Carol, then
Carol loses the money. For this reason, Alice will probably want to
prove to users that no funds they receive in a payment derive from any
deposit less than safe_confirmation_depth blocks.
[1] https://twitter.com/roasbeef/status/1661266771784126464
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.html
[3]
https://min.sc/#c=pk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29

2023-06-08 01:21:18

- reply

📅 Original date posted:2023-05-07
🗒️ Summary of this message: The concern is that current maintainers will decide which proposed new maintainers to add and which to block, but this is how many organizations are run. The questions to ask are whether the current maintainers are capable of moving Bitcoin Core in the right direction and what can be done if they are not. However, this matter should not have been posted to this mailing list.
📝 Original message:On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> Essentially my concern is going forward current maintainers will
> decide which proposed new maintainers to add and which to block.
This is how a large percentage of organizations are run. The current
members of a board or other governance group choose who will become a
new board member.
One alternative to self-perpetuating governance is membership voting,
but building and maintaining democratic institutions is hard and not a
good fit for many types of endeavors---the building of highly technical
software being one of those cases IMO.
I think the questions we want to ask is whether the current set of
maintainers is capable of moving Bitcoin Core in the direction we want
and what we can do about it if we conclude that they are ill-suited (or
malicious). For the first question, I think that's something everyone
needs to answer for themselves, as we may each have different visions
for the future of the project. That said, I note that several
initiatives championed by the current maintainers in the IRC meeting you
mention received overwhelmingly positive support from a significant
number of current contributors, which seems like a healthy sign to me.
For the second question, I think AJ Towns already answered that quite
well (though he was talking about a different project):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
Finally, I don't think this matter warranted a post to this mailing
list. Discussion about internal project decisions, such as who should
have merge access and what maintainers should communicate in PRs, belong
in communication channels dedicated to that project.
-Dave

2023-06-08 01:20:29

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: RGB allows for the creation of user-defined sidechains based on arbitrary scripts, reducing global state and allowing sidechain tokens to be used with LN. However, it does not provide trustless contracting beyond the capabilities of Bitcoin script.
📝 Original message:On 2023-04-18 13:16, Dr Maxim Orlovsky wrote:
> 1. Assume we have some BTC lifted to RGB, which we will name BTC*.
> (let’s leave the question on how to do that aside; it can be
> discussed separately).
Hi Maxim,
Ok, I think I understand you, but I'd like to try rephrasing what you
wrote in a very brief format to see if you agree that it's correct and
in the hopes that it might help other Bitcoin/LN developers understand.
- Xavier and Yasmin create an RGB contract that says any BTC deposited
into multi(2,x,y) can be used as BTC\*
- Bob acquires some of this BTC\*
- Bob offers his BTC\* to anyone who can provide x for (4 == 2 * x)
- Alice knows x = 2
- Alice asks Xavier and Yasmin to sign an onchain transaction
withdrawing Bob's BTC\*. She provides them proof that Bob offered his
BTC\* and that she knew the answer. The both sign the the
transaction.
In short, I think this capability of RGB allows easily creating
user-defined sidechains based on arbitrary scripts. This is similar to
what Elements allowed last I looked at it, although RGB makes the
process of creating new sidechains much smoother, reduces global state,
and allows sidechain tokens (including tokens like lifted BTC) to be
used with LN without sidechain-specific programming. That seems like a
significant advance to me.
What it doesn't provide is trustless contracting beyond the capabilities
of Bitcoin script. To be fair, when I looked at your documentation
again just now, I don't see it promising enhanced **trustless**
contracting---I see it only promising enhanced contracting, which I (and
perhaps others) seem to have interpreted as also being trustless.
I hope I've understood you correctly. Regardless, thank you for your
many detailed answers to my questions!
-Dave

2023-06-08 01:20:24

- reply

📅 Original date posted:2023-04-16
🗒️ Summary of this message: Dr. Orlovsky's RGB project aims to build a programmability layer for Bitcoin and Lightning, enabling assets beyond tokens, such as DAOs and decentralized identities. However, there are concerns about the security of non-publishable conditional statements in multiparty protocols.
📝 Original message:Hi Dr Orlovsky,
Thank you for writing about your interesting project. Some replies
inline below:
On 2023-04-10 12:09, Dr Maxim Orlovsky via bitcoin-dev wrote:
> RGB v0.10 can be downloaded and installed as described on
> <https://rgb.tech>
> website, which also contains a number of user and developer guidelines.
> RGB source code can be found on <https://github.com/RGB-WG>
FYI: the RGB-WG organization page links to a repository whose latest
release is 0.9 and whose latest commit is titled, "Release v.0.9.1", see
https://github.com/RGB-WG/rgb-node/
> My goal with RGB was not just to enable assets on Lightning, but that
> of a much larger scope: to build a programmability layer for Bitcoin
> and Lightning, which may unlock other cases than just tokens - DAOs,
> decentralized identities and other things that bitcoin itself was
> lacking.
Is there any documentation or discussion archives that address the
problem of non-publishable conditional statements seemingly being
insecure in
multiparty protocols, as previously described on this list[1] by Ruben
Somsen? To give my own example of the problem:
- Bob doesn't believe that there's a number which can be multiplied by 2
to produce 4. He's willing to pay a bounty for proof that he's wrong
but Bitcoin does not currently provide a multiplication opcode, so he
can't simply pay a script that says: "2 OP_MUL 4 OP_EQUAL"
- Bob hears that RGB has turing-complete scripting, so he buys some
random tokens that have an RGB contract which allows him to encumber
them by any AlumVM script. He then creates a Bitcoin transaction
signed SIGHASH_NONE|SH_ANYONECANPAY that will allow anyone knowing the
solution to (x * 2 == 4) to spend his RGB-based tokens. He publishes
a PSBT for the transaction along with the RGB data needed to claim the
tokens.
- Anyone on the network can now claim the BTC without knowing the
solution, destroying the RGB-based tokens.
- If, instead, Bob hears that Mallory knows the solution, he could sign
a
PSBT with the default SH_ALL to her, but then Mallory could take the
BTC without solving the problem, again destroying the RGB-based
tokens.
- Or, in another case, Bob hears that Alice knows the solution, but he
doesn't want to risk his tokens being destroyed, so he refuses to sign
a transaction paying Alice until she provides him the answer. When
Alice does provide him the answer, and he realizes it's so simple, he
changes his mind about paying her and doesn't sign his transaction to
her. She has no recourse.
It seems to me, based on my understanding of Somsen's original insight,
that client-side validation by itself cannot enforce conditions in a
trustless multiparty setting.
I think that implies that it's only possible to enforce conditions in a
consensus system (or in a trust-dependent system), which would have
significant implications for the future direction of your work, as you
wrote in your email:
> We're also working on the design of a layer 1 which will be perfect for
> the
> client-side-validated applications (“how to design a blockchain today
> if we
> knew about client-side-validation/single-use-seals”). This should be
> very
> compact (order of one signature per block) ultra-scalable
> (theoretically
> unlimited no of tx in a block) chain which can run systems like RGB -
> with
> Bitcoin UTXO set migrated into RGB [...]
* * *
Looking at other parts of your email:
> Nevertheless, in 2021 we were able to present both RGB powered with a
> Turing-complete virtual machine (AluVM) [2] and RGB had became
> operational on
> Lightning Network [3] using the LNP Node - a complete rust
> re-implementation of
> the Lightning protocol made by me at the Association [4].
Could you clarify the status of these implementations? While trying to
learn about RGB, I noticed that you don't have much completed
documentation. Previous reviewers also mentioned this and I saw that
you suggested them to read the code or view your videos.
When reading your code for your LN implementation (LNP), I noticed it
seemed to be missing a lot of things present in other LN implementations
I regularly review. For example, I can't find where it supports
creating or parsing onions, which seems to be a fundamental requirement
for using LN. In trying to figure out how it works, I also noticed that
I couldn't find either unit tests or integration tests---indeed several
of your applications seem to almost entirely lack the string "test".
For example, here are LNP-node and RGB-node compared to the four LN
implementations I regularly monitor:
/tmp/rgb-node$ git grep -i '\<test\>' | wc -l
7
/tmp/lnp-node$ git grep -i '\<test\>' | wc -l
4
~/repos/rust-lightning$ git grep -i '\<test\>' | wc -l
2008
~/repos/cln$ git grep -i '\<test\>' | wc -l
1459
~/repos/lnd$ git grep -i '\<test\>' | wc -l
3547
~/repos/eclair$ git grep -i '\<test\>' | wc -l
2576
I realize those are all projects by larger teams than that which works
on RGB, but a difference of three orders of magnitude is very surprising
to me. Do you have out-of-tree testing or am I missing something else?
I did my best to earnestly search both your repository and your GitHub
issues and PRs. All I found was that a small amount of previous unit
testing was removed, and that several issues mentioning the need for
testing were closed without referencing a resolution.
As your replies to previous reviewers also mentioned that they should
view your Youtube videos, I also tried that. I focused on the ones
discussing LNP, as LN is something I know fairly well, and I admit that
I skimmed them quite fast, but I couldn't find any demos where you
progressed beyond using LNP to open a channel with another node. E.g.,
they seemed to stop at the same point as this demo:
https://github.com/LNP-WG/lnp-node/blob/c402decc9ff5b557a9e3d542f74e2fd6ed856742/doc/demo-alpha.4/README.md
> Despite 4 years of active development, weekly community calls, talks on
> all mainstream bitcoin-only evens and conferences, the awareness about
> RGB
> in the bitcoin community is still very small
My understanding of the basic goal of RGB from years ago was that it
would allow ordinary users to define new assets on Bitcoin in a way that
would allow those assets to be transferred over LN. As far as I can
tell, it doesn't do that yet, not even in a way that's accessible to a
power user such as myself. Even for that original goal, there are
several problems outstanding---problems which will likely require
significant research and experimentation to overcome, e.g.[2].
Instead of tackling those problems and building upon existing wallet and
LN libraries, I see an ambitious effort at reimplementation and massive
scope creep. The payoff for that effort could be a huge change that
affects how we use Bitcoin and LN for decades to come. But it also
seems possible that the ambition and scope creep may be preventing the
project from currently serving many of the people who were most excited
about it in the first place. Awareness may be limited because the
near-term benefits for most people who invest time in learning about RGB
also seems limited.
Thanks again for writing about your research for this mailing list,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003540.html
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003549.html

2023-06-08 01:20:11

- reply

📅 Original date posted:2023-03-01
🗒️ Summary of this message: A proposed solution to send a fraction of transaction fees to contracts for redistribution may incentivize miners to prefer out-of-band fees, undermining the redistribution scheme and decentralization of Bitcoin's confirmation mechanism.
📝 Original message:On 2023-02-27 03:32, Rastislav Budinsky via bitcoin-dev wrote:
> When a miner mines a block he takes all the fees currently. However
> with the proposed solution he takes only fraction M and remaining
> fraction C is sent to one of more contracts. One contract at its
> simplest collects fees from the miner and at the same time
> redistributes it back to the miner.
Hi Rastislav,
I think you've incorrectly made the assumption that the only way a miner
can profit from confirming a transaction is by collecting its
transaction fees. Miners can (and many have) accept payment through
alternative means, which the Bitcoin technical community often calls
"out-of-band fees".[1] For example, some miners have provided a
"transaction accelerator" service that accepts fiat-denominated credit
cards to increase their prioritization of certain transactions and I'm
personally aware of a large web wallet provider that would occasionally
pay miners out of band to confirm hundreds or thousands of transactions
rather than fix its broken fee estimation.
Out-of-band fees aren't frequently used in Bitcoin today because they
have no advantage over correctly estimated in-band fees, and good fee
estimation is very accessible to modern wallets. However, if the
consensus rules are changed to require each miner pay a percentage of
its in-band fees to future miners, then there would be a strong
incentive for them to prefer out-of-band fees that weren't subject to
this redistribution scheme.
I think may have seen a variation on the scheme you propose play out in
real life. Here's how it works where I live: the government imposes
taxes on goods, services, and income. Ostensibly, it redistributes the
collected funds back to citizens in the future by providing government
services. When I go to pay someone who trusts my discretion, they often
offer me a discounted rate if I pay in a way that isn't reported to the
government (e.g., I pay with cash); even with the discount provided to
me, they get to keep more of their income than if they had reported the
transaction to the government.
In the case of a government, tax evasion can be reduced by the
deployment of investigators and enforcers. In Bitcoin, we have no
control over activity that happens outside of the protocol and so even a
modest incentive to pay fees out of band might quickly lead to almost
all fees being paid out of band. This prevents the effective
redistribution of fees as in your proposal. Additionally, previous
discussions on this mailing list about paying out-of-band fees have
highlighted that larger miners have an advantage over smaller miners in
collecting miner-specific fee payments, undermining the essential
decentralization of Bitcoin's transaction confirmation mechanism (moreso
than it is already weakened by fundamental economies of scale in
mining).
In short, I think serious consideration of your proposal can only
proceed if it adequately addresses the problem of out-of-band fees.
That said, thank you and your co-authors for putting serious thought
into Bitcoin's long-term economic incentives.
-Dave
[1] https://bitcoinsearch.xyz/?q=out%20of%20band%20fees&size=n_50_n

2023-06-08 01:19:42

- reply

📅 Original date posted:2023-02-19
🗒️ Summary of this message: Codex32 is a new seed phrase scheme that offers a longer, stronger checksum and more compact encoding, designed to be readable and computable by hand. It uses the bech32 alphabet and does not support passphrases or hardening. It also allows for periodic recollection verification and versioning metadata for wallets.
📝 Original message:On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> the draft lists several benefits over SLIP-0039.
The only benefit over SLIP39 that I see explicitly mentioned in the
draft BIP is "simple enough for hand computation". In the FAQ[1] on the
project's website, I see some additional reasons:
| This scheme is essentially the same as SLIP39, with the following
differences:
|
| - The checksum is longer, slightly stronger, and designed to be
| computable by hand.
|
| - Our encoding is more compact, giving us room for a bit of more
| metadata, which is also designed to be readable by hand.
|
| - Unlike SLIP39, we do not support passphrases or hardening of any
| form.
|
| - Unlike SLIP39, we have no hardware wallet support. But we hope that
| will change!
From having perused the extended documentation myself, I think I would
personally note the following differences.
- Alphabet: Codex32 uses the bech32 alphabet rather than SLIP39's
alphabet consisting of English words. The benefit to human-language
words is easier memorization for those proficient in the particular
language (in this case, SLIP39 only allows the use of English). A
disadvantage, IMO, is that it encourages the practice of memorization
(which does have a few advantages but also a lot of drawbacks).
Interestingly, Codex32 addresses what I think is the main problems of
memorization: difficult-to-prove successful recollection. Someone who
wants to reliably keep seed-related material only in their head
needs to practice recalling it on a regular basis, but for BIP39,
SLIP39, Aezeed, etc... there's no way for them to confirm they
successfully recalled it short of going through the entire recovery
process; they probably just judge how confident they feel about the
recollection and assume that feeling like they recalled it correctly
is the same thing as recalling it correctly.
Codex32 allows the individual to periodically perform their
recollection on paper in a private room without electronics and use
nothing but a pen and some loookup tables (or a paper device) to
verify that they recalled the string correctly (and its checksum can
help with correcting up to several errors, although you might need a
computer for error location and correction assistance).
- Hierarchy: Codex32 does not natively provide support for nested SSSS
whereas SLIP39 does. E.g., in SLIP39, you can require 2-of-3 for
{me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,
buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends
are 2-of-5 {d, e, f, g, h}. I assume you can do the same with Codex32
by using the share for one level as the secret for the next level,
although this is not described in the protocol.
- Versioning: Codex32's metadata can store version information for
wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although
this would cut into the space available for users to set their own
metadata and it is not specified in the draft BIP. SLIP39 also
doesn't specify anything about implicit path versioning and, AFAICT,
doesn't have any room to store such metadata without reducing seed
entropy.
- Plausible deniability dummy wallets: Codex32 doesn't support this;
SLIP39 does. Much has been written by other people about whether
dummy wallets are a good idea or not, with strong opinions on both
sides, so maybe we can just leave it at that.
---
When I first saw the post about this, it was unclear to me that it was a
serious project, but I've become increasingly interested as I researched
it. I'm not personally that interested in generating entropy from dice
or encoding shares by hand---it's already imperative that I acquire a
trustworthy computer and load it with trustworthy software in order to
use my seed securely, so I might as well have it generate my seeds and
my
recovery codes for me.
What really did catch my attention, but which was kind of buried in the
project documentation, is the ability to verify the integrity of each
share independently without using a computer. For example, if I store a
share with some relative who lives thousands of kilometers away, I'll be
able to take that share out of its tamper-evident bag on my annual
holiday visit, verify that I can still read it accurately by validating
its checksum, and put it into a new bag for another year. For this
procedure, I don't need to bring copies of any of my other shares,
allowing them (and my seed) to stay safe.
---
I do have one question after watching an excellent video[2] about the
motivation for this system. In the video, one of the threat models
described is a disarrangement of the words in a metal backup system.
The implication seems to be that this would be an accidental
disarrangement, which obviously the Codex32 checksum would catch during
periodic offline verification. But what about deliberate modification
of a recovery code? For example, Bob doesn't keep his seed loaded on
any computer; it only exists in Codex32 shares which Bob plans to
combine together in 20 years when he retires, although he makes regular
deposits to the pubkeys derived from the seed's master xpub. Mallory is
able to obtain access to Bob's shares, allowing her to immediately steal
his current funds---but also allowing her to replace them with
similar-looking
shares with the same metadata and valid checksums so that Bob
continues making deposits to the wallet.
I'm curious about whether there's a way to prevent this attack without
otherwise compromising the properties of the code? For example, some
extra data that Bob can carry around (or memorize) for verifying the
shares haven't changed, but which is not otherwise needed for recovery
(so there's no problem if it's lost).
Thanks,
-Dave
[1] https://secretcodex32.com/faq/index.html
[2]
https://www.youtube.com/watch?v=kf48oPoiHX0&list=PLyOGyBytgcuQLi9DC5g88DOEGnqBDPmq1&index=2

2023-06-08 01:18:51

- reply

📅 Original date posted:2023-01-30
🗒️ Summary of this message: A proposal has been made to reserve a canonical example of future segwit addresses that won't interfere with future soft forks but will exercise wallets supporting bech32m. This will avoid any annoyance for developers of future soft forks.
📝 Original message:Hi y'all!,
One of the benefits proposed for bech32 (and, by extension, bech32m) is
that spender wallets shouldn't need to be upgraded to pay segwit outputs
defined in future soft forks. For example, Bitcoin Core today can pay a
bech32m address for a segwit v2 output, even though no meaning has been
assigned to output scripts matching a segwit v2 template.
However, testing this behavior in production[1] can create an annoyance
for developers of future soft forks. They will need to deal with any
existing outputs paid to the templates used in that proposed soft fork.
See, for example, some discussion by developer 0xB10C about payments to
segwit v1 addresses before activation of the taproot soft fork:
https://b10c.me/blog/007-spending-p2tr-pre-activation/
I was wondering if it would be useful to have a canonical examples of
future segwit addresses that are designed to be very unlikely to
interfere with future soft forks but which would still reasonably
exercise wallets supporting bech32m. I think of this as the rough
equivalent of the RFC2606 domain "example.com" which has been reserved
for examples in documentation.
Specifically, I'm thinking of the following addresses, one each for
mainnet and testnet:
- HRP: bc for mainnet; tb for testent
- Witness version: 16 (the last segwit version)
- Witness program: 0x0000. Two bytes is the minimum allowed
by BIP141, but it's far too small to make any sort of secure
commitment,
so I'm hoping it won't conflict with any future use
I think we should try to start with just one reserved address per
network, but if that isn't enough, I think we could allow any two-byte
witness program with witness version 16.
Outputs paid to reserved addresses will still be anyone-can-spend, so
there's no change required to Bitcoin Core or other software and those
outputs can still be cleaned out of the UTXO set. Additionally, if we
ever *really* need that address space for a soft fork, it will be
available.
Are there any objections to this idea, or suggestions for a better way
to go about it?
Thanks!,
-Dave
[1] Testing in production should be avoided because it uses block space
that could otherwise be used by actual value transfers. Also, it costs
money and pollutes the UTXO set (at least temporarily). However, when
testing whether proprietary third-party software, such as an exchange,
supports payments to future segwit versions, sometimes the only
convenient method is to actually pay the address for a future segwit
version. Additionally, my specific use case is just to write
documentation
about bech32m---but I worry that people will pay my example of a future
segwit
version address.

2023-06-08 01:18:29

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Two methods for implementing "conflict monitoring" in decentralized coinjoin implementations like Joinmarket are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.
📝 Original message:On 2023-01-10 00:06, Peter Todd wrote:
> Remember, we'd like decentralized coinjoin implementations like
> Joinmarket to
> work. How does a decentralized coinjoin implement "conflict
> monitoring"?
1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core
with -debug=mempoolrej will tell you when it rejects a transaction
for conflicting with a transaction already in the mempool, e.g.:
2022-11-01T02:53:17Z
867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
peer=58 was not accepted: txn-mempool-conflict
I think it would be easy to extend this facility to list the inputs
which conflicted. So if Alice sees a conflict created by Mallory,
she can create a new coinjoin transaction without Mallory. This
method has the advantage of being fast and attributing fault,
although it does require Alice's node be online at the time Mallory's
conflict is propagated.
2. Simply assume a conflict exists for otherwise unexplainable failures.
For example, if Alice sees several new blocks whose bottom feerates
are well below the feerates of an unconfirmed coinjoin transaction
that Alice helped create and broadcast, she can assume it's a
conflict that is preventing preventing confirmation of the coinjoin.
She can find an entirely different set of collaborators and create a
non-conflicting transaction without ever needing to know which inputs
from the original transaction conflicted. This method has the
disadvantage of being slow (on the order of hours) and not
attributing
fault, although it doesn't require Alice has any information beyond
copies
of recent blocks.
I didn't list these methods or others before because the specific method
used to
detect conflicts doesn't matter to the realization that software which
uses conflict detection and evasion to defeat the $17.00 attack also
defeats the $0.05 attack without any need for full-RBF.
-Dave

2023-06-08 01:18:28

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: The need for full-RBF to prevent a $0.05 individual conflicting input attack is unnecessary as other conflict monitoring systems can provide the same benefits.
📝 Original message:On 2023-01-09 22:47, Peter Todd wrote:
> How do you propose that the participants learn about the double-spend?
> Without
> knowing that it happened, they can't respond as you suggested.
I can think of various ways---many of them probably the same ideas that
would occur to you. More concise than listing them is to just assume
they exist and realize that any protocol software which wants to defeat
the $17.00 pinning attack needs to implement some sort of conflict
monitoring system---but by using that monitoring system to defeat the
$17.00 pinning attack, the software also defeats the $0.05 individual
conflicting input attack without any need for full-RBF.
Full-RBF provides no benefits here except those which are already
provided by other necessary tools.
Thanks,
-Dave

2023-06-08 01:18:27

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Full-RBF can prevent DoS attacks on multi-party protocols caused by double-spending inputs with low-fee transactions, but the issue can also be solved without it.
📝 Original message:On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
> [The quote:]
>
> "Does fullrbf offer any benefits other than breaking zeroconf
> business
> practices?"
>
> ...has caused a lot of confusion by implying that there were no
> benefits. [...]
>
> tl;dr: without full-rbf people can intentionally and unintentionally
> DoS attack
> multi-party protocols by double-spending their inputs with low-fee txs,
> holding
> up progress until that low-fee tx gets mined.
Hi Peter,
I'm confused. Isn't this an easily solvable issue without full-RBF?
Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.
Mallory either intentionally or unintentionally creates a conflicting
transaction that does not opt-in to RBF.
You seem to be proposing that the other participants force the coinjoin
to complete by having the coinjoin transaction replace Mallory's
conflicting transaction, which requires a full-RBF world.
But isn't it also possible in a non-full-RBF world for Alice, Bob, and
Carol to simply create a new coinjoin transaction which does not include
any of Mallory's inputs so it doesn't conflict with Mallory's
transaction? That way their second coinjoin transaction can confirm
independently of Mallory's transaction.
Likewise, if Alice and Mallory attempt an LN dual funding and Mallory
creates a conflict, Alice can just create an alternative dual funding
with Bob rather than try to use full-RBF to force Mallory's earlier dual
funding to confirm.
> ## Transaction Pinning
>
> Exploiting either rule is expensive.
I think this transaction pinning attack against coinjoins and dual
fundings is also solved in a non-full-RBF world by the honest
participants just creating a non-conflicting transaction.
That said, if I'm missing something and these attacks do actually apply,
then it might be worth putting price figures on the attack in terms most
people will understand. The conflicting inputs attack you described in
the beginning as being solved by full-RBF costs about $0.05 USD at
$17,000/BTC. The transaction pinning attack you imply is unsolved by
full-RBF costs about $17.00. If both attacks apply, any protocol which
is vulnerable to a $17.00 attack still seems highly vulnerable to me, so
it doesn't feel like a stretch to say that full-RBF lacks significant
benefits for those protocols.
Thanks,
-Dave

2023-06-08 01:16:53

- reply

📅 Original date posted:2022-11-10
📝 Original message:On 2022-11-07 23:17, Salvatore Ingala via bitcoin-dev wrote:
> Hi list,
Hi Salvatore!,
> I have been working on some notes to describe an approach that uses
> covenants in order to enable general smart contracts in bitcoin. You
> can find them here:
>
> https://merkle.fun
I haven't yet been able to understand everything in your post, but I'm
wondering if you can describe how your proposal significantly differs in
application from [1]? E.g., you write:
> 1. Alice posts the statement “f(x) = y”.
> 2. After a challenge period, if no challenge occurs, Alice is free to
> continue and unlock the funds; the statement is true.
> 3. At any time before the challenge period expires, Bob can start a
> challenge: “actually, f(x) = z”.
That looks to me very similar to Gregory Maxwell's script from[1]
(comments and variable name changes mine):
# Offchain, Alice posts the statement f(x) = y
# Offchain, Bob provides Ex, an encrypted form of x that can be proven
in zero knowledge to satisfy both f(x) = y and sha256(x) = Y
OP_SHA256
<Y> OP_EQUAL
OP_IF
# Bob provided the preimage for Y, that preimage being the solution,
so he can spend the funds now
<Bob Pubkey>
OP_ELSE
# The challenge period ended, so Alice can reclaim her funds
<block_height+100> OP_CHECKLOCKTIMEVERIFY OP_DROP
<Alice Pubkey>
OP_ENDIF
OP_CHECKSIG
Thanks and apologies if I'm missing something obvious!,
-Dave
[1]
https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/

2023-06-08 01:16:01

- reply

📅 Original date posted:2022-10-29
📝 Original message:On 2022-10-26 13:52, Anthony Towns via bitcoin-dev wrote:
> The cutoff for that is probably something like "do 30% of listening
> nodes have a compatible policy"? If they do, then you'll have about a
> 95% chance of having at least one of your outbound peers accept your
> tx,
> just by random chance.
I think this might be understating the problem. A 95% chance of having
an outbound peer accept your tx conversely implies 1 in 20 payments will
fail to
propagate on their initial broadcast. That seems to me like an
unacceptably high failure rate both for the UX of regular payments and
for the safety of time-sensitive transactions like onchain HTLC
resolutions.
Additionally, the less reliable propagation is, the more reliably spy
nodes can assume the first IP address they received a transaction from
is the creator of that transaction.
I think those two problems combine in an especially unfortunate way for
lightweight clients. Lightweight clients wanting to find a peer who
supports a more permissive policy than most of the network and whose
client authors want to provide a good UX (or safety in the case of time
sensitive contract protocols like LN) will need to open large numbers of
connections, increasing their chance of connecting to a spy node which
will associate their IP address with their transaction, especially since
lightweight clients can't pretend to be relaying transactions for other
users. Some napkin math: there are about 250,000 transactions a day; if
we round that up to 100 million a year and assume we only want one
transaction per year to fail to initially propagate on a network where
30% of nodes have adopted a more permissive policy, lightweight clients
will need to connect to over 50 randomly selected nodes.[1] For a more
permissive policy only adopted by 10% of nodes, the lightweight client
needs to connect to almost 150 nodes.
This also implies that nodes adopting a more restrictive policy degrades
UX, safety, and privacy for users of transactions violating that policy.
For example, if 30% of nodes used Knots's -spkreuse configuration option
and about 50% of transactions reuse scriptPubKeys, then about 9
transactions a day wouldn't initially propagate (assuming 8 randomly
selected peers[2]) and lightweight clients who wanted 1-in-100-million
safety would need to connect to about 15 random nodes.
Towns's post to which I'm replying describes several alternative
approaches which mitigate the above problems, but he also documents that
they're not without tradeoffs.
-Dave
[1] (1-0.3)**50 * 100_000_000 =~ 1.8
[2] That assumes every transaction is sent to a different
randomly-selected set of peers, which isn't really the case. However,
one day $GIANT_EXCHANGE could suddenly be unable to broadcast hundreds
or
thousands of withdrawal transactions because all of its peers implement
a restrictive policy.

2023-06-08 01:15:01

- reply

📅 Original date posted:2022-10-23
📝 Original message:On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
> The biggest risk
> in accepting bitcoin payments is in fact not zeroconf risk (it's
> actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over
> time some transactions lose money to FX and others earn money - that
> evens out in the end. But if there is an _easily accessible in the
> wallet_ feature to "cancel transaction" that means it will eventually
> get systematically abused.
One way to address this risk is by turning it into a certainty. If the
price of BTC increases between when the invoice is generated and when a
transaction is included in a block, give the customer a future purchase
credit equal in value to the difference between the price they paid and
the value of the purchase at confirmation time. Now there's no benefit
to the customer from canceling their transaction.
Of course, this means that the merchant will always either break even or
lose money on the exchange rate part of the transaction and will need to
raise their prices accordingly. I can see how that would be unappealing
to implement, but it seems better to me to address the incentive
incompatibility you've raised rather than hope no large miners ever
start performing full RBF. Plus, maybe the future credit feature is
something customers would like: I know I've been sad several times when
the exchange rate changed significantly while I was waiting for one of
my transactions to confirm.
The above mitigation is also compatible with LN payments. For example,
a merchant today might issue an LN invoice that expires in 10 minutes.
The customer can wait for most of that time to elapse to see how the
exchange rate changes before deciding to pay, obtaining the same
American call option. If they are instead offered a future purchase
credit for any gains, the customer doesn't suffer any opportunity cost
by paying immediately. (With LN, it might be possible to have a better
UX for this by either refunding any excess or (if using something like
Original AMP or PTLCs) not claiming any parts of the payment which are
in excess.)
-Dave

2023-06-08 01:14:52

- reply

📅 Original date posted:2022-10-20
📝 Original message:On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
> bitcoin-dev wrote:
>> AJ previously wrote:
>> > presumably that makes your bitcoin
>> > payments break down as something like:
>> > 5% txs are on-chain and seem shady and are excluded from zeroconf
>> > 15% txs are lightning
>> > 20% txs are on-chain but signal rbf and are excluded from zeroconf
>> > 60% txs are on-chain and seem fine for zeroconf
>> Numbers are right. [...]
>
> [...]
>
> So the above suggests 25% of payments already get a sub-par experience
> [...]
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
Is it worth considering incremental steps between opt-in only (BIP125)
and replace anything full RBF? For example, in addition to opt-in RBF
rules, treat any transaction with a txid ending in `0x1` as replacable?
I assume 1/16th (6.25%) of transactions would match that pattern (some
of which already opt-in to RBF, so the net effect would be smaller).
This would have the following advantages:
1. We could see if miners are willing to enable unsignaled RBF at all
2. We could gather more evidence on how the change affects zeroconf
businesses and everyday users, hopefully without requiring they make
immediate and huge changes
3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding
their txids, at least until full RBF is accomplished
4. We can increase the percentage of transactions subject to unsignaled
RBF in later releases of Bitcoin Core, steadily moving the system
towards full RBF without any sudden leaps (assuming nobody builds a
successful relay and mining network with less restrictive replacement
rules)
I don't think this directly helps solve the problems with non-replacable
transactions suffered by contract protocols since any adversary can
opt-out of this scheme by grinding their txid, but I do think there's an
advantage in transitioning slowly when people are still depending on
previous behaviors.
Thanks,
-Dave

2023-06-08 01:14:17

- reply

📅 Original date posted:2022-10-07
📝 Original message:On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> Hello list,
>
> I'm Dario, from Muun wallet [...] we've been reviewing the latest
> bitcoin core release
> candidate [...] we understood we had at least a year from the initial
> opt-in deployment until opt-out was deployed, giving us enough time to
> adapt
> Muun to the new policies. However, when reviewing the 24.0 release
> candidate
> just a few days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.
Hi Dario,
I'm wondering if there's been some confusion. There are two RBF-related
items in the current release notes draft:[1]
1. "A new mempoolfullrbf option has been added, which enables the
mempool to accept transaction replacement without enforcing BIP125
replaceability signaling. (#25353)"
2. "The -walletrbf startup option will now default to true. The wallet
will now default to opt-in RBF on transactions that it creates.
(#25610)"
The first item (from PR #25353) does allow a transaction without a
BIP125 signal to be replaced, but this configuration option is set to
disabled by default.[2] There have been software forks of Bitcoin Core
since at least 2015 which have allowed replacement of non-signaling
transactions, so this option just makes that behavior a little bit more
accessible to users of Bitcoin Core. Some developers have announced
their intention to propose enabling this option by default in a future
release, which I think is the behavior you're concerned about, but
that's not planned for the release of 24.0 to the best of my knowledge.
The second item (from PR #25610) only affects Bitcoin Core's wallet, and
in particular transactions created with it through the RPC interface.
Those transactions will now default to signaling BIP125 replacability.
This option has been default false for many years for the RPC, but for
the GUI it's been default true since Bitcoin Core 0.16, released in
early 2018[3]. It's no different than another popular wallet beginning
to signal BIP125 support by default.
In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly
changes the current situation related to transaction replacability. All
it does is give Bitcoin Core RPC users by default the same settings long
used for GUI users and introduce an option that those who object to
non-signalled RBF will later be able to use to disable their relay of
non-signalled replacements.
Does the above information resolve your concerns?
Thanks,
-Dave
[1]
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft
[2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf
-mempoolfullrbf
Accept transaction replace-by-fee without requiring
replaceability
signaling (default: 0)
[3]
https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui

2023-06-08 01:14:04

- reply

📅 Original date posted:2022-10-02
📝 Original message:On 2022-09-29 05:39, Ruben Somsen via bitcoin-dev wrote:
> An alternative mitigation (more user friendly, but more implementation
> complexity) would be to require the sender to reveal their intended
> transaction to the server prior to receiving the address[^9]. This is
> not a privacy degradation, since the server could already learn this
> information regardless. If the transaction doesn't end up getting
> sent, any subsequent attempt to reuse one of the inputs should either
> be (temporarily) blacklisted or responded to with the same address
> that was given out earlier
> [...]
> [^9]: *This would essentially look like an incomplete but signed
> transaction where the output address is still missing.*
Hi Ruben,
Instead of maintaining a database of inputs that should be blocked or
mapped to addresses, have the spender submit to you (but not the
network) a valid transaction paying a placeholder address and in return
give them a guaranteed unique address. They can then broadcast a
transaction using the same inputs to pay the guaranteed unique address.
If you don't see that transaction within a reasonable amount of time,
broadcast the transaction paying the placeholder address. This makes it
cost the same to them whether they use the unique address or not. By
placeholder address, I mean an address of yours that's never received a
payment but which may have been provided in a previous invoice (e.g. to
prevent exceeding the gap limit).
In short, what I think I've described is the BIP78 payjoin protocol
without any payjoining going on (which is allowed by BIP78). BTCPay
already implements BIP78, as do several wallets, and I think it
satisfies all the design constraints you've described.
-Dave

2023-06-08 01:12:55

- reply

📅 Original date posted:2022-08-19
📝 Original message:On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
> Multiple parties could
> trustlessly collaborate to settle into a single CTV output using
> SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction
> similar to coinjoins.
Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that
any of the parties can subsequently RBF fee bump the transaction?
> Conceptually, CTV is the most parsimonious way to do such a scheme,
> since you can't really get smaller than a SHA256 commitment
What's the advantage of CTV here compared to presigned transactions? If
multiple parties need to interact to cooperatively sign a transaction,
no significant overhead is added by having them simultaneously sign a
second transaction that spends from the output of the first transaction.
Presigned transactions actually have two small benefits I can think of:
1. The payment from the first transaction (containing the spends from
the channel setup transactions) can be sent to a P2WPKH output, which is
actually smaller than a SHA256 commitment. Though this probably does
require an extra round of communication for commit-and-reveal to prevent
a collision attack on the P2WPKH address.[1]
2. Having the first transaction pay a either a P2WPKH or bech32m output
and the second transaction spend from that UTXO may blend in better with
other transactions, enhancing privacy. This advantage probably isn't
compatible with SH_ALL|SH_ACP, though, and it would require other
privacy upgrades to LN.
> direct-from-coinbase payouts seem like a
> desirable feature which avoids some trust in pools.
> [...]
> If the payout was instead a single OP_CTV output, an arbitrary number
> of pool participants could be paid out "atomically" within a single
> coinbase. One limitation is
> the size of the coinbase outputs owed to constituent miners; this
> limits the number of participants in the pool.
I'm confused by this. What is the size limitation on coinbase outputs,
how does it limit the number of participants in a pool, and how does CTV
fix that?
Thanks,
-Dave
[1]
https://bitcoinops.org/en/newsletters/2020/06/24/#reminder-about-collision-attack-risks-on-two-party-ecdsa

2023-06-08 01:12:11

- reply

📅 Original date posted:2022-07-29
📝 Original message:On 2022-07-26 02:45, Peter Todd via bitcoin-dev wrote:
> On Tue, Jul 26, 2022 at 01:56:05PM +0530, Aaradhya Chauhan via
> bitcoin-dev wrote:
>> [...] in its early days, 1 sat/vB was a good dust protection
>> measure. But now, I think it's a bit high [...] I think it can be done
>> easily [...]
>
> [...] lowering the dust limit now is a good way to ensure
> the entire ecosystem is ready to deal with those conditions.
I don't have anything new to add to the conversation at this time, but I
did want to suggest a clarification and summarize some previous
discussion that might be useful.
I think the phrasing by Aaradhya Chauhan and Peter Todd above are
conflating the minimum output amount policy ("dust limit") with the
minimum transaction relay feerate policy ("min tx relay fee"). Any
transaction with an output amount below a node's configured dust limit
(a few hundred sat by default) will not be relayed by that node no
matter how high of a feerate it pays. Any transaction with feerate
below a nodes's minimum relay feerate (1 sat/vbyte by default) will not
be relayed by that node even if the node has unused space in its mempool
and peers that use BIP133 feefilters to advertise that they would accept
low feerates.
Removing the dust limit was discussed extensively a year ago[1] with
additional follow-up discussion about eight months ago.[2]
Lowering the minimum relay feerate was seriously proposed in a patch to
Bitcoin Core four years ago[3] with additional related PRs being opened
to ease the change. Not all of the related PRs have been merged yet,
and the original PR was closed. I can't easily find some of the
discussions I remember related to that change, but IIRC part of the
challenge was that lower minimum relay fees reduce the cost of a variety
of DoS attacks which could impact BIP152 compact blocks and erlay
efficiency, could worsen transaction pinning, may increase IBD time due
to more block chain data, and have other adverse effects. Additionally,
we've found in the past that some people who build systems that take
advantage of low feerates become upset when feerates rise, sometimes
creating problems even for people who prepared for eventual feerate
rises.
Compared to the complexity of lowering the minimum feerate, the
challenges of preventing denial/degregation-of-service attacks, and
dealing with a fragmented userbase, the economic benefit of reducing the
feerates for the bottom of the mempool seems small---if we lower min
feerates to 1/10th their current values and that results in the
equivalent of an extra 10 blocks of transactions getting mined a day,
then users save a total of 0.09 BTC (~$1,800 USD) per day and miners
earn an extra 0.01 BTC ($200 USD) per day (assuming all other things
remain equal).[4]
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019635.html
[3] https://github.com/bitcoin/bitcoin/pull/13922
[4] The current min relay fee is 1 sat/vbyte. There are ~1 million
vbytes in a block that can be allocated to regular transactions. Ten
blocks at the current min relay fee would pay (10 * 1e6 / 1e8 = 0.1 BTC)
in fees. Ten blocks at 1/10 sat/vbyte would thus pay 0.01 BTC in fees,
which is $200 USD @ $20k/BTC. Thus users would save (0.1 - 0.01 = 0.09
BTC = $1,800 USD @ $20k/BTC).

2023-06-08 01:11:29

- reply

📅 Original date posted:2022-07-18
📝 Original message:On 2022-07-10 07:27, Peter Todd via bitcoin-dev wrote:
> The block subsidy directly ties miner revenue to the total value of
> Bitcoin:
> that's exactly how you want to incentivise a service that keeps Bitcoin
> secure.
I'm confused. I thought your argument in the OP of this thread was that
a perpetual block subsidy would *not* be tied to the total value of
bitcoin. It'd be tied to the total value of bitcoin *lost* each year on
average.
If so, would you then agree that the inability of a perpetual block
subsidy to directly tie miner revenue to the total value of Bitcoin
makes it not exactly how we want to incentivise a service that keeps
Bitcoin secure?
Thanks,
-Dave

2023-06-08 01:09:37

- reply

📅 Original date posted:2022-05-12
📝 Original message:On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
> We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
> the proposal) to the "state" input's script.
> This is used in the update transaction to set the upper bound on the
> final transaction weight.
> In this same input, for each contract participant, we also
> conditionally commit to the change output's scriptpubkey
> via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.
> This means any participant can send change back
> to themselves, but with a catch. Each change output script possibility
> in that state input also includes a 1 block
> CSV to avoid mempool spending to reintroduce pinning.
I like the idea! However, I'm not sure the `1 CSV` trick helps much.
Can't an attacker just submit to the mempool their other eltoo state
updates? For example, let's assume Bob and Mallory have a channel with
>25 updates and Mallory wants to prevent update[-1] from being committed onchain before its (H|P)TLC timeout. Mallory also has at least 25 unencumbered UTXOs, so she submits to the mempool update[0], update[1], update[...], update[24]---each of them with a different second input to pay fees.
If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
vbytes[1] and the default node relay/mempool policy of allowing a
transaction and up to 24 descendants remains, Mallory can pin the
unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
what she can pin under current mempool policies.
Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule
#3), and an RBF of update[24] will have its additional fees divided by
its size plus the 24,000 vbytes of update[1..24].
To me, that seems like your proposal makes escaping the pinning at most
75% cheaper than today. That's certainly an improvement---yay!---but
I'm not sure it eliminates the underlying concern. Also depending on
the mempool ancestor/descendant limits makes it harder to raise those
limits in the future, which is something I think we might want to do if
we can ensure raising them won't increase node memory/CPU DoS risk.
I'd love to hear that my analysis is missing something though!
Thanks!,
-Dave
[1] 1,000 vbytes per update seems like a reasonable value to me.
Obviously there's a tradeoff here: making it smaller limits the amount
of pinning possible (assuming mempool ancestor/descendant limits remain)
but also limits the number and complexity of inputs that may be added.
I don't think we want to discourage people too much from holding
bitcoins in deep taproot trees or sophisticated tapscripts.

2023-06-08 01:07:41

- reply

📅 Original date posted:2022-04-21
📝 Original message:On 21.04.2022 14:28, Anthony Towns wrote:
> But, if [it's true that "many [...] use cases [...] to use CTV for
> are very long term in nature"], that's presumably incompatible
> with any sort of sunset that's less than many decades away, so doesn't
> seem much better than just having it be available on a signet?
I fully acknowledge that a temporary test can't fully replicate a
permanent condition. That said, if people truly believe CTV vaults will
significantly enhance their security, wouldn't it be worth using them
for most of the deployment? Users would receive both years of added
security and the opportunity to convince other Bitcoiners to make CTV
permanent by demonstrating real-world usage.
> If sunsetting were a good idea, one way to think about implementing it
> might be to code it as:
>
> if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
> !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
> {
> EnforceFoo();
> }
Defining at the outset how we'll signal years later if we want to keep
the rules seems intelligent to me.
Thanks!,
-Dave

2023-06-08 01:07:37

- reply

📅 Original date posted:2022-04-21
📝 Original message:[Rearranging Matt's text in my reply so my nitpicks come last.]
On 21.04.2022 13:02, Matt Corallo wrote:
> I agree, there is no universal best, probably. But is there a concrete
> listing of a number of use-cases and the different weights of things,
> plus flexibility especially around forward-looking designs?
I'm sure we could make a nice list of covenant usecases, but I don't
know how we would assign reasonable objective weights to the different
things purely through group foresight. I know I'm skeptical about
congestion control and enthusiastic about joinpools---but I've talked to
developers I respect who've had the opposite opinions from me about
those things. The best way I know of to reconcile our differing
opinions is to see what real Bitcoin users actually pay for. But to do
that, I think they must have a way to use covenants in something like
the production environment.
> You're also writing off [...] a community of
> independent contributors who care about Bitcoin working together to
> make decisions on what is or isn't the "right way to go" [...]. Why are
> you
> suggesting its something that you "don't know how to do"?
You said we should use the best design. I said the different designs
optimize for different things, so it's unlikely that there's an
objective best. That implies to me that we either need to choose a
winner (yuck) or we need to implement more than one of the designs. In
either of those cases, choosing what to implement would benefit from
data about how much the thing will be used and how much users will pay
for it in fees.
> Again, my point *is not* "will people use CTV", I think they will. I
> think they would also use TLUV if that were activated for the exact
> same use-cases. I think they would also use CAT+CSFS if that were what
> was activated, again for the exact same use-cases. Given that, I'm not
> sure how your proposal teaches us anything at all, aside from "yes,
> there was demand for *some* kind of covenant".
I'm sorry if my OP was ambiguous about this, but my goal there was to
describe a general framework for activating temporary consensus changes
for the purpose of demonstrating demand for proposed features. I gave
CTV as an example for how the framework could be used, but we could use
the same framework to activate APO and TLUV (or IIDs and EVICT)---and
then we would see which of them people actually used. If there was
significant ongoing use of all three after 5 years, great! We keep them
all. If some of them went largely unused, we let the extra validation
rules expire and move on.
Alternatively, if we only enabled one covenant design (e.g. CTV), we
would still gain data about how it was used and we could see if some of
the alternative designs would've been more optimal for those
demonstrated uses.
My goal here is obtaining data from which we can make informed
decisions. A transitory soft fork is an extreme way to acquire that
data and I fully acknowledge it has several significant problems
(including those I listed in my OP). I'm hoping, though, that it's a
better solution than another activation battle, prolonged yelling on
this mailing list and elsewhere, or everyone just giving up and letting
Bitcoin ossify prematurely. Alternatively, I'm hoping one of the many
people on this list who is smarter than I am will think of another way
to obtain decisive data with less fuss.
> Again, you're writing off the real and nontrivial risk of doing a fork
> to begin with.
I agree this risk exists and it isn't my intention to write it off---my
OP did say "we [must be] absolutely convinced CTV will have no negative
effects on the holders or receivers of non-CTV coins." I haven't been
focusing on this in my replies because I think the other issues we've
been discussing are more significant. If we were to get everyone to
agree to do a transitory soft fork, I think the safety concerns related
to a CTV soft fork could be mitigated the same way we've mitigated them
for previous soft forks: heaps of code review/testing and making sure a
large part of the active community supports the change.
> You don't
> mention the lack of recursion in CTV vs CAT+CSFS
I mentioned recursion, or the lack thereof, in various proposals like
five times in this thread. :-)
Thanks again for your replies,
-Dave

2023-06-08 01:07:36

- reply

📅 Original date posted:2022-04-21
📝 Original message:On 21.04.2022 08:39, Matt Corallo wrote:
> We add things to Bitcoin because (a) there's some demonstrated
> use-cases and intent to use the change (which I think we definitely
> have for covenants, but which only barely, if at all, suggests
> favoring one covenant design over any other)
I'm unconvinced about CTV's use cases but others have made reasonable
claims that it will be used. We could argue about this indefinitely,
but I would love to give CTV proponents an opportunity to prove that a
significant number of people would use it.
> (b) because its
> generally considered aligned with Bitcoin's design and goals, based on
> developer and more broad community response
I think CTV fulfills this criteria. At least, I can't think of any way
BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
designs and goals.
> (c) because the
> technical folks who have/are wiling to spend time working on the
> specific design space think the concrete proposal is the best design
> we have
This is the criteria that most concerns me. What if there is no
universal best? For example, I mentioned in my previous email that I'm
a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
simplicity versus production flexibility. But one problem is that
spends using them would need to contain a lot of witness data. In my
mind, they're the best for experimentation and for proving the existence
of demand for more optimized constructions.
OP_TX or OP_TXHASH would likely offer almost as much simplicity and
flexibility but be more efficient onchain. Does that make them better
than OP_CAT+OP_CSFS? I don't know how to objectively answer that
question, and I don't feel comfortable with my subjective opinion of
CAT+CSFS being better than OP_TX.
APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
certain usecases (respectively: Eltoo, congestion control, and
joinpools), providing maximum onchain efficiency for those cases but
requiring contortions or larger witnesses to accomplish other covenant
usecases. Is their increased efficiency better than more general
constructions like CSFS or TX? Again, I don't know how to answer that
question objectively, although subjectively I'm ok with optimized
constructions for cases of proven demand.
> , and finally (d) because the implementation is well-reviewed
> and complete.
No comment here; I haven't followed CTV's review progress to know
whether I'd consider it well enough reviewed or not.
> I do not see how we can make an argument for any specific covenant
> under (c) here. We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".
I'm curious how we as a technical community will be able to determine
which is the best approach. Again, I like starting simple and general,
gathering real usage data, and then optimizing for demonstrated needs.
But the simplest and most general approaches seem to be too general for
some people (because they enable recursive covenants), seemingly forcing
us into looking only at application-optimized designs. In that case, I
think the main thing we want to know about these narrow proposals for
new applications is whether the applications and the proposed consensus
changes will actually receive significant use. For that, I think we
need some sort of test bed with real paying users, and ideally one that
is as similar to Bitcoin mainnet as possible.
> we
> cannot remove the validation code for something ever, really - you
> still want to be able to validate the historical chain
You and Jeremy both brought up this point. I understand it and I
should've addressed it better in my OP, but I'm of the opinion that
reverting to earlier consensus rules gives future developers the
*option* of dropping no-longer-used consensus code as a practical
simplification of the same type we've used on several occasions before,
and which is an optional default in newly started Bitcoin Core nodes for
over a decade now (i.e. skipping verification of old signatures). If
future devs *want* to maintain code from a set of temporary rules used
millions of blocks ago, that's great, but giving them the option to
forget about those rules eliminates one of my concerns about making
consensus changes without fully proven demand for that change.
I just wanted to mention the above in case this discussion comes back to
serious consideration of a transitory soft fork. For now, I think we
can table a debate over validating reverted rules and focus on how we'll
come to agreement that a particular covenant-related consensus change is
warranted.
Thanks for your thoughtful response,
-Dave

2023-06-08 01:07:35

- reply

📅 Original date posted:2022-04-21
📝 Original message:On 21.04.2022 04:58, Matt Corallo wrote:
> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to
>> evaluate later
>> consensus change proposals due to their interactions with CTV
>
> Also "is this even the way we should be going about covenants?"
I consider this to be a version of point 1b above. If we find a better
way for going about covenants, then we'll activate that and let CTV
automatically be retired at the end of its five years.
If you still think your point is separate from point 1b, I would
appreciate you helping me understand.
> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,
This is also my assessment: neither CTV nor any other proposal currently
has enough support to warrant a permanent change to the consensus rules.
My question to the list was whether we could use a transitory soft fork
as a method for collecting real-world usage data about proposals. E.g.,
a consensus change proposal could proceed along the following idealized
path:
- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin
similar to Bitcoin, or in Bitcoin via a transitory soft fork)
- Permanent consensus change
> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.
How should we think about changes to Bitcoin and maintaining its culture
of security and careful design? My post suggested a generalized way we
could evaluate proposed consensus changes for real-world demand,
allowing us to settle what I see as the most contended part of the CTV
proposal. That feels to me like legitimate engineering and social
consensus building. What would be your preferred alternatives?
(For the record, my preferred alternative for years has been to add the
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what
covenant-y things people build with them, and then consider proposals to
optimize the onchain usage of those covenant-y things. Alas, this seems
to fall afoul of the concerns held by some people about recursive
covenants.)
> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.
If the only choices are to support activation of BIP119 CTV at this time
or to reject it, I would currently side with rejection. But I would
prefer over both of those options to find a third way that doesn't
compromise safety or long-term maintainability and which gives us the
data about CTV (or other covenant-related constructions) to see whether
the concerns described above in 1a and 1b are actually non-issues.
I see one of those third ways as the testing on the CTV signet described
in a contemporaneous thread on this list.[1] Other third ways would be
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be
temporarily used on Bitcoin as proposed in this thread. Is there
interest in working on those alternatives, or is the only path forward
an argument over attempting activation of CTV?
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html

2023-06-08 01:07:32

- reply

📅 Original date posted:2022-04-20
📝 Original message:Hi all,
The main criticisms I'm aware of against CTV seem to be along the
following lines:
1. Usage, either:
a. It won't receive significant real-world usage, or
b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating extra
maintenance
burden, increasing security surface, and making it harder to evaluate
later
consensus change proposals due to their interactions with CTV
Could those concerns be mitigated by making CTV an automatically
reverting
consensus change with an option to renew? E.g., redefining OP_NOP4 as
OP_CTV
for five years from BIP119's activation date and then reverting to
OP_NOP4.
If, prior to the end of those five years, a second soft fork was
activated, it
could continue enforcing the CTV rules either for another five years or
permanently.
This would be similar in nature to the soft fork described in BIP50
where the
maximum block size was temporarily reduced to address the BDB locks
issue and
then allowed to return to its original value. In Script terms, any use
of
OP_CTV would effectively be:
OP_IF
<arguments> OP_CTV
OP_ELSE
<5 years after activation> OP_CLTV
OP_ENDIF
As long as we are absolutely convinced CTV will have no negative effects
on the
holders or receivers of non-CTV coins, I think an automatically
reverting soft
fork gives us some ability to experiment with new features without
committing
ourselves to live with them forever.
The main downsides I can see are:
1. It creates a big footgun. Anyone who uses CTV without adequately
preparing for
the reversion could easily lose their money.
2. Miners would be incentivized to censor spends of the reverting
opcode near its reversion date. E.g., if Alice receives 100 bitcoins
to a
script secured only by OP_CTV and attempts to spend them the day
before it
becomes OP_NOP4, miners might prefer to skip confirming that
transaction even
if it pays a high feerate in favor of spending her 100 bitcoins to
themselves
the next day after reversion.
The degree to which this is an issue will depend on the diversity of
hashrate and the willingness of any large percentage of hashrate to
deliberately reorg the chain to remove confirmed transactions. This
could be
mitigated by having OP_CTV change to OP_RETURN, destroying any
unspent CTV-only
coins so that any censoring miners only benefited from the (hopefully
slight)
decrease in bitcoin currency supply.
3. A bias towards keeping the change. Even if it turned out very few
people
really used CTV, I think there would be a bias at the end of five
years towards
"why not just keep it".
4. The drama doesn't end. Activating CTV now, or decisively not
activating it,
may bring to an end our frequent discussions about it (though I
wouldn't
count on that). An automatically reverting soft fork would probably
guarantee we'll have further consensus-level discussions about CTV in
the
future.
Thanks for reading. I'm curious to hear y'alls thoughts,
-Dave

2023-06-08 01:03:26

- reply

📅 Original date posted:2022-02-10
📝 Original message:On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Whether [recursive covenants] is an issue or not precluding this sort
> of design or not, I defer to others.
For reference, I believe the last time the merits of allowing recursive
covenants was discussed at length on this list[1], not a single person
replied to say that they were opposed to the idea.
I would like to suggest that anyone opposed to recursive covenants speak
for themselves (if any intelligent such people exist). Citing the risk
of recursive covenants without presenting a credible argument for the
source of that risk feels to me like (at best) stop energy[2] and (at
worst) FUD.
-Dave
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
[2] http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
(thanks to AJ who told me about stop energy one time when I was
producing it)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/c471f94d/attachment.sig>

2023-06-08 01:00:38

- reply

📅 Original date posted:2021-11-21
📝 Original message:On Wed, Nov 17, 2021 at 08:05:55PM +0000, n1ms0s via bitcoin-dev wrote:
> This seems to be the case. I saw your reply on Bitcoin StackExchange
> as well. In bitcoinj I just made it so the client only connects to
> nodes with at least protocol version 70016. Seems to work well.
Hi,
This is a clever solution, but when I looked into this I found that P2P
protocol version 70016 was introduced in Bitcoin Core version 0.21.0[1].
This release will not ever relay taproot spends because it doesn't
contain taproot activation parameters[2]. So this heuristic is
imperfect: it only works when it happens to connect to the 0.21.1 and
22.0 versions of Bitcoin Core (or compatible nodes) which were
programmed to begin relaying taproot spends starting one block before
activation.
Can anyone recommend a better heuristic lite wallets can use to ensure
they're connecting to a taproot-activated node? (If not, maybe this is
something we want nodes to advertise during activation of future
protocol extensions.)
Thanks,
-Dave
[1] https://github.com/bitcoin/bitcoin/commit/ccef10261efc235c8fcc8aad54556615b0cc23be
https://bitcoincore.org/en/releases/0.21.0/
[2] https://github.com/bitcoin/bitcoin/pull/20165
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211121/d3dda5b4/attachment.sig>

2023-06-08 00:58:40

- reply

📅 Original date posted:2021-09-05
📝 Original message:On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> Hi Bitcoin Devs,
>
> I recently noticed a flaw in the Sequence lock implementation with respect
> to upgradability. It might be the case that this is protected against by
> some transaction level policy (didn't see any in policy.cpp, but if not,
> I've put up a blogpost explaining the defect and patching it
> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
deploy any new nSequence rules with tx.version>2?
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/2f55d419/attachment.sig>

2023-06-08 00:58:28

- reply

📅 Original date posted:2021-09-06
📝 Original message:On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote:
> How would you compare this to Stratum v2?
Specifically, I'd be interested in learning what advantages this has
over a centralized mining pool using BetterHash or StratumV2 with
payouts made via LN (perhaps immediately after each submitted share is
validated).
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/a2d81ede/attachment.sig>

2023-06-08 00:58:28

- reply

📅 Original date posted:2021-09-06
📝 Original message:On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote:
> It doesn’t centralize payment, which ultimately controls transaction selection (censorship).
Yeah, but if you get paid after each share via LN and you can switch
pools instantly, then the worst case with centralized pools is that
you don't get paid for one share. If the hasher sets their share
difficulty low enough, that shouldn't be a big deal.
I'm interested in whether braidpool offers any significant benefits over
an idealized version of centralized mining with independent transaction
selection.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/26c8c9d4/attachment-0001.sig>

2023-06-08 00:57:57

- reply

📅 Original date posted:2021-08-10
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210809/24595273/attachment-0001.sig>

2023-06-08 00:57:52

- reply

📅 Original date posted:2021-08-08
📝 Original message:On Sun, Aug 08, 2021 at 11:52:55AM -0700, Jeremy wrote:
> We should remove the dust limit from Bitcoin. Five reasons:
Jeremy knows this, but to be clear for other readers, the dust limit is
a policy in Bitcoin Core (and other software) where it refuses by
default to relay or mine transactions with outputs below a certain
amount. If nodes or miners running with non-default policy choose to
relay or mine those transactions, they are not penalized (not directly,
at least; there's BIP152 to consider).
Question for Jeremy: would you also allow zero-value outputs? Or would
you just move the dust limit down to a fixed 1-sat?
I think the dust limit is worth keeping:
> 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?
> 2) dust outputs can be used in various authentication/delegation smart
> contracts
All of which can also use amounts that are economically rational to
spend on their own. If you're gonna use the chain for something besides
value transfer, and you're already wiling to pay X in fees per onchain
use, why is it not reasonable for us to ask you to put up something on
the order of X as a bond that you'll actually clean up your mess when
you're no longer interested in your thing?
> 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
Nope, nothing is forced. Any LN node can simply refuse to accept/route
HTLCs below the dust limit.
> which has implications
> (AFAIU) for the regulatory classification of channels in various
> jurisdictions
Sucks for the people living there. They should change their laws. If
they can't do that, they should change their LN node policies not to
route uneconomic HTLCs. We shouldn't make Bitcoin worse to make
complying with regulations easier.
I also doubt your proposed solution fixes the problem. Any LN node that
accepts an uneconomic HTLC cannot recover that value, so the money is
lost either way. Any sane regulation would treat losing value to
transaction fees the same as losing value to uneconomical conditions.
Finally, if LN nodes start polluting the UTXO set with no economic way
to clean up their mess, I think that's going to cause tension between
full node operators and LN node operators.
> agnostic treatment of fund transfers would simplify this
> (like getting a 0.01 cent dividend check in the mail)
I'm not sure I understand this point. It sounds to me like you're
comparing receiving an uneconomic output to receiving a check that isn't
worth the time to cash. But the costs of checks are borne only by the
people who send, receive, and process them. The costs of uneconomic
outputs polluting the UTXO set are borne by every full node forever (or
for every archival full node forever if non-archival nodes end up using
something like utreexo).
> 4) thinly divisible colored coin protocols might make use of sats as value
> markers for transactions.
I'm not exactly sure what you're talking about, but if Alice wants to
communicate the number n onchain, she can do:
if n < dust:
nSequence = 0x0000 + n # should probably check endianess
else:
nValue = n
There's at least 15 bits of nSequence currently without consensus or
policy meaning, and the dust limits are currently in the hundreds of
sat, so there's plenty of space.
Alice could probably also communicate the same thing by grinding her
output script's hash or pubkey; again, with dust limits just being
hundreds of sats, that's not too much grinding.
> 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.
I haven't looked since they upgraded to bulletproofs, but ISTR the
original CT implementation leaked the most significant digits or
something (that kept down the byte size of the proofs), so maybe it was
already possible to know what was certainly not dust and what might be
dust.
In short, it's my opinion that the dust limit is not creating any real
problems, so it should be kept for its contribution to keeping full
nodes faster, cheaper, and more efficient.
-Dave
P.S. As I prepared to send this, Matt's email arrived about "If it
weren't for the implications in changing standardness here, I think we
should consider increasing the dust limit instead." I'm in agreement
with both parts of that statement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210808/3feb232d/attachment.sig>

2023-06-08 00:57:08

- reply

📅 Original date posted:2021-07-25
📝 Original message:On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote:
> find the median fee-rate for each block and store that, then calculate
> the average of those stored per-block median numbers.
One datapoint per block seems fine to me and it works much nicer with
pruned nodes.
> So the only situations where miners would gain something
> from raising the fee rate is for griefing situations, which should be so
> rare as to be completely insignificant to miners.
I don't believe the problem scope can be reduced this way. Although we
we often look at miners as separate from users, it's important to
remember that every miner is also a user of Bitcoin and ever user of
Bitcoin may also someday be a miner. Users may also employ miners
directly via out-of-band payments.
In your usecase of vaults, we can imagine Bob is attempting to store
100,000 BTC. He designs his vault to allow spending on fees up to 10x
the 3,000 block median fee. Mallory steals Bob's encumbered spending
key. Mallory could immediately go to a miner and offer them a 50/50
split on the 10x fees over the median (~10,000 sat?), or Mallory could
take a bit more time and work with a cartel of miners to raise the
median over a period of three weeks (3k blocks) to 10,000
BTC/transaction, allowing them to take all of Bob's coins in fees.
> if OP_CD allowed spending the entire output as a fee then it wouldn't
> be successful in constraining the destination to the listed addresses.
The alternative is to never allow OP_CD to spend any of the UTXOs it
encumbers to fees, requiring all fees be paid via another mechanism.
Since satisfactory designs are going to provide those other mechanisms
anyway, it seems to me that there's no need for OP_CD to manage fees.
That said, I don't have a real strong opinion here.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210725/b442f887/attachment.sig>

2023-06-08 00:57:06

- reply

📅 Original date posted:2021-07-25
📝 Original message:On Tue, Jul 20, 2021 at 07:44:19PM +0000, Michael Flaxman via bitcoin-dev wrote:
> I've been working on ways to prevent privacy leaks in multisig
> quorums, and have come up with a creative use of BIP32 paths.
It seems to me like it would be rare for an attacker to obtain a private
BIP32 seed but not simultaneously learn what HD paths it's being used with.
I assume basically everyone is storing their descriptors (or descriptor
equivalents) alongside their seeds; doing so helps ensure a robust
recovery.
However, to the degree that privacy from seed thieves is a problem we
want to solve, I think it's largely fixed by using taproot with
multisignatures and threshold signatures. As long as participants
aren't reusing the same keys in different contexts, it shouldn't be
possible for a third party who doesn't know all involved pubkeys to
determine that any particular aggregated pubkey contained material from
a certain base pubkey.
I would suggest that it's probably more beneficial for wallet authors to
work on implementing support for taproot and MuSig or MuSig2 than
support for this scheme, although maybe I'm misunderstanding this
scheme's motivation.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210724/8873de50/attachment.sig>

2023-06-08 00:56:21

- reply

📅 Original date posted:2021-07-04
📝 Original message:On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
> However, I think the broader community is unconvinced by the cost benefit
> of arbitrary covenants. See
> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
> as a recent example. Therefore as a critical part of building consensus on
> various techniques I've worked to emphasize that specific additions do not
> entail risk of accidentally introducing more than was bargained for to
> respect the concerns of others.
Respecting the concerns of others doesn't require lobotomizing useful
tools. Being respectful can also be accomplished by politely showing
that their concerns are unfounded (or at least less severe than they
thought). This is almost always the better course IMO---it takes much
more effort to satisfy additional engineering constraints (and prove to
reviewers that you've done so!) than it does to simply discuss those
concerns with reasonable stakeholders. As a demonstration, let's look
at the concerns from Shinobi's post linked above:
They seem to be worried that some Bitcoin users will choose to accept
coins that can't subsequently be fungibily mixed with other bitcoins.
But that's already been the case for a decade: users can accept altcoins
that are non-fungible with bitcoins.
They talk about covenants where spending is controlled by governments,
but that seems to me exactly like China's CBDC trial.
They talk about exchanges depositing users' BTC into a covenant, but
that's just a variation on the classic not-your-keys-not-your-bitcoins
problem. For all you know, your local exchange is keeping most of its
BTC balance commitments in ETH or USDT.
To me, it seems like the worst-case problems Shinobi describes with
covenants are some of the same problems that already exist with
altcoins. I don't see how recursive covenants could make any of those
problems worse, and so I don't see any point in limiting Bitcoin's
flexibility to avoid those problems when there are so many interesting
and useful things that unlimited covenants could do.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210704/141168f5/attachment.sig>

2023-06-08 00:56:20

- reply

📅 Original date posted:2021-07-03
📝 Original message:On Sat, Jul 03, 2021 at 09:31:57AM -0700, Jeremy via bitcoin-dev wrote:
> Note that with *just* CheckSigFromStack, while you can do some very
> valuable use cases, but without OP_CAT it does not enable sophisticated
> covenants
Do you have concerns about sophisticated covenants, and if so, would you
mind describing them? Your BIP119 CTV also mentions[1] being designed
to avoid sophisticated covenants. If this is some sort of design
principle, I'd like to understand the logic behind it.
I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
but it seems artificially limited without OP_CAT. (I also stand by my
answer on that survey of believing there's a deep lack of developer
interest in CSFS at the moment. But, if you'd like to tilt at that
windmill, I won't stop you.)
-Dave
[1] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#design-tradeoffs-and-risks
[2] https://twitter.com/zndtoshi/status/1405235814712422402
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/0e0be72f/attachment.sig>

2023-06-08 00:56:01

- reply

📅 Original date posted:2021-07-03
📝 Original message:On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> There is a downside to using "h"/"H" from a UX perspective - taking up more
> space
Is this a serious concern of yours? An apostrophe is 1/2 en; an "h" is
1 en; the following descriptor contains three hardened derivations in 149
characters; assuming the average non-'/h character width is 1.5 en, the
difference between 207 en and 208.5 en is barely more than half a
percent.
pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)#ml40v0wf
Here's a direct visual comparison: https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80
> appearing as alphanumeric characters similar to the path numbers
First, I think you'd have to be using an awful font to confuse "h" with
any arabic numeral. Second, avoiding transcription errors is exactly
why descriptors now have checksums.
> they make derivation paths and descriptors more difficult to read.
The example descriptor pasted above looks equally (un)readable to me
whether it uses ' or h.
> Also, although not as important, less efficient when making metal
> backups.
I think many metal backup schemes are using stamps or punch grids that
are fixed-width in nature, so there's no difference either way. (And
you can argue that h is better since it's part of both the base58check
and bech32 character sets, so you already need a stamp or a grid row for
it---but ' is otherwise unused, so a stamp or grid row for it would be
special).
But even if people are manually etching descriptors into metal, we're
back to the original point where we're looking at something like a 0.7%
difference in "efficiency".
By comparison, the Bitcoin Core issue I cited in my earlier post
contains several examples of actual users needing technical support
because they tried to use '-containing descriptors in a bourne-style
shell. (And I've personally lost time to that class of problems.) In
the worst case, a shell-quoting accident can cause loss of money by
sending bitcoins to the descriptor for a key your hardware signing
device won't sign for. I think these problems are much more serious
than using a tiny bit of extra space in a GUI or on a physical backup
medium.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210703/ac399f1f/attachment-0001.sig>

2023-06-08 00:56:00

- reply

📅 Original date posted:2021-07-03
📝 Original message:On Tue, Jun 29, 2021 at 09:14:39PM +0000, Andrew Chow via bitcoin-dev wrote:
> *** Optionally followed by a single <tt>/*</tt> or <tt>/*'</tt> final
> step to denote all direct unhardened or hardened children.
>
> [...]
>
> In the above specification, the hardened indicator <tt>'</tt> may be
> replaced with alternative hardnened indicators of <tt>h</tt> or <tt>H</tt>.
Is there any chance we can take this opportunity to make "h"/"H" the
preferred aliases? Using "'" in bourne-style shells is very
annoying[1], and I suspect it's also creating unnecessary complications
elsewhere.
Alternatives:
- Completely kill "'" (I'd prefer this, but I realize it's complicated
with descriptors already being used widely). If "h"/"H" are made the
preferred aliases, maybe it'd be enough to make implementing "'" a
SHOULD rather than a MUST; this would push implementations towards
displaying descriptors using the h versions for maximum compatibility.
- Calculate the checksum over s/(h|H)/'/ (again, I know that's
complicated with descriptors already widely used)
Thanks,
-Dave
[1] https://github.com/bitcoin/bitcoin/issues/15740#issuecomment-695815432
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210702/ea8e1323/attachment.sig>

2023-06-08 00:52:10

- reply

📅 Original date posted:2021-04-26
📝 Original message:On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
> In general, I think its time we all agree the BIP process has simply failed
> and move on. Luckily its not really all that critical and proposed protocol
> documents can be placed nearly anywhere with the same effect.
I recommend:
1. We add additional BIP editors, starting with Kalle Alm (if there are
no continuing significant objections).
2. We seek Luke Dashjr's resignation as BIPs editor.
3. We begin treating protocol documents outside the BIPs repository as
first-class BIP documentation.
The first recommendation permits continued maintenance of existing BIPs
plus gives the additional maintainers an opportunity to rebuild the
credibility of the repository.
The second recommendation addresses the dissatisfaction of many BIP
authors and potential authors with the current editor, which I think
will discourage many of them from making additional significant
contributions to the repository. It also seems to me to be a better use
of Luke's talents and interests for him to focus on protocol research
and review rather than procedurally checking whether a bunch of
documents are well formed.
The third recommendation provides an escape hatch for anyone, such as
Matt, who currently thinks the process has failed, or for anyone who
comes to that same conclusion in the future under a different editing
team. My specific recommendations there are:
a. Anyone writing protocol documentation in the spirit of the BIP
process can post their idea to this mailing list like we've always
done and, when they've finished collecting initial feedback, they can
assign themselves a unique decentralized identifier starting with
"bip-". They may also define a shorter alias that they encourage
people to use in cases where the correct document can be inferred
from context. E.g.,
bip-wuille-taproot (bip-taproot)
bip-towns-versionbits-min-activation-height (bip-vbmah)
bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
b. The author then publishes the document to any place they'd like, although
they are strongly encouraged to make any document source available
under an open license to ensure others can create their own
modifications.
c. Implementations of BIPs, whether original repository BIPs or
decentralized BIPs, link to the BIPs they implement to ensure
researchers and developers can find the relevant protocol
documentation. E.g.,
https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
(It may also be advisable for implementations to mirror copies of
the BIPs they implement so later modifications to the document
don't confuse anyone. For this reason, extremely liberal
licensing of BIP documents is encouraged.)
d. To help maintain quality and consistency between documentation, the
BIP editors provide a BIP document template, guidelines similar to
the existing BIP2, and an easy-to-run format linter.
I think this decentralized BIPs alternative also helps address some
longstanding problems with the BIPs system: that many casual Bitcoin
users and developers think of documents in the BIPs repo as
authoritative and that there are some development teams (such as for LN)
that have already abandoned the BIPs process because, in part, they want
complete control over their own documentation.
The recommendations above were developed based on conversations I had
with a few stakeholders in the BIPs process, but I did not attempt a
comprehensive survey and I certainly don't claim to speak for anyone
else. I hope the recommendations are satisfactory and I look forward to
your feedback.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210426/2c57cc4a/attachment-0001.sig>

2023-06-08 00:52:06

- reply

📅 Original date posted:2021-04-25
📝 Original message:On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via bitcoin-dev wrote:
> I am opposed to the addition of Kalle Alm at this time. Those who
> believe [this] will resolve the situation [...] re: PR1104 are
> mistaken.
PR1104 has been merged. Do you continue to oppose the addition?
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210425/80fd21d6/attachment.sig>

2023-06-08 00:51:56

- reply

📅 Original date posted:2021-04-24
📝 Original message:On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As in
> Script can represent things we know nothing about.
I guess I still don't understand your concern, then. If script can
represent things we know nothing about, then script commitments such as
P2SH, P2WSH, and P2TR also represent things we know nothing about. All
you know is what container format they used. For P2PK, bare multisig,
OP_RETURN, and other direct uses of scriptPubKey, that container format
is "bare" (or whatever you want to call it).
> Btw: According to... Oh wait... You?
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
> the max size is 10k bytes.
I'm not sure what I knew at the time I wrote that answer, but the 10,000
byte limit is only applied when EvalScript is run, which only happens
when the output is being spent. I've appended to this email a
demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
999,000 bytes but ran into problems with bash's maximum command line
length limit). I've updated the answer to hopefully make it more
correct.
> Is it possible/easy to, say, using bech32m make an inappropriate message in
> the address? You'd have to write the message, then see what it decodes to
> without checking, and then re encode? I guess this is worse than hex?
If someone wants to abuse bech32m, I suspect they'll do it the same way
people have abused base58check[1], by using the address format's
alphabet directly. E.g., you compose your message using only
the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
the appropriate checksum.
[1] https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes
> But it seems this is a general thing... If you wanted an inappropriate
> message you could therefore just use bech32m addressed outputs.
Yes, and people have done that with base58check. IsStandard OP_RETURN
attempts to minimize that abuse by being cheaper in two ways:
1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
think) for OP_RETURN versus 40 bytes for a BIP141 payload.
Maximizing payload size better amortizes the overhead cost of the
containing transaction and the output's nValue field.
2. Exemption from the dust limit. If you use a currently defined
address type, the nValue needs to pay at least a few thousand nBTC
(few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC. For
OP_RETURN, the nValue can be 0, so there's no additional cost beyond
normal transaction relay fees.
Although someone creating an OP_RETURN up to ~1 MB with miner support
can bypass the dust limit, the efficiency advantage remains no matter
what.
> One of the nice things is that the current psbt interface uses a blind
> union type whereby the entires in an array are either [address, amount] or
> ["data", hex]. Having an address type would allow more uniform handling,
> which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses
> a hashmap of address to amount so without a patch you can't create op
> returns).
I don't particularly care how the data in PSBTs are structured. My mild
opposition was to adding code to the wallet that exposes everyday users
to OP_RETURN addresses.
> I would much prefer to not have to do this in a custom way, as opposed
> to a way which is defined in a standard manner across all software
> (after all, that's the point of standards).
I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
want to make sure this isn't underwhelmingly motivated or will lead to a
resurgence of block chain graffiti.
-Dave
## Creating an 11,000 byte OP_RETURN
$ bitcoind -daemon -regtest -acceptnonstdtxn
Bitcoin Core starting
$ bitcoin-cli -regtest -generate 101
{
"address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
"blocks": [
[...]
}
$ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000 count=11 | xxd -g0 -p | tr -d '\n' )'"}]'
11+0 records in
11+0 records out
11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s
{
"txid": "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51",
"complete": true
}
$ bitcoin-cli -regtest getrawmempool
[
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
]
$ bitcoin-cli -regtest -generate 1
{
"address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh",
"blocks": [
"2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b"
]
}
$bitcoin-cli -regtest getblock 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq .tx[1].txid
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210424/a3d85f0a/attachment.sig>

2023-06-08 00:51:55

- reply

📅 Original date posted:2021-04-23
📝 Original message:On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
> Script is technically "too wide" a type as what I really want is to
> only return coins with known output types.
I don't understand this concern. If script is too wide a type, then
OP_RETURN being a scriptPubKey of arbitrary length up to almost a
million bytes is also going to be too wide, right?
> 1) Should it be human readable & checksummed or encoded?
It should absolutely not be human readable in the sense of being
meaningful to humans. We've seen in the past that tools and sites that
display OP_RETURN data as ASCII encourage people to put text in the
block chain that is offensive and illegal. This puts people running
nodes at risk of social and legal intervention. Bitcoin's
premissionless nature means we can't stop people from creating such
problems, but we can lower the risk by having our tools default to
meaningless representations of OP_RETURN data.
The best advice I've seen is to display OP_RETURN data in hex. It's
still possible to say things like "dead beef" with that, but significant
abuse is hard. This will, of course, make even 80 byte OP_RETURN
"addresses" very long.
> 2) Should it have a fixed length of max 40-80 bytes or should we support
> arbitrary length strings?
If it doesn't support the fell range, somebody's just going to complain
later and there will have to be a v2 address.
> 3) Should it be possible (i.e., from core) to pay into such an OP_RETURN or
> should we categorize OP_RETURNS as a non-payable address type (and just use
> it for parsing blockdata)
I don't think including arbitrary data in the block chain is something
that's currently useful for typical end users, and applications that
want to use OP_RETURN with Bitcoin Core can already call
create(psbt|rawtransaction) with the `data` field, so I'd be mildly
opposed in including such a feature in Bitcoin Core's wallet. If at
least a few other wallets add the feature to pay OP_RETURN "addresses"
and it seems popular, then I'm wrong and so I would probably then change
my position.
Regarding "parsing block data", I don't think there's any need to change
Bitcoin Core's current representation of OP_RETURN outputs (which is
just showing the hex-encoded script in RPC output). For any program
needing OP_RETURN output, hex format is going to be a the next best
thing to getting it in raw binary. Any other address format is going to
be equal or more work.
Additionally, as mentioned in the other thread about OP_RETURN this
week, increasing transaction fees should increasingly push uses of
OP_RETURN off the network or into more efficient constructions, so it
doesn't seem warranted to me to spend a lot of time trying to optimize
how we use it when we'll be using it less and less over time.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/9b78956c/attachment.sig>

2023-06-08 00:51:32

- reply

📅 Original date posted:2021-04-08
📝 Original message:On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> So the latest circus act is apparently a technical decision made by a
> coin toss [organized by] Jeremy Rubin
Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
and is the same method I've been using in Bitcoin-related discussions
for over seven years[3] to help people transition from ancillary arguments
back to working on the things they really think are important.
I proposed the coin toss because I understood that both the MTP and the
height approaches required tradeoffs that were, to a certain degree,
unresolvable to the best of our current knowledge. MTP is harder to
analyze for unexpected edge cases; heights would create extra work for
seasoned developers working on post-taproot soft forks. MTP would
require developers of currently-planned UASF software either do extra
work or wait to release their software; heights don't guarantee a
minimum amount of time for a large number of economic full nodes to
upgrade.
Different people gave different weights to the different tradeoffs. In
cases like this where there's no known way to eliminate the tradeoffs
and no way to objectively rank them, I think it's better to begin
working on something concrete than it is to try to persuade everyone to
adopt the same subjective ranking of the tradeoffs---or, as the IETF
published in RFC7282:
"There are times where the result of [an informal open-ended
conversation] is a pretty even split. In practical terms, that
means it doesn't matter where the chair starts the discussion. And
in fact, we've had working groups where a coin flip decided which
proposal to start with. That doesn't mean that the coin flip
determined the outcome; if a fatal technical flaw was found in the
solution that won the coin flip, it is still incumbent upon the
group to address the issue raised or abandon that solution and find
another. Rough consensus on the technical points, in the end, is
always required. Any way to find a place to start, be it the hum or
the coin flip, is only getting to the beginning of the discussion,
not the end."
As Jeremy wrote, in this occassion, we didn't actually need the coin
toss. The authors of the two PRs we were considering found a compromise
solution that seems to be good enough for both of them and which so far
seems to be good enough for the handful of people who agreed to the coin
toss (plus, it seems, several others who didn't agree to the toss).
In short, I think the coin toss was a good attempt. Although we didn't
use its results this time, I think it's something we should keep in our
toolkit for the future when a group of people want to coordinate their
work on getting *a* solution released, even in cases where they don't
necessarily start out in agreement about which solution is best.
> I dread to think what individuals and businesses all over the world
> who have plans to utilize and build on Taproot are making of all of
> this.
Geeks arguing over minutia is a well established stereotype. That we've
conformed to that stereotype in this case is not great---but I don't
think it does us any significant reputational harm. I hope those
individuals and businesses awaiting taproot are discerning enough to
realize that the method we use to activate taproot has nothing to do
with taproot itself. I hope they realize that it remains the case that
there is nearly universal support for taproot from every entity that has
so far commented on it.
Hopefully we've made progress on Speedy Trial this week, that progress
will continue and we'll be able to release activation-ready software
soon, miners will be willing to signal for taproot, and we'll soon be
able to end this chapter in Bitcoin's storied history of soft fork
activations.[4] (But I look forward to continued discussion about
better activation mechanisms for the future---if taproot locks in
quickly, I'd love to see human consensus form around a follow-up
deployment even before taproot reaches activation.)
Respectfully,
-Dave
[1] http://gnusha.org/taproot-activation/2021-04-04.log "<harding> [...]
If that's not our goal and we just want to give miners a chance to
activate taproot as soon as possible (which was certainly my original
objective in supporting ST), I'm personally happy with either MTP or
heights, and I'd be willing to join others in putting my effort behind
just one of them based on fair random chance."
[2] http://gnusha.org/taproot-activation/2021-04-04.log "18:09 <
harding> e.g.: bitcoin-cli getblockhash 123456 | cut -b64 | grep -q
'[02468ace]' && echo MTP || echo height"
[3] E.g.,
https://github.com/bitcoin-dot-org/Bitcoin.org/pull/589#discussion_r18314009
and https://github.com/bitcoin-dot-org/Bitcoin.org/pull/566#issuecomment-56281595
[4] https://bitcoinops.org/en/topics/soft-fork-activation/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210408/4ab23028/attachment.sig>

2023-06-08 00:51:14

- reply

📅 Original date posted:2021-04-06
📝 Original message:(Replies to multiple emails)
On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote:
> It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's
> "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016))
> minutes".
Ah, drat, I forgot about that. Thank you for correcting my oversight!
> That doesn't seem like a particularly important design goal to me? Having
> a last minute two week delay seems easy to deal with
From my perspective, that of a person focused on communicating
information that affects Bitcoin users and recommending infrastructure
adjustments that should be made to accomodate those changes, I'd find
having a predictable activation date to be of significant benefit.
Given that, an activation scheme that could provide a tight timeline
(only delayable, not accellerable, by miner shenanegeans) would be
something I'd consider an advantage of that method.
That said, it's probably not worth making the activation state machine
more complicated for when the simplicity of the machine for height-based
activations is it's chief touted benefit.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/6f9d5311/attachment.sig>

2023-06-08 00:51:12

- reply

📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev wrote:
> The other relevant value of giving enough time for users to upgrade is not
> very sensitive. It's not like 180 days is magic number that going over is
> safe and going below is unsafe.
I don't think it's the 180 days value that's important but the deadline
to upgrade before taproot activates. With heights, some people will be
conservative and say:
You need to upgrade by $( date -d "66 days" )
Some people will just assume 10 minutes and say:
You need to upgrade by $( date -d "$((10 * 2016 * 13)) minutes" )
Some people might assume 9 minutes, which I think is roughly our
historic average:
You need to upgrade by $( date -d "$((9 * 2016 * 13)) minutes" )
As a few weeks pass and the number of blocks left until activation
decreases, it's likely everyone will be saying slightly different dates.
Basically, it'll be like a few months before the recent halving where
you could go to different sites that would give you wildly different
estimates---several of them claiming to be better than the others
because they factored in ____.
We're stuck with that for halvings, but I think coordinating human
actions around heights creates unnecessary confusion.
Using Towns's updated MTP doesn't eliminate this problem, but it reduces
it significantly, especially early in the process. Now conservative
estimators can say:
You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
Ten minute estimators can say:
You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes" )
And nine minute estimators can say:
You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((9 * 2016)) minutes" )
Those predictions are unlikely to change until shortly before the
lockin period.
I think those dates being much closer together (within 3 days) and
static for several months makes it much easier to communicate to users
(including organizations) the date by which they should upgrade if they
want to help enforce the soft fork's new rules.
As a side advantage, it also makes it easier to plan activation parties,
which is something I think we'll especially want after we finally start
doing something useful with the bikeshed we repainted so many times. :-)
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210406/e48fbe57/attachment.sig>

2023-06-07 20:31:10

- reply

2023-06-07 20:30:56

- reply

📅 Original date posted:2021-03-15
📝 Original message:On Mon, Mar 15, 2021 at 09:48:15PM +0000, Luke Dashjr via bitcoin-dev wrote:
> Note that in all circumstances, Bitcoin is endangered when QC becomes
> a reality [...] it could very well become an unrecoverable situation
> if QC go online prior to having a full quantum-safe solution.
The main concern seems to be someone developing, in secret, a quantum
computer with enough capacity to compromise millions of keys and then
deciding to use the most powerful and (probably) expensive computer ever
developed to steal coins that will almost immediately lose most or all
of their value.
That's certainly a threat we should consider, but like other "movie
plot" threats, I think we should weigh its unlikeliness in comparison
to the people who are losing smaller amounts of money on a regular basis
right now because we don't already have taproot---people who don't use
multisig, or contracts with threshold reduction timeout clauses, or
certain types of covenants because the contingencies these types of
scripts protect against come at too great a cost in fees for the typical
case where no contingencies are needed.
We have many ideas about how to mitigate the risk of effective quantum
computing attacks, from emergency protection to long-term solutions, so
it seems to me that the real risk in the movie plot scenario comes
entirely from *secret advances* in quantum computing. Other similar
risks for Bitcoin exist, such as secret discoveries about how to
compromise the hash functions Bitcoin depends on. One way to help
control those risks is to pay a public bounty to anyone who provably and
publicly discloses the secret advance (ideally while allowing the leaker
to remain anonymous). Several years ago, Peter Todd created a series of
Bitcoin addresses that does exactly that.[1]
For example, if you pay 35Snmmy3uhaer2gTboc81ayCip4m9DT4ko, then
anyone[2] who can prove a collision attack against Bitcoin's primary
hash function, SHA256, will be able to claim the bitcoins you and other
people sent to that address. Their claim of the funds will publicly
demonstrate that someone can create a SHA256 collision, which is an
attack we currently believe to be impractical. This system was
demonstrated to work about four years ago[3] when the collision bounty
for the much weaker SHA1 function was claimed.[4]
We can already create an output script with a Nothing Up My Sleeve
(NUMS) point that would provide a trustless bounty to anyone proving the
capability to steal any P2PK-style output with secp256k1's 128-bit
security. I curious about whether anyone informed about ECC and QC
knows how to create output scripts with lower difficulty that could be
used to measure the progress of QC-based EC key cracking. E.g.,
NUMS-based ECDSA- or taproot-compatible scripts with a security strength
equivalent to 80, 96, and 112 bit security.
That way the people and businesses concerned about QC advances could
send a few BTC to those addresses to create a QC early warning system
that would allow us to continue confidently working on EC-based
protocols for now but also objectively alert us to when we need to shift
to working on post-QC protocols for the future.
Thank you,
-Dave
[1] https://bitcointalk.org/index.php?topic=293382.0
[2] Anyone claiming the reward may need to mine their own transaction to
protect it against rewriting. In the worst case, they may need to
mine at a depth of several blocks or share their reward with miners
to prevent sniping reorgs.
[3] https://blockstream.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
[4] To the best of my knowledge, nothing in Bitcoin ever depended
significantly on SHA1, and especially not on SHA1 collision
resistance, which was known to be weak even in 2009 when Nakamoto
first published the Bitcoin software.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210315/7c7043d8/attachment-0001.sig>

2023-06-07 20:30:34

- reply

📅 Original date posted:2021-03-06
📝 Original message:On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote:
> I'm really unsure that three months is a short enough time window that there
> wouldn't be a material effort to split the network with divergent consensus
> rules.
I oppose designing activation mechanisms with the goal of preventing
other people from effectively exercising self determination over what
consensus rules their nodes enforce.
Three months was chosen because it's long enough to give miners a
reasonable enough amount of time to activate taproot but it's also short
enough that it doesn't delay any of the existing proposals with roughly
one-year timelines. As such, I think it has the potential to gain
acceptance from multiple current factions (even if it doesn't ever gain
their full approval), allowing us to move forward with rough social
consensus and to gain useful information from the attempt that can
inform future decisions.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210306/69399d40/attachment.sig>

2023-06-07 20:30:29

- reply

📅 Original date posted:2021-03-06
📝 Original message:On the ##taproot-activation IRC channel, Russell O'Connor recently
proposed a modification of the "Let's see what happens" activation
proposal.[1] The idea received significant discussion and seemed
acceptable to several people who could not previously agree on a
proposal (although this doesn't necessarily make it their first
choice). The following is my attempt at a description.
1. Start soon: shortly after the release of software containing this
proposed activation logic, nodes will begin counting blocks towards
the 90% threshold required to lock in taproot.[2]
2. Stop soon: if the lockin threshold isn't reached within approximately
three months, the activation attempt fails. There is no mandatory
activation and everyone is encouraged to try again using different
activation parameters.
2. Delayed activation: in the happy occasion where the lockin threshold
is reached, taproot is guaranteed to eventually activate---but not
until approximately six months after signal tracking started.
## Example timeline
(All dates approximate; see the section below about BIP9 vs BIP8.)
- T+0: release of one or more full nodes with activation code
- T+14: signal tracking begins
- T+28: earliest possible lock in
- T+104: locked in by this date or need to try a different activation process
- T+194: activation (if lockin occurred)
## Analysis
The goal of Speedy Trial is to allow a taproot activation attempt to
either quickly succeed or quickly fail---without compromising safety in
either case. Details below:
### Mitigating the problems of early success
New rules added in a soft fork need to be enforced by a large part of
the economy or there's a risk that a long chain of blocks breaking the
rules will be accepted by some users and rejected by others, causing a
chain split that can result in large direct losses to transaction
receivers and potentially even larger indirect losses to holders due to
reduced confidence in the safety of the Bitcoin system.
One step developers have taken in the past to ensure widespread adoption
of new consensus rules is programming in a delay between the time software
with those rules is expected to be released and when the software starts
tracking which blocks signal for activation. For example:
Soft fork | Release | Start | Delta
-----------------+------------+------------+----------
BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days
BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days
Sources: BitcoinCore.org, https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
Speedy Trial replaces most of that upfront delay with a backend delay.
No matter how fast taproot's activation threshold is reached by miners,
there will be six months between the time signal tracking starts and when
nodes will begin enforcing taproot's rules. This gives the userbase even
more time to upgrade than if we had used the most recently proposed start
date for a BIP8 activation (~July 23rd).[2]
### Succeed, or fail fast
The earlier version of this proposal was documented over 200 days ago[3]
and taproot's underlying code was merged into Bitcoin Core over 140 days
ago.[4] If we had started Speedy Trial at the time taproot
was merged (which is a bit unrealistic), we would've either be less than
two months away from having taproot or we would have moved on to the
next activation attempt over a month ago.
Instead, we've debated at length and don't appear to be any closer to
what I think is a widely acceptable solution than when the mailing list
began discussing post-segwit activation schemes over a year ago.[5] I
think Speedy Trial is a way to generate fast progress that will either
end the debate (for now, if activation is successful) or give us some
actual data upon which to base future taproot activation proposals.
Of course, for those who enjoy the debate, discussion can continue while
waiting for the results of Speedy Trial.
### Base activation protocol
The idea can be implemented on top of either Bitcoin Core's existing
BIP9 code or its proposed BIP8 patchset.[6]
- BIP9 uses two time-based[7] parameters, starttime and timeout. Using
these values plus a time-based parameter for the minimum activation
delay would give three months for miners to activate taproot, but some
of that time near the start or the end might not be usable due to
signals only being measured in full retarget periods. However, the
six month time for users to upgrade their node would be not be
affected by either slow or fast block production.
BIP9 is already part of Bitcoin Core and I think the changes being
proposed would be relatively small, resulting in a small patch that
could be easy to review.
- BIP8 uses two height-based parameters, startheight and timeoutheight.
Using height values would ensure miners had a certain number of
retarget periods (6) to lock in taproot and that there'd be a certain
number of blocks (about 24,000) until activation, although latest lock
in and expected activation could occur moderately earlier or later
than the estimated three and six months.
BIP8 would likely be used if Speedy Trial fails, so it could be
advantageous to base this proposal on BIP8 so that we gain
experience running that code in production.
For additional discussion about using times versus heights, see today's
log for ##taproot-activation.[11]
### Additional concerns
- Encourages false signaling: false signaling is when miners signal
readiness to enforce rules that their nodes don't actually support.
This was partially responsible for a six-block reorg shortly after the
final BIP66 activation[8] and was found to still be a problem during
the BIP68 lockin period despite BIP9 being designed to avoid it.[9]
Because Speedy Trial only gives miners a maximum of three months to
signal support for taproot, it may encourage such false signaling. If
taproot locks in as a result of their signaling but most of them fail
to upgrade by the activation date several months later, unprepared
miners could lose large amounts of money and users could see long
reorgs (with unupgraded nodes and SPV lite clients potentially losing
money).
Compared to other activation proposals, I think the only difference is
Speedy Trial's short timeline. False signaling is possible with any
other proposal and the same problems can occur if miners fail to
upgrade for any mandatory activation.
### Additional advantages
- No mandatory signaling: at no time are miners required to signal by
Speedy Trial. This includes no mandatory signaling during the
locked_in period(s), although such signaling will be encouraged (as it
was with BIP9[10]).
- Party time: to a lesser degree, a benefit mentioned for flag day
activation may also apply here: we could get up to six months
advanced notice of taproot activation, allowing users, developers, and
organizations to prepare software, announcements, and celebrations for
that event.
## Implementation details and next steps
Initial discussion about implementation may be found in today's
##taproot-activation log.[11] If it appears Speedy Trial may have
traction, Russell O'Connor has offered to work on a patch against BIP8
implementing it.
## Acknowledgments
The original idea for a short-duration attempt was discussed in the
##taproot-activation IRC channel last July and the revised idea saw
additional evaluation there this week. Despite growing frustration,
discussion has been overwhelmingly constructive, for which all the
contributors should be commended. Although this should not in any way
imply endorsement, I'm grateful for the review and comments on a draft
of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,
Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell
O'Connor, and IRC users maybehuman and proofofkeags
## Footnotes
[1] https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
[2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period
seemed to have near-universal support during the 2021-02-16 IRC
meeting. See: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
[3] https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldid=68062
[4] https://github.com/bitcoin/bitcoin/pull/19953
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
[6] https://github.com/bitcoin/bitcoin/pull/19573
[7] BIP9's times are based on the median of the past 11 blocks, which
usually trails UTC by about 90 minutes but which can trail behind
realtime significantly if miners are doing weird things.
[8] https://en.bitcoin.it/wiki/July_2015_chain_forks
[9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32
[10] https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339
[11] http://gnusha.org/taproot-activation/2021-03-05.log
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210305/5c5b4037/attachment.sig>

2023-06-07 20:28:25

- reply

📅 Original date posted:2021-02-13
📝 Original message:On Fri, Feb 05, 2021 at 12:43:57PM +0000, Michael Folkson via bitcoin-dev wrote:
> https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
> [...]
> F6) It is more important that no rules that harm users are deployed
> than it is that new useful rules are deployed quickly. If there is a
> choice between “faster” and “more clear that this isn’t a mechanism to
> force bad things on users” we should prefer the latter. Plenty of
> people just don’t like LOT=true very much absent evidence that miners
> are blocking deployment. To some it just feels needlessly antagonistic
> and distrusting towards part of our community.
I think F6, above, bundles together several of Maxwell's points and
maybe loses something in summary. I'd encourage interested readers to
view the original post that Folkson referenced. I'd like to extract one
part as a separate point and write about it a bit in my own words:
F7) defaulting to LOT=false makes non-activation possible even if people
run the code that developers provide, meaning a successful
activation proves that at least some people (e.g. miners or UASFers)
voluntarily took actions that were well outside the scope of
developer control.
This makes it clear that developers don't control changes to the
system. There are other arguments that demonstrate that developers
aren't in control[1], but they aren't as clear as simply pointing
out that a rule change won't go into effect until at least several
non-developers independently act of their own accord.
Having such a clear argument that developers aren't in control
bolsters the decentralized ethos of Bitcoin and reduces the chance
that bad actors will pressure Bitcoin developers to attempt future
unwanted changes.
-Dave
[1] IMO, the main evidence we have that developers aren't in control of
the system is that Bitcoin Core is free software which gives anyone
who obtains a copy of it the legal right to run it, learn from it,
modify it, and share additional copies of it for any purpose. Each
time someone uses those rights to create alternative Bitcoin
implementations, altcoins, or forkcoins, they demonstrate that users
could change the system---or resist changes to it---in opposition to
the current developer team, should that become necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210213/47a055ac/attachment.sig>

2023-06-07 20:27:41

- reply

📅 Original date posted:2020-12-06
📝 Original message:On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev wrote:
> I think these results really show there is no reason to try to
> maintain the old-software-can-send-to-future-segwit-versions property,
> given that more than one not just didn't support it, but actually sent
> coins into a black hole.
I don't think this is a good criteria to use for making a decision. We
shouldn't deny users of working implementations the benefit of a feature
because some other developers didn't implement it correctly.
> Thus, I agree with Rusty that we should change the checksum for v1+
> unconditionally.
I disagreed with Rusty previously and he proposed we check to see how
disruptive an address format change would be by seeing how many wallets
already provide forward compatibility and how many would need to be
updated for taproot no matter what address format is used. I think that
instead is a good criteria for making a decision.
I understand the results of that survey to be that only two wallets
correctly handled v1+ BIP173 addresses. One of those wallets is Bitcoin
Core, which I personally believe will unhesitatingly update to a new
address format that's technically sound and which has widespread support
(doubly so if it's just a tweak to an already-implemented checksum
algorithm).
Given that, I also now agree with changing the checksum for v1+.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201206/415223da/attachment.sig>

2023-06-07 20:27:24

- reply

📅 Original date posted:2020-10-20
📝 Original message:On Tue, Oct 20, 2020 at 11:12:06AM +1030, Rusty Russell wrote:
> Here are my initial results:
A while ago, around the Bitcoin Core 0.19.0 release that enabled
relaying v1+ segwit addresses, Mike Schmidt was working on the Optech
Compatibility Matrix[1] and tested a variety of software and services
with a v1 address using the original BIP341 specification (33 byte
pubkeys; we now use 32 byte keys). Here's a summary of his results,
posted with his permission:
- abra: Bech32 not supported.
- binance: Does not pass front end javascript validation
- bitgo: Error occurs during sending process, after validation.
- bitmex: Bech32 not supported.
- bitrefill: Address does not pass validation.
- bitstamp: Address text input doesn’t allow bech32 addresses due to
character limits.
- blockchain.info: Error occurs during sending process, after
validation.
- brd: Allows sending workflow to complete in the UI. Transaction stays
as pending in the transaction list.
- casa: Fails on signing attempt.
- coinbase: Fails address validation client side in the UI.
- conio: Server error 500 while attemping to send.
- copay: Allows v1 address to be entered in the UI. Fails during
broadcast.
- edge: Allows sending workflow to complete. Transaction stays in
pending state. Appears to causes issues with the balance calculation
as well as ability to send subsequent transactions.
- electrum: Error message during broadcasting of transaction.
- green: Fails on validation of the address.
- jaxx: Fails on validation of the address.
- ledger live: Fails when transaction is sent to the hardwave device for
signing.
- mycelium: Fails during address validation.
- purse: Transaction can be created and broadcast, relayed by peers
compatible with Bitcoin Core v0.19.0.1 or above.
- river: Transaction can be created and broadcast, relayed by peers
compatible with Bitcoin Core v0.19.0.1 or above.
- samourai: Fails on broadcast of transaction to the network.
- trezor: Fails on validation of the address.
- wasabi: Fails on validation of the address.
- xapo: Xapo allows users to create segwit v1 transactions in the UI.
However, the transaction gets stuck as pending for an indeterminate
period of time
I would guess that some of the failures / stuck transactions might now
be successes if the backend infrastructure has upgraded to Bitcoin Core
>= 0.19.
-Dave
[1] https://bitcoinops.org/en/compatibility/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201020/e35b6eb1/attachment.sig>