<unnamed>

Public Key

npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5am

Profile Code

nprofile1qqsv673vh28mtznpxyssrp0jy4mf9attvehmyjleeuqke2925jj2uqgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dskvsfu3

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:18:23 UTC

- reply

📅 Original date posted:2019-05-26
📝 Original message:The scriptSig when evaluated populates the stack so opcodes can operate
on them. A witness is essentially a list of data elements, quite similar
to the script stack (the witness is passed in as the script stack in fact)
OP_0 when evaluated pushes a _zero length_ value onto the stack, hence
the 00 (the varlen) in the witness serialization. OP_1 (51 in decimal)
pushes 0x01 to the stack, so when serialized would be 0101.
It may help to consider the entire witness structure as
vector<vector<data element>> and it's length must equal the number of
inputs - so a non-segwit input must have a zero sized witness.
On 5/26/19 12:56 AM, Aymeric Vitte via bitcoin-dev wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:59:02 UTC

- reply

📅 Original date posted:2017-04-05
📝 Original message:A schism is just that: miners can't ameliorate a HF transition in the way they can censor transactions without permission. This is how miners became a convenient way to activate soft-forks.
So while BIP9 can indicate the later censorship (a soft fork) in a way that nodes can follow (or not) a hardfork always requires nodes to upgrade to the version increasing the degrees of freedom of the system.
Signaling is less useful here: the change is not opt-in and will require coordination; and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening.
On 04/05/2017 12:08 PM, Tom Zander via bitcoin-dev wrote:
On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
BIP 9 provides a mechanism for having miners coordinate softforks because they can make the upgrade process smoother this way. But the same is not true of hardforks: miners are essentially irrelevant to them, and cannot make the process any smoother.
Can you explain how miners are irrelevant if the upgrade is not a soft fork?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/a0b4d424/attachment.html>

2023-06-07 17:54:20 UTC

- reply

📅 Original date posted:2016-11-16
📝 Original message:BIP30 actually was given similar treatment after a reasonable amount of
time had passed.
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
neither benefited nor improved bitcoin, but did document an event for
posterity.
This is not a hard fork. Removing ISM just means we've committed to
those soft-forks only locking into the chain we use now.
On 11/16/2016 01:58 PM, Eric Voskuil via bitcoin-dev wrote:
> This sort of statement represents one consequence of the
> aforementioned bad precedent.
>
> Are checkpoints good now? Are hard forks okay now?
>
> What is the maximum depth of a reorg allowed by this non-machine
> consensus?
>
> Shouldn't we just define a max depth so that all cruft deeper than
> that can just be discarded on a regular basis?
>
> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?
>
> The "BIP" is neither a Proposal (it's been decided, just documenting
> for posterity), nor an Improvement (there is no actual benefit, just
> some tidying up in the notoriously obtuse satoshi code base), nor
> Bitcoin (a hard fork defines an alt coin, so from Aug 4 forward it has
> been CoreCoin).
>
> e
>
> On Nov 16, 2016, at 5:29 AM, Jameson Lopp <jameson.lopp at gmail.com
> <mailto:jameson.lopp at gmail.com>> wrote:
>
>> Since "buried deployments" are specifically in reference to
>> historical consensus changes, I think the question is more one of
>> human consensus than machine consensus. Is there any disagreement
>> amongst Bitcoin users that BIP34 activated at block 227931, BIP65
>> activated at block 388381, and BIP66 activated at block 363725?
>> Somehow I doubt it.
>>
>> It seems to me that this change is merely cementing into place a few
>> attributes of the blockchain's history that are not in dispute.
>>
>> - Jameson
>>
>> On Tue, Nov 15, 2016 at 5:42 PM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Actually this does nothing to provide justification for this
>> consensus rule change. It is just an attempt to deflect criticism
>> from the fact that it is such a change.
>>
>> e
>>
>> > On Nov 15, 2016, at 9:45 AM, Btc Drak <btcdrak at gmail.com
>> <mailto:btcdrak at gmail.com>> wrote:
>> >
>> > I think this is already covered in the BIP text:-
>> >
>> > "As of November 2016, the most recent of these changes (BIP 65,
>> > enforced since December 2015) has nearly 50,000 blocks built on
>> top of
>> > it. The occurrence of such a reorg that would cause the activating
>> > block to be disconnected would raise fundamental concerns about the
>> > security assumptions of Bitcoin, a far bigger issue than any
>> > non-backwards compatible change.
>> >
>> > So while this proposal could theoretically result in a consensus
>> > split, it is extremely unlikely, and in particular any such
>> > circumstances would be sufficiently damaging to the Bitcoin
>> network to
>> > dwarf any concerns about the effects of this proposed change."
>> >
>> >
>> > On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >> NACK
>> >>
>> >> Horrible precedent (hardcoding rule changes based on the
>> assumption that
>> >> large forks indicate a catastrophic failure), extremely poor
>> process
>> >> (already shipped, now the discussion), and not even a material
>> performance
>> >> optimization (the checks are avoidable once activated until a
>> sufficiently
>> >> deep reorg deactivates them).
>> >>
>> >> e
>> >>
>> >> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Recently Bitcoin Core merged a simplification to the consensus
>> rules
>> >> surrounding deployment of BIPs 34, 66, and 65
>> >> (https://github.com/bitcoin/bitcoin/pull/8391
>> <https://github.com/bitcoin/bitcoin/pull/8391>), and though the
>> change is a
>> >> minor one, I thought it was worth documenting the rationale in
>> a BIP for
>> >> posterity.
>> >>
>> >> Here's the abstract:
>> >>
>> >> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated
>> via miner
>> >> signaling in block version numbers. Now that the chain has
>> long since passed
>> >> the blocks at which those consensus rules have triggered, we
>> can (as a
>> >> simplification and optimization) replace the trigger mechanism
>> by caching
>> >> the block heights at which those consensus rules became enforced.
>> >>
>> >> The full draft can be found here:
>> >>
>> >>
>> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>> <https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> >>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161116/794ee05f/attachment.html>

2023-06-07 17:52:52 UTC

- reply

📅 Original date posted:2016-08-24
📝 Original message:I want to pitch a use-case that might have been ignored in this discussion:
I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find this valuable.
I hope we can move forward with a protocol that suits both the hardware
people, and the people who find signing transactions in browsers
unsettling.
Maybe we the focus should move away from only servicing hardware, and
asking if the motivation is better captured by "allow users pick their
own ECDSA implementation, hardware or software", then working out what
we need to get us there.
On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
> On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to
> define such
> > rigid standards yet. Also, TREZOR concept (device as a server
> and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is
> clear NACK
> > for me.
>
> The current question – as already mentioned – is we ACK to work
> together
> on a signing protocol or if we NACK this before we even have started.
>
>
> ACK for Ledger. What's necessary to sign a transaction is well known,
> I don't see how driving any hardware wallet from the wallet itself or
> from a third party daemon implementing that URL scheme would make any
> difference, other than providing better devices interoperability, as
> well as easier maintenance and update paths for the wallets.
>
> --
> Nicolas Bacca | CTO, Ledger
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.sig>

2023-06-07 17:52:48 UTC

- reply

📅 Original date posted:2016-08-16
📝 Original message:Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in
Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.
The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH
Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].
The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.
I do think it enables two important choices for bitcoin users:
* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.
* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services
All the best
Thomas
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.sig>

2023-06-07 17:42:21 UTC

- reply

📅 Original date posted:2015-10-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Jean Pierre,
This is a problem I've considered before, though I have to say I prefer
your solution.
The problem is, how can a person who restores his wallet from just a
seed restore
all his multi-signature addresses with other parties?
Your proposal is nice because all participants are equal, and it
minimalizes the data
required for recovery because it's deterministic, and the (extended)
public key is the first
piece of metadata you'll ask for from others.. Let it be the only thing
we need!
Regards amending BIP45 - BIP's are not amended after the fact, however
bad it may be
in retrospect. It might be best to write a BIP specifying a
"pseudorandom & deterministic
path generation for HD/multi-signature accounts"
TK
On 04/10/15 16:18, Jean-Pierre Rupp via bitcoin-dev wrote:
> I have a possible solution:
>
> Take all public keys encoded in the purpose-specific extended public
> keys (m/45') of all cosigners and sort them lexicographically, according
> to BIP-45. Serialize this information and calculate its HASH160
> (RIPEMD160 ∘ HASH256). Split the output in five 32-bit chunks, setting
> the MSB on all of them to 0. Use these 32-bit chunks to build a
> derivation path from the purpose-specific extended public keys. Treat
> this derivation path as if it was the purpose-specific extended public
> key in BIP-45.
>
> This scheme will avoid public key sharing, and as long as you share your
> purpose-specific extended public key only with your cosigners, it should
> be relatively hard for a passive observer to link activity between
> different cosigning accounts.
>
> On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
>> Hello,
>>
>> I have been reviewing BIP-45 today. There is a privacy problem with it
>> that should at least be mentioned in the document.
>>
>> When using the same extended public key for all multisig activity, and
>> dealing with different cosigners in separate multisig accounts, reuse of
>> the same set of public keys means that all cosigners from all accounts
>> will be able to monitor multisig activity from every other cosigner, in
>> every other account.
>>
>> Besides privacy considerations, HD wallet's non-reuse of public keys
>> provide some defence against wallets that do not implement deterministic
>> signing, and use poor entropy for signature nonces.
>>
>> Unless users are expected to establish a single cosigning account, this
>> scheme will result in reuse of public keys, and degradation of privacy.
>>
>> I understand that for convenience it is useful to have a single extended
>> public key that can be handed to every cosigner. This makes setting up
>> accounts or recovering from data loss a easier.
>>
>> I suggest that privacy & potential security degradation due to increased
>> public key reuse in the case of users with multiple multisig accounts
>> should get a mention in the BIP-45 document.
>>
>> Greetings
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJWEWDlAAoJEAiDZR291eTlFAkQALgiiKX+VzLOwLK13S0EcE0v
RZeC8hqS5AEi/wpOYC2H0TFaHhDqDgy7Pt7nTt/vfOr9QFbJm076I/iFIhLPPAWf
rRg5kzL6ebOyX1NLmALcNgE9L+Jwz09kdzLUj+xZesJfu1AiSMgND38vFq4CmRfg
YSnWI4iMSP3OoMO5Akjq7m9Ww/lENPDmxTrz2ET9KwKPEkjrdt3c0ipQcs+/vGuU
RfRCUwxcdu/0nl5JhltxMV6wUMjdJ3AGbamWZpL+vA+jT5paOd4ORjc64huQGtFQ
W7l8ynbbVqtXlYYs9mXCMm70316sdo5ZpOXzQmplwtuHWVYt9ssS1aLkBoLYCBtU
i95Ki79S2ooeIjDEqI6FKpgVnLTmUbhudg/vk7eA0+RoNh3SBEHV2HmZ5yTBNtjk
P2a2tRmrbe3CmrdogbJzaweZenzoR82PziF7DAb/2JqtccPSdTW/GrAGyCoe0O5B
PId/iELHKpQepvybp+5PI6q2Atgzut4ze+a2vBiXjbiU3j0sX0XWg5fu9R9Ea1Bw
5+BY71GSa20OTDYEsp5esrl5/AUFj4ivB2OWFok77nGi2rTK+rKL3qMvbmYjAKUV
rWN4m6r8pU2hdhBCEJkXjg57whiMYn5w7ILlrbK5lLEu5qo0txoRtBPaid+y4mkK
moZU0LtvSQSX6ZaojQ/v
=Vs6z
-----END PGP SIGNATURE-----

2023-06-07 15:31:46 UTC

- reply

📅 Original date posted:2015-03-11
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
I just created a PR on bitcoin/bips for a proposed standard for creating
standard multisignature P2SH addresses given m, and a set of public keys.
https://github.com/bitcoin/bips/pull/146
I used BIP0090 as a place-holder, but I would like to request a BIP
number for this now.
All the best,
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJVACrVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVkGgQAIUpyA3PsNjCA99W1HwFI7Ra
+g+JTtXBdhJSvVpv67TlaPZzp4LP7rRW/U1Nv0JYvhpQZTsV/xcMSKpy56d3S50M
Yvxwy51Aco1LEPC1vuiE2aJ8lDwCrXJMxJwfdBp6iNwf0huZNrsqZNKUHwMepePj
PYlGBkyfnp7QXo0ZkYBCJ2yerir5emKap3AibijRtkTrq6K1+YRk/9UZHllZSmmk
/B8n6xy/+v65uoAriVwKkX7H0bXmNTjleMzXbm/+Zhh9qfEnp2zqGmBIk5ooV5x4
3Flb76EYAMXibfAQ2+NPoCiPxCDIEWIsWqyzOC9zWX1QZN55qT3s/p7olYtaYheD
mf2xZ2pI/cIxpiYGfFEn4C/l0dOCNFLfElgsFcn4RsqRE41Grm+MGAPrf7S5bstp
TPIALOoVShucHaMvD/6sdK51hC54MKktNDtzTIumnWtOMwTy9qbELIcNvD8DaFe8
7FVZ7Vndj2FfXCNBF2EHzmy4D4+BE2YZ07pLQVUrc79oidUTs/099PsnUNOEYz0l
Y4IL/5qJMep9PJlj+IlbfXFX0zfTLJF7vJgjYMybr0iKP66iTtuHc46QFxTRyIhC
dMLXbSqm9X5zEc1j9Q50dSE5rqIT3/gkQe7nWFwf4xC7hlLAXSm8HuqwRSkZdP19
2byvsvoZ+4D4drXHXXpi
=QU8i
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150311/9a51df90/attachment.html>

2023-06-07 15:16:22 UTC

- reply

📅 Original date posted:2014-03-27
📝 Original message:Isn't the length of the seed arbitrary anyway? Once decoded using whatever
mnemonic implementation (electrums, or BIP0039) the bytestream is
immediately passed to HMAC-SHA256 to generate the master key. No matter
what your initial entropy is, it would be hashed anyway.
On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike at plan99.net> wrote:
> Ah, BIP32 allows for a range of entropy sizes and it so happens that they
> picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedom?
>
>
> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> By the way, I just noticed that greenaddress.it is creating seeds that
>> have 24 words instead of 12. Does anyone know what's up with that? They
>> claim to be using BIP32 wallets so I wanted to see if they were using the
>> default structure and if so, whether bitcoinj was compatible with it
>> (before I switch to the one discussed here). But it seems we fall at the
>> first hurdle ...
>>
>>
>> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1 at gmx.de> wrote:
>>
>>>
>>>
>>> Le 27/03/2014 12:30, Marek Palatinus a écrit :
>>> > Ah, I forget to two things, which should be into the BIP as well:
>>> >
>>> > a) Gap factor for addresses; as Thomas mentioned, although some
>>> software
>>> > can watch almost unlimited amount of unused addresses, this is serious
>>> > concern for lightweight or server-based wallets like Electrum or
>>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>>> > experience so far) quite sane for most of users.
>>>
>>>
>>> Yes, I was planning to increase the number of available unused addresses
>>> to 10 or 20 in the bip32 version of Electrum.
>>>
>>> Related to this, here is another idea I would like to submit:
>>>
>>> Instead of using a "gap limit" (maximal number of consecutive unused
>>> addresses), I think we should get rid of the topology, and simply count
>>> the number of unused addresses since the beginning of the sequence.
>>> Indeed, the topology of the sequence of addresses is of no interest to
>>> the user. Users often misinterpret "gap limit" as the "number of unused
>>> addresses available", so I think we should just give them what they want
>>> :) This is easier to understand, and it makes things more predictable,
>>> because the wallet will always display the same number of unused
>>> addresses (except when it is waiting for confirmations).
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/1de2fe0e/attachment.html>