Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain

2017-02-13 Thread Sergio Demian Lerner via bitcoin-dev
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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain

2017-02-13 Thread John Hardy via bitcoin-dev
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'

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

2017-02-13 Thread Hampus Sjöberg via bitcoin-dev
> 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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Eric Voskuil via bitcoin-dev
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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Eric Voskuil via bitcoin-dev
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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Eric Voskuil via bitcoin-dev
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 >

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Jonas Schnelli via bitcoin-dev
>> 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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Jonas Schnelli via bitcoin-dev
> 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

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Eric Voskuil via bitcoin-dev
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. >

Re: [bitcoin-dev] BIP151 protocol incompatibility

2017-02-13 Thread Pieter Wuille via bitcoin-dev
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