BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)
I would like to use additional version bytes to indicate the type of
output script u
I would like to propose an efficient UTXO commitment scheme.
A UTXO commitment can be useful for:
1. Fast syncing a full node, by downloading the UTXO-set
2. Proofing (non) existence of a UTXO..
Various schemes have been proposed:
* Merkle/radix trees and variants; all of which have the problem
Hi,
Thanks Thomas. The procedure described in
http://docs.electrum.org/en/latest/seedphrase.html is really what I was
looking for ! I really don't see any point of following BIP49, If possible
it would be great if you can propose an alternative to BIP49 that follows
similar structure to what is us
Good morning all,
I have started to consider a unification of drivechains, blind merged mining,
and sidechain SPV proofs to form yet another solution for sidechains.
Briefly, below are the starting assumptions:
1. SPV proofs are a short chain of sidechain block headers. This is used to
prove
On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> 0x042393df , sxpr , segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb , segwit testnet public key
> 0x042224cc , stpr , segwit testnet private key
I am fine with both your proposal and p
On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> == === ===
> VersionPrefix Description
> == === ===
> 0x0488ade4 xprvP2PKH or P2SH
> 0x0488b21e xpubP2PKH or P2SH
> 0x
On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> Thanks Thomas. The procedure described in
> http://docs.electrum.org/en/latest/seedphrase.html is really what I was
> looking for ! I really don't see any point of following BIP49, If possible
> it would be great if you can pr
On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote:
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length. In the
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
On 05.09.2017 19:03, Luke Dashjr wrote:
> It seems desirable to use the same seed for all different script formats...
That does not seem desirable to everybody.
If you want to guarantee that users will be able to recover all their
funds from their mnemonic seed (and that is what they expect),
This is not a priority, not very important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the
utxo, but I think it would be slightl
Generally I like the idea, but maybe we should come up with a
(Bech32-based?) new standard that also includes the key birthdate (aka
"wallet birthdate").
Also I heard Core will mix addresses of all types on the same HD chain.
What prefix would it pick? "*pub"?
On 09/05/2017 12:25 PM, Thomas Voeg
Good morning Chris,
>>Basically, in case of a sidechain fork, the mainchain considers the longest
>>chain to be valid if it is longer by the SPV proof required length. In the
>>above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
>>longer than the other sidechain fork that e
We support a change to the version bits of the HD serialization that will
inform the receiving utility of the exact derivation method used for the
pubkeys. Third-parties handling xpubs must not require additional
information from the user about the derivation path or serialization format
of the add
). If they do not work together
> they will not be able to spend their s:coinbase_tx outputs until they
> extend their own sidechain by 288 blocks meaning they need to tie up a
> large amount of capital to go rogue on their fork.
>
> Another interesting thing might be to use the OP_WI
15 matches
Mail list logo
