<unnamed>

Public Key

npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd

Profile Code

nprofile1qqsdx462yssg7n3apqsmkjnf5rp6appqg02yf7juf2xynsmfjx9xlvspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsmar4eu

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-08-13 14:32:58 UTC

- 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-06 23:37:36 UTC

- 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 13:02:28 UTC

- 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 11:15:34 UTC

- 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 18:19:54 UTC

- 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 18:19:50 UTC

- 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 00:54:55 UTC

- 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 13:12:25 UTC

- 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 13:07:47 UTC

- 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 13:07:27 UTC

- 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 13:07:26 UTC

- 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 13:06:58 UTC

- 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 13:06:49 UTC

- 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 13:06:48 UTC

- 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 13:01:44 UTC

- 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 13:01:43 UTC

- 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 13:01:35 UTC

- 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 13:00:30 UTC

- reply

📅 Original date posted:2020-06-20
📝 Original message:
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.
The problem I have with that approach is that the incentive is to
connect to the highest hashrate pools and ignore the long tail of
smaller pools and solo miners. If miners realize people are doing this,
they may begin to charge for information about their mempool and the
largest miners will likely be able to charge more money per hashrate
than smaller miners, creating a centralization force by increasing
existing economies of scale.
Worse, information about a node's mempool is partly trusted. A node can
easily prove what transactions it has, but it can't prove that it
doesn't have a certain transaction. This implies incumbent pools with a
long record of trustworthy behavior may be able to charge more per
hashrate than a newer pools, creating a reputation-based centralizing
force that pushes individual miners towards well-established pools.
This is one reason I suggested using independent pay-to-preimage
transactions[1]. Anyone who knows the preimage can mine the
transaction, so it doesn't provide reputational advantage or direct
economies of scale---pay-to-preimage is incentive equivalent to paying
normal onchain transaction fees. There is an indirect economy of
scale---attackers are most likely to send the low-feerate
preimage-containing transaction to just the largest pools, so small
miners are unlikely to learn the preimage and thus unlikely to be able
to claim the payment. However, if the defense is effective, the attack
should rarely happen and so this should not have a significant effect on
mining profitability---unlike monitoring miner mempools which would have
to be done continuously and forever.
ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
hoping one of Bitcoin's several inventive cryptographers would come
along and describe how someone with an adaptor signature could use that
information to create a pubkey that could be put into a transaction with
a second output that OP_RETURN included the serialized adaptor
signature. The pubkey would be designed to be spendable by anyone with
the final signature in a way that revealed the hidden value to the
pubkey's creator, allowing them to resolve the PTLC. But if that's
fundamentally not possible, I think we could advocate for making
pay-to-revealed-adaptor-signature possible using something like
OP_CHECKSIGFROMSTACK.[3]
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
[2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html
[3] https://bitcoinops.org/en/topics/op_checksigfromstack/
> Do you think it's unreasonable to expect at least some LN nodes to
> also invest in running nodes in mining pools, ensuring that they learn
> about attackers' txs and can potentially share discovered preimages
> with the network off-chain (by gossiping preimages found in the
> mempool over LN)?
Ignoring my concerns about mining centralization and from the
perspective of just the Lightning Network, that doesn't sound
unreasonable to me. But from the perspective of a single LN node, it
might make more sense to get the information and *not* share it,
increasing your security and allowing you to charge lower routing fees
compared to your competitors. This effect would only be enhanced if
miners charged for their mempool contents (indeed, to maximize their
revenue, miners might require that their mempool subscribers don't share
the information---which they could trivially enforce by occasionally
sending subscribers a preimage specific to the subscriber and seeing if
it propagated to the public network).
> I think that these recent attacks show that we need (at least some)
> off-chain nodes to be somewhat heavily invested in on-chain operations
> (layers can't be fully decoupled with the current security assumptions
> - maybe Eltoo will help change that in the future?).
I don't see how eltoo helps. Eltoo helps ensure you reach the final
channel state, but this problem involves an abuse of that final state.
-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/20200620/6085153a/attachment-0001.sig>

2023-06-09 13:00:29 UTC

- reply

📅 Original date posted:2020-06-19
📝 Original message:
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Quoted text below is from the gist:
> The trick to protect against a malicious participant that broadcasts a
> low-fee HTLC-success or Remote-HTLC-success transaction is that we can
> always blindly do a CPFP carve-out on them; we know their txid
I think you're assuming here that the attacker broadcast a particular
state. However, in a channel which potentially had thousands of state
changes, you'd have to broadcast a blind child for each previous state
(or at least each previous state that pays the attacker more than the
latest state). That's potentially thousands of transactions times
potentially dozens of peers---not impossible, but it seems messy.
I think there's a way to accomplish the same goal for less bandwidth and
zero fees. The only way your Bitcoin peer will relay your blind child
is if it already has the parent transaction. If it has the parent, you
can just request it using P2P getdata(type='tx', id=$txid).[1] You can
batch multiple txid requests together (up to 50,000 IIRC) to minimize
overhead, making the average cost per txid a tiny bit over 36 bytes.
If you receive one of the transactions you request, you can extract the
preimage at no cost to yourself (except bandwidth). If you don't
receive a transaction, then sending a blind child is hopeless
anyway---your peers won't relay it.
Overall, it's hard for me to guess how effective your proposal would be
at defeating the attack. I think the strongman argument for the attack
would be that the attacker will be able to perform a targeted relay of
their outdated state to just miners---everyone else on the network
will receive the counterparty's honest final-state close. Unless the
counterparty happens to have a connection to a miner's node, the
counterparty will neither be able to CPFP fee bump nor use getdata to
retrieve the preimage.
It seems to me it's practical for a motivated attacker to research which
IP addresses belong to miners so that they can target them, whereas
honest users won't practically be able to do that research (and, even if
they could, it would create a centralizing barrier to new miners
entering the market if users focused on maintaining connections to
previously-known miners).
-Dave
[1] You'd have to be careful to not attempt the getdata too soon after
you think the attacker broadcast their old state, but I think that
only means waiting a single block, which you have to do anyway to
see if the honest final-commitment transaction confirmed. See
https://github.com/bitcoin/bitcoin/pull/18861
-------------- 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/20200619/09974bd2/attachment.sig>

2023-06-09 13:00:29 UTC

- reply

📅 Original date posted:2020-06-19
📝 Original message:
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be broadcasting the latest
state, so the honest counterparty would only need to send one blind
child. However, the blind child will only be relayed by a Bitcoin peer
if the peer also has the parent transaction (the latest state) and, if
it has the parent transaction, you should be able to just getdata('tx',
$txid) that transaction from the peer without CPFPing anything. That
will give you the preimage and so you can immediately resolve the HTLC
with the upstream channel.
Revising my conclusion from the previous post:
I think the strongman argument for the attack would be that the attacker
will be able to perform a targeted relay of the low-feerate
preimage-containing transaction to just miners---everyone else on the
network will receive the honest user's higher-feerate expired-timelock
transaction. Unless the honest user happens to have a connection to a
miner's node, the user will neither be able to CPFP fee bump nor use
getdata to retrieve the preimage.
Sorry for the confusion.
-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/20200619/917b77aa/attachment.sig>

2023-06-09 13:00:28 UTC

- 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 12:59:39 UTC

- 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 12:59:38 UTC

- 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 12:59:24 UTC

- reply

📅 Original date posted:2020-04-04
📝 Original message:
On Fri, Apr 03, 2020 at 02:51:15AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Ah, right, E knows the revocation for the unilateral close of EE,
> because it is a self-channel, sigh. And by this revocation clause it
> can claim the money immediately and put it into a channel as well.
If it's a self channel, E can also just RBF replace the close
transaction with a minimally-sized 1-input, 1-output transaction.
In addition, if typical mempools are full and the closing transaction
feerate is very low (i.e. because anchor outputs are meant to be used)
E may also be able to create a close transaction that will be
dropped from typical mempools in the near future and may never
confirm, allowing E to continue using the channel in attacks against its
other peers.
-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/20200404/9350d3a0/attachment.sig>

2023-06-09 12:57:55 UTC

- 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 12:57:47 UTC

- reply

📅 Original date posted:2019-12-17
📝 Original message:
On Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:
> With Phoenix [1], we've been experimenting with pay-to-open [2].
>
> That works well in practice and provides a great UX for newcomers, but
> it requires temporary trust between the user and our node (until the
> funding tx confirms).
>
> That trust relationship appears in two places:
> [...]
> b. The user trusts that we won't double-spend the funding transaction
> [...]
> I'm more concerned about fixing (b). As long as the funding
> transaction is unconfirmed, there's a risk of double-spending by the
> funder.
The typical proposed solution for this type of problem is a single-show
signature[1], a signature that will reveal the private key used to
create it if it's combined with another signature from the same private
key. In other words, if you sign two different spends of the same UTXO,
someone who see both spends will be able to redirect all of that UTXO's
value to themselves. In that case, your change output becomes a form of
fidelity bond---you get to keep it if you act honestly; otherwise,
someone else gets it (most likely whoever mines the next block).
I'm not aware of any way to currently force single-show signatures in
Bitcoin, so this is pretty theoretical. Also, single-show signatures
add a lot of fragility to any setup and make useful features like RBF
fee bumping unavailable.
As a less complete but more practical solution, you might want to
consider a signing federation. This doesn't change the need for trust,
but it does allow spreading that trust around. E.g. if spending your
funds requires three signatures each from one of five different
respected companies helping pioneer LN (perhaps all in different legal
jurisdictions), that might help mitigate user concerns about double
spending. Besides the extra communicating and signing, your existing
workflow wouldn't need to change.
-Dave
[1] Here's some math for single show signatures in ECDSA:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html
Probably a more practical way to enforce single-show in Bitcoin
would be something like OP_CHECKSIGFROMSTACK, e.g. as implemented in
Elements:
https://elementsproject.org/features/opcodes
Maybe SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT could also be used to
enforce single-show with the right script? I'm not so sure about
that.
-------------- 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/20191217/dcd8987d/attachment.sig>

2023-06-09 12:57:39 UTC

- 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 12:57:00 UTC

- 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 12:53:46 UTC

- reply

📅 Original date posted:2019-01-05
📝 Original message:
On Sat, Jan 05, 2019 at 07:01:18AM +0000, ZmnSCPxj wrote:
> Good morning David,
>
> What happens if the exchange node only sends its preimage towards the
> payer and not towards the payee?
>
> If the payer and payee do not coordinate, then it becomes possible for
> the exchange node to take the funds without the payee gaining the
> ability to claim the payment.
Indeed, you are correct. I had not taken that into account. Thinking
about it from that perspective, there's no way to depend on proof that
the someone received something (e.g. a payment) without also allowing
the receiver to block payment by refusing to provide that proof. That
invalidates this class of solutions.
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/20190105/6d4121cf/attachment.sig>

2023-06-09 12:53:45 UTC

- reply

📅 Original date posted:2019-01-04
📝 Original message:
On Thu, Dec 27, 2018 at 05:43:51AM +0000, ZmnSCPxj via Lightning-dev wrote:
> We can try to mitigate this, but the solutions below all have significant drawbacks.
An alternative is to give the person making the exchange the ability to
cancel the payment if they think the exchange rate has changed
unfavorably for them. I think you could do that by adding an extra
hashlock to the HTLC that's controlled by the exchanger. For example,
here's what we'd expect a cross-asset path to look like:
Alice Bob Charlie Dan Eliza
1.3 mBTC -> 1.3 mBTC -> 1.2 mBTC
1.2 mWJT -> 1.1 mWJT -> 1.0 mWJT
Instead of Alice's node just locally constructing this path and trying
to pay it like normal, she first sends a special probe to Charlie
requesting a new hash for which only he knows the preimage. With this
hash plus the hash Alice received from Eliza, Alice sends a payment that
requires both hashlocks be unlocked before anyone can claim the payment.
1. When this payment reaches the exchanger, Charlie, he checks that the
payment includes a hashlock he controls before routing the payment on to
a different asset.
2. When the payment reaches receiver Eliza's node, she releases her
PreImage (PI0) back along the path.
3. When Eliza's preimage reaches exchanger Charlie's node, he releases
his preimage (PI1) in both directions along the path and continues
forwarding PI0 backwards. Eventually everyone receives both preimages
through the usual offchain or onchain mechanisms.
Alice Bob Charlie Dan Eliza
PI0 <- PI0 <- PI0 <- PI0 <- PI0 (start here)
PI1 <- PI1 <- PI1 -> PI1 -> PI1
However, if the exchange rate changes too much for Charlie's comfort
before both preimages have been released, Charlie can unilaterally
decide to cancel the payment by simply not releasing his preimage.
Note that by making the payment contingent on the approval of the
exchanger, the ability to create an underhanded call option is
transferred to the exchanger. However, this may be less concerning
because the exchanger can only keep this option open by refusing to
immediately claim the routing fees.
For example, our exchanger Charlie is being offered 0.1 mBTC to route
the payment (a made up number). If he can route 100 such payments in a
day (another made up number), he can earn 10.0 mBTC from routing. By
comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the
exchange rate to change by an order of magnitude within a day to earn
the same amount. In ZmnSCPxj's terminology, the option is now no longer
free because Charlie must decide between potential routing income and
potential option income. Whether or not exchangers play the option game
will therefore likely be based on the amount of honest routing income
they can earn relative to the exchange rate volatility (and also on how
good nodes get at tracking reliable routes).
This idea certainly complicates the current protocol (both routing and
transaction construction), but maybe there are simplifications
available.
-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/20190104/09413fd9/attachment.sig>

2023-06-09 12:40:45 UTC

- 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 12:40:02 UTC

- 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-07 23:22:07 UTC

- 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-07 23:22:01 UTC

- 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-07 23:21:55 UTC

- 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-07 23:21:54 UTC

- 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-07 23:20:24 UTC

- 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-07 23:19:42 UTC

- 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-07 23:18:51 UTC

- 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-07 23:18:29 UTC

- 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-07 23:18:28 UTC

- 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-07 23:18:27 UTC

- 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-07 23:16:53 UTC

- 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-07 23:16:01 UTC

- 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-07 23:14:17 UTC

- 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-07 23:14:04 UTC

- 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-07 23:11:29 UTC

- 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-07 23:07:32 UTC

- 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-07 23:03:26 UTC

- 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-07 22:57:08 UTC

- 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-07 22:52:10 UTC

- 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-07 22:51:55 UTC

- 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-07 18:30:34 UTC

- 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 18:30:29 UTC

- 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 18:28:25 UTC

- 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 18:26:55 UTC

- reply

📅 Original date posted:2020-09-19
📝 Original message:On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is as
> an attack because it's quite expensive for the attacker.
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
2. After you no longer need your pinning transaction in the mempool, you
make an out-of-band arrangement with a pool to mine a small
conflicting transaction.
> But there are a few simple policies that can eliminate it:
>
> 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
> outputs. Restricting this via policy would help, or more flexibly
> limiting the total size of a sponsoring transaction to 1000 bytes.
I think that works (as policy).
> 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
> increase the feerate (perhaps with a constant relay fee bump to prevent
> spam).
I think it'd be hard to find a constant relay fee bump amount that was
high enough to prevent abuse but low enough not to unduly hinder
legitimate users.
> I think 1) is simpler and should allow full use of the sponsor mechanism
> while preventing this class of issue mostly.
Agreed.
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/20200919/15f5bf2c/attachment.sig>

2023-06-07 18:26:54 UTC

- reply

📅 Original date posted:2020-09-19
📝 Original message:On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to replace
> CPFP and RBF for increasing fees on transactions in the mempool that
> should be more robust against attacks.
Interesting idea! This is going to take a while to think about, but I
have one immediate question:
> To prevent garbage sponsors, we also require that:
>
> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate
>
> We allow one Sponsor to replace another subject to normal replacement
> policies, they are treated as conflicts.
Is this in the reference implementation? I don't see it and I'm
confused by this text. I think it could mean either:
1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
one input in common (which is part of the "normal replacement policies")
2. A can be replaced by B even if they don't have any inputs in common
as long as they do have a Sponsor Vector in common (while otherwise
using the "normal replacement policies").
In the first case, I think Mallory can prevent Bob from
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
sponsor before he does; since Bob has no control over Mallory's inputs,
he can't replace Mallory's sponsor tx.
In the second case, I think Mallory can use an existing pinning
technique to make it expensive for Bob to fee bump. The normal
replacement policies require a replacement to pay an absolute higher fee
than the original transaction, so Mallory can create a 100,000 vbyte
transaction with a single-vector sponsor at the end pointing to Bob's
transaction. This sponsor transaction pays the same feerate as Bob's
transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee. In order
for Bob to replace Mallory's sponsor transaction with his own sponsor
transaction, Bob needs to pay the incremental relay feerate (10
nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
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/20200919/b6c53712/attachment.sig>

2023-06-07 18:26:24 UTC

- reply

📅 Original date posted:2020-08-20
📝 Original message:On Sun, Aug 16, 2020 at 12:06:55PM -0700, Eric Voskuil via bitcoin-dev wrote:
> A requirement to ignore unknown (invalid) messages is [...] a protocol
> breaking change
I don't think it is. The proposed BIP, as currently written, only tells
nodes to ignore unknown messages during peer negotiation. The only case
where this will happen so far is BIP339, which says:
The wtxidrelay message must be sent in response to a VERSION message
from a peer whose protocol version is >= 70016, and prior to sending
a VERACK
So unless you signal support for version >=70016, you'll never receive an
unknown message. (And, if you do signal, you probably can't claim that
you were unaware of this new requirement, unless you were using a
non-BIP protocol like xthin[1]).
However, perhaps this new proposed BIP could be a bit clearer about its
expectations for future protocol upgrades by saying something like:
Nodes implementing this BIP MUST also not send new negotiation
message types to nodes whose protocol version is less than 70017.
That should promote backwards compatibility. If you don't want to
ignore unknown negotiation messages between `version` and `verack`, you
can just set your protocol version to a max of 70016.
> A requirement to ignore unknown (invalid) messages is [...] poor
> protocol design. The purpose of version negotiation is to determine
> the set of valid messages.
To be clear, the proposed requirement to ignore unknown messages is
limited in scope to the brief negotiation phase between `version` and
`verack`. If you want to terminate connections (or do whatever) on
receipt of an unknown message, you can do that at any other time.
> Changes to version negotiation itself are very problematic.
For whom?
> The only limitation presented by versioning is that the system is
> sequential.
That seems like a pretty significant limitation to decentralized
protocol development.
I think there are currently several people who want to run long-term
experiements for new protocol features using open source opt-in
codebases that anyone can run, and it would be advantageous to them to
have a flexible and lightweight feature negotiation system like this
proposed method.
> As such, clients that do not wish to implement (or operators who do
> not wish to enable) them are faced with a problem when wanting to
> support later features. This is resolvable by making such features
> optional at the new protocol level. This allows each client to limit
> its communication to the negotiated protocol, and allows ignoring of
> known but unsupported/disabled features.
I don't understand this. How do two peers negotiate a set of two or
more optional features using only the exchange of single numbers? For
example:
- Node A supports Feature X (implemented in protocol version 70998) and Feature Y (version 70999).
- Node B does not support X but does want to use Y; what does it use for its
protocol version number when establishing a connection with node A?
---
Overall, I like the proposed BIP and the negotiation method it
describes.
Cheers,
-Dave
[1] This is not a recommendation for xthin, but I do think it's an example
of the challenges of using a shared linear version number scheme for
protocol negotiation in a decentralized system where different teams
don't necessarily get along well with each other.
https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b#diff-c61070c281aed6ded69036c08bd08addR12
-------------- 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/20200820/faec9a70/attachment.sig>

2023-06-07 18:24:14 UTC

- reply

📅 Original date posted:2020-05-02
📝 Original message:On Wed, Apr 29, 2020 at 04:57:46PM +0200, Andrew Kozlik via bitcoin-dev wrote:
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input.
A wallet can easily check whether a scriptPubKey contais a specific
pubkey (as in P2PK/P2TR), but I think it's impractical for most wallets
to check whether a scriptPubKey contains any of the possible ~two
billion keys available in a specific BIP32 derivation path (and many
wallets natively support multiple paths).
It would seem to me that checking a list of scriptPubKeys for wallet
matches would require obtaining the BIP32 derivation paths for the
corresponding keys, which would have to be provided by a trusted data
source. If you trust that source, you could just trust them to tell you
that none of the other inputs belong to your wallet.
Alternatively, there's the scheme described in the email you linked by
Greg Saunders (with the scheme co-attributed to Andrew Poelstra), which
seems reasonable to me.[1] It's only downside (AFAICT) is that it
requires an extra one-way communication from a signing device to a
coordinator. For a true offline signer, that can be annoying, but for
an automated hardware wallet participating in coinjoins or LN, that
doesn't seem too burdensome to me.
-Dave
[1] The scheme could be trivially tweaked to be compatible with BIP322
generic signed messages, which is something that could become widely
adopted (I hope) and so make supporting the scheme easier.
-------------- 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/20200502/1879177c/attachment.sig>

2023-06-07 18:22:54 UTC

- reply

📅 Original date posted:2020-02-14
📝 Original message:On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
> I'm missing something in one of the cases?
That's fair. However, it's only true if everyone constructs their
merkle tree in the same way, with a single `<schnorr_pk> OP_CHECKSIG` as
one of the top leaves. Taproot effectively standardizes the position
of the all-parties-agree condition and so its anonymity set may contain
spends from scripts whose creators buried or excluded the the all-agree
option because they didn't think it was likely to be used.
More importantly, there's no incentive for pure single-sig users to use a
merkle tree, since that would make both the scriptPubKey and the witness
data are larger for them than just continuing to use v0 segwit P2WPKH.
Given that single-sig users represent a majority of transactions at
present (see AJ Towns's previous email in this thread), I think we
really want to make it as convenient as possible for them to participate
in the anonymity set.
(To be fair, taproot scriptPubKeys are also larger than P2WPKH
scriptPubKeys, but its witness data is considerably smaller, giving
receivers an incentive to demand P2TR payments even if spenders don't
like paying the extra 12 vbytes per output.)
Rough sums:
- P2WPKH scriptpubkey (22.00 vbytes): `OP_0 PUSH20 <hash160>`
- P2WPKH witness data (26.75): `size(72) <sig>, size(33) <pubkey>`
- P2TR scriptpubkey (34.00): `OP_1 PUSH32 <pubkey>`
- P2TR witness data (16.25): `size(64) <sig>`
- BIP116 MBV P2WSH scriptpubkey (34.00): `OP_0 PUSH32 <sha256>`
- BIP116 MBV P2WSH witness data (42.00): `size(64) <signature>, size(32)
<pubkey>, size(32) <inclusion_proof>, size(36) <PUSH1 <n> PUSH32
<merkle_root> OP_MBV>`
-Dave
P.S. I think this branch of the thread is just rehashing points that
were originally covered over two years ago and which haven't really
changed since then. E.g.:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015629.html
-------------- 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/20200214/bc1102fd/attachment-0001.sig>

2023-06-07 18:22:52 UTC

- reply

📅 Original date posted:2020-02-09
📝 Original message:On Sun, Feb 09, 2020 at 02:47:29PM -0600, Anon via Bryan Bishop via bitcoin-dev wrote:
> 1) Is Taproot actually more private than bare MAST and Schnorr separately?
Yes.
> What are the actual anonymity set benefits compared to doing the separately?
When schnorr and taproot are done together, all of the following
transaction types can be part of the same set:
- single-sig spends (similar to current use of P2PKH and P2WPKH)
- n-of-n spends with musig or equivalent (similar to current use of
P2SH and P2WSH 2-of-2 multisig without special features as used by
Blockstream Green and LN mutual closes)
- k-of-n (for low values of n) using the most common k signers
(similar to BitGo-style 2-of-3 where the keys involved are
alice_hot, alice_cold, and bob_hot and almost all transactions are
expected to be signed by {alice_hot, bob_hot}; that common case
can be the key-path spend and the alternatives {alice_hot,
alice_cold} and {alice_cold, bob_hot} can be script-path spends)
- contract protocols that can sometimes result in all parties
agreeing on an outcome (similar to LN mutual closes, cross-chain
atomic swaps, and same-chain coinswaps)
The four cases above represent an overwhelming percentage of the spends
seen on the block chain today and throughout Bitcoin's entire history to
date, so optimizing to include them in the anonymity set presents a huge
benefit.
> 2) Is Taproot actually cheaper than bare MAST and Schnorr separately?
Earlier in y'alls email, you claim that the difference between the two
approaches for a particular example is 67 bytes. I haven't checked that
calculation, but it seems you're talking entirely about bytes that could
appear in the witness data and so would only represent 16.75 vbytes.
Compare that to the size of the other elements which would need to be
part of a typical input:
- (36 vbytes) outpoint
- (1) scriptSig compactSize uint
- (4) nSequence
- (16.25) schnorr signature (includes size byte)
That's 57.25 vbytes exclusive of your example data or 74.00 vbytes
inclusive. That means the overhead you're concerned about adds only
about 23% to the size of the input (or 30% on an exclusive basis).
That's definitely worth considering optimizations for, but I'm
personally ok with requiring users of advanced scripts (who can't manage
to produce mutual closes) pay an extra 23% for their inputs in order to
allow the creation of the large anonymity set described above for all
the other cases.
If, subsequent to deployment, large numbers of users do end up using
taproot script-path spends and we want to make things more fair, we can
even out the weighting, perhaps by simply increasing the weight of
key-path spends by 16.75 vbytes (though that would, of course,
proportionally lower the capacity of the block chain). As mentioned in
a separate email by Matt Corallo, it seems worthwhile to optimize for
the case where script-path spenders are encouraged to look for
mutually-agreed contract resolutions in order to both minimize block
chain use and increase the size of the anonymity set.
> What evidence do we have that the assumption it will be more common to
> use Taproot with a key will outweigh Script cases?
The evidence that current users of single-sig, n-of-n, and k-of-n (for
small n) with a default k-set, and mutual-agreed contract protocol
outcomes vastly outweigh all other transaction inputs today and for all
of Bitcoin's history to date.
-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/20200209/c79b6dae/attachment.sig>

2023-06-07 18:21:27 UTC

- 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-07 18:21:21 UTC

- reply

📅 Original date posted:2019-10-20
📝 Original message:On Sun, Oct 20, 2019 at 12:29:25AM +0000, SomberNight via bitcoin-dev wrote:
> waxwing, ThomasV, and I recently had a discussion about implementing
> SNICKER in Electrum; specifically the "Receiver" role.
That'd be awesome!
> As the referenced section [0] explains, the "Receiver" can restore
> from seed, and assuming he knows he needs to do extra scanning steps
> (e.g. via a seed version that signals SNICKER support), he can find
> and regain access to his SNICKER outputs. However, to calculate `c` he
> needs access to his private keys, as it is the ECDH of one of the
> Receiver's pubkeys and one of the Proposer's pubkeys.
>
> This means the proposed scheme is fundamentally incompatible with
> watch-only wallets.
>
> [0] https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys
Your logic seems correct for the watching half of the wallet, but I
think it's ok to consider requiring interaction with the cold wallet.
Let's look at the recovery procedure from the SNICKER documentation
that you kindly cited:
1. Derive all regular addresses normally (doable watch-only for
wallets using public BIP32 derivation)
2. Find all transactions spending an output for each of those
addresses. Determine whether the spend looks like a SNICKER
coinjoin (e.g. "two equal-[value] outputs"). (doable watch-only)
3. "For each of those transactions, check, for each of the two equal
sized outputs, whether one destination address can be regenerated
from by taking c found in the method described above" (not doable
watch only; requires private keys)
I'd expect the set of candidate transactions produced in step #2 to be
pretty small and probably with no false positives for users not
participating in SNICKER coinjoins or doing lots of payment batching.
That means, if any SNICKER candidates were found by a watch-only wallet,
they could be compactly bundled up and the user could be encouraged to
copy them to the corresponding cold wallet using the same means used for
PSBTs (e.g. USB drive, QR codes, etc). You wouldn't even need the whole
transactions, just the BIP32 index of the user's key, the pubkey of the
suspected proposer, and a checksum of the resultant address.
The cold wallet could then perform step #3 using its private keys and
return a file/QRcode/whatever to the hot wallet telling it any shared
secrets it found.
This process may need to be repeated several times if an output created
by one SNICKER round is spent in a subsequent SNICKER round. This can be
addressed by simply refusing to participate in chains of SNICKER
transactions or by refusing to participant in chains of SNICKERs more
than n long (requring a maximum n rounds of recovery). It could also be
addressed by the watching-only wallet looking ahead at the block chain a
bit in order to grab SNICKER-like child and grandchild transactions of
our SNICKER candidates and sending them also to the cold wallet for
attempted shared secret recovery.
The SNICKER recovery process is, of course, only required for wallet
recovery and not normal wallet use, so I don't think a small amount of
round-trip communication between the hot wallet and the cold wallet is
too much to ask---especially since anyone using SNICKER with a
watching-only wallet must be regularly interacting with their cold
wallet anyway to sign the coinjoins.
-Dave

2023-06-07 18:17:12 UTC

- reply

📅 Original date posted:2019-03-24
📝 Original message:On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short command ID)
> [...]
> The command field MUST start with a byte that defines the length of the ASCII
> command string up to 12 chars (1 to 12) or a short command ID (see below).
> [...]
> ==== Short Command ID ====
>
> To save valuable bandwidth, the v2 message format supports message command
> short IDs for message types with high frequency. The ID/string mapping is a
> peer to peer arrangement and MAY be negotiated between the initiating and
> responding peer.
Why is this optional and only specified here for some message types
rather than being required by v2 and specified for all message types?
There's only 26 different types at present[1], so it seems better to
simply make this a one-byte fixed-length field than it is to deal with
variable size, mapping negotiation, per-peer mapping in general, and
(once the network is fully v2) the dual-logic of being able to process
messages either from a short ID or a full command name.
Thanks,
-Dave
[1] src/protocol.cpp:
const static std::string allNetMessageTypes[] = {
NetMsgType::VERSION,
NetMsgType::VERACK,
NetMsgType::ADDR,
NetMsgType::INV,
NetMsgType::GETDATA,
NetMsgType::MERKLEBLOCK,
NetMsgType::GETBLOCKS,
NetMsgType::GETHEADERS,
NetMsgType::TX,
NetMsgType::HEADERS,
NetMsgType::BLOCK,
NetMsgType::GETADDR,
NetMsgType::MEMPOOL,
NetMsgType::PING,
NetMsgType::PONG,
NetMsgType::NOTFOUND,
NetMsgType::FILTERLOAD,
NetMsgType::FILTERADD,
NetMsgType::FILTERCLEAR,
NetMsgType::REJECT,
NetMsgType::SENDHEADERS,
NetMsgType::FEEFILTER,
NetMsgType::SENDCMPCT,
NetMsgType::CMPCTBLOCK,
NetMsgType::GETBLOCKTXN,
NetMsgType::BLOCKTXN,
};
-------------- 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/20190324/84a5b971/attachment.sig>

2023-06-07 18:15:35 UTC

- reply

📅 Original date posted:2018-12-09
📝 Original message:On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev wrote:
> One more item to consider is "signature covers witness weight".
>
> While signing the witness weight doesn't completely eliminate witness
> malleability (of the kind that can cause grief for compact blocks), it does
> eliminate the worst kind of witness malleability from the user's
> perspective, the kind where malicious relay nodes increase the amount of
> witness data and therefore reduce the overall fee-rate of the transaction.
To what degree is this an actual problem? If the mutated transaction
pays a feerate at least incremental-relay-fee[1] below the original
transaction, then the original transaction can be rebroadcast as an RBF
replacement of the mutated transaction (unless the mutated version has
been pinned[2]).
-Dave
[1] $ bitcoind -help-debug | grep -A2 incremental
-incrementalrelayfee=<amt>
Fee rate (in BTC/kB) used to define cost of relay, used for mempool
limiting and BIP 125 replacement. (default: 0.00001)
[2] https://bitcoin.stackexchange.com/questions/80803/what-is-meant-by-transaction-pinning
-------------- 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/20181209/7ae94da5/attachment.sig>

2023-06-07 18:15:35 UTC

- reply

📅 Original date posted:2018-12-11
📝 Original message:On Tue, Dec 11, 2018 at 10:36:59AM -0500, Russell O'Connor wrote:
> I don't believe that the default RBF policy works that way. My
> understanding is that current policy requires an absolute fee increase (by
> an amount related to incrementalrelayfee).
Indeed, you are correct (BIP125 rule 4[1]).
Thanks for the correction,
-Dave
[1] For the curious, the relevant code from master's validation.cpp:
// Finally in addition to paying more fees than the conflicts the
// new transaction must pay for its own bandwidth.
CAmount nDeltaFees = nModifiedFees - nConflictingFees;
if (nDeltaFees < ::incrementalRelayFee.GetFee(nSize))
{
return state.DoS(0, false,
REJECT_INSUFFICIENTFEE, "insufficient fee", false,
strprintf("rejecting replacement %s, not enough additional fees to relay; %s < %s",
hash.ToString(),
FormatMoney(nDeltaFees),
FormatMoney(::incrementalRelayFee.GetFee(nSize))));
}
-------------- 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/20181211/20ba89d0/attachment.sig>

2023-06-07 18:12:41 UTC

- reply

📅 Original date posted:2018-06-09
📝 Original message:On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via bitcoin-dev wrote:
> 2. Since the coinbase transaction is the first in a block, it has the
> longest merkle proof path. As a result, it may be several hundred bytes
> (and grows with future capacity increases) to present a proof to the
> client.
I'm not sure why commitment proof size is a significant issue. Doesn't
the current BIP157 protocol have each filter commit to the filter for
the previous block? If that's the case, shouldn't validating the
commitment at the tip of the chain (or buried back whatever number of
blocks that the SPV client trusts) obliviate the need to validate the
commitments for any preceeding blocks in the SPV trust model?
> Depending on the composition of blocks, this may outweigh the gains
> had from taking advantage of the additional compression the prev outs
> allow.
I think those are unrelated points. The gain from using a more
efficient filter is saved bytes. The gain from using block commitments
is SPV-level security---that attacks have a definite cost in terms of
generating proof of work instead of the variable cost of network
compromise (which is effectively free in many situations).
Comparing the extra bytes used by block commitments to the reduced bytes
saved by prevout+output filters is like comparing the extra bytes used
to download all blocks for full validation to the reduced bytes saved by
only checking headers and merkle inclusion proofs in simplified
validation. Yes, one uses more bytes than the other, but they're
completely different security models and so there's no normative way for
one to "outweigh the gains" from the other.
> So should we optimize for the ability to validate in a particular
> model (better security), or lower bandwidth in this case?
It seems like you're claiming better security here without providing any
evidence for it. The security model is "at least one of my peers is
honest." In the case of outpoint+output filters, when a client receives
advertisements for different filters from different peers, it:
1. Downloads the corresponding block
2. Locally generates the filter for that block
3. Kicks any peers that advertised a different filter than what it
generated locally
This ensures that as long as the client has at least one honest peer, it
will see every transaction affecting its wallet. In the case of
prevout+output filters, when a client receives advertisements for
different filters from different peers, it:
1. Downloads the corresponding block and checks it for wallet
transactions as if there had been a filter match
This also ensures that as long as the client has at least one honest
peer, it will see every transaction affecting its wallet. This is
equivilant security.
In the second case, it's possible for the client to eventually
probabalistically determine which peer(s) are dishonest and kick them.
The most space efficient of these protocols may disclose some bits of
evidence for what output scripts the client is looking for, but a
slightly less space-efficient protocol simply uses randomly-selected
outputs saved from previous blocks to make the probabalistic
determination (rather than the client's own outputs) and so I think
should be quite private. Neither protocol seems significantly more
complicated than keeping an associative array recording the number of
false positive matches for each peer's filters.
-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/20180609/ff14b111/attachment.sig>

2023-06-07 18:12:38 UTC

- reply

📅 Original date posted:2018-06-02
📝 Original message:On Fri, Jun 01, 2018 at 07:02:38PM -0700, Jim Posen via bitcoin-dev wrote:
> Without the ability to verify filter validity, a client would have to stop
> syncing altogether in the presence of just one malicious peer, which is
> unacceptable.
I'm confused about why this would be the case. If Alice's node
generates filters accurately and Mallory's node generates filters
inaccurately, and they both send their filters to Bob, won't Bob be able
to download any blocks either filter indicates are relevant to his
wallet?
If Bob downloads a block that contains one of his transactions based on
Alice's filter indicating a possible match at a time when Mallory's
filter said there was no match, then this false negative is perfect
evidence of deceit on Mallory's part[1] and Bob can ban her.
If Bob downloads a block that doesn't contain any of his transactions
based on Mallory's filter indicating a match at a time when Alice's
filter said there was no match, then this false positive can be recorded
and Bob can eventually ban Mallory should the false positive rate
exceeds some threshold.
Until Mallory is eventually banned, it seems to me that the worst she
can do is waste Bob's bandwidth and that of any nodes serving him
accurate information, such as Alice's filters and the blocks Bob
is misled into downloading to check for matches. The amount of
attacker:defender asymetry in the bandwidth wasted increases if
Mallory's filters become less accurate, but this also increases her
false positive rate and reduces the number of filters that need to be
seen before Bob bans her, so it seems to me (possibly naively) that this
is not a significant DoS vector.
-Dave
[1] Per BIP158 saying, "a Golomb-coded set (GCS), which matches all
items in the set with probability 1"
-------------- 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/20180602/9556f60f/attachment.sig>

2023-06-07 18:09:59 UTC

- reply

📅 Original date posted:2018-01-28
📝 Original message:On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev wrote:
> Peter Todd wrote:
> > In fact I considered only requiring an increase in fee rate, based on the
> > theory that if absolute fee went down, the transaction must be smaller and thus
> > miners could overall earn more from the additional transactions they could fit
> > into their block. But to do that properly requires considering whether or not
> > that's actually true in the particular state the mempool as a whole happens to
> > be in, so I ditched that idea early on for the much simpler criteria of both a
> > feerate and absolute fee increase.
>
> Why would you need to consider the whole mempool?
Imagine a miner is only concerned with creating the next block and his
mempool currently only has 750,000 vbytes in it. If two 250-vbyte
transactions each paying a feerate of 100 nanobitcoins per vbyte (50k
total) are replaced with one 325-vbyte transaction paying a feerate of
120 nBTC (39k total), the miner's potential income from mining the next
block is reduced by 11k nBTC.
Moving away from this easily worked example, the problem can still exist
even if a miner has enough transactions to fill the next block. For
replacement consideration only by increased feerate to be guaranteed
more profitable, one has to assume the mempool contains an effectively
continuous distribution of feerates. That may one day be true of the
mempool (it would be good, because it helps keep block production
regular sans subsidy) but it's often not the case these days.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180128/f2431b67/attachment.sig>

2023-06-07 18:08:42 UTC

- reply

📅 Original date posted:2017-12-13
📝 Original message:On Wed, Dec 13, 2017 at 01:46:09PM -0600, Jimmy Song via bitcoin-dev wrote:
> Hey all,
>
> I am proposing an informational BIP to standardize the term "bits". The
> term has been around a while, but having some formal informational standard
> helps give structure to how the term is used.
>
> https://github.com/jimmysong/bips/blob/unit-bias/bip-unit-bias.mediawiki
Wallets and other software is already using this term, so I think it's a
good idea to ensure its usage is normalized.
That said, I think the term is unnecessary and confusing given that
microbitcoins provides all of the same advantages and at least two
additional advantages:
- Microbitcoins is not a homonym for any other word in English (and
probably not in any other language), whereas "bit" and "bits" have
more than a dozen homonyms in English---some of which are quite common
in general currency usage, Bitcoin currency usage, or Bitcoin
technical usage.
- Microbitcoins trains users to understand SI prefixes, allowing them to
easily migrate from one prefix to the next. This will be important
when bitcoin prices rise to $10M USD[1] and the bits denomination has
the same problems the millibitcoin denomination has now, but it's also
useful in the short term when interacting with users who make very
large payments (bitcoin-scale) or very small payments
(nanobitcoin-scale).[2] Maybe a table of scale can emphasize this
point:
Wrong (IMO): Right (IMO):
--------------- --------------
BTC BTC
mBTC mBTC
bits µBTC
nBTC nBTC
[1] A rise in price to $10M doesn't require huge levels of growth---it
only requires time under the assumption that a percentage of bitcoins will
be lost every year due to wallet mishaps, failure to inherit bitcoins,
and other issues that remove bitcoins from circulation. In other words,
it's important to remember that Bitcoin is expected to become a
deflationary currency and plan accordingly.
[2] Although Bitcoin does not currently support committed
nanobitcoin-scale payments in the block chain, it can be supported in a
variety of ways by offchain systems---including (it is hypothesized)
trustless systems based on probabilistic payments.
Thanks,
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171213/7d7cdfb6/attachment.sig>

2023-06-07 17:49:35 UTC

- reply

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 02, 2016 at 05:53:46PM +0000, Gregory Maxwell wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it is now, or 25% of what it is
> now-- this is strong evidence that supermajority of the hashrate is
> equipment with state of the art power efficiency.
To avoid duplication of looking up this statistic among readers, here
are the various recent difficulties:
$ for i in $( seq 0 2016 60000 ) ; do echo -n $i blocks ago:' ' ; bitcoin-cli getblock $( bitcoin-cli getblockhash $(( 400857 - i )) ) | jshon -e difficulty ; done | column -t
0 blocks ago: 163491654908.95929
2016 blocks ago: 144116447847.34869
4032 blocks ago: 120033340651.237
6048 blocks ago: 113354299801.4711
8064 blocks ago: 103880340815.4559
10080 blocks ago: 93448670796.323807
12096 blocks ago: 79102380900.225983
14112 blocks ago: 72722780642.54718
16128 blocks ago: 65848255179.702606
18144 blocks ago: 62253982449.760818
20160 blocks ago: 60883825480.098282
22176 blocks ago: 60813224039.440353
24192 blocks ago: 59335351233.86657
26208 blocks ago: 56957648455.01001
28224 blocks ago: 54256630327.889961
30240 blocks ago: 52699842409.347008
32256 blocks ago: 52278304845.591682
34272 blocks ago: 51076366303.481934
36288 blocks ago: 49402014931.227463
38304 blocks ago: 49692386354.893837
40320 blocks ago: 47589591153.625008
42336 blocks ago: 48807487244.681381
44352 blocks ago: 47643398017.803436
46368 blocks ago: 47610564513.47126
48384 blocks ago: 49446390688.24144
50400 blocks ago: 46717549644.706421
52416 blocks ago: 47427554950.6483
54432 blocks ago: 46684376316.860291
56448 blocks ago: 44455415962.343803
58464 blocks ago: 41272873894.697021
<50% of current hash rate was last seen roughly six retarget periods (12
weeks) ago and <25% of current hash rate was last seen roughly 29 periods
(58 weeks) ago.
I think that's reasonably strong evidence for your thesis given that
the increases in hash rate from the introduction of new efficient
equipment are likely partly offset by the removal from the hash rate of
lower efficiency equipment, so the one-year tail of ~25% probably means
that less than 25% of operating equipment is one year old or older.
However, it is my understanding that most mining equipment can be run at
different hash rates. Is there any evidence that high-efficiency miners
today are using high clock speeds to produce more hashes per ASIC than
they will after halving? Is there any way to guess at how many fewer
hashes they might produce?
> If a pre-programmed ramp and drop is set then it has the risk of
> massively under-setting difficulty; which is also strongly undesirable
> (e.g. advanced inflation and exacerbating existing unintentional
> selfish mining)
Maybe I'm not thinking this through thoroughly, but I don't think it's
possible to significantly advance inflation unless the effective hash
rate increases by more than 300% at the halving. With the proposal
being replied to, if all mining equipment operation before the
halving continued operating after it, the effective increase would be
200%. That doubling in effective hash rate would've been offset in
advance through a reduction in the effective hash rate in the weeks
before the halving.
Exacerbated unintentional selfish mining is a much more significant
concern IMO, even if it's only for a short retarget period or two. This
is especially the case given the current high levels of centralization
and validationless mining on the network today, which we would not want
to reward by making those miners the only ones effectively capable of
creating blocks until difficulty adjusted. I had not thought of this
aspect; thank you for bringing it up.
> and that is before suggesting that miners voluntarily take a loss of
> inflation now.
Yes, I very much don't like that aspect, which is why I made sure to
mention it.
> So while I think this concern is generally implausible; I think it's
> prudent to have a difficulty step patch (e.g. a one time single point
> where a particular block is required to lower bits a set amount) ready
> to go in the unlikely case the network is stalled.
I think having that code ready in general is a good idea, and a one-time
change in nBits is sounds like a good and simple way to go about it.
Thank you for your insightful reply,
-Dave

2023-06-07 17:49:34 UTC

- reply

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote:
> To alleviate this risk, it seems reasonable to propose a hardfork to the
> difficulty adjustment algorithm so it can adapt quicker to such a significant
> drop in mining rate.
Having a well-reviewed hard fork patch for rapid difficulty adjustment
would seem to be a useful reserve for all sorts of possible problems.
That said, couldn't this specific potential situation be dealt with by a
relatively simple soft fork?
Let's say that, starting soon, miners require that valid block header
hashes be X% below the target value indicated by nBits. The X% changes
with each block, starting at 0% and increasing to 50% just before block
420,000 (the halving). This means the before the halving, every two
hashes are being treated as one hash, on average.
For blocks 420,000 and higher the code is disabled, immediately doubling
the effective hash rate at the same time the subsidy is halved,
potentially roughly canceling each other out to make a pre-halving hash
equal in economic value to a post-halving hash.
Of course, some (perhaps many) miners will not be profitable at the
post-halving subsidy level, so the steady increase in X% will force them
off the network at some point before the halving, hopefully in small
numbers rather than all at once like the halving would be expected to do.
For example, if the soft fork begins enforcement at block 410,000, then
X% can be increased 0.01% per block. Alice is a miner whose costs are
24BTC per block and she never claims tx fees for some reason, so her
profits now are always 25BTC per block. During the first difficulty
period after the soft fork is deployed, the cost to produce a hash will
increase like this,
0: 0% 500: 5% 1000: 10% 1500: 15% 2000: 20%
100: 1% 600: 6% 1100: 11% 1600: 16%
200: 2% 700: 7% 1200: 12% 1700: 17%
300: 3% 800: 8% 1300: 13% 1800: 18%
400: 4% 900: 9% 1400: 14% 1900: 19%
Somewhere around block 417, Alice will need to drop out because her
costs are now above 25BTC per block. With the loss of her hash rate,
the average interblock time will increase and the capacity will decrease
(all other things being equal). However, Bob whose costs are 20BTC per
block can keep mining through the period.
At the retarget, the difficulty will go down (the target goes up) to
account for the loss of Alice's hashes. It may even go down enough
that Alice can mine profitably for a few more blocks early in the new
period, but the increasing X% factor will make her uneconomical again,
and this time it might even make Bob uneconomical too near the end of
the period. However, Charlie whose costs are 12BTC per block will
never be uneconomical as he can continue mining profitably even after
the halving. Alice and Bob mining less will increase the percentage of
blocks Charlie produces before the retarget, steadily shifting the
dynamics of the mining network to the state expected after the halving
and hopefully minimizing the magnitude of any shocks.
This does create the question about whether this soft fork would be
ethical, as Alice and Bob may have invested money and time on the
assumption that their marginal hardware would be usable up until the
halving and with this soft fork they would become uneconomical earlier
than block 420,000. A counterargument here is such an investment was
always speculative given the vagaries of exchange rate fluctuation, so
it could be permissible to change the economics slightly in order to
help ensure all other Bitcoin users experience minimal disruption during
the halving.
Unless I'm missing something (likely) I think this proposal has the
advantage of fast rollout (if the mechanism of an adjusted target is as
simple as I think it could be) in a non-emergency manner without a hard
fork that would require all full nodes upgrade (plus maybe some SPV
software that check nBits, which they probably all should be doing
given it's in the block headers that they download anyway).
-Dave
P.S. I see Tier Nolan proposed something similar while I was writing
this. I think this proposal differs in its analysis to warrant a
possible duplicate posting.

2023-06-07 15:21:53 UTC

- reply

📅 Original date posted:2014-05-21
📝 Original message:On Wed, May 21, 2014 at 06:39:44PM +0200, Chris Beams wrote:
> I [was] searching for a way to enable signing by default [...]
> Unfortunately, there isn't one, meaning it's likely that most folks
> will forget to do this most of the time.
For all of my projects, I now I put this script in
.git/hooks/post-commit and post-merge:
#!/bin/bash -eu
if ! git log -n1 --show-signature | grep -q 'gpg: Good signature'
then
yes "FORGOT TO SIGN COMMIT MESSAGE"
exit 1
fi
So anytime I forget to sign, I get an obvious error and can immediately
run git commit --amend -S.
To automatically add a script like the one above to all new projects (plus
quickly add it old current projects), you can follow these instructions:
http://stackoverflow.com/questions/2293498/git-commit-hooks-global-settings
> If you're really serious about it, you should probably reject pull
> requests without signed commits; otherwise, signing becomes
> meaningless because only honest authors do it
I find signing my commits quite useful even on projects without a
default signing policy because it lets me diff from the last time I
provably reviewed the code. Here's my script for that:
#!/bin/bash -eu
KEY=F29EC4B7
last_signed_commit=$( git log --topo-order --show-signature --pretty=oneline \
| grep -m1 " gpg: Signature made.*RSA key ID $KEY" \
| sed 's/ .*//' \
| grep .
) || { echo "No signed commit found. Dying..." ; exit 1 ; }
set -x
git diff $last_signed_commit
By diffing against the last signed commit I made, I also review any
commits that were made using my name but which I didn't actually make,
such as squashes and rebases of my commits (and, of course, forgeries).
For anyone who's bored and wants to read a lot of text, I think the
definitive work on git signing is this:
http://mikegerwitz.com/papers/git-horror-story.html
-Dave
--
David A. Harding