On Wed, Jun 18, 2014 at 5:23 AM, Wladimir wrote:
> Anyhow -- back to the original proposal. I'm fine with setting aside
> part of the service bit space for experiments.
ACK
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd wrote:
> For my replace-by-fee implementation(1) I used service bit 26 to let
> preferential peering work so that replace-by-fee nodes could easily find
> each other. Of course, that's a temporary/experimental usage that can be
> dropped after wider adop
On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik wrote:
> I wrote a patch for string-based name extensions, circa 2011-2012. I
> agree that is preferable to unreadable bits, for reasons you cite.
>
> However, it was noted that extensions (or UUIDs etc.) would not be
> propagated around the network i
I wrote a patch for string-based name extensions, circa 2011-2012. I
agree that is preferable to unreadable bits, for reasons you cite.
However, it was noted that extensions (or UUIDs etc.) would not be
propagated around the network in "addr" messages, as service bits are.
On Tue, Jun 17, 2014 a
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir wrote:
> On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock
> wrote:
>> On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
>>> Yes, as I said in the github topic
>>> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
>>> string-based na
On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock wrote:
> On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
>> Yes, as I said in the github topic
>> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
>> string-based name space for extensions.
>
> Why use textual strings? These
On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
> Yes, as I said in the github topic
> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
> string-based name space for extensions.
Why use textual strings? These fields are not for human consumption. Why not
use UUIDs, which
On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd wrote:
> Alternately Wladimir J. van der Laan brought up elsewhere(2) the
> possibility for a wider notion of an extension namespace. I'm personally
> not convinced of the short-term need - we've got 64 service bits yet
> NODE_BLOOM is the first fully f
For my replace-by-fee implementation(1) I used service bit 26 to let
preferential peering work so that replace-by-fee nodes could easily find
each other. Of course, that's a temporary/experimental usage that can be
dropped after wider adoption, so I included the following comment:
// Reserve 2
9 matches
Mail list logo
