Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

Ah sorry, I just thought you were saying doesn't matter which side let 'em burn.

If I were the Chinese and people moved to 20mb MAX size blocks and said stuff 
you, I'd just start firing out small coinbase only blocks now, if they truly 
have >50% hashing power and they collaborate chances are they can build a 
longer chain of just coinbase for themselves then the rest of the network doing 
big blocks. They don't even have to propagate this chain to you in a hurry 
right? And then they never have to receive a 20mb block from you because they 
have a longer chain without 20mb blocks and always ahead of your big blocks. As 
long as it is the longest chain it is Authority so let you guys transact your 
coinbase from the blocks you create etc. then whamo along come the chinese and 
supply a longer chain of just coinbase only blocks which invalidates all your 
previous transactions and gives them all the coinbase they stamped, while 
invalidating yours.

But who cares about them right :p

From: Warren Togami Jr.<mailto:wtog...@gmail.com>
Sent: ‎2/‎06/‎2015 4:19 AM
Cc: Bitcoin Dev<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

By reversing Mike's language to the reality of the situation I had hoped
people would realize how abjectly ignorant and insensitive his statement
was.  I am sorry to those in the community if they misunderstood my post. I
thought it was obvious that it was sarcasm where I do not seriously believe
particular participants should be excluded.

On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle  wrote:

>  Doesn't mean you should build something that says "fuck you" to the
> companies that have invested in farms of ASICS. To say "Oh yea if they
> can't mine it how we want stuff 'em" is naive. I get decentralisation, but
> don't dis incentivise mining. If miners are telling you that you're going
> to hurt them, esp. Miners that combined hold > 50% hashing power, why would
> you say too bad so sad? Why not just start stripping bitcoin out of
> adopters wallets? Same thing.
>  --
> From: Warren Togami Jr. 
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev 
> Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
>
>   Whilst it would be nice if miners in *outside* China can carry on
> forever regardless of their internet situation, nobody has any inherent
> "right" to mine if they can't do the job - if miners in *outside* China
> can't get the trivial amounts of bandwidth required through their firewall *TO
> THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too
> bad, we'll have to carry on without them.
>
>
> On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn  wrote:
>
>  Whilst it would be nice if miners in China can carry on forever
> regardless of their internet situation, nobody has any inherent "right" to
> mine if they can't do the job - if miners in China can't get the trivial
> amounts of bandwidth required through their firewall and end up being
> outcompeted then OK, too bad, we'll have to carry on without them.
>
>  But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

Doesn't mean you should build something that says "fuck you" to the companies 
that have invested in farms of ASICS. To say "Oh yea if they can't mine it how 
we want stuff 'em" is naive. I get decentralisation, but don't dis incentivise 
mining. If miners are telling you that you're going to hurt them, esp. Miners 
that combined hold > 50% hashing power, why would you say too bad so sad? Why 
not just start stripping bitcoin out of adopters wallets? Same thing.

From: Warren Togami Jr.
Sent: ‎1/‎06/‎2015 10:30 PM
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Whilst it would be nice if miners in *outside* China can carry on forever
regardless of their internet situation, nobody has any inherent "right" to
mine if they can't do the job - if miners in *outside* China can't get the
trivial amounts of bandwidth required through their firewall *TO THE
MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad,
we'll have to carry on without them.


On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn  wrote:

> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if
> they can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node
> on a server in Taiwan and connect the hardware to it via a VPN or so.
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Thy Shizzle]

WOW Way to burn your biggest adopters who put your transactions into the 
chain...what a douche.

From: Mike Hearn
Sent: ‎1/‎06/‎2015 8:15 PM
To: Alex Mizrahi
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

Whilst it would be nice if miners in China can carry on forever regardless
of their internet situation, nobody has any inherent "right" to mine if
they can't do the job - if miners in China can't get the trivial amounts of
bandwidth required through their firewall and end up being outcompeted then
OK, too bad, we'll have to carry on without them.

But I'm not sure why it should be a big deal. They can always run a node on
a server in Taiwan and connect the hardware to it via a VPN or so.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] No Bitcoin For You

[Thy Shizzle]

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:j...@ergophobia.org>
Sent: ‎26/‎05/‎2015 12:53 PM
To: Thy Shizzle<mailto:thyshiz...@outlook.com>
Cc: Mike Hearn<mailto:m...@plan99.net>; Bitcoin 
Dev<mailto:bitcoin-development@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  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 
> Sent: ‎26/‎05/‎2015 12:27 PM
> To: Mike Hearn 
> Cc: Bitcoin Dev 
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn  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 again

Re: [Bitcoin-development] No Bitcoin For You

[Thy Shizzle]

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:gapplet...@gmail.com>
Sent: ‎26/‎05/‎2015 12:41 PM
To: Thy Shizzle<mailto:thyshiz...@outlook.com>
Cc: Jim Phillips<mailto:j...@ergophobia.org>; Mike 
Hearn<mailto:m...@plan99.net>; Bitcoin 
Dev<mailto:bitcoin-development@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 
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 
> Sent: ‎26/‎05/‎2015 12:27 PM
> To: Mike Hearn 
> Cc: Bitcoin Dev 
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn  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 huma

Re: [Bitcoin-development] No Bitcoin For You

[Thy Shizzle]

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
Sent: ‎26/‎05/‎2015 12:27 PM
To: Mike Hearn
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] No Bitcoin For You

On Mon, May 25, 2015 at 1:36 PM, Mike Hearn  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*


*"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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size

[Thy Shizzle]

Yes This!

So many people seem hung up on growing the block size! If gaining a higher tps 
throughput is the main aim, I think that this proposition to speed up block 
creation has merit!

Yes it will lead to an increase in the block chain still due to 1mb ~1 minute 
instead of ~10 minute, but the change to the protocol is minor, you are only 
adding in a different difficulty rate starting from hight blah, no new features 
or anything are being added so there seems to me much less of a security risk! 
Also that impact if a hard fork should be minimal because there is nothing but 
absolute incentive for miners to mine at the new easier difficulty!

I feel this deserves a great deal of consideration as opposed to blowing out 
the block through miners voting etc

From: Sergio Lerner
Sent: ‎11/‎05/‎2015 5:05 PM
To: 
bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Reducing the block rate instead of increasing 
the maximum block size

In this e-mail I'll do my best to argue than if you accept that
increasing the transactions/second is a good direction to go, then
increasing the maximum block size is not the best way to do it. I argue
that the right direction to go is to decrease the block rate to 1
minute, while keeping the block size limit to 1 Megabyte (or increasing
it from a lower value such as 100 Kbyte and then have a step function).
I'm backing up my claims with many hours of research simulating the
Bitcoin network under different conditions [1].  I'll try to convince
you by responding to each of the arguments I've heard against it.

Arguments against reducing the block interval

1. It will encourage centralization, because participants of mining
pools will loose more money because of excessive initial block template
latency, which leads to higher stale shares

When a new block is solved, that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes,
then a new block header candidate is created, and this header must be
propagated to all the mining pool users, ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around, the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients, then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources, so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth, but I guess the investment would be low.

2. It will increase the probability of a block-chain split

The convergence of the network relies on the diminishing probability of
two honest miners creating simultaneous competing blocks chains. To
increase the competition chain, competing blocks must be generated in
almost simultaneously (in the same time window approximately bounded by
the network average block propagation delay). The probability of a block
competition decreases exponentially with the number of blocks. In fact,
the probability of a sustained competition on ten 1-minute blocks is one
million times lower than the probability of a competition of one
10-minute block. So even if the competition probability of six 1-minute
blocks is higher than of six ten-minute blocks, this does not imply
reducing the block rate increases this chance, but on the contrary,
reduces it.

3, It will reduce the security of the network

The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.

A still holds. B holds for the same amount of confirmation blocks, so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes, as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However, there is no shop where
one can find 51% of the hashing power to rent right now, nor probably
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments,
so the security decreases only if participant wish to decrease it.

4. Reducing the block propagation time on the average case is good, but
what happen in the worse case?

Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression re

Re: [Bitcoin-development] Solution for Block Size Increase

[Thy Shizzle]

Nicolas, can you think if there would be a problem with allowing blocks to be 
created faster instead of increasing block size? So say if difficulty was 
reduced to allow block creation every 2 minutes instead of 10 minutes, can you 
think of any bad outcome from this (I know this is different to what you are 
saying) but I'm thinking if we allow 1mb blocks to be built faster, that way 
transactions are processed quicker  thus gaining a higher tps rate, i'd think 
no hard fork need occur right?

Is there any downsides that you can see? Obviously miners need yo update, but I 
mean if they don't it just means they potentially take too long to make blocks 
and thus loose out in reward so there is the incentive for them to update to 
the easier difficulty, while still allowing blocks done on the harder 
difficulty for backwards compatibility.

Thoughts?

From: Nicolas DORIER
Sent: ‎8/‎05/‎2015 9:17 AM
To: 
bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Solution for Block Size Increase

Executive Summary:

I explain the objectives that we should aim to reach agreement without
drama, controversy, and relief the core devs from the central banker role.
(As Jeff Garzik pointed out)
Knowing the objectives, I propose a solution based on the objectives that
can be agreed on tomorrow, would permanently fix the block size problem
without controversy and would be immediately applicable.

The objectives:

There is consensus on the fact that nobody wants the core developers to be
seen as central bankers.
There is also consensus that more decentralization is better than less.
(assuming there is no cost to it)

This means you should reject all arguments based on economical, political
and ideological principles about what Bitcoin should become. This includes:

1) Whether Bitcoin should be storage of value or suitable for coffee
transaction,
2) Whether we need a fee market, block scarcity, and how much of it,
3) Whether we need to periodically increase block size via some voodoo
formula which speculate on future bandwidth and cost of storage,

Taking decisions based on such reasons is what central bankers do, and you
don’t want to be bankers. This follow that decisions should be taken only
for technical and decentralization considerations. (more about
decentralization after)

Scarcity will evolve without you taking any decisions about it, for the
only reason that storage and bandwidth is not free, nor a transaction,
thanks to increased propagation time.
This backed in scarcity will evolve automatically as storage, bandwidth,
encoding, evolve without anybody taking any decision, nor making any
speculation on the future.

Sadly, deciding how much decentralization should be in the system by
tweaking the block size limit is also an economic decision that should not
have its place between the core devs. This follow :

4) Core devs should not decide about the amount of suitable
decentralization by tweaking block size limit,

Still, removing the limit altogether is a no-no, what would happen if a
block of 100 GB is created? Immediately the network would be decentralized,
not only for miners but also for bitcoin service providers. Also, core devs
might have technical consideration on bitcoin core which impose a temporary
limit until the bug resolved.

The solution:

So here is a proposal that address all my points, and, I think, would get a
reasonable consensus. It can be published tomorrow without any controversy,
would be agreed in one year, and can be safely reiterated every year.
Developers will also not have to play politics nor central banker. (well,
it sounds to good to be true, I waiting for being wrong)

The solution is to use block voting. For each block, a miner gives the size
of the block he would like to have at the next deadline (for example, 30
may 2015). The rational choice for them is just enough to clear the memory
pool, maybe a little less if he believes fee pressure is beneficial for
him, maybe a little more if he believes he should leave some room for
increased use.
At the deadline, we take the median of the votes and implement it as a new
block size limit. Reiterate for the next year.

Objectives reached:


   - No central banking decisions on devs shoulder,
   - Votes can start tomorrow,
   - Implementation has only to be ready in one year, (no kick-in-the-can)
   - Will increase as demand is growing,
   - Will increase as network capacity and storage is growing,
   - Bitcoin becomes what miners want, not what core devs and politician
   wants,
   - Implementation reasonably easy,
   - Will get miner consensus, no impact on existing bitcoin services,


Unknown:

   - Effect on bitcoin core stability (core devs might have a valid
   technical reason to impose a limit)
   - Maybe a better statistical function is possible

Additional input for the debate:

Some people were deb

Re: [Bitcoin-development] Where do I start?

[Thy Shizzle]

Zero conf :D

From: gabe appleton
Sent: ‎16/‎04/‎2015 12:15 PM
To: 
bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Where do I start?

Background: I'm a CS student quickly approaching his research project, and
I'd like to do something meaningful with it.

Essentially, I'd like to know what issues someone up for their bachelor's
degree might actually be able to help on, and where I can start. Obviously
I'm not going to be able to just dive into a 6-year-running project without
some prior research, so I'm looking for a start.

What are some current things that are lacking in Bitcoin core? Or am I
better off making something else for the ecosystem?
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Thy Shizzle]

If the IP discovery is your main motivation, why don't you introduce some onion 
routing into transactions? That would solve this problem easily, of course 
there is an overhead which will slightly slow down the relay of transactions 
but not significantly, also make it an option not enforced, for those worried 
about IP association.

From: Robert McKay
Sent: ‎28/‎03/‎2015 2:33 AM
To: Matt Whitlock
Cc: 
bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] "network disruption as a service" and proof 
of local storage

The main motivation is to try and stop a single entity running lots of
nodes in order to harvest transaction origin IPs. That's what's behind
this.

Probably the efforts are a waste of time.. if someone has to keep a few
hundred copies of the blockchain around in order to keep IP specific
precomputed data around for all the IPs they listen on then they'll just
buy a handful of 5TB HDs and call it a day.. still some of the ideas
proposed are quite interesting and might not have much downside.

Rob


On 2015-03-27 15:16, Matt Whitlock wrote:
> I agree that someone could do this, but why is that a problem? Isn't
> the goal of this exercise to ensure more full nodes on the network?
> In
> order to be able to answer the challenges, an entity would need to be
> running a full node somewhere. Thus, they have contributed at least
> one additional full node to the network. I could certainly see a case
> for a company to host hundreds of lightweight (e.g., EC2) servers all
> backed by a single copy of the block chain. Why force every single
> machine to have its own copy? All you really need to require is that
> each agency/participant have its own copy.
>
>
> On Friday, 27 March 2015, at 2:32 pm, Robert McKay wrote:
>> Basically the problem with that is that someone could setup a single
>> full node that has the blockchain and can answer those challenges
>> and
>> then a bunch of other non-full nodes that just proxy any such
>> challenges
>> to the single full node.
>>
>> Rob
>>
>> On 2015-03-26 23:04, Matt Whitlock wrote:
>> > Maybe I'm overlooking something, but I've been watching this
>> thread
>> > with increasing skepticism at the complexity of the offered
>> solution.
>> > I don't understand why it needs to be so complex. I'd like to
>> offer
>> > an
>> > alternative for your consideration...
>> >
>> > Challenge:
>> > "Send me: SHA256(SHA256(concatenation of N pseudo-randomly
>> selected
>> > bytes from the block chain))."
>> >
>> > Choose N such that it would be infeasible for the responding node
>> to
>> > fetch all of the needed blocks in a short amount of time. In other
>> > words, assume that a node can seek to a given byte in a block
>> stored
>> > on local disk much faster than it can download the entire block
>> from
>> > a
>> > remote peer. This is almost certainly a safe assumption.
>> >
>> > For example, choose N = 1024. Then the proving node needs to
>> perform
>> > 1024 random reads from local disk. On spinning media, this is
>> likely
>> > to take somewhere on the order of 15 seconds. Assuming blocks are
>> > averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of
>> > data. Can 500 MiB be downloaded in 15 seconds? This data transfer
>> > rate
>> > is 280 Mbps. Almost certainly not possible. And if it is, just
>> > increase N. The challenge also becomes more difficult as average
>> > block
>> > size increases.
>> >
>> > This challenge-response protocol relies on the lack of a "partial
>> > getdata" command in the Bitcoin protocol: a node cannot ask for
>> only
>> > part of a block; it must ask for an entire block. Furthermore,
>> nodes
>> > could ban other nodes for making too many random requests for
>> blocks.
>> >
>> >
>> > On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote:
>> >>
>> >> > If I understand correctly, transforming raw blocks to keyed
>> blocks
>> >> > takes 512x longer than transforming keyed blocks back to raw.
>> The
>> >> key
>> >> > is public, like the IP, or some other value which perhaps
>> changes
>> >> less
>> >> > frequently.
>> >> >
>> >> Yes. I was thinking that the IP could be part of a first layer of
>> >> encryption done to the blockchain data prior to the asymetric
>> >> operation.
>> >> That way the asymmetric operation can be the same for all users
>> (no
>> >> different primers for different IPs, and then the verifiers does
>> not
>> >> have to verify that a particular p is actually a pseudo-prime
>> >> suitable
>> >> for P.H. ) and the public exponent can be just 3.
>> >>
>> >> >
>> >> >> Two protocols can be performed to prove local possession:
>> >> >> 1. (prover and verifier pay a small cost) The verifier sends a
>> >> seed to
>> >> >> derive some n random indexes, and the prover must respond with
>> >> the hash
>> >> >> of the decrypted blocks within a certain time

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

[Thy Shizzle]

Indeed, and with things like BIP32 it would be pointless to use one address, 
and I agree it is silly to reuse addresses, some for the privacy aspect, some 
for the revealing the pubkey on a spend aspect. But just because it is silly, 
doesn't mean it's necessarily required for devs to disallow it. I mean if a 
business doesn't care who can see their  bitcoin takings and they are willing 
to keep shifting the bitcoin and live woth the exposed pubkey let them yea?

http://www.forexminute.com/bitcoin/australian-association-asks-voluntary-bitcoin-register-individuals-companies-51183

From: Gregory Maxwell<mailto:gmaxw...@gmail.com>
Sent: ‎27/‎03/‎2015 2:13 PM
To: Thy Shizzle<mailto:thyshiz...@outlook.com>
Cc: s...@sky-ip.org<mailto:s...@sky-ip.org>; Tom 
Harding<mailto:t...@thinlink.com>; Bitcoin 
Development<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse

On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle  wrote:
> 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 :(

I hope you're mistaken, because that would be a serious attack on the
design of bitcoin, which obtains privacy and fungibility, both
essential properties of any money like good, almost exclusively
through avoiding reuse.

[What business would use a money where all their competition can see
their sales and identify their customers, where their customers can
track their margins and suppliers? What individuals would use a system
where their inlaws could criticize their spending? Where their
landlord knows they got a raise, or where thieves know their net
worth?]

Though no one here is currently suggesting blocking reuse as a network
rule, the reasonable and expected response to what you're suggesting
would be to do so.

If some community wishes to choose not to use Bitcoin, great, but they
don't get to simply choose to screw up its utility for all the other
users.

You should advise this "country specific bitcoin group" that they
shouldn't speak for the users of a system which they clearly do not
understand.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

[Thy Shizzle]

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
Sent: ‎27/‎03/‎2015 9:29 AM
To: Gregory Maxwell; Tom 
Harding
Cc: Bitcoin Development
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 
> 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@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Thy Shizzle]

Wow, that's quite impressive. But what comes to my mind is if such an 
extravagant solution really need to be implemented regarding proof of storage? 
I mean, my idea whilst building my node was to do something along the lines of 
"tell me what you got" i.e get block height from the version message, and then 
fire off your getblock, getdata etc and simply if a node does not respond with 
the requested data after a few attempts, we disconnect  and perhaps blacklist 
until the  node restarts or something. I am of course purely looking at it from 
the perspective of useless nodes consuming connection slots, there may be other 
scenarios where you require proof of storage that I am not considering. I just 
think that simple blacklist rules could easily avoid this without the extra 
resource usage? I mean if you start doing encryption for every task then before 
you know it you need to dedicate all your cpu to the node! Especially for tasks 
that are not mission critical or require verification, I mean useless nodes are 
more of an annoyance with the potential to disrupt the network, slow it down, 
but not compromise it, so I shouldn't think it would be something that you 
would turn to encryption for right? I feel this anyway.

From: Sergio Lerner
Sent: ‎17/‎03/‎2015 3:45 AM
To: 
bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] "network disruption as a service" and proof of 
local storage

The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage here:
https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919

I proposed a (what I think) is better protocol for Proof of Storage that
I call "Proof of Local storage" here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
. It's better because it does not need the storage of additional data,
but more importantly, it allows you to prove full copy of the blockchain
is being maintained by the peer.
This is specially important now that Bitnodes is trying a full-node
incentive program that may be easily cheated
(http://qntra.net/2015/02/pseudonode-proxy-fools-bitcoin-full-node-incentive-program/)

Proof of local storage allows a node to prove another peer that he is
storing a LOCAL copy of a PUBLIC file, such as the blockchain. So the
peer need not waste more resources (well, just some resources to
encode/decode the block-chain).
The main idea is to use what I called asymmetric-time-encoding.
Basically you encode the block-chain in a way that it takes 100 more
times to write it than to read it. Since the block-chain is an
append-only (write-only) file, this fit good for our needs. For instance
(and as a simplification), choosing a global 1024-bit prime, then
splitting the block-chain in 1024-bit blocks, and encrypting each block
using Polihg-Hellman (modexp) with decryption exponent 3.  Then
encryption is at least 100 times slower than decryption. Before PH
encryption each node must xor each block with a pseudo-random mask
derived from the public IP and the block index.  So block encryption
could be:
BlockEncryptIndex(i) = E(IP+i,block(i))^inv(3) (mod p),

where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption
routine (tweak = index), but we only need the PRNG properties of E() and
that E() does share algebraic properties with P.H..

Two protocols can be performed to prove local possession:
1. (prover and verifier pay a small cost) The verifier sends a seed to
derive some n random indexes, and the prover must respond with the hash
of the decrypted blocks within a certain time bound. Suppose that
decryption of n blocks take 100 msec (+-100 msec of network jitter).
Then an attacker must have a computer 50 faster to be able to
consistently cheat. The last 50 blocks should not be part of the list to
allow nodes to catch-up and encrypt the blocks in background.

2. (prover pay a high cost, verified pays negligible cost). The verifier
chooses a seed n, and then pre-computes the encrypted blocks derived
from the seed using the prover's IP. Then the verifier sends the  seed,
and the prover must respond with the hash of the encrypted blocks within
a certain time bound. The proved does not require to do any PH
decryption, just take the encrypted blocks for indexes derived from the
seed, hash them and send the hash back to the verifier. The verifier
validates the time bound and the hash.

Both protocols can me made available by the client, under different
states. For instance, new nodes are only allowed to request protocol 2
(and so they get an initial assurance their are connecting to
full-nodes). After a first-time mutual authentication, they are allowed

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Thy Shizzle]

Oh so you're talking about the criminality of one single entity? So having a 
quick look, it seems that the issue is they are collecting IPs and that kind of 
thing as well? So similar to what http://getaddr.bitnodes.io is doing but 
without the funding from the bitcoin foundation? If you are worried about your 
IP getting out you're behind a VPN. They can only collect the information made 
available to them. Botnets etc are completely different because you are forcing 
control over something you have no right to do. If companies want to sit there 
and collect publicly available information that you are voluntarily making 
available to them, why do you care? I can't see how it could be at all 
criminal. Remembering that most privacy laws relate to information that YOU 
PROVIDE to an entity during an agreement for service, payment, etc. You are 
providing this information publicly and they are collecting it from the public 
domain, not you giving it to them in an agreement, therefore the usual 
provisions of privacy etc don't apply. If you connect to their scraper node, of 
course they can log that. How could it possibly be criminal?

From: odinn<mailto:odinn.cyberguerri...@riseup.net>
Sent: ‎23/‎03/‎2015 4:50 PM
To: Thy Shizzle<mailto:thyshiz...@outlook.com>
Cc: 
bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network 
disruption as a service" startups

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Back to what is Chainalysis and country of their origin, so criminal
complaints against them would likely relate to violation of Swiss
laws, as is described here:
https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882

It is fairly obvious that Chainalysis is not merely doing what
blockchain.info etc. is. Let's not delude ourselves here.

As stated, it would be advisable for such a firm to cease operations,
and it would seem that plenty of polite shots over the bow have been
given to Chainalysis, which should now fold up its operation, pack its
bags, and go back to its hole before trying to serve its masters again
in another way. Etc.

Corporations similar to Chainalysis which are domiciled in other
countries which conduct collection of information in ways that violate
countries' laws (there are many countries and each have their own ways
of interpreting user privacy and what constitutes permissible breach
and in what circumstances) can indeed be held to legal standards that
may result in minimal or severe legal penalties.  It is true that
analyzing information that is publicly available, such as that which
is in a library, is not illegal. But the act of surveillance is.
(Then there is the question of what sort of surveillance, targeted or
general, and whether it is limited to the bitcoin network or if it
moves beyond that to attempts to correlate with usernames, IDs, IPs,
and other information available on fora and apparent from services,
but I won't get into that here.)  Even if you argue that the manner in
which you are performing your actions is not actually "surveillance,"
or you argue that it is "legally permissible," someone else will
certainly come along and make a reasonable argument that you are
indeed engaging in illegal surveillance.  They may even suggest to a
judge that you are in the process of constructing a botnet and demand
that your domains be seized, and may successfully obtain an ex parte
temporary restraining order (TRO) against Chainalysis and similar
corporations to have domain(s) seized.  Any and all arguments may be
added in here, there are 196 countries in the world today - each with
their own unique laws - (maybe less by the time you read this) and a
shit-ton of possible legal arguments that can be made by creative
minds that might want to sue you if you have been surveilling people,
each different depending on where your surveillance corporation is
domiciled.  There are plenty of legal processes available for people
to do exactly that.  You are indeed subject to having that happen to
you if you continue to surveill the network even if you are doing so
on behalf of the state for the purpose of gathering information for a
state's compliance initiative.

So, don't delude yourself, and be happy if all that happens is your
little surveillance initiative has to close its doors (or gets sued if
it stays open).  Because that is the legal side of things.  The
extralegal stuff is far worse.  The community is helping you by asking
you gently to close up shop and go away. It is a helpful suggestion
and I believe also a fair warning, again, a shot off the bow.

On the development side, developers are certainly responsible for
doing what they can to resist this kind of surveillance activity.  But
I have a feeling that will be a different thread 

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Thy Shizzle]

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" 
Sent: ‎23/‎03/‎2015 1:48 PM
To: "bitcoin-development@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 
> 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 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

@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: nei...@thecodefactory.org
> To: thashizn...@yahoo.com.au
> CC: Bitcoin-development@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 +, 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 +, 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.
> > 
> &g

[Bitcoin-development] Broken Threading

[Thy Shizzle]

Yes apologies for the broken threading, it was the result of me auto forwarding 
between mail providers etc.

To fix this issue I have created this new dedicated outlook account 
(thyshiz...@outlook.com) that I shall use for all my subscriptions here and I 
am unsubscribing the yahoo address. This should solve this issue going forward 
:)
  --
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Testnet3

[Thy Shizzle]

Strangely enough, it has started to work properly and I didn't even touch my 
code just had it sitting there in the loop/ping circuit it was performing and 
capturing with wireshark.that is quite odd!

"Hi, so I have my .NET node communicating on the P2P network just fine, so I 
figured as I'll now start looking at making and validating transactions etc I 
should probably migrate to test net. Now I see that we are up to the third 
generation testnet testnet3, and I am sending my messages now using packet 
magic 0x0b110907 and I'm using Wireshark and I can confirm that my messages are 
going out with that packet magic.
Now what is interesting is that when I try connect to a test node obtained from 
DNS seed testnet-seed.bitcoin.petertodd.org, I send it a version message with 
the testnet3 packet magic, yet I get no verack or version in response In 
fact, the only thing I get back is a ping and then the connection is severed by 
the remote node.
What is going on? Also, it works fine with the mainnet packet magic value of 
0x0f9beb4d9 and I am debuging my code and ensuring it is looking for the 
testnet3 packet magic, but I am not getting a response from the node?"--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

  Why on earth would you want to derive the mnemonic from the wallet seed? Ever?
Remembering that as an attacker doesn't actually have to do any key stretching, 
they can just keep trying (what is it 64 bytes from memory?) at a time without 
any PBKDF2 to attack a seed, it seems that the PBKDF2 is just to slow down 
anyone attempting to attack through an interface such as a web service or to a 
TREZOR or whatever, in a real world attack you would not even be performing 
PBKDF2 you would just brute force the raw bytes and force them into the BIP32 
wallet as there is no Authentication scheme that hashes and compares against 
the result. It purely limits abuse through an online wallet provider or 
something like that by slowing down seed generation attempts THROUGH that API, 
it doesn't really add any security to the seed in a real world brute force 
attack! So yea I think the 2048 iteration count is sufficient for it's purpose 
because even if it only forces an extra 1ms per seed generation through the 
API, it is still slower than just brute forcing the 64 bytes straight up, and 
so they would have no reason to abuse your API that is all :)
"meh... the fact that you can't derive the seed phrase from the wallet seed, 
and that the password key stretching is so weak as to be ineffectual security 
theater bugs me. Feels like a pretty big compromise to work on current 
generation low power embedded devices when the next generation will be more 
than capable. But I understand the motivation for the compromise.

Aaron Voisine
co-founder and CEO
breadwallet.com"--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

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  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--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

 "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 +, 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 o

[Bitcoin-development] Testnet3

[Thy Shizzle]

 Hi, so I have my .NET node communicating on the P2P network just fine, so I 
figured as I'll now start looking at making and validating transactions etc I 
should probably migrate to test net. Now I see that we are up to the third 
generation testnet testnet3, and I am sending my messages now using packet 
magic 0x0b110907 and I'm using Wireshark and I can confirm that my messages are 
going out with that packet magic.
Now what is interesting is that when I try connect to a test node obtained from 
DNS seed testnet-seed.bitcoin.petertodd.org, I send it a version message with 
the testnet3 packet magic, yet I get no verack or version in response In 
fact, the only thing I get back is a ping and then the connection is severed by 
the remote node.
What is going on? Also, it works fine with the mainnet packet magic value of 
0x0f9beb4d9 and I am debuging my code and ensuring it is looking for the 
testnet3 packet magic, but I am not getting a response from the node?




--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

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:
> H 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--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

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 writte

Re: [Bitcoin-development] Useless Address attack?

[Thy Shizzle]

Interesting!
Thanks Kevin, I now need to research this and include such protections in my 
node. 
Also (I am fuzzy on the details for this), Bitcoind will detect when a node is 
misbehaving and (I believe) it will blacklist misbehaving nodes for a period of 
time so it doesn't continually keep trying to connect to tarpit nodes, for 
example.
On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene  wrote:

Bitcoind protects against this by storing the addresses it has learned about in 
buckets. The bucket an address is stored in is chosen based on the IP of the 
peer that advertised the addr message, and the address in the addr message 
itself. The idea is that the bucketing is done in a randomized way so that no 
attacker should be able to fill your database with his or her own nodes.
>From addrman.h:
/** Stochastic address manager * * Design goals: *  * Keep the address tables 
in-memory, and asynchronously dump the entire to able in peers.dat. *  * Make 
sure no (localized) attacker can fill the entire table with his 
nodes/addresses. * * To that end: *  * Addresses are organized into buckets. *  
  * Address that have not yet been tried go into 256 "new" buckets. *      * 
Based on the address range (/16 for IPv4) of source of the information, 32 
buckets are selected at random *      * The actual bucket is chosen from one of 
these, based on the range the address itself is located. *      * One single 
address can occur in up to 4 different buckets, to increase selection chances 
for addresses that *        are seen frequently. The chance for increasing this 
multiplicity decreases exponentially. *      * When adding a new address to a 
full bucket, a randomly chosen entry (with a bias favoring less recently seen * 
       ones) is removed from it first. *    * Addresses of nodes that are known 
to be accessible go into 64 "tried" buckets. *      * Each address range 
selects at random 4 of these buckets. *      * The actual bucket is chosen from 
one of these, based on the full address. *      * When adding a new good 
address to a full bucket, a randomly chosen entry (with a bias favoring less 
recently *        tried ones) is evicted from it, back to the "new" buckets. *  
  * Bucket selection is based on cryptographic hashing, using a 
randomly-generated 256-bit key, which should not *      be observable by 
adversaries. *    * Several indexes are kept for high performance. Defining 
DEBUG_ADDRMAN will introduce frequent (and expensive) *      consistency checks 
for the entire data structure. */
On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle  wrote:

 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?
--
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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Useless Address attack?

[Thy Shizzle]

 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?--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] What's what with addr relaying?

[Thy Shizzle]

Oh and I realised I stuffed up the subject and it talks about the addr relay 
but I actually answered my own question on the addr relaying, I had just miss 
interpreted one document I thought it was talking about subtracting 2 hours 
before relaying but I see we subtract 2 hours on receipt not relay because the 
if it hadn't been seen for 60 minutes previously it now becomes 3 hours and we 
use but don't relay makes sense. 

 On Thursday, 19 February 2015, 22:33, Thy Shizzle 
 wrote:
   
 

  Hi, plugging away at my C# Bitcoin node "Lego.NET" Thashiznets/Lego.NET now I 
am currently working on addr relaying. I am as we speak wiring up my DB in 
Azure, and ready to start plopping net_addrs in my DB, all good however I'm 
reading two different specification docs that seem to be wildly varying. I mean 
the first one here Developer Reference - Bitcoin didn't mention that version 
message now has the 4 byte checksum and no time in the net_addrs and I was 
getting reject malformed messages until I found the other document which 
informed me we now use the 4 byte checksum in version and no time in the 
net-addrs in version message. So I solved that and here is the other doco. I 
have found other variances like one document said that the heartbeat AND 
disconnect were 30 minutes, but then in the other document I read that 
Heartbeat is 30 minutes and disconnect is 90 minutes which seems far more 
sensible so I went with that and modified my code. Is there any other 
variations between these two spec docos that perhaps some of you devs know 
about that I need to look out for! Thanks! Shizzle.
|   |
|   |  |   |   |   |   |   |
| Thashiznets/Lego.NETLego.NET - A C# full node for processing the Bitcoin 
block chain |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  
|   |
|   |  |   |   |   |   |   |
| Developer Reference - BitcoinBETA: This documentation has not been 
extensively reviewed by Bitcoin experts and so likely contains numerous errors. 
Please use the Issue and Edit links on the bot... |
|  |
| View on bitcoin.org | Preview by Yahoo |
|  |
|   |

  
|   |
|   |   |   |   |   |
| Satoshi Client Node Discovery - BitcoinContents 1 Overview 2 Handling Message 
"getaddr" 3 Discovery Methods 3.1 Local Client's External Address 3.2 Connect 
Callback Address 3.3 IRC Addresses 3.4 DNS Addresses  |
|  |
| View on en.bitcoin.it | Preview by Yahoo |
|  |
|   |

    

 
   --
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] What's what with addr relaying?

[Thy Shizzle]

 Hi, plugging away at my C# Bitcoin node "Lego.NET" Thashiznets/Lego.NET now I 
am currently working on addr relaying. I am as we speak wiring up my DB in 
Azure, and ready to start plopping net_addrs in my DB, all good however I'm 
reading two different specification docs that seem to be wildly varying. I mean 
the first one here Developer Reference - Bitcoin didn't mention that version 
message now has the 4 byte checksum and no time in the net_addrs and I was 
getting reject malformed messages until I found the other document which 
informed me we now use the 4 byte checksum in version and no time in the 
net-addrs in version message. So I solved that and here is the other doco. I 
have found other variances like one document said that the heartbeat AND 
disconnect were 30 minutes, but then in the other document I read that 
Heartbeat is 30 minutes and disconnect is 90 minutes which seems far more 
sensible so I went with that and modified my code. Is there any other 
variations between these two spec docos that perhaps some of you devs know 
about that I need to look out for! Thanks! Shizzle.
|   |
|   |  |   |   |   |   |   |
| Thashiznets/Lego.NETLego.NET - A C# full node for processing the Bitcoin 
block chain |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  
|   |
|   |  |   |   |   |   |   |
| Developer Reference - BitcoinBETA: This documentation has not been 
extensively reviewed by Bitcoin experts and so likely contains numerous errors. 
Please use the Issue and Edit links on the bot... |
|  |
| View on bitcoin.org | Preview by Yahoo |
|  |
|   |

  
|   |
|   |   |   |   |   |
| Satoshi Client Node Discovery - BitcoinContents 1 Overview 2 Handling Message 
"getaddr" 3 Discovery Methods 3.1 Local Client's External Address 3.2 Connect 
Callback Address 3.3 IRC Addresses 3.4 DNS Addresses  |
|  |
| View on en.bitcoin.it | Preview by Yahoo |
|  |
|   |

    --
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development