Hi Tom,
Yesterday a PR was opened to do just that, with caveats:
https://github.com/bitcoin/bitcoin/pull/27609
For higher level tracking of the project:
https://github.com/bitcoin/bitcoin/issues/27463
Cheers,
Greg
On Wed, May 10, 2023 at 11:39 AM Tom Trevethan via bitcoin-dev <
bitcoin-dev@list
The submitpackage RPC is available on regtest in the current core release.
Is there any plan or timeline for deploying this on mainnet in the next
release? Can't find any recent discussion. It would be very helpful given
current (and likely future) issues with mempool purge.
Tom
__
Hi everyone,
I've made some significant changes to my package relay proposal based on
observations while implementing, feedback on this thread, and offline
discussions [1].
The new proposal is called Ancestor Package Relay, BIP331, and PR'd at
https://github.com/bitcoin/bips/pull/1382
The major
Hi Gloria,
Thanks for working on that,
> Always overestimating fees may sidestep this issue temporarily (while
mempool
> traffic is low and predictable), but this solution is not foolproof
> and wastes users' money. The feerate market can change due to sudden
> spikes in traffic (e.g. huge 12sat/
they arrive, not for rebroadcast, and we're not doing full
>> mempool set reconciliation. In any case, making sure a node receives the
>> transactions announced when it was offline is not something we guarantee,
>> not an intended use case for package relay, and not worsened by thi
uires identity in a
>> BIP152 scheme. For example 'header' and 'blockhash' fields can be replaced
>> with a Merkle root (e.g. "identity" field) for the package, uniquely
>> identifying the partially-ordered set of txs. And use of 'getdata'
for the package, uniquely
> identifying the partially-ordered set of txs. And use of 'getdata' (to
> obtain a package by hash) can be eliminated (not a use case).
>
> e
>
> > -Original Message-----
> > From: e...@voskuil.org
> > Sent: Wednesday, May
Hi aj, answering slightly out of order:
> what happens if the peer announcing packages to us is dishonest?
> They announce pkg X, say X has parents A B C and the fee rate is garbage.
But actually X has parent D and the fee rate is excellent. Do we request
the package from another peer, or every pe
use of 'getdata' (to
obtain a package by hash) can be eliminated (not a use case).
e
> -Original Message-
> From: e...@voskuil.org
> Sent: Wednesday, May 25, 2022 1:52 PM
> To: 'Anthony Towns' ; 'Bitcoin Protocol Discussion'
> ; 'Gloria Zhao&
> From: bitcoin-dev On
Behalf
> Of Anthony Towns via bitcoin-dev
> Sent: Wednesday, May 25, 2022 11:56 AM
> So the other thing is what happens if the peer announcing packages to us
is
> dishonest?
>
> They announce pkg X, say X has parents A B C and the fee rate is garbage.
But
> actually X has
On 24 May 2022 5:05:35 pm GMT-04:00, Gloria Zhao via bitcoin-dev
wrote:
>To clarify, in this situation, I'm imagining something like
>A: 0 sat, 100vB
>B: 1500 sat, 100vB
>C: 0 sat, 100vB
>X: 500 sat, 100vB
>feerate floor is 3sat/vB
>
>With the algo:
>> * is X alone above my fee rate? no, then fo
The set of txs is the graph. Anything else would just reproduce the tx graph
which must be traversed in any case.
Similarly the set of txs is the fee, the sigops, the size, and the weight. The
only information required by packaging is the association of the txs with each
other for the purpose o
Hi aj,
> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is
below fee floor while A+B and A+B+C+X are above fee floor you have the
problem though.
To clarify, in this situation, I'm imagining something like
A: 0 sat, 100vB
B: 1500 sat, 100vB
C: 0 sat, 100vB
X: 500 sat, 100vB
On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao wrote:
>> If you're asking for the package for "D", would a response telling you:
>> txid_D (500 sat, 100vB)
>> txid_A (0 sat, 100vB)
>> txid_B (2000 sat, 100 vB)
>> be better, in that case? Then the receiver can maybe do the logic
>> themselv
Hi aj,
> if you're writing a protocol that's
> dependent on people seeing that a package as a whole pays a competitive
> feerate, don't you want to know in advance what conditions the network
> is going to impose on your transactions in order to consider them as a
> package?
I do think unifying t
On Wed, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev wrote:
> > Does it make sense for these to be configurable, rather than implied
> > by the version?
> > … would it be better to either just not do sendpackages
> > at all if you're limiting ancestors in the mempool incompatibly
>
(To everyone):
I should have made it much clearer that version 1 is only supposed to solve
1 of the 2 use cases. I was a lot more focused on the fee-bumping use case,
since it’s more important. Orphan-fetching was added to the motivation
section last-minute because John Newbery mentioned to me “hey
On Tue, May 17, 2022 at 12:01:04PM -0400, Gloria Zhao via bitcoin-dev wrote:
> New Messages
> Three new protocol messages are added for use in any version of
> package relay. Additionally, each version of package relay must define
> its own inv type and "pckginfo" message version, referred
Hi Greg,
Thanks for reading!
>> A child-with-unconfirmed-parents package sent between nodes must abide by
the rules below, otherwise the package is malformed and the sender should
be disconnected.
>> However, if the child has confirmed parents, they must not be in the
package.
> If my naive und
Hi Gloria,
Thanks for working on this important proposal!
Still a lot to digest, but I just had on area of comment/question:
> A child-with-unconfirmed-parents package sent between nodes must abide by
the rules below, otherwise the package is malformed and the sender should
be disconnected.
> H
Hi everybody,
I’m writing to propose a set of p2p protocol changes to enable package
relay, soliciting feedback on the design and approach. Here is a link
to the most up-to-date proposal:
https://github.com/bitcoin/bips/pull/1324
If you have concept or approach feedback, *please respond on the
m
21 matches
Mail list logo
