Dustin Dettmer [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-01-22 to 2023-04-04
💬 Posted a total of 15 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:13:02

- reply

📅 Original date posted:2023-04-04
🗒️ Summary of this message: A race condition has been discovered in the `splice_locked` workflow, affecting `commitment_signed` and `announcement_signatures` messages. A solution has been proposed involving temporary storage of two items.
📝 Original message:
Hey,
In testing the `splice_locked` workflow I discovered a race condition which
is critical we solve correctly. The core problem happens if any channel
activity occurs in the time after `splice_locked` is sent and before
`splice_locked` is received.
`splice_locked` is defined as being locked once it is both sent and
received. It is fairly trivial to build a test case for this -- have a node
continually spamming payments while `splice_lock`ing is occurring and the
race condition will trigger relatively often.
The race condition effects two messages in particular: `commitment_signed`
and `announcement_signatures`. Below is an example of how it occurs with
commitment but the flow is essentially the same for announcement:
Legend:
Item -> means sent
Item <- means received
Chan X (implies a channel at block height X)
(Since these happen at different times)
Splice locked race condition example
Node A. Node B.
* Channel starts at block height 100
splice_locked ->
<- splice_locked
<- commitments_signed (Chan 100)
-> splice_locked
Node B now considers splice locked (Chan 106)
<- commitments_signed (Chan 106)
splice_locked <-
Node A now considers splice locked (Chan 106)
commitments_signed <- (Chan 100)
commitments_signed <- (Chan 106)
Node A considers the commitments_signed for Chan 100 invalid.
The commitments_signed for Chan 106 is, however, valid.
This example uses commitments_signed but remains a problem for any message
that depends on channel state.
The solution requires the temporary storing of two items:
* [scid] last_short_channel_id (the pre-splice short channel id)
* [bool] splice_await_commitment_succcess
After sending & receiving `splice_locked` (so called 'mutual splice lock),
the last_short_channel_id should be set to the pre-splice short channel id
and splice_await_commitment_succcess should be flagged to true.
If an `announcement_signatures` is received with an scid matching
`last_short_channel_id` the message should be ignored and the channel
connection should not be aborted (as it normally would).
If a `commitment_signed` message is received with the
tlv splice_info->splice_channel_id set to something other than the
successfully confirmed splice channel_id, the message should be ignored.
Once a revoke_and_ack is successfully sent OR received,
`last_short_channel_id` and `splice_await_commitment_succcess` should be
reset and normal validation of `announcement_signatures` and
`commitment_signed` should be resumed.
This solves the race condition while preserving as strict a validation of
messages as possible and removes the need to add new fields to these
messages.
Cheers,
Dusty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/15da6a65/attachment-0001.html>

2023-06-09 13:13:02

- reply

📅 Original date posted:2023-04-04
🗒️ Summary of this message: A proposal for simplifying and improving the splicing protocol has been shared, including sending one `commitment_signed` message per active commitment and not revoking previous commitments during a splice. A new name for `funding_amount` is suggested.
📝 Original message:
This all works for me, I will update my implementation to be compatible
with this approach.
Perhaps we should pick another name than `funding_amount` though?
The current spec (for `splice` & `splice_ack`) proposal uses
* [`u64`:`funding_satoshis`]
How about we go with something like:
* [`s64`:`relative_satoshis`]
In this new mid-splice single commit_sig approach, `tx_signature` will be a
little
overloaded as the commit ACK as well as the ending of STFU mode.
Which should work fine but we will need to modify the spec to no longer
"MUST" reply
`revoke_and_ack` to `commitment_signed` with a carve out for this special
case.
On Sun, Apr 2, 2023 at 7:25 PM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Good morning list,
>
> As some of you may know, we've been hard at work experimenting with
> splicing [1]. Splicing is a complex feature with a large design space.
> It was interesting to iterate on two separate implementations (eclair
> and cln) and discover the pain points, edge cases and things that could
> be improved in the protocol specification.
>
> After a few months trying out different approaches, we'd like to share
> changes that we believe make the splicing protocol simpler and more
> robust.
>
> We call "active commitments" the set of valid commitment transactions to
> which updates must be applied. While one (or more) splices are ongoing,
> there is more than one active commitment. When signing updates, we send
> one `commitment_signed` message per active commitment. We send those
> messages in the order in which the corresponding funding transactions
> have been created, which lets the receiver implicitly match every
> `commitment_signed` to their respective funding transaction.
>
> Once we've negotiated a new splice and reached the signing steps of the
> interactive-tx protocol, we send a single `commitment_signed` for that
> new commitment. We don't revoke the previous commitment(s), as this adds
> an unnecessary step. Conceptually, we're simply adding a new commitment
> to our active commitments set.
>
> A sample flow will look like this:
>
> Alice Bob
> | stfu |
> |----------------------------->|
> | stfu |
> |<-----------------------------|
> | splice_init |
> |----------------------------->|
> | splice_ack |
> |<-----------------------------|
> | |
> | <interactive-tx> |
> |<---------------------------->|
> | |
> | tx_complete |
> |----------------------------->|
> | tx_complete |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | tx_signatures |
> |----------------------------->|
> | tx_signatures |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob use the channel while
> the splice transaction is unconfirmed.
> |----------------------------->|
> | update_add_htlc |
> |----------------------------->|
> | commit_sig | Sign the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the old commitment.
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
> | splice_locked | The splice transaction confirms.
> |----------------------------->|
> | splice_locked |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob can use the channel
> and forget the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
>
> You can find many more details and sample flows in [2].
>
> We require nodes to store data about the funding transaction as soon as
> they send their `commitment_signed` message. This lets us handle every
> disconnection scenario safely, allowing us to either resume the signing
> steps on reconnection or forget the funding attempt. This is important
> because if peers disagree on the set of active commitments, this will
> lead to a force-close. In order to achieve that, we only need to add
> the `next_funding_txid` to the `channel_reestablish` message, and fill
> it when we're missing signatures from our peer. Again, you can find more
> details and sample flows in [2].
>
> Finally, after trying various approaches, we believe that the funding
> amounts that peer exchange in `splice_init` and `splice_ack` should be
> relative amounts based on each peer's current channel balance.
>
> If Alice sends `funding_amount = 200_000 sats`, it means she will be
> adding 200 000 sats to the channel's capacity (splice-in).
>
> If she sends `funding_amount = -50_000 sats`, it means she will be
> removing 50 000 sats from the channel's capacity (splice-out).
>
> This makes it easier to compute the new channel balances (otherwise we
> have to deal with millisatoshi to satoshi truncation) and better matches
> the UX that node operators are expecting, which means there is less need
> to glue code between the RPC exposed to the node operator and the actual
> underlying protocol.
>
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only *active* commitment but is unconfirmed. We'd be happy
> to discuss that in more details with other implementers to reduce the
> risk of introducing new vulnerabilities when shipping that feature.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/925b7825/attachment-0001.html>

2023-06-09 13:08:31

- reply

📅 Original date posted:2023-04-04
📝 Original message:
Hey,
In testing the `splice_locked` workflow I discovered a race condition which
is critical we solve correctly. The core problem happens if any channel
activity occurs in the time after `splice_locked` is sent and before
`splice_locked` is received.
`splice_locked` is defined as being locked once it is both sent and
received. It is fairly trivial to build a test case for this -- have a node
continually spamming payments while `splice_lock`ing is occurring and the
race condition will trigger relatively often.
The race condition effects two messages in particular: `commitment_signed`
and `announcement_signatures`. Below is an example of how it occurs with
commitment but the flow is essentially the same for announcement:
Legend:
Item -> means sent
Item <- means received
Chan X (implies a channel at block height X)
(Since these happen at different times)
Splice locked race condition example
Node A. Node B.
* Channel starts at block height 100
splice_locked ->
<- splice_locked
<- commitments_signed (Chan 100)
-> splice_locked
Node B now considers splice locked (Chan 106)
<- commitments_signed (Chan 106)
splice_locked <-
Node A now considers splice locked (Chan 106)
commitments_signed <- (Chan 100)
commitments_signed <- (Chan 106)
Node A considers the commitments_signed for Chan 100 invalid.
The commitments_signed for Chan 106 is, however, valid.
This example uses commitments_signed but remains a problem for any message
that depends on channel state.
The solution requires the temporary storing of two items:
* [scid] last_short_channel_id (the pre-splice short channel id)
* [bool] splice_await_commitment_succcess
After sending & receiving `splice_locked` (so called 'mutual splice lock),
the last_short_channel_id should be set to the pre-splice short channel id
and splice_await_commitment_succcess should be flagged to true.
If an `announcement_signatures` is received with an scid matching
`last_short_channel_id` the message should be ignored and the channel
connection should not be aborted (as it normally would).
If a `commitment_signed` message is received with the
tlv splice_info->splice_channel_id set to something other than the
successfully confirmed splice channel_id, the message should be ignored.
Once a revoke_and_ack is successfully sent OR received,
`last_short_channel_id` and `splice_await_commitment_succcess` should be
reset and normal validation of `announcement_signatures` and
`commitment_signed` should be resumed.
This solves the race condition while preserving as strict a validation of
messages as possible and removes the need to add new fields to these
messages.
Cheers,
Dusty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/15da6a65/attachment-0001.html>

2023-06-09 13:08:31

- reply

📅 Original date posted:2023-04-04
📝 Original message:
This all works for me, I will update my implementation to be compatible
with this approach.
Perhaps we should pick another name than `funding_amount` though?
The current spec (for `splice` & `splice_ack`) proposal uses
* [`u64`:`funding_satoshis`]
How about we go with something like:
* [`s64`:`relative_satoshis`]
In this new mid-splice single commit_sig approach, `tx_signature` will be a
little
overloaded as the commit ACK as well as the ending of STFU mode.
Which should work fine but we will need to modify the spec to no longer
"MUST" reply
`revoke_and_ack` to `commitment_signed` with a carve out for this special
case.
On Sun, Apr 2, 2023 at 7:25 PM Bastien TEINTURIER <bastien at acinq.fr> wrote:
> Good morning list,
>
> As some of you may know, we've been hard at work experimenting with
> splicing [1]. Splicing is a complex feature with a large design space.
> It was interesting to iterate on two separate implementations (eclair
> and cln) and discover the pain points, edge cases and things that could
> be improved in the protocol specification.
>
> After a few months trying out different approaches, we'd like to share
> changes that we believe make the splicing protocol simpler and more
> robust.
>
> We call "active commitments" the set of valid commitment transactions to
> which updates must be applied. While one (or more) splices are ongoing,
> there is more than one active commitment. When signing updates, we send
> one `commitment_signed` message per active commitment. We send those
> messages in the order in which the corresponding funding transactions
> have been created, which lets the receiver implicitly match every
> `commitment_signed` to their respective funding transaction.
>
> Once we've negotiated a new splice and reached the signing steps of the
> interactive-tx protocol, we send a single `commitment_signed` for that
> new commitment. We don't revoke the previous commitment(s), as this adds
> an unnecessary step. Conceptually, we're simply adding a new commitment
> to our active commitments set.
>
> A sample flow will look like this:
>
> Alice Bob
> | stfu |
> |----------------------------->|
> | stfu |
> |<-----------------------------|
> | splice_init |
> |----------------------------->|
> | splice_ack |
> |<-----------------------------|
> | |
> | <interactive-tx> |
> |<---------------------------->|
> | |
> | tx_complete |
> |----------------------------->|
> | tx_complete |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | tx_signatures |
> |----------------------------->|
> | tx_signatures |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob use the channel while
> the splice transaction is unconfirmed.
> |----------------------------->|
> | update_add_htlc |
> |----------------------------->|
> | commit_sig | Sign the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the old commitment.
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
> | splice_locked | The splice transaction confirms.
> |----------------------------->|
> | splice_locked |
> |<-----------------------------|
> | |
> | update_add_htlc | Alice and Bob can use the channel
> and forget the old commitment.
> |----------------------------->|
> | commit_sig | Sign the new commitment.
> |----------------------------->|
> | revoke_and_ack |
> |<-----------------------------|
> | commit_sig | Sign the new commitment.
> |<-----------------------------|
> | revoke_and_ack |
> |----------------------------->|
> | |
>
> You can find many more details and sample flows in [2].
>
> We require nodes to store data about the funding transaction as soon as
> they send their `commitment_signed` message. This lets us handle every
> disconnection scenario safely, allowing us to either resume the signing
> steps on reconnection or forget the funding attempt. This is important
> because if peers disagree on the set of active commitments, this will
> lead to a force-close. In order to achieve that, we only need to add
> the `next_funding_txid` to the `channel_reestablish` message, and fill
> it when we're missing signatures from our peer. Again, you can find more
> details and sample flows in [2].
>
> Finally, after trying various approaches, we believe that the funding
> amounts that peer exchange in `splice_init` and `splice_ack` should be
> relative amounts based on each peer's current channel balance.
>
> If Alice sends `funding_amount = 200_000 sats`, it means she will be
> adding 200 000 sats to the channel's capacity (splice-in).
>
> If she sends `funding_amount = -50_000 sats`, it means she will be
> removing 50 000 sats from the channel's capacity (splice-out).
>
> This makes it easier to compute the new channel balances (otherwise we
> have to deal with millisatoshi to satoshi truncation) and better matches
> the UX that node operators are expecting, which means there is less need
> to glue code between the RPC exposed to the node operator and the actual
> underlying protocol.
>
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only *active* commitment but is unconfirmed. We'd be happy
> to discuss that in more details with other implementers to reduce the
> risk of introducing new vulnerabilities when shipping that feature.
>
> Cheers,
> Bastien
>
> [1] https://github.com/lightning/bolts/pull/863
> [2] https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/925b7825/attachment-0001.html>

2023-06-09 13:06:39

- reply

📅 Original date posted:2022-08-09
📝 Original message:
As raised by @crypto-iq and @roasbeef, splices which permit arbitrary
script and input inclusion are at risk of being mempool pinned. Here we
present a solution to this splice pinning problem.
## Background
Pinning can be done by building a very large “junk” transaction that spends
from an important pending one. There are two known pinning vectors:
ancestor bulking thru addition of new inputs and junk pinning via the
spending of outputs.
Pinning pushes transactions to the bottom of the priority list without a
practical way of bumping it up. It is in effect a griefing attack, but in
the case of lightning can risk funds loss for HTLCs that have timed out for
a pinned commitment transaction.
Anchor outputs were introduced to lightning to mitigate the junk pinning
vector; they work by adding a minimum of `1 CSV` lock to all outputs on
the commitment transaction except for two “anchor” outputs, one for each
channel peer. (These take advantage of a 1-tx carve-out exception to enable
propagation of anchors despite any junk attached to the peer’s anchor).
## Mitigation
Splice transactions are susceptible to both junk and bulk pinning attacks.
Here’s how we propose mitigating these for splice.
[https://i.imgur.com/ayiO1Qt.png]
For “ancestor bulking”, every `tx_add_input` proposed by a peer must be
included in the UTXO set. A node MUST verify the presence of a proposed
input before adding it to the splicing transaction.
For “output junk”, every output included directly in a splice transaction
MUST be a v0 P2SH witness script which begins with a minimum of `1 CSV`
relative timelock. No output on the splice transaction will be spendable
until it is included in a block. This prevents junk pinning by removing the
ability to propose spends of splice outputs before the transaction is
included in a block.
There are two side effects here.
1) You cannot CPFP a splice transaction. All splices must be RBF’d to be
fee-bumped. The interactive tx protocol already provides a protocol for
initiating an RBF, which we re-use for splicing.
2) Arbitrary 3rd party scriptPubKeys are not permissible directly into the
splice tx.
In order for this to work we need to validate that every output has a 1
block CSV. There are two output types to consider:
1. New channel outpoints
2. Arbitrary splice out funds
For arbitrary splice out, funds can be included in a “fan-out” transaction.
Here standard pay to address etc outputs can live. The output leading to
the fan-out transaction will be a P2WSH that also begins with [OP_1,
OP_CHECKSEQUENCEVERIFY] (referred to from here on as ‘1 CSV’). Each splice
party SHOULD build a fan-out transaction for all arbitrary spliced outputs.
[https://i.imgur.com/40Dy3oq.png]
Splice-in transactions will not require any fan-out children as long as all
change goes into the channel outpoint.
For new channel outpoints, the v0 witness script should be modified to
start with [OP_1, OP_CHECKSEQUENCEVERIFY]. It needs to be the first item in
the script to allow easy validation that it is used and not hidden in a
false conditional. This would need to be applied to post-splice channel
outpoints and probably dual funding channels should add it as well so they
can be successfully included in splices.
### interactive tx protocol changes
For splices, `tx_add_output` MUST include the `witness_script` in the tlv.
Upon receiving outputs, nodes must validate the script matches the script
hash in the output and that it begins with a minimum of 1 CSV.
## HTLC Timeouts and Splices
Typically when this technique is used, one or two anchor outputs are added
to purposely allow for CPFP fee bumping. But, turns out, we already have a
usable anchor in the original commitment transaction! Very exciting.
The interactive tx protocol mandates that splice txs are RBF-enabled.
Broadcast splice proposals can be replaced out for the original commitment
transaction at any time. Since the original commitment transaction has
existing anchors, these may be used to increase fees on a force close. This
combined with every other output in the tree being locked behind a 1 CSV
means the force close will always have top mempool priority, mitigating the
“output junk” style pin.
- Nifty & Dusty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220809/d79c4ee0/attachment.html>

2023-06-07 22:59:52

- reply

📅 Original date posted:2021-10-03
📝 Original message:Jim Posen,
A few years ago you mentioned roastbeef’s proposal of a P2P message to
retrieve all prev-outputs for a given block:
1) Introduce a new P2P message to retrieve all prev-outputs for a given
> block (essentially the undo data in Core), and verify the scripts against
> the block by executing them. While this permits some forms of input script
> malleability (and thus cannot discriminate between all valid and invalid
> filters), it restricts what an attacker can do. This was proposed by Laolu
> AFAIK, and I believe this is how btcd is proceeding.
>
I’m trying to find the follow up on this. Was there discussion about it
under another name (thread, PR, bip etc)? Apologies if I’m being obtuse and
it’s easily found but for the life of me I can’t find any references.
Bip157 seems to not make any mention of it.
Thanks!
Dustin
>
If anyone has other ideas, I'd love to hear them.
>
> -jimpo
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html
>
>
>
> On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> TLDR: a change to BIP158 would allow decision on which filter chain is
>> correct at lower bandwith use
>>
>> Assume there is a BIP157 client that learned a filter header chain
>> earlier and is now offered an alternate reality by a newly connected BIP157
>> server.
>>
>> The client notices the alternate reality by routinely asking for filter
>> chain checkpoints after connecting to a new BIP157 server. A divergence at
>> a checkpoint means that the server disagrees the client's history at or
>> before the first diverging checkpoint. The client would then request the
>> filter headers between the last matching and first divergent checkpoint,
>> and quickly figure which block’s filter is the first that does not match
>> previous assumption, and request that filter from the server.
>>
>> The client downloads the corresponding block, checks that its header fits
>> the PoW secured best header chain, re-calculates merkle root of its
>> transaction list to know that it is complete and queries the filter to see
>> if every output script of every transaction is contained in there, if not
>> the server is lying, the case is closed, the server disconnected.
>>
>> Having all output scripts in the filter does not however guarantee that
>> the filter is correct since it might omit input scripts. Inputs scripts are
>> not part of the downloaded block, but are in some blocks before that.
>> Checking those are out of reach for lightweight client with tools given by
>> the current BIP.
>>
>> A remedy here would be an other filter chain on created and spent
>> outpoints as is implemented currently by Murmel. The outpoint filter chain
>> must offer a match for every spent output of the block with the divergent
>> filter, otherwise the interrogated server is lying since a PoW secured
>> block can not spend coins out of nowhere. Doing this check would already
>> force the client to download the outpoint filter history up-to the point of
>> divergence. Then the client would have to download and PoW check every
>> block that shows a match in outpoints until it figures that one of the
>> spent outputs has a script that was not in the server’s filter, in which
>> case the server is lying. If everything checks out then the previous
>> assumption on filter history was incorrect and should be replaced by the
>> history offered by the interrogated server.
>>
>> As you see the interrogation works with this added filter but is highly
>> ineffective. A really light client should not be forced to download lots of
>> blocks just to uncover a lying filter server. This would actually be an
>> easy DoS on light BIP157 clients.
>>
>> A better solution is a change to BIP158 such that the only filter
>> contains created scripts and spent outpoints. It appears to me that this
>> would serve well both wallets and interrogation of filter servers well:
>>
>> Wallets would recognize payments to their addresses by the filter as
>> output scripts are included, spends from the wallet would be recognized as
>> a wallet already knows outpoints of its previously received coins, so it
>> can query the filters for them.
>>
>> Interrogation of a filter server also simplifies, since the filter of the
>> block can be checked entirely against the contents of the same block. The
>> decision on filter correctness does not require more bandwith then download
>> of a block at the mismatching checkpoint. The client could only be forced
>> at max. to download 1/1000 th of the blockchain in addition to the filter
>> header history.
>>
>> Therefore I suggest to change BIP158 to have a base filter, defined as:
>>
>> A basic filter MUST contain exactly the following items for each
>> transaction in a block:
>> • Spent outpoints
>> • The scriptPubKey of each output, aside from all OP_RETURN
>> output scripts.
>>
>> Tamas Blummer
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211003/d02b1381/attachment-0001.html>

2023-06-07 18:23:14

- reply

📅 Original date posted:2020-03-24
📝 Original message:Hi Tim,
Hm, so what vectors is this supposed to mitigate? Leaking through the
> generated public keys? Anything else?
The main thing it’s protecting against is the stealing of your funds by
malicious hardware & software. There are some side benefits as well though.
- What are you trying to achieve? You seem to describe how you get
> from the setup to the goal in four steps but I don't understand what
> the setup is or what the goal is. (What's a storage solution?)
“Storage solution” is however you’re storing bitcoins today. Could be 12
words on some paper plus a computer running electrum. Could be a Ledger +
computer. Point is this technique works regardless of how you’re storing
your bitcoin.
- "all SW being compromised" do you mean "SW and HW compromised"? Note
> that SW and HW are parties in Pieter's writeup, not just abbreviations
> for software and hardware.
Yeah — if you split the SW party into two, “generator” and “validator” some
interesting and useful security properties emerge.
- Where are the two stages? You mention four steps.
“Generator” and “validator”. The generator creates and passes on receiving
addresses and withdrawal transactions (while remaining offline). The
validator double checks everything the generator did..
It works best if the validator is written entirely independently of the
generator.
- Where do you run the external software? On a second SW? Is this the
> second stage?
Yes
- Do you use unhardened derivation?
It’s an open ended solution — it would work with a (presumably
non-trivial/random) unhardened derivation just fine.
- What's a k commitment?
It is one of the proposed solutions presented (collected?) by Peter in this
thread. As I understand it k is used to generate R in the signature. By
committing to some k value the hardware wallet can’t “sneak out” your
private key(s) in the R value.
Best,
Dustin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200324/db2f881c/attachment.html>

2023-06-07 18:23:13

- reply

📅 Original date posted:2020-03-23
📝 Original message:Excellent write up, thanks for putting it together.
On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:
> When both the HW and the SW are compromised, clearly no security is
> possible,
> as all entities are controlled by the same party in that case.
>
While all SW being compromised can’t be stopped, splitting the SW over two
stages can dramatically increase your security if both HW & SW are
compromised. You can do that by:
1) When you setup your storage solution (whatever it may be), export the
xpub(s) and verify the receiving addresses match xpubs with external
software before receiving.
2) Generate and export withdrawal transactions offline
3) Verify transactions against the same xpub(s) using external software
4) Upload transactions
This mitigates, I believe, all leak vectors besides k/R hacking and
prechosen entropy.
I made an external tool to just that here:
https://github.com/koinkeep/gatekeeper
Would love to add k commitments when (if?) we settle on best practices for
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200323/114914d9/attachment.html>

2023-06-07 18:23:10

- reply

📅 Original date posted:2020-03-02
📝 Original message:Stepan have you spent any time considering a scheme that could involve HD
keys, preregistering n (ie. 1000) preimages, or something similar to reduce
the number of rounds at time of signing?
Would a zero knowledge solution allow for a reduction in rounds?
On Wed, Feb 26, 2020 at 7:13 PM Stepan Snigirev via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This topic appeared in the list a few times so I would like to discuss it
> in more detail and maybe push forward to standardization.
>
> We have to accept that any hardware wallet or an air-gapped computer we
> use to sign transactions can be compromised. It may happen via a supply
> chain attack or malicious firmware update.
>
> If the signer is isolated (faraday cage, airgap and so on), it still can
> leak private keys to the outside world by choosing nonces for signatures in
> a funny way such that the attacker can calculate our private keys. Back in
> the days, I wrote a small post [1] and a proof-of-concept demo [2] of this
> attack.
>
> Deterministic nonce generation can be verified only if we have private
> keys somewhere else. It doubles the attack surface - now we need to
> maintain two independent signers from different vendors that use the same
> private key and the same deterministic algorithm for a nonce generation. In
> addition to that, as Pieter mentioned in the Schnorr-BIP, deterministic
> nonces are vulnerable to glitch attacks [3].
>
> A simple way to fix it is by forcing the signer to use additional entropy
> from the host. This protocol takes away the privilege of picking nonce from
> the signer and doesn't require any secret material outside the signer.
>
> I suggest the following implementation of the protocol for signing a
> message `m`:
>
> 1. Host picks a random number `n` and sends its hash together with the
> message `m` to the signer.
> 2. Signer computes a nonce `k` it wants to use for signing. It can be
> either a deterministic scheme or using RNG. Signer commits to the chosen
> nonce by sending the corresponding point `R=kG` to the host.
> 3. Host sends the preimage `n` to the signer
> 4. Signer tweaks the nonce by this number `k'=k+n`, signs the message and
> sends back the signature (R',s)
> 5. Host verifies that the public point in the signature is tweaked by n:
> `R'==R+nG`
>
> ASCII-art:
>
> Host Untrusted signer
> 1. Pick random n --- sha256(n),m --> calculate nonce k
> 2. <------ R=kG ------ commit to k
> 3. Send preimage -------- n -------> sign with nonce k'=k+n
> 4. Verify R'==R+nG <------- sig ------
>
> I believe this protocol solves the problem. A drawback of this scheme is
> that the number of communication rounds doubles, so it might be pretty
> inconvenient for air-gapped remotely located signers.
>
> I also suggest the following extensions that might be helpful for certain
> use-cases
>
> # Extensions
>
> ## Multiple hosts
>
> There are some use-cases where multiple hosts are involved in the setup
> and all hosts don't trust each other and the signer. So all of them want to
> give extra entropy to the signer and verify that it was included. At the
> moment I have exactly this scenario - our main MCU doesn't trust the
> proprietary closed-source secure element, and the computer doesn't trust
> the whole hardware wallet. We need a way to convince both of them that
> their entropy was used in the nonce.
>
> It can be solved by concatenating hashes and preimages:
>
> Host1 ------- h(n1) --> Host 2 -- h(n1) h(n2) --> Signer
> <--- R+n2 G ----- <------- R -------
> ------- n1 -----> ------ n1 n2 ----> sign with k''=k+n1+n2
> Ver: R''==R'+n1 G Ver: R''==R+n2 G + n1 G
>
> In this case, the first host doesn't even notice that the second host was
> also using this protocol and mixing in the entropy. And the signer only
> needs to add one extra number to the nonce.
>
> ## Stateless random signer
>
> If the signer wants to generate a nonce non-deterministically but doesn't
> have an ability to store a generated nonce it may send back to the host
> some meta-information that would help it to re-generate the same nonce
> later. It can be for example additional random data used in a deterministic
> scheme, either encrypted and authenticated or just as a plain text (I am
> more a fan of encrypted though).
>
> Generally, the host shouldn't care what this data is about - he just
> stores the data between rounds and sends it back to the signer with the
> next round.
>
> # Implementation for PSBT
>
> We can either use proprietary fields [4] or define key-value pairs and add
> them to the BIP-174. Depends if anyone else is interested in using this
> protocol or not.
>
> I would suggest the following key-value per-input pairs assuming multiple
> hosts want to mix in external entropy:
>
> 1. Key: {PSBT_IN_EXT_NONCE_HASH}|{pubkey}, Value:
> {sha256(n1)}|{sha256(n2)}|...
> 2. Key: {PSBT_IN_NONCE_COMMITMENT}|{pubkey}, Value: {33-byte R point}
> 3. Key: {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey}, Value: {anything}
> 4. Key: {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey}, Value: {n1}|{n2}|...
>
> Then the signature from the signer is placed into existing
> PSBT_IN_PARTIAL_SIG. Combiner and Finaliser should verify that nonce in the
> signature includes external entropy and may remove their own entropy from
> the set. They should also verify that the values of the fields did not
> change between rounds.
>
> So, list, what do you think? Am I missing something? Would it be
> interesting to have this protocol standardized and deployed?
>
> # References
>
> [1]
> https://medium.com/cryptoadvance/hardware-wallets-can-be-hacked-but-this-is-fine-a6156bbd199
> [2]
> https://github.com/stepansnigirev/chosen_nonce_demo/blob/master/HD_key.ipynb
> [3]
> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing
> [4]
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#proprietary-use-type
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200302/7860629d/attachment.html>

2023-06-07 18:23:09

- reply

📅 Original date posted:2020-03-02
📝 Original message:+1 love that progress is being made on this. Excited to implement it once
it’s ready.
Would love if things like the incrementing number were included in the
standard as well.
Cheers! 🍻
On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for starting this initiative; it has been a long standing goal of
> mine to implement and release this protocol. Your blog post on the topic
> actually inspired me to pick up this work again a few months ago.
>
> Jonas Nick has implemented the protocol in the secp256k1 library for
> Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590
>
> I have backported the same scheme to ECDSA in the secp256k1 library
> here, so it can be used also for current transactions:
>
> https://github.com/bitcoin-core/secp256k1/pull/669
>
> I also made proof of concepts for the BitBox02 hw wallet firmware and
> BitBoxApp wallet to verify that the protocol also works well in practice.
>
> The actual scheme used in those implementations is a generalized
> sign-to-contract scheme, where the final nonce is computed as `k' = k +
> H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same
> for the anti nonce covert channel protocol. I suggest to use this scheme
> in PSBT as well.
>
> > We can either use proprietary fields [4] or define key-value pairs and
> add
> > them to the BIP-174. Depends if anyone else is interested in using this
> > protocol or not.
>
> I'd definitely be interested in seeing widespread support for this, and
> standardizing it would help with that.
>
> With PSBT used with an air-gapped signer, there is increased danger in
> implementing the protocol wrongly by relying on the contents of the PSBT
> alone in the final verification step of a signature. The PSBT must be
> verified carefully against state stored by the host for the PSBT.
> Otherwise the signer can for example change or pre-fill the relevant
> NONCE fields and leak the private keys anyway. Is there a current best
> practice for how a PSBT can be identified by the host to store/retrieve
> the state?
>
> Are there other examples in PSBT where the host can't trust the contents
> of the PSBT the signer returns (except of course for the parts the user
> can verify themselves, like recipients, amounts, etc.)? In any case,
> guidelines or conventions on how to avoid the pitfalls would be good.
>
> Best, Marko
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200302/668d43e4/attachment.html>

2023-06-07 18:20:06

- reply

📅 Original date posted:2019-08-07
📝 Original message:Does revaulting vault up with the same keys, or new ones?
Are they new derivation paths on the same key?
Would love some expanded explanation on how you’re proposing this would
work.
Thanks,
Dustin
On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> One of the biggest problems with the vault scheme (besides all of the
> setup data that has to be stored for a long time) is an attacker that
> silently steals the hot wallet private key and waits for the vault's
> owner to make a delayed-spend transaction to initiate a withdrawal
> from the vault. If the user was unaware of the theft of the key, then
> the attacker could steal the funds after the delay period.
>
> To mitigate this, it is important to choose a stipend or withdrawal
> amount per withdrawal period like x% of the funds. This limits the
> total stolen funds to x% because once the funds are stolen the user
> would know their hot key is compromised, and the user would know to
> instead use one of the other clawback paths during all of the future
> withdrawal delay periods instead of letting the delay timeout all the
> way to the (stolen) default/hot key.
>
> The reason why a loss limiter is the way to go is because there's
> currently no way (that I am aware of, without an upgrade) to force an
> attacker to reveal his key on the blockchain while also forcing the
> attacker to use a timelock before the key can spend the coins. I am
> curious about what the smallest least invasive soft-fork would be for
> enabling this kind of timelock. There are so many covenant proposals
> at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
> ....). Or there's crazy things like a fork that enables a transaction
> mode where the (timelock...) script of the first output is
> automatically prefixed to any of the other scripts on any of the other
> outputs when an input tries to spend in the future. A thief could add
> his key to a new output on the transaction and try to spend (just like
> a user would with a fresh/rotated key), but the OP_CSV would be
> automatically added to his script to implement the public observation
> delay window.
>
> Also, there was other previous work that I was only informed about
> today after posting my proposal, so I should mention these as related
> work:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
>
> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
> https://www.youtube.com/watch?v=diNxp3ZTquo
> https://bitcointalk.org/index.php?topic=5111656
>
> - Bryan
> http://heybryan.org/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190807/eb1c27d9/attachment.html>

2023-06-07 18:19:38

- reply

📅 Original date posted:2019-07-22
📝 Original message:Has someone built an analysis of how much extra bandwidth CFB uses over
bloom filters?
Obviously an active merchant in an impoverished country paying data rates
per MB will never be able to afford CFB — so those people are being cut out
of Bitcoin entirely. I suppose the plan is they will rely on custodial
services now?
But if someone receives say, 5 tx a day, how much more bandwidth precisely
will CFB require over bloom?
On Mon, Jul 22, 2019 at 8:10 AM Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote:
> > (less trustful and privacy-violating) alternative
> > over the coming years.
>
> The same paper that established the 'privacy-violating' conventional
> wisdom presented mitigations which have seen little exploration.
> https://eprint.iacr.org/2014/763.pdf
>
> Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive
> push into infrastructure for fully custodial accounts.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190722/95f794b2/attachment.html>

2023-06-07 18:16:50

- reply

📅 Original date posted:2019-03-10
📝 Original message:What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”
On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org <
> bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors at sprovoost.nl> wrote:
> >
> >
> >> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >>
> >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it. Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >>
> >> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190310/a327b977/attachment.html>

2023-06-07 18:16:37

- reply

📅 Original date posted:2019-03-13
📝 Original message:I’ve solved the same problem in a different way.
1) Submit a transaction
2) Collect all reject messages (that have matching txid in the reject data)
3) Wait 16 seconds after first error message received (chosen semirandomly
from trial and error) before processing errors
4) Wait for our txid to be submitted back to us through the mempool, if we
get it notify success and delete all pending error events
5) Signal failure with the given reject code if present (after the 16
seconds have elapsed)
6) If no error or success after 20 seconds, signal timeout failure
This works fairly well in testing. Newer transaction types seem to generate
reject codes 100% of the time (from at least one node when sending to 4
nodes) so this culling / time delay approach is essentially required.
On a related note: One issue is that RBF attempts with too small a fee and
accidental double spends (with enough fee for 1 tx but not a RBF) both
generate the same reject code: not enough fee.
A new reject code for RBF based too small of fee would definitely make for
a better user experience as I’ve seen this exact problem create confusion
for users.
Removing reject codes would make for a much worse user experience. “Your tx
failed and we have no idea why” would be the only message and it would
require waiting for a full timeout.
On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190313/29d5abf3/attachment-0001.html>

2023-06-07 18:16:35

- reply

📅 Original date posted:2019-03-06
📝 Original message:The reject message is helpful for figuring out why a tx was rejected.
It’s not useful for determining success, yes. Particularly when doing
segwit / newer types of tx’s as there’s always one or more pesky nodes who
still don’t support it and send a reject message for perfectly good tx’s.
But after a delay where you haven’t seen your tx propagated on the network,
it’s useful to know *why* it failed.
What would be nice is actually expanding this error message. Currently with
RBF tx’s “fee too small” is sent for both original transactions as well as
replacement transactions. So a bug accidentally sending spent txos
(currently in mempool) says “fee too small” instead of something more
appropriate like “fee too small to supersede existing unconfirmed
transaction.”
On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190305/bf105368/attachment.html>

2023-06-07 18:16:00

- reply

📅 Original date posted:2019-01-22
📝 Original message:How could you prove the private key is in the burning transaction?
On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This could could be a viable option. I think this is the right approach.
>
> Any downside to this and how much does this add to the blockweight if
> anything at all.
>
> Anonymouse
>
> > On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Good Morning Matt,
> >
> >> ### ZmnSCPxj,
> >>
> >> I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> > unique for each blockheight but still can be used to create signatures
> or verify?
> >
> > One possibility is to derive `R` using standard hierarchical derivation.
> > Then require that the staking pubkey be revealed to the sidechain
> network as actually being `staking_pubkey = P + hash(P || parent_R) * G`
> (possibly with some trivial protection against Taproot).
> > To sign for a blockheight `h`, you must use your public key `P` and the
> specific `R` we get from hierarchical derivation from `parent_R` and the
> blockheight as index.
> >
> >
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190122/46b08c8b/attachment-0001.html>

2023-06-07 18:16:00

- reply

📅 Original date posted:2019-01-22
📝 Original message:Wouldn’t a revealed private key for time locked funds create a race to
spend? I imagine miners who are paying attention would have the advantage
but it would still just be a race.
Would be nice to have the funds destroyed or sent somewhere specific. Like
if somehow the revealed key was actually itself a presigned transaction. Or
perhaps a 32 byte piece of a tx needed to complete it.
On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good Morning Matt,
>
> > ### ZmnSCPxj,
> >
> > I'm intrigued by this mechanism of using fixed R values to prevent
> multiple signatures, but how do we derive the R values in a way where they
> are
> unique for each blockheight but still can be used to create signatures or
> verify?
>
> One possibility is to derive `R` using standard hierarchical derivation.
> Then require that the staking pubkey be revealed to the sidechain network
> as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly
> with some trivial protection against Taproot).
> To sign for a blockheight `h`, you must use your public key `P` and the
> specific `R` we get from hierarchical derivation from `parent_R` and the
> blockheight as index.
>
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190122/0ef4688e/attachment.html>