Hi,
First, thanks for resurrecting this, I agree this is worth pursuing.
On Mon, Dec 11, 2017 at 4:04 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Nbits _never_ needs to be sent even with other consensus rules because
> its more or less necessarily a st
Hi,
I propose backdating the P2SH and Segwit version 0 script rules back to the
genesis block, as a way to simplify these consensus rules. Here's the
abstract from a draft BIP I wrote up to explain this change:
The Pay to Script Hash (P2SH, BIP 16) script rules and the Version 0
Witness Program
Hi all,
I've been working on a proposal to add support for relaying transactions
based on their wtxid, rather than just their txid. The current draft is at
https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki,
and for some background I'll paste the motivation sectio
Hi,
I'm proposing the addition of a new, optional p2p message to help improve
the way blocks are announced on the network. The draft BIP is available
here and pasted below:
https://gist.github.com/sdaftuar/465bf008f0a4768c0def
The goal of this p2p message is to facilitate nodes being able to
opt
On Thu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Is there actually a requirement for the new message? New nodes could just
> unilaterally switch to sending headers and current nodes would be
> compatible.
>
I don't believe that unila
t;
> On 24 September 2015 14:37:40 GMT-04:00, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >On Thu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev <
> >bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >>
>
Hi,
Recently Bitcoin Core merged a simplification to the consensus rules
surrounding deployment of BIPs 34, 66, and 65 (
https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
minor one, I thought it was worth documenting the rationale in a BIP for
posterity.
Here's the abstrac
even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi,
>
Hi,
There have been two threads recently that have made references to
peer-to-peer implementation details in Bitcoin Core's Segregated Witness
code that I would like to clarify.
In the thread "Issolated Bitcoin Nodes" (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013765.htm
Hi,
I've moved the bitcoin-dev list to bcc:, as this question is better suited
to forums dedicated to Bitcoin Core implementation specifics, rather than
the general bitcoin development list.
Please feel free in the future to ask questions like this on the
bitcoin-core-dev mailing list (https://li
I also do not support the BIP 148 UASF, and I'd like to add to the points
that Greg has already raised in this thread.
BIP 148 would introduce a new consensus rule that softforks out non-segwit
signalling blocks in some time period. I reject this consensus rule as
both arbitrary and needlessly di
On Thu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative, and the most likely effect of being that conservative is that
> the main blockchain becomes a sett
Hi,
Back in February I posted a proposal for WTXID-based transaction relay[1]
(now known as BIP 339), which included a proposal for feature negotiation
to take place prior to the VERACK message being received by each side. In
my email to this list, I had asked for feedback as to whether that prop
t its
> communication to the negotiated protocol, and allows ignoring of known but
> unsupported/disabled features.
>
> Sorry I missed your earlier post. Been distracted for a while.
>
> e
>
>
> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev <
> bit
Hi all,
Thanks for the helpful discussion.
My primary motivation in starting this thread was to establish what the
expectations are for new feature deployment (particularly whether the
protocol version should continue to be bumped or not), and I think I have
that answer -- different from what I p
Hi,
I think the topic of how to improve transaction relay policy and fee
bumping is an important one that needs to be worked on, so I'm glad
this is a topic of discussion. However I am pretty skeptical of this
consensus change proposal:
The Sponsor Vector TXIDs must also be in the block the tran
Hi,
I'm proposing the addition of a new, optional p2p message to allow peers to
communicate that they do not want to send or receive (loose) transactions
for the lifetime of a connection.
The goal of this message is to help facilitate connections on the network
over which only block-related data
On Thu, Jan 14, 2021 at 1:46 AM Anthony Towns wrote:
> > ==Specification==
> > # A new disabletx message is added, [...]
> > # A node that has sent or received a disabletx message to/from a peer
> MUST NOT send any of these messages to the peer:
> > ## inv messages for transactions
> > [...]
> >
Hi,
Thanks again for your work on this!
One question I have is about potential bandwidth waste in the case of nodes
running with different policy rules. Here's my understanding of a scenario
I think could happen:
1) Transaction A is both low-fee and non-standard to some nodes on the
network.
2)
(Apologies for the double-post -- I'm resending this message to the list
with much of the quoted text trimmed, because my first message was placed
in the moderation queue for being too large)
Hi,
Thanks for sharing your thoughts on packaged transaction relay.
The sole objective, as expressed in
I have more to say on this broader topic, but since you've brought up this
particular example I think it's worth commenting:
On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Is that true? Antoine claims [1] that opt-in RBF isn't enoug
AJ,
Thanks for the thoughtful post. I think your observations about how we view
mempool policy in the Bitcoin Core project, and how that seems to be
changing in the discussions around `-mempoolfullrbf`, are on-point and
provide a helpful baseline for considering future policy changes.
For a long
Hello bitcoin-dev,
The description in the OP is completely broken for the simple reason that
Bitcoin transactions can have multiple inputs, and so a single transaction
can conflict with multiple in-mempool transactions. The proposal would
limit the number of descendants of each in-mempool transact
23 matches
Mail list logo
