[bitcoin-dev] Fwd: Services bit for xthin blocks

[Gregory Maxwell via bitcoin-dev]

On Tue, Mar 8, 2016 at 5:14 AM, Dave Scotese  wrote:
> I think a BIP is a good idea, but rather than making such a specific
> proposal as "Let's use bit 4 to indicate communication of thin blocks," how
> about a more general one like "Let's use bit(s?) 4(-5?) as user-agent

Not communicated in address messages, so useless for discovery.

I think any feature which could do this could use the BIP130 approach instead.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Services bit for xthin blocks

[Dave Scotese via bitcoin-dev]

I think a BIP is a good idea, but rather than making such a specific
proposal as "Let's use bit 4 to indicate communication of thin blocks," how
about a more general one like "Let's use bit(s?) 4(-5?) as user-agent
specific service bits so that if you customize your user-agent string, you
can use them for whatever you want"? That way, other clients can choose to
follow suit by saying so, or simply recognize the meaning (or lack thereof)
of those bits based on the user-agent setting.  This relieves future
development from the burden of agreeing on where to put what, and allows
time and utility to show when such a user-agent-specific service bit should
be moved into the protocol section of service bits.

PS I am not well versed in the creation of standards, but the reservation
of digital real estate for self-identified customization (bits, bytes, or
whatever that will never be used by the standard) such as what I'm
proposing seems like something that probably has a standard name.  "Public
provisioning" or something like that?

On Mon, Mar 7, 2016 at 12:51 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
>  wrote:
> > The Bitcoin Unlimited client needs a services bit to indicate that the
> node
> > is capable of communicating thin blocks.  We propose to use bit 4 as
> AFAIK
> > bit 3 is already earmarked for Segregated Witness.
>
> Does this functionality change peer selection?  If not, the preferred
> signaling mechanism is probably the one in BIP 130.
>
> Otherwise, I think the standard method for getting numbers has been to
> write a BIP documenting the usage. I don't know if that is intentional
> or just how things have previously happened; and I don't have much of
> an opinion on it.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Services bit for xthin blocks

[dagurval via bitcoin-dev]

Hi,

> Does this functionality change peer selection?

This bit will be used for selecting outgoing peers in Bitcoin XT.

On Mon, Mar 7, 2016 at 9:51 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
>  wrote:
> > The Bitcoin Unlimited client needs a services bit to indicate that the
> node
> > is capable of communicating thin blocks.  We propose to use bit 4 as
> AFAIK
> > bit 3 is already earmarked for Segregated Witness.
>
> Does this functionality change peer selection?  If not, the preferred
> signaling mechanism is probably the one in BIP 130.
>
> Otherwise, I think the standard method for getting numbers has been to
> write a BIP documenting the usage. I don't know if that is intentional
> or just how things have previously happened; and I don't have much of
> an opinion on it.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP44 & BIP32 chain address look-ahead limits

[Jameson Lopp via bitcoin-dev]

I recently ran into an issue while importing a Mycelium HD wallet where it
was not finding all of my funds - upon further investigation with Mycelium
devs we realized that the wallet was following the BIP44 spec correctly,
but BIP44 may have a flaw.

The problem was a result of my creating 16 transactions in Mycelium in a
fairly short timeframe, but the first 15 transactions ended up never
confirming while the 16th was confirmed. As a result, when I later
reimported the account from the master seed, the chain derivation stopped
upon hitting this large gap of unused addresses on the internal / change
chain.

BIP44 recommends that there need not be a lookahead on internal chains
"because internal chains receive only coins that come from the associated
external chains."
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit

BIP32 also notes that "the look-ahead for internal chains can be very
small, as no gaps are to be expected here."
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Full_wallet_sharing_m

It seems to me that there /is/ an edge case that can result in significant
gaps in internal chain address usage and as such, the recommendation should
be to look ahead on both external and internal chains when performing
account discovery. On a related note, the recommended look-ahead of 20 may
not be safe enough - perhaps it should be raised to 100 if not higher.

In addition to recommending a larger look-ahead, it may also be advisable
for BIP44 to recommend that wallets "fill in" gaps of unused chain
addresses by "looking back" from the current tip of the internal chain's
index when the wallet decides to create a new change address. This could
help mitigate the size of gaps caused by failed transactions.

- Jameson
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Services bit for xthin blocks

[Gregory Maxwell via bitcoin-dev]

On Mon, Mar 7, 2016 at 8:06 PM, G. Andrew Stone via bitcoin-dev
 wrote:
> The Bitcoin Unlimited client needs a services bit to indicate that the node
> is capable of communicating thin blocks.  We propose to use bit 4 as AFAIK
> bit 3 is already earmarked for Segregated Witness.

Does this functionality change peer selection?  If not, the preferred
signaling mechanism is probably the one in BIP 130.

Otherwise, I think the standard method for getting numbers has been to
write a BIP documenting the usage. I don't know if that is intentional
or just how things have previously happened; and I don't have much of
an opinion on it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Services bit for xthin blocks

[G. Andrew Stone via bitcoin-dev]

The Bitcoin Unlimited client needs a services bit to indicate that the node
is capable of communicating thin blocks.  We propose to use bit 4 as AFAIK
bit 3 is already earmarked for Segregated Witness.

Andrew
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev