On Mon, Feb 13, 2017 at 8:58 AM, John Hardy wrote:
> Hi Sergio,
>
>
> Thanks for your response, interesting work, very excited for RSK.
>
>
> I like the ephemeral payload, I suppose that aspect of my proposal could
> be described as ephemeral blockspace.
>
>
> I'm curious about the challenge phas
Sorry, I'm still missing it...
So your claim is that a) ignoring incoming messages of a type you do not
recognize is bad, and thus b) we should be disconnecting/banning peers which
send us messages we do not recognize (can you spell out why? Anyone is free to
send your host address messages/tran
Hi Sergio,
Thanks for your response, interesting work, very excited for RSK.
I like the ephemeral payload, I suppose that aspect of my proposal could be
described as ephemeral blockspace.
I'm curious about the challenge phase, what incentive do nodes to have to check
other nodes' responses?
> It gives miners complete control over the limit. They can make blocks of
any size (within the current limit), thus triggering the conditions by
which your proposal would raise the limit further.
There might be a long term incentive to keep increasing the blocksize, to
further centralize the netw
On 02/13/2017 02:16 AM, Matt Corallo wrote:
> For the reasons Pieter listed, an explicit part of our version
handshake and protocol negotiation is the exchange of otherwise-ignored
messages to set up optional features.
Only if the peer is at the protocol level that allows the message:
compact blo
On 02/13/2017 03:11 AM, Matt Corallo wrote:
> I believe many, if not all, of those messages are sent irrespective of
> version number.
In the interest of perfect clarity, see your code:
https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1372-L1403
Inside of the VERACK handle
On 02/13/2017 02:07 AM, Jonas Schnelli via bitcoin-dev wrote:
>> All adopted BIPs to date have followed this
>> pattern. This is not the same and it is not helpful to imply that it is
>> just following that pattern.
>
> Look at feefilter BIP 133
> (https://github.com/bitcoin/bips/blob/master/bip-0
>> Look at feefilter BIP 133
>> (https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
>> or sendheaders BIP130
>> (https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki#backward-compatibility)
>> Isn't it the same there?
> No. This is what I was referring
I believe many, if not all, of those messages are sent irrespective of version
number.
In any case, I fail to see how adding any additional messages which are ignored
by old peers amounts to a lack of backward compatibility.
On February 13, 2017 11:54:23 AM GMT+01:00, Eric Voskuil
wrote:
>On
For the reasons Pieter listed, an explicit part of our version handshake and
protocol negotiation is the exchange of otherwise-ignored messages to set up
optional features.
Peers that do not support this ignore such messages, just as if they had
indicated they wouldn't support it, see, eg BIP 1
> All adopted BIPs to date have followed this
> pattern. This is not the same and it is not helpful to imply that it is
> just following that pattern.
Look at feefilter BIP 133
(https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki#backward-compatibility)
or sendheaders BIP130
(https://g
On 02/13/2017 12:47 AM, Pieter Wuille wrote:
> On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev"
>
> The BIP151 proposal states:
>
> > This proposal is backward compatible. Non-supporting peers will ignore
> the encinit messages.
>
> This statement is incorrect. Sending cont
On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
The BIP151 proposal states:
> This proposal is backward compatible. Non-supporting peers will ignore
the encinit messages.
This statement is incorrect. Sending content that existing nodes do not
13 matches
Mail list logo
