<unnamed>

Public Key

npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsqu

Profile Code

nprofile1qqsr22e42w9ht0x38pxt9x87mfs4u32yrxhvzpnr98yv8lem5x8w09qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dst53f54

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-09 13:13:02 UTC

- 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 UTC

- 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:06:39 UTC

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

- 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 UTC

- 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 UTC

- 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:16:37 UTC

- 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 UTC

- 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>