Hello,
We'd like to announce two recent updates to BIP324 ("Version 2 P2P
Encrypted Transport Protocol"). Some of these changes affect semantics
and some are backwards-incompatible.
While we are not aware of any implementations of BIP324 except the one
in Bitcoin Core (see
you can always do what protocols usually do. 1 byte is fine for now, but
reserve the top bit for "this is a two byte id" (128 choices). then when
you run out of room, set the top bit which means "this is a 2 byte id
(again with one reserved) and so-on. ie: how protobuf stores integers.
On
The relevant changes from this discussion about short 1-byte message
type IDs are now in a PR for the bips repo:
https://github.com/bitcoin/bips/pull/1428
On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote:
> On Mon, Feb 20, 2023 at 03:22:30PM +, Pieter Wuille via bitcoin-dev wrote:
>> On
On Mon, Feb 20, 2023 at 03:22:30PM +, Pieter Wuille via bitcoin-dev wrote:
> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns
> wrote:
> > On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev
> > wrote:
> > > > I think it's probably less complex to close some of
On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns
wrote:
> On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev wrote:
>
> > > I think it's probably less complex to close some of the doors?
> > > 2) are short ids available/meaningful to send prior to VERACK being
> >
On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev wrote:
> > I think it's probably less complex to close some of the doors?
> > 2) are short ids available/meaningful to send prior to VERACK being
> > completed?
> Ah, I hadn't considered this nuance. If we don't care about
On Friday, February 17th, 2023 at 10:51 AM, Anthony Towns via bitcoin-dev
wrote:
> I think it's probably less complex to close some of the doors?
> 2) are short ids available/meaningful to send prior to VERACK being
> completed?
Ah, I hadn't considered this nuance. If we don't care about
On Thu, Feb 16, 2023 at 05:43:22PM +, Dhruv M via bitcoin-dev wrote:
> Problem:
> - 1 byte message type IDs are lacking a co-ordination mechanism when multiple
> in-flight BIPs are proposing new message types as the id space is reduced
> form 12 ASCII bytes to 1 byte.
> - 1 byte IDs are
Attempting to summarize the thread thus far:
Problem:
- 1 byte message type IDs are lacking a co-ordination mechanism when multiple
in-flight BIPs are proposing new message types as the id space is reduced form
12 ASCII bytes to 1 byte.
- 1 byte IDs are scarce and should be allocated
On Fri, Jan 06, 2023 at 09:12:50AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Thu, Jan 05, 2023 at 10:06:29PM +, Pieter Wuille via bitcoin-dev wrote:
> > Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the
> > negotiation/coordination mechanism. There could still
On Thu, Jan 05, 2023 at 10:06:29PM +, Pieter Wuille via bitcoin-dev wrote:
> > > So this gives a uniform space which commands can be assigned from, and
> > > there is no strict need for thinking of the short-binary and
> > > long-alphabetic commands as distinct. In v2, some short ones would
--- Original Message ---
On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns
wrote:
> > * etc
> > So this gives a uniform space which commands can be assigned from, and
> > there is no strict need for thinking of the short-binary and
> > long-alphabetic commands as distinct. In
On Sat, Nov 12, 2022 at 03:23:16AM +, Pieter Wuille via bitcoin-dev wrote:
> Another idea...
> This means:
> * Every alphabetic command of L characters becomes L bytes.
> * 102 non-alphabetic 1-byte commands can be assigned.
> * 15708 non-alphabetic 2-byte commands can be assigned.
(There
On Sat, 12 Nov 2022, 11:01 Pieter Wuille via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think we can just merge the two and have a single variable-length
> command structure that can be used for both: command encodings are 1 to 12
> bytes, each byte's top bit indicating
Another idea...
On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev
wrote:
> On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
>
> > From what I understand we'll have about 35 message types on the network
> > with the addition of BIP324. 256 possible IDs sounds
Hi,
Thanks for the comments so far. I think these are all reasonable ideas.
Comments inline below.
On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
> From what I understand we'll have about 35 message types on the network
> with the addition of BIP324. 256 possible IDs sounds like
On Wed, Oct 26, 2022 at 04:39:02PM +, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 1. The most straightforward solution is using the BIP process
> From what I understand we'll have about 35 message types on the network with
> the addition of BIP324. 256 possible IDs sounds like plenty room to grow, but
> perhaps we can be a bit more conservative:
>
> We could use the first bit to signal a 2-byte message ID. That allows us to
>
Hi Pieter, hello list,
On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
1. The most straightforward solution is using the BIP process as-is: let BIP324
introduce a fixed initial table, and future BIPs which introduce new
messages can introduce new mapping entries for it. In
On Wed, Oct 26, 2022 at 16:39:02 +, Pieter Wuille via bitcoin-dev wrote:
[...]
> Our idea is to start out with approach (1)
[...]
> That said, we're not all that convinced this is the best approach, and feel
> this more a community/process question than a technical one, so it would be
> good
Hi all,
On Saturday, October 8th, 2022 at 8:59 AM, Dhruv M wrote:
> We have refreshed the proposal for BIP324, a new bitcoin P2P protocol
> featuring opportunistic encryption, a mild bandwidth reduction, and the
> ability
> to negotiate upgrades before exchanging application messages. We'd like
Hi all,
We have refreshed the proposal for BIP324, a new bitcoin P2P protocol
featuring opportunistic encryption, a mild bandwidth reduction, and the
ability
to negotiate upgrades before exchanging application messages. We'd like
to invite community members to review the BIP[1] and the related
22 matches
Mail list logo
