<unnamed>

Public Key

npub1836zrd49hyr9aad6tvgng94uyy4r3xjcs5lkdza0ld9g5p8jkd0speeux6

Profile Code

nprofile1qqsrcappk6jmjpj77ka9kyf5z67zz23cnfvg20mx3whlkj52qnetxhcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvcphy70

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:35:21 UTC

- reply

📅 Original date posted:2015-05-26
📝 Original message:Indeed Jim, your internet connection makes a good reason why I don't like 20mb blocks (right now). It would take you well over a minute to download the block before you could even relay it on, so much slow down in propagation! Yes I do see how decreasing the time to create blocks is a bit of a band-aid fix, and to use tge term I've seen mentioned here "kicking the can down the road" I agree that this is doing this, however as you say bandwidth is our biggest enemy right now and so hopefully by the time we exceed the capacity gained by the decrease in block time, we can then look to bump up block size because hopefully 20mbps connections will be baseline by then etc.
________________________________
From: Jim Phillips<mailto:jim at ergophobia.org>
Sent: ‎26/‎05/‎2015 12:53 PM
To: Thy Shizzle<mailto:thyshizzle at outlook.com>
Cc: Mike Hearn<mailto:mike at plan99.net>; Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
Frankly I'm good with either way. I'm definitely in favor of faster
confirmation times.
The important thing is that we need to increase the amount of transactions
that get into blocks over a given time frame to a point that is in line
with what current technology can handle. We can handle WAY more than we are
doing right now. The Bitcoin network is not currently Disk, CPU, or RAM
bound.. Not even close. The metric we're closest to being restricted by
would be Network bandwidth. I live in a developing country. 2Mbps is a
typical broadband speed here (although 5Mbps and 10Mbps connections are
affordable). That equates to about 17MB per minute, or 170x more capacity
than what I need to receive a full copy of the blockchain if I only talk to
one peer. If I relay to say 10 peers, I can still handle 17x larger block
sizes on a slow 2Mbps connection.
Also, even if we reduce the difficulty so that we're doing 1MB blocks every
minute, that's still only 10MB every 10 minutes. Eventually we're going to
have to increase that, and we can only reduce the confirmation period so
much. I think someone once said 30 seconds or so is about the shortest
period you can practically achieve.
--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>
*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <thyshizzle at outlook.com> wrote:
> Nah don't make blocks 20mb, then you are slowing down block propagation
> and blowing out conf tikes as a result. Just decrease the time it takes to
> make a 1mb block, then you still see the same propagation times today and
> just increase the transaction throughput.
> ------------------------------
> From: Jim Phillips <jim at ergophobia.org>
> Sent: ‎26/‎05/‎2015 12:27 PM
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>
> This meme about datacenter-sized nodes has to die. The Bitcoin wiki is
> down right now, but I showed years ago that you could keep up with VISA on
> a single well specced server with today's technology. Only people living in
> a dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
> ... And will certainly NEVER have if we can't solve the capacity problem
> SOON.
>
> In a former life, I was a capacity planner for Bank of America's
> mid-range server group. We had one hard and fast rule. When you are
> typically exceeding 75% of capacity on a given metric, it's time to expand
> capacity. Period. You don't do silly things like adjusting the business
> model to disincentivize use. Unless there's some flaw in the system and
> it's leaking resources, if usage has increased to the point where you are
> at or near the limits of capacity, you expand capacity. It's as simple as
> that, and I've found that same rule fits quite well in a number of systems.
>
> In Bitcoin, we're not leaking resources. There's no flaw. The system is
> performing as intended. Usage is increasing because it works so well, and
> there is huge potential for future growth as we identify more uses and
> attract more users. There might be a few technical things we can do to
> reduce consumption, but the metric we're concerned with right now is how
> many transactions we can fit in a block. We've broken through the 75%
> marker and are regularly bumping up against the 100% limit.
>
> It is time to stop debating this and take action to expand capacity. The
> only questions that should remain are how much capacity do we add, and how
> soon can we do it. Given that most existing computer systems and networks
> can easily handle 20MB blocks every 10 minutes, and given that that will
> increase capacity 20-fold, I can't think of a single reason why we can't go
> to 20MB as soon as humanly possible. And in a few years, when the average
> block size is over 15MB, we bump it up again to as high as we can go then
> without pushing typical computers or networks beyond their capacity. We can
> worry about ways to slow down growth without affecting the usefulness of
> Bitcoin as we get closer to the hard technical limits on our capacity.
>
> And you know what else? If miners need higher fees to accommodate the
> costs of bigger blocks, they can configure their nodes to only mine
> transactions with higher fees.. Let the miners decide how to charge enough
> to pay for their costs. We don't need to cripple the network just for them.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy *
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/40d01923/attachment.html>

2023-06-07 15:35:20 UTC

- reply

📅 Original date posted:2015-05-25
📝 Original message:I wouldn't say same trade-off because you need the whole 20mb block before you can start to use it where as a 1mb block can be used quicker thus transactions found in tge block quicker etc. As for tge higher rate of orphans, I think this would be complimented by a faster correction rate, so if you're pumping out blocks at a rate of 1 per minute, if we get a fork and the next block comes in 10 minutes and is the decider, it took 10 minutes to determine which block is the orphan. But at a rate of 1 block per 1 minute then it only takes 1 minute to resolve the orphan (obviously this is very simplified) so I'm not so sure that orphan rate is a big issue here. Indeed you would need to draw upon more confirmations for easier block creation but surely that is not an issue?
Why would sync time be longer as opposed to 20mb blocks?
________________________________
From: gabe appleton<mailto:gappleto97 at gmail.com>
Sent: ‎26/‎05/‎2015 12:41 PM
To: Thy Shizzle<mailto:thyshizzle at outlook.com>
Cc: Jim Phillips<mailto:jim at ergophobia.org>; Mike Hearn<mailto:mike at plan99.net>; Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
But don't you see the same trade-off in the end there? You're still
propagating the same amount of data over the same amount of time, so unless
I misunderstand, the costs of such a move should be approximately the same,
just in different areas. The risks as I understand are as follows:
20MB:
1. Longer per-block propagation (eventually)
2. Longer processing time (eventually)
3. Longer sync time
1 Minute:
1. Weaker individual confirmations (approx. equal per confirmation*time)
2. Higher orphan rate (immediately)
3. Longer sync time
That risk-set makes me want a middle-ground approach. Something where the
immediate consequences aren't all that strong, and where we have some idea
of what to do in the future. Is there any chance we can get decent network
simulations at various configurations (5MB/4min, etc)? Perhaps
re-appropriate the testnet?
On Mon, May 25, 2015 at 10:30 PM, Thy Shizzle <thyshizzle at outlook.com>
wrote:
> Nah don't make blocks 20mb, then you are slowing down block propagation
> and blowing out conf tikes as a result. Just decrease the time it takes to
> make a 1mb block, then you still see the same propagation times today and
> just increase the transaction throughput.
> ------------------------------
> From: Jim Phillips <jim at ergophobia.org>
> Sent: ‎26/‎05/‎2015 12:27 PM
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>
> This meme about datacenter-sized nodes has to die. The Bitcoin wiki is
> down right now, but I showed years ago that you could keep up with VISA on
> a single well specced server with today's technology. Only people living in
> a dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
> ... And will certainly NEVER have if we can't solve the capacity problem
> SOON.
>
> In a former life, I was a capacity planner for Bank of America's
> mid-range server group. We had one hard and fast rule. When you are
> typically exceeding 75% of capacity on a given metric, it's time to expand
> capacity. Period. You don't do silly things like adjusting the business
> model to disincentivize use. Unless there's some flaw in the system and
> it's leaking resources, if usage has increased to the point where you are
> at or near the limits of capacity, you expand capacity. It's as simple as
> that, and I've found that same rule fits quite well in a number of systems.
>
> In Bitcoin, we're not leaking resources. There's no flaw. The system is
> performing as intended. Usage is increasing because it works so well, and
> there is huge potential for future growth as we identify more uses and
> attract more users. There might be a few technical things we can do to
> reduce consumption, but the metric we're concerned with right now is how
> many transactions we can fit in a block. We've broken through the 75%
> marker and are regularly bumping up against the 100% limit.
>
> It is time to stop debating this and take action to expand capacity. The
> only questions that should remain are how much capacity do we add, and how
> soon can we do it. Given that most existing computer systems and networks
> can easily handle 20MB blocks every 10 minutes, and given that that will
> increase capacity 20-fold, I can't think of a single reason why we can't go
> to 20MB as soon as humanly possible. And in a few years, when the average
> block size is over 15MB, we bump it up again to as high as we can go then
> without pushing typical computers or networks beyond their capacity. We can
> worry about ways to slow down growth without affecting the usefulness of
> Bitcoin as we get closer to the hard technical limits on our capacity.
>
> And you know what else? If miners need higher fees to accommodate the
> costs of bigger blocks, they can configure their nodes to only mine
> transactions with higher fees.. Let the miners decide how to charge enough
> to pay for their costs. We don't need to cripple the network just for them.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy *
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150526/f03594e9/attachment.html>

2023-06-07 15:35:19 UTC

- reply

📅 Original date posted:2015-05-25
📝 Original message:Nah don't make blocks 20mb, then you are slowing down block propagation and blowing out conf tikes as a result. Just decrease the time it takes to make a 1mb block, then you still see the same propagation times today and just increase the transaction throughput.
________________________________
From: Jim Phillips<mailto:jim at ergophobia.org>
Sent: ‎26/‎05/‎2015 12:27 PM
To: Mike Hearn<mailto:mike at plan99.net>
Cc: Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
> right now, but I showed years ago that you could keep up with VISA on a
> single well specced server with today's technology. Only people living in a
> dreamworld think that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
... And will certainly NEVER have if we can't solve the capacity problem
SOON.
In a former life, I was a capacity planner for Bank of America's mid-range
server group. We had one hard and fast rule. When you are typically
exceeding 75% of capacity on a given metric, it's time to expand capacity.
Period. You don't do silly things like adjusting the business model to
disincentivize use. Unless there's some flaw in the system and it's leaking
resources, if usage has increased to the point where you are at or near the
limits of capacity, you expand capacity. It's as simple as that, and I've
found that same rule fits quite well in a number of systems.
In Bitcoin, we're not leaking resources. There's no flaw. The system is
performing as intended. Usage is increasing because it works so well, and
there is huge potential for future growth as we identify more uses and
attract more users. There might be a few technical things we can do to
reduce consumption, but the metric we're concerned with right now is how
many transactions we can fit in a block. We've broken through the 75%
marker and are regularly bumping up against the 100% limit.
It is time to stop debating this and take action to expand capacity. The
only questions that should remain are how much capacity do we add, and how
soon can we do it. Given that most existing computer systems and networks
can easily handle 20MB blocks every 10 minutes, and given that that will
increase capacity 20-fold, I can't think of a single reason why we can't go
to 20MB as soon as humanly possible. And in a few years, when the average
block size is over 15MB, we bump it up again to as high as we can go then
without pushing typical computers or networks beyond their capacity. We can
worry about ways to slow down growth without affecting the usefulness of
Bitcoin as we get closer to the hard technical limits on our capacity.
And you know what else? If miners need higher fees to accommodate the costs
of bigger blocks, they can configure their nodes to only mine transactions
with higher fees.. Let the miners decide how to charge enough to pay for
their costs. We don't need to cripple the network just for them.
--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/744b3e51/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:32:15 UTC

- reply

📅 Original date posted:2015-03-26
📝 Original message:Yes I agree, also there is talks about a government body I know of warming to bitcoin by issuing addresses for use by a business and then all transactions can be tracked for that business entity. This is one proposal I saw put forward by a country specific bitcoin group to their government and so not allowing address reuse would neuter that :(
________________________________
From: s7r<mailto:s7r at sky-ip.org>
Sent: ‎27/‎03/‎2015 9:29 AM
To: Gregory Maxwell<mailto:gmaxwell at gmail.com>; Tom Harding<mailto:tomh at thinlink.com>
Cc: Bitcoin Development<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).
I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.
On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh at thinlink.com>
> wrote:
>> I should have been clearer that the motivation for address
>> expiration is to reduce the rate of increase of the massive pile
>> of bitcoin addresses out there which have to be monitored
>> forever for future payments. It could make a significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
--------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
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/20150327/4306e1a3/attachment.html>

2023-06-07 15:31:57 UTC

- reply

📅 Original date posted:2015-03-23
📝 Original message:I don't believe that at all. Analyzing information publicly available is not illegal. Chainalysis or whatever you call it would be likened to observing who comes and feeds birds at the park everyday. You can sit in the park and observe who feeds the birds, just as you can connect to the Bitcoin P2P network and observe the blocks being formed into the chain and transactions etc. Unless there is some agreement taking place where it is specified that upon connecting to the Bitcoin P2P swarm you agree to a set of terms, however as every node is providing their own "entry" into the P2P swarm it becomes really up to the node providing the connection to uphold and enforce the terms of the agreement. If you allow people to connect to you without terms of agreement, you cannot cry foul when they record the data that passes through. To say Chainalysis needs to cease is silly, the whole point of the public blockchain is for Chainalysis, whether it be for the verification of transactions, research or otherwise.
-----Original Message-----
From: "odinn" <odinn.cyberguerrilla at riseup.net>
Sent: ‎23/‎03/‎2015 1:48 PM
To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
If you (e.g. Chainalysis) or anyone else are doing surveillance on the
network and gathering information for later use, and whether or not
the ultimate purpose is to divulge it to other parties for compliance
purposes, you can bet that ultimately the tables will be turned on
you, and you will be the one having your ass handed to you so to
speak, before or after you are served, in legal parlance. Whether or
not the outcome of that is meaningful and beneficial to any concerned
parties and what is the upshot of it in the end depends on on what you
do and just how far you decide to take your ill-advised enterprise.
Chainalysis and similar operations would be, IMHO, well advised to
cease operations. This doesn't mean they will, but guess what:
Shot over the bow, folks.
Jan Møller:
> What we were trying to achieve was determining the flow of funds
> between countries by figuring out which country a transaction
> originates from. To do that with a certain accuracy you need many
> nodes. We chose a class C IP range as we knew that bitcoin core and
> others only connect to one node in any class C IP range. We were
> not aware that breadwallet didn't follow this practice. Breadwallet
> risked getting tar-pitted, but that was not our intention and we
> are sorry about that.
>
> Our nodes DID respond with valid blocks and merkle-blocks and
> allowed everyone connecting to track the blockchain. We did however
> not relay transactions. The 'service' bit in the version message is
> not meant for telling whether or how the node relays transactions,
> it tells whether you can ask for block headers only or full
> blocks.
>
> Many implementations enforce non standard rules for handling
> transactions; some nodes ignore transactions with address reuse,
> some nodes happily forward double spends, and some nodes forward
> neither blocks not transactions. We did blocks but not
> transactions.
>
> In hindsight we should have done two things: 1. relay transactions
> 2. advertise address from 'foreign' nodes
>
> Both would have fixed the problems that breadwallet experienced.
> My understanding is that breadwallet now has the same 'class C'
> rule as bitcoind, which would also fix it.
>
> Getting back on the topic of this thread and whether it is illegal,
> your guess is as good as mine. I don't think it is illegal to log
> incoming connections and make statistical analysis on it. That
> would more or less incriminate anyone who runs a web-server and
> looks into the access log. At lease one Bitcoin service has been
> collecting IP addresses for years and given them to anyone visiting
> their web-site (you know who) and I believe that this practise is
> very wrong. We have no intention of giving IP addresses away to
> anyone, but we believe that you are free to make statistics on
> connection logs when nodes connect to you.
>
> On a side note: When you make many connections to the network you
> see lots of strange nodes and suspicious patterns. You can be
> certain that we were not the only ones connected to many nodes.
>
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
>
> /Jan
>
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike at plan99.net>
> wrote:
>
>> That would be rather new and tricky legal territory.
>>
>> But even putting the legal issues to one side, there are
>> definitional issues.
>>
>> For instance if the Chainalysis nodes started following the
>> protocol specs better and became just regular nodes that happen
>> to keep logs, would that still be a violation? If so, what about
>> blockchain.info? It'd be shooting ourselves in the foot to try
>> and forbid block explorers given how useful they are.
>>
>> If someone non-maliciously runs some nodes with debug logging
>> turned on, and makes full system backups every night, and keeps
>> those backups for years, are they in violation of whatever
>> pseudo-law is involved?
>>
>> I think it's a bit early to think about these things right now.
>> Michael Grønager and Jan Møller have been Bitcoin hackers for a
>> long time. I'd be interested to know their thoughts on all of
>> this.
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development,
>> from weekly thought leadership blogs to news, videos, case
>> studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVD34mAAoJEGxwq/inSG8CvrQH/28Rt26oGdo9rS+PaR1fIQ1p
Jwks11Axsmu5x3emTgIz0xUJ6zz/4ERM0LeNLBpfSFwZyLbuCgw1uiJplT+9uPgY
hPXb9OTNejfWZJjYc3i6rNjf2SNc5E3/4PtgeOI6lI/SsGQ6ineNm6gFjwe8xVpt
wCLOPetzCukQegXluFZZdALnPDf4H9yAeSsrfX2h2iCBAJ3qd9f1DP7+e6hvr+xr
POVBjlRYtnSd/viKJ2IhMbRvnqd86pRNAKEWrjZp0CIkGyY7wh4nqtYErZi4TcOK
H7yhU8o4/mgTNSIYdLTOSMlRi+nTMPWUD2jvO/Z9i9VTR9afn8E7j7iHD6QPMB0=
=vdbG
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:31:44 UTC

- reply

📅 Original date posted:2015-03-04
📝 Original message:Hi, so just a thought as my node relays addresses etc. If I wanted to really slow down communication over the P2P network, what's stopping me from popping up a heap of dummy nodes that do nothing more than exchange version and relay addresses, except I send addr messages with all 1000 addresses pointing to my useless nodes that never send invs or respond to getdata etc so clients connect to my dumb nodes instead of legit ones. I'm thinking that if I fill up their address pool with enough addresses to dumb nodes and keep them really fresh time wise, it could have a bit of an impact especially if all 8 outbound connections are used up by my dumb nodes right?
I don't want to do this obviously, I'm just thinking about it as I'm building my node, what is there to stop this happening?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150305/1d39ad29/attachment.html>

2023-06-07 15:31:38 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:Yes I agree with this sentiment.
As for the version, don't forget we can kinda "brute force" our way to determine a version, because lets say there is 10 versions, we can generate the seed for all 10 versions and then check to see which seed was in use (has transacted) and then use that seed. If no transactions are found, we could restore the wallet with the seed of the latest and greatest version. Not really any need to store the version, sure it may save some time but as Marek rightly says, this is for restoration of a wallet from cold storage not an everyday thing so the extra time to brute force the version etc is acceptable as a trade off for not forcing the remembering of a version.
BIP39 is beautiful.
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike at plan99.net> wrote:
- Electrum v2 with a version number but no date
- myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12.
- MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta).
- GreenAddress with no version, no date and BIP32
- Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only.
To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses BIP44 with first account only and GreenAddress uses another scheme because it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date stored in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic, extra version flag won't save our asses, because we'll fail in meaning of its meaning. Then it will be completely useless, as implementations cannot rely on it. I know Thomas was sound proponent of this solution, but he was unable to give any reasonable rules about who/how define meaning of version flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic words are kind of cold storage (longterm storage), it *really* does not make much difference in 2020, if your wallet has been created in 02/2014 or 10/2016. If there's performance issue with scanning of the blockchain, creation date don't save our asses. We need to find another solution, and as a bonus, we don't need users to know some weird numbers on top of mnemonic itself.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. There is some recommendations regarding the wordlists to help with things such as predictive text, so mobile apps can easily predict the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way only, which means you can use *any* wordlist to create the mnemonic, and any other implementation can derive BIP32 root node even without knowing that particular wordlist. Namely this has been changed because of constructive criticism of ThomasV, and from discussion on the mailing list I had a feeling that we've found a consensus. I was *very* surprised that Electrum 2.0 started to use yet another algo "just because".
Shortly said, I think BIP39 does perfect job and there's no need to use anything else.
Cheers,Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/bf558c63/attachment.html>

2023-06-07 15:31:37 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:@Neill, Indeed supplying entropy is necessary for testing etc, that's the main reason why I put this in my .NET implementation, the test vectors require us to supply entropy and build the mnemonic from the supplied wordlist and you are correct that changes to the word list will null and void the test vectors. Also it allows us to do fun things like swap between languages so one entropy set can have many seeds based on many languages etc, just novel little things like that. I'm not at all against a standard wordlist. The point I want to get across is that people seem to think that BIP39 is restricted by its word list but not at all. As long as you give a BIP39 implementation 12 words or more (in 3 word increments) it will always derive the same seed bytes, independent of any word list and this is the most important message to realise.
@Thomas V if you must record a version, why don't you just put an integer at the end of your mnemonic or something? I can't understand why you have disregarded BIP39 when designing Electrum 2.0? 12 - 24 words plus a version integer tacked on the end, tell the user to omit the version integer if they want to import to multibit HD or whatever, job done!
I really think you need to rethink the use of BIP39 with Electrum Thomas! If you want to maintain a version field and/or date independent of the BIP39 spec then do so because at least the seed can still be recreated from anyone else utilising BIP39!!!
Thy
> Date: Thu, 12 Mar 2015 06:51:37 -0500
> From: neillm at thecodefactory.org
> To: thashiznets at yahoo.com.au
> CC: Bitcoin-development at lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
>
>
> Ok, I see your point here, and I was referring to rebuilding from
> entropy -- which as you noted is not a real world usage. It is a
> useful implementation test though and at the very least the existing
> test vectors would need to be regenerated with each word list change.
>
> I recently added BIP39 to libbitcoin and our implementation would fail
> with an arbitrarily new word list because we validate the user
> provided word list before converting it to a seed (i.e. we check that
> the encoded entropy/checksum line up and warn the user if that's not
> the case to distinguish a rubbish word list from a BIP39 mnemonic --
> as referenced in the BIP). You're correct that we could use rubbish
> words, but at the moment it's not allowed there. By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed. But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.
>
> Thanks for clarifying,
> -Neill.
>
> On Thu, Mar 12, 2015 at 04:21:59AM +0000, Thy Shizzle wrote:
> > "I agree that it's true that a static wordlist is
> > required once people have started using BIP39 for anything real and
> > changing the word lists will invalidate any existing mnemonics"
> > ^ This is incorrect I think Neill, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated mnemonics UNLESS you are trying to rebuild from entropy but you wouldn't do that. You would be rebuilding from the Mnemonic in real world scenario. You really can have a word list of total rubbish in BIP39 as long as it is 2048 words long that is all! If you input the mnemonic made out of rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
> >
> > On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> > > That's disappointing the Electrum 2.0 doesn't use BIP39.
> >
> > Agreed, but I don't know the full background on this.
> >
> > > Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
> >
> > That's true for generating new mnemonics (i.e. same entropy can
> > generate any combinations of words), but not for converting a mnemonic
> > to a seed (i.e. a specific wordlist/passphrase should always generate
> > the same seed). I agree that it's true that a static wordlist is
> > required once people have started using BIP39 for anything real and
> > changing the word lists will invalidate any existing mnemonics (unless
> > your 'new' wordlist simply substitutes one word for another and the
> > index mapping is made public ... which means it's not really an
> > arbitrary word list).
> >
> > > Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> > > So most of what you are suggesting as problems are not.
> >
> > I don't see how this can work given the BIP39 spec as it is today
> > (there's simply no room for a version in the bits). I do think
> > versioning would be nice, but as of now, I'm in the camp that thinks
> > complete wallet interoperability is a bit of a myth -- so long as you
> > can fundamentally move into/out of wallets at will.
> >
> > -Neill.
> >
> > > As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, but I found it easy to look for a word in the mnemonic that is unique to that language/wordlist and so straight away you can determine the language, remembering you get minimum 12 goes at doing that :)
> > > Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do that :) I don't have any interest in BIP39 other than it being a standard. I think TREZOR may have an interest in it?
> > > Thomas V:
> > > "Thanks Mike, and sorry to answer a bit late; it has been a busy couple
> > > of weeks.
> > >
> > > You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> > > versa. It is indeed unfortunate. However, I believe BIP39 should not be
> > > followed, because it reproduces two mistakes I did when I designed the
> > > older Electrum seed system. Let me explain.
> > >
> > > The first problem I have with BIP39 is that the seed phrase does not
> > > include a version number.
> > >
> > > Wallet development is still in an exploratory phase, and we should
> > > expect even more innovation in this domain. In this context, it is
> > > unwise to make decisions that prevent future innovation.
> > >
> > > However, when we give a seed phrase to users, we have a moral obligation
> > > to keep supporting this seed phrase in future versions. We cannot simply
> > > announce to Electrum users that their old seed phrase is not supported
> > > anymore, because we created a new version of the software that uses a
> > > different derivation. This could lead to financial losses for users who
> > > are unaware of these technicalities. Well, at least, that is how I feel
> > > about it.
> > >
> > > BIP39 and Electrum v2 have a very different ways of handling future
> > > innovation. Electrum v2 seed phrases include an explicit version number,
> > > that indicates how the wallet addresses should be derived. In contrast,
> > > BIP39 seed phrases do not include a version number at all. BIP39 is
> > > meant to be combined with BIP43, which stipulates that the wallet
> > > structure should depend on the BIP32 derivation path used for the wallet
> > > (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> > > innovation in BIP43 is allowed only within the framework of BIP32. In
> > > addition, having to explore the branches of the BIP32 tree in order to
> > > determine the type of wallet attached to a seed might be somewhat
> > > inefficient.
> > >
> > > The second problem I see with BIP39 is that it requires a fixed
> > > wordlist. Of course, this forbids innovation in the wordlist itself, but
> > > that's not the main problem. When you write a new standard, it is
> > > important to keep this standard minimal, given the goal you want to
> > > achieve. I believe BIP39 could (and should) have been written without
> > > including the wordlist in the standard.
> > >
> > > There are two ways to derive a master key from a mnemonic phrase:
> > > 1. A bidirectional mapping between words and numbers, as in old
> > > Electrum versions. Pros: bidirectional means that you can do Shamir
> > > secret sharing of your seed. Cons: It requires a fixed wordlist.
> > > 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
> > > required. Cons: the mapping isn't bidirectional.
> > >
> > > Electrum v1 uses (1). Electrum v2 uses (2).
> > >
> > > Early versions of BIP39 used (1), and later they switched to (2).
> > > However, BIP39 uses (2) only in order to derive the wallet keys, not for
> > > its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> > > wordlist. This is just plainly inconsistent. As a result, you have
> > > neither wordlist flexibility, nor Shamir secret sharing.
> > >
> > > Having a fixed wordlist is very unfortunate. First, it means that BIP39
> > > will probably never leave the 'draft' stage, until all languages of the
> > > world have been added. Second, once you add a wordlist for a new
> > > language, you cannot change it anymore, because it will break existing
> > > seed phrases; therefore you have to be extremely careful in the way you
> > > design these wordlists. Third, languages often have words in common.
> > > When you add a new language to the list, you should not use words
> > > already used by existing wordlists, in order to ensure that the language
> > > can be detected. It leads to a first come first served situation, that
> > > might not be sustainable in the future.
> > >
> > > In order to support the old Electrum v1 seeds, all future versions of
> > > Electrum will have to include the old wordlist. In addition, when
> > > generating new seed phrases, Electrum now has to avoid collisions with
> > > old seed phrases, because the old ones did not have a version number.
> > > This is painful enough, I will not repeat the same errors twice.
> > >
> > > Electrum v2 derives both its private keys and its checksum/version
> > > number using a hash of the seed phrase. This means that wordlists can be
> > > added and modified in the future, without breaking existing seed
> > > phrases. It also means that it will be very easy for other wallets to
> > > support Electrum seedphrases: it requires about 20 lines of code, and no
> > > wordlist is required."
> > >
> > >
> > > Thomas
> > >
> > >
> > > Le 02/03/2015 16:37, Mike Hearn a écrit :
> > > > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > > >
> > > >
> > > >> * New seed derivation method (not compatible with BIP39).
> > > >
> > > >
> > > > Does this mean a "12 words" wallet created by Electrum won't work if
> > > > imported into some other wallet that supports BIP39? Vice versa? This seems
> > > > unfortunate. I guess if seeds are being represented with 12 words
> > > > consistently, people will expect them to work everywhere.
> > > >
> > >
> > > ------------------------------------------------------------------------------
> > > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > > things parallel software development, from weekly thought leadership blogs to
> > > news, videos, case studies, tutorials and more. Take a look and join the
> > > conversation now. http://goparallel.sourceforge.net/
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > Bitcoin-development --
> > > | |
> > > | | | | | |
> > > | Bitcoin-development --To see the collection of prior postings to the list, visit the Bitcoin-development Archives. |
> > > | |
> > > | View on lists.sourceforge.net | Preview by Yahoo |
> > > | |
> > > | |
> > >
> > >
> > >
> > >
> > >
> >
> > > ------------------------------------------------------------------------------
> > > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > > things parallel software development, from weekly thought leadership blogs to
> > > news, videos, case studies, tutorials and more. Take a look and join the
> > > conversation now. http://goparallel.sourceforge.net/
> >
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150312/d0a28c36/attachment.html>

2023-06-07 15:31:36 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:"I agree that it's true that a static wordlist is
required once people have started using BIP39 for anything real and
changing the word lists will invalidate any existing mnemonics"
^ This is incorrect I think Neill, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated mnemonics UNLESS you are trying to rebuild from entropy but you wouldn't do that. You would be rebuilding from the Mnemonic in real world scenario. You really can have a word list of total rubbish in BIP39 as long as it is 2048 words long that is all! If you input the mnemonic made out of rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> That's disappointing the Electrum 2.0 doesn't use BIP39.
Agreed, but I don't know the full background on this.
> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
That's true for generating new mnemonics (i.e. same entropy can
generate any combinations of words), but not for converting a mnemonic
to a seed (i.e. a specific wordlist/passphrase should always generate
the same seed). I agree that it's true that a static wordlist is
required once people have started using BIP39 for anything real and
changing the word lists will invalidate any existing mnemonics (unless
your 'new' wordlist simply substitutes one word for another and the
index mapping is made public ... which means it's not really an
arbitrary word list).
> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> So most of what you are suggesting as problems are not.
I don't see how this can work given the BIP39 spec as it is today
(there's simply no room for a version in the bits). I do think
versioning would be nice, but as of now, I'm in the camp that thinks
complete wallet interoperability is a bit of a myth -- so long as you
can fundamentally move into/out of wallets at will.
-Neill.
> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, but I found it easy to look for a word in the mnemonic that is unique to that language/wordlist and so straight away you can determine the language, remembering you get minimum 12 goes at doing that :)
> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do that :) I don't have any interest in BIP39 other than it being a standard. I think TREZOR may have an interest in it?
> Thomas V:
> "Thanks Mike, and sorry to answer a bit late; it has been a busy couple
> of weeks.
>
> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> versa. It is indeed unfortunate. However, I believe BIP39 should not be
> followed, because it reproduces two mistakes I did when I designed the
> older Electrum seed system. Let me explain.
>
> The first problem I have with BIP39 is that the seed phrase does not
> include a version number.
>
> Wallet development is still in an exploratory phase, and we should
> expect even more innovation in this domain. In this context, it is
> unwise to make decisions that prevent future innovation.
>
> However, when we give a seed phrase to users, we have a moral obligation
> to keep supporting this seed phrase in future versions. We cannot simply
> announce to Electrum users that their old seed phrase is not supported
> anymore, because we created a new version of the software that uses a
> different derivation. This could lead to financial losses for users who
> are unaware of these technicalities. Well, at least, that is how I feel
> about it.
>
> BIP39 and Electrum v2 have a very different ways of handling future
> innovation. Electrum v2 seed phrases include an explicit version number,
> that indicates how the wallet addresses should be derived. In contrast,
> BIP39 seed phrases do not include a version number at all. BIP39 is
> meant to be combined with BIP43, which stipulates that the wallet
> structure should depend on the BIP32 derivation path used for the wallet
> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> innovation in BIP43 is allowed only within the framework of BIP32. In
> addition, having to explore the branches of the BIP32 tree in order to
> determine the type of wallet attached to a seed might be somewhat
> inefficient.
>
> The second problem I see with BIP39 is that it requires a fixed
> wordlist. Of course, this forbids innovation in the wordlist itself, but
> that's not the main problem. When you write a new standard, it is
> important to keep this standard minimal, given the goal you want to
> achieve. I believe BIP39 could (and should) have been written without
> including the wordlist in the standard.
>
> There are two ways to derive a master key from a mnemonic phrase:
> 1. A bidirectional mapping between words and numbers, as in old
> Electrum versions. Pros: bidirectional means that you can do Shamir
> secret sharing of your seed. Cons: It requires a fixed wordlist.
> 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
> required. Cons: the mapping isn't bidirectional.
>
> Electrum v1 uses (1). Electrum v2 uses (2).
>
> Early versions of BIP39 used (1), and later they switched to (2).
> However, BIP39 uses (2) only in order to derive the wallet keys, not for
> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> wordlist. This is just plainly inconsistent. As a result, you have
> neither wordlist flexibility, nor Shamir secret sharing.
>
> Having a fixed wordlist is very unfortunate. First, it means that BIP39
> will probably never leave the 'draft' stage, until all languages of the
> world have been added. Second, once you add a wordlist for a new
> language, you cannot change it anymore, because it will break existing
> seed phrases; therefore you have to be extremely careful in the way you
> design these wordlists. Third, languages often have words in common.
> When you add a new language to the list, you should not use words
> already used by existing wordlists, in order to ensure that the language
> can be detected. It leads to a first come first served situation, that
> might not be sustainable in the future.
>
> In order to support the old Electrum v1 seeds, all future versions of
> Electrum will have to include the old wordlist. In addition, when
> generating new seed phrases, Electrum now has to avoid collisions with
> old seed phrases, because the old ones did not have a version number.
> This is painful enough, I will not repeat the same errors twice.
>
> Electrum v2 derives both its private keys and its checksum/version
> number using a hash of the seed phrase. This means that wordlists can be
> added and modified in the future, without breaking existing seed
> phrases. It also means that it will be very easy for other wallets to
> support Electrum seedphrases: it requires about 20 lines of code, and no
> wordlist is required."
>
>
> Thomas
>
>
> Le 02/03/2015 16:37, Mike Hearn a écrit :
> > Congrats Thomas! Glad to see Electrum 2 finally launch.
> >
> >
> >> * New seed derivation method (not compatible with BIP39).
> >
> >
> > Does this mean a "12 words" wallet created by Electrum won't work if
> > imported into some other wallet that supports BIP39? Vice versa? This seems
> > unfortunate. I guess if seeds are being represented with 12 words
> > consistently, people will expect them to work everywhere.
> >
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> Bitcoin-development --
> | |
> | | | | | |
> | Bitcoin-development --To see the collection of prior postings to the list, visit the Bitcoin-development Archives. |
> | |
> | View on lists.sourceforge.net | Preview by Yahoo |
> | |
> | |
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150312/ba0f7b83/attachment.html>

2023-06-07 15:31:35 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it is not, it is unfortunate that Electrum did not go the route of BIP39. The wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39 On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?
Unfortunately there's more incompatibility than just the date issue:
* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own
So actually very few wallets are seed-compatible, even ignoring the date
question.
>
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.
That's a reasonable solution.
>
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."
--
devrandom / Miron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/d1164461/attachment.html>

2023-06-07 15:31:33 UTC

- reply

📅 Original date posted:2015-03-12
📝 Original message:That's disappointing the Electrum 2.0 doesn't use BIP39.
>From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. There is some recommendations regarding the wordlists to help with things such as predictive text, so mobile apps can easily predict the word being typed in after a few chars etc. This would seem to be the reasoning for the reference word lists. Now there is nothing stopping one from implementing a wordlist of say profanities or star wars terms or whatever and still accepting a mnemonic from another provider. Remember if you have a mnemonic from a different wordlist, simply Normalization of the words occurs and then the hashing the mnemonic to derive the seed bytes. It is not really a restriction at all! BIP39 was designed such that the mnemonic generation is decoupled from seed derivation, just like what you are saying Electrum 2.0 can do! The wordlist is only needed for mnemonic generation NOT seed derivation, so Electrum DOES NOT need a copy of the BIP39 word lists to generate the seed from the phrase, there is really not much reason for Electrum not to accept BIP39 mnemonics at the moment! it requires bugger all code! Here is my seed generation code
//literally this is the bulk of the decoupled seed generation code, easy.byte[] salt = Utilities.MergeByteArrays(UTF8Encoding.UTF8.GetBytes(cSaltHeader),_passphraseBytes);return Rfc2898_pbkdf2_hmacsha512.PBKDF2(UTF8Encoding.UTF8.GetBytes(Utilities.NormaliseStringNfkd(MnemonicSentence)), salt);
Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
So most of what you are suggesting as problems are not.
As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, but I found it easy to look for a word in the mnemonic that is unique to that language/wordlist and so straight away you can determine the language, remembering you get minimum 12 goes at doing that :)
Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do that :) I don't have any interest in BIP39 other than it being a standard. I think TREZOR may have an interest in it?
Thomas V:
"Thanks Mike, and sorry to answer a bit late; it has been a busy couple
of weeks.
You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.
The first problem I have with BIP39 is that the seed phrase does not
include a version number.
Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.
However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.
BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, having to explore the branches of the BIP32 tree in order to
determine the type of wallet attached to a seed might be somewhat
inefficient.
The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without
including the wordlist in the standard.
There are two ways to derive a master key from a mnemonic phrase:
1. A bidirectional mapping between words and numbers, as in old
Electrum versions. Pros: bidirectional means that you can do Shamir
secret sharing of your seed. Cons: It requires a fixed wordlist.
2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
required. Cons: the mapping isn't bidirectional.
Electrum v1 uses (1). Electrum v2 uses (2).
Early versions of BIP39 used (1), and later they switched to (2).
However, BIP39 uses (2) only in order to derive the wallet keys, not for
its checksum. The BIP39 checksum uses (1), and it does requires a fixed
wordlist. This is just plainly inconsistent. As a result, you have
neither wordlist flexibility, nor Shamir secret sharing.
Having a fixed wordlist is very unfortunate. First, it means that BIP39
will probably never leave the 'draft' stage, until all languages of the
world have been added. Second, once you add a wordlist for a new
language, you cannot change it anymore, because it will break existing
seed phrases; therefore you have to be extremely careful in the way you
design these wordlists. Third, languages often have words in common.
When you add a new language to the list, you should not use words
already used by existing wordlists, in order to ensure that the language
can be detected. It leads to a first come first served situation, that
might not be sustainable in the future.
In order to support the old Electrum v1 seeds, all future versions of
Electrum will have to include the old wordlist. In addition, when
generating new seed phrases, Electrum now has to avoid collisions with
old seed phrases, because the old ones did not have a version number.
This is painful enough, I will not repeat the same errors twice.
Electrum v2 derives both its private keys and its checksum/version
number using a hash of the seed phrase. This means that wordlists can be
added and modified in the future, without breaking existing seed
phrases. It also means that it will be very easy for other wallets to
support Electrum seedphrases: it requires about 20 lines of code, and no
wordlist is required."
Thomas
Le 02/03/2015 16:37, Mike Hearn a écrit :
> Congrats Thomas! Glad to see Electrum 2 finally launch.
>
>
>> * New seed derivation method (not compatible with BIP39).
>
>
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
Bitcoin-development --
| |
| | | | | |
| Bitcoin-development --To see the collection of prior postings to the list, visit the Bitcoin-development Archives. |
| |
| View on lists.sourceforge.net | Preview by Yahoo |
| |
| |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/8f2ef0c6/attachment.html>