Thy Shizzle [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-19 to 2015-06-01
💬 Posted a total of 28 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1836zrd49hyr9aad6tvgng94uyy4r3xjcs5lkdza0ld9g5p8jkd0speeux6

Profile Code

nprofile1qqsrcappk6jmjpj77ka9kyf5z67zz23cnfvg20mx3whlkj52qnetxhczs64kj

Author Public Key

npub1836zrd49hyr9aad6tvgng94uyy4r3xjcs5lkdza0ld9g5p8jkd0speeux6

Show more details

Last Notes

2023-06-07 15:36:10

- reply

📅 Original date posted:2015-06-01
📝 Original message: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:wtogami at gmail.com>
Sent: ‎2/‎06/‎2015 4:19 AM
Cc: Bitcoin Dev<mailto:bitcoin-development at 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 <thyshizzle at outlook.com> 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. <wtogami at gmail.com>
> Sent: ‎1/‎06/‎2015 10:30 PM
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> 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 <mike at plan99.net> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/bc3d7499/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:36:08

- reply

📅 Original date posted:2015-06-01
📝 Original message: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.<mailto:wtogami at gmail.com>
Sent: ‎1/‎06/‎2015 10:30 PM
Cc: Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
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 <mike at plan99.net> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/eca65e9f/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:36:08

- reply

📅 Original date posted:2015-06-01
📝 Original message:WOW!!!! Way to burn your biggest adopters who put your transactions into the chain.......what a douche.
________________________________
From: Mike Hearn<mailto:mike at plan99.net>
Sent: ‎1/‎06/‎2015 8:15 PM
To: Alex Mizrahi<mailto:alex.mizrahi at gmail.com>
Cc: Bitcoin Dev<mailto:bitcoin-development at lists.sourceforge.net>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/85fbfd51/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:35:21

- reply

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

2023-06-07 15:35:20

- reply

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

2023-06-07 15:35:19

- reply

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

2023-06-07 15:34:41

- reply

📅 Original date posted:2015-05-11
📝 Original message: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<mailto:sergiolerner at certimix.com>
Sent: ‎11/‎05/‎2015 5:05 PM
To: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at 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 relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners,
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice, and surely doomed to fail, as network conditions dynamically
change. Also it would be perceived as an attack to the network, and the
miner (if it is a public mining pool) would be probably blacklisted.
5. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016, then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
advance will give plenty of time to SPV wallet users to upgrade.
6. If there are 10x more blocks, then there are 10x more block headers,
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
to be done only at night when the phone is connected to the power line,
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment, and the smart-phone is 1 day
out-of-synch, then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher,
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
According to CISCO mobile bandwidth connection speed increases 20% every
year. In four years, it will have doubled, so mobile phones with lower
than average data connection will soon be able to catchup.
Also there is low-hanging-fruit optimizations to the protocol that have
not been implemented: each header is 80 bytes in length. When a set of
chained headers is transferred, the headers could be compressed,
stripping 32 bytes of each header that is derived from the previous
header hash digest. So a 40% compression is already possible by slightly
modifying the wire protocol.
7. There has been insufficient testing and/or insufficient research into
technical/economic implications or reducing the block rate
This is partially true. in the GHOST paper, this has been analyzed, and
the problem was shown to be solvable for block intervals of just a few
seconds. There are several proof-of-work cryptocurrencies in existence
that have lower than 1 minute block intervals and they work just fine.
First there was Bitcoin with a 10 minute interval, then was LiteCoin
using a 2.5 interval, then was DogeCoin with 1 minute, and then
QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a
little bit. Some time ago I decided to research on the block rate to
understand how the block interval impacts the stability and capability
of the cryptocurrency network, and I came up with the idea of the DECOR+
protocol [4] (which requires changes in the consensus code). In my
research I also showed how the stale rate can be easily reduced only
with changes in the networking code, and not in the consensus code.
These networking optimizations ( O(1) propagation using headers-first or
IBLTs), can be added later.
Mortifying Bitcoin to accommodate the change to lower the block rate
requires at least:
- Changing the 21 BTC reward per block to 2.1 BTC
- Changing the nPowTargetTimespan constant
- Writing code to hard-fork automatically when the majority of miners
have upgraded.
- Allow transaction version 3, and interpret nLockTimes of transaction
version 2 as being multiplied by 10.
All changes comprises no more than 15 lines of code. This is much less
than the number of lines modified by Gavin's 20Mb patch.
As a conclusion, I haven't yet heard a good argument against lowering
the block rate.
Best regards,
Sergio.
[0] https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
[1] https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
[2] http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
[3]
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white_paper_c11-520862.html
[4] https://bitslog.wordpress.com/2014/05/02/decor/
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/daee8db4/attachment.html>

2023-06-07 15:33:49

- reply

📅 Original date posted:2015-05-08
📝 Original message: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<mailto:nicolas.dorier at gmail.com>
Sent: ‎8/‎05/‎2015 9:17 AM
To: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at 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 debating whether miners are altruist or act rationally. We
should always expect them to act rationally, but we should not forget the
peculiarity of TCP backoff game: While it is in the best interest of
players to NOT reemit TCP packet with a backoff if the ACK is not received,
everybody does it. (Because of the fallacy that changing a TCP
implementation is costless)
Often, when we think a real life situation is a prisoner dilemma problem,
it turns out that the incentives where just incorrectly modeled.
Core devs, thanks for all your work, but please step out of the banker's
role and focus on where you are the best, I speak as an entrepreneur that
doesn't want decisions about bitcoin to be taken by who has the biggest.
If the decision of the hard limit is taken for other than purely technical
decisions, ie, for the maximization of whatever metric, it will clearly put
you in banker's shoes. As an entrepreneur, I have other things to speculate
than who gets the biggest gun in the core team.
Please consider my solution,
Nicolas Dorier,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/f4a6cb22/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:32:37

- reply

📅 Original date posted:2015-04-16
📝 Original message:Zero conf :D
________________________________
From: gabe appleton<mailto:gappleto97 at gmail.com>
Sent: ‎16/‎04/‎2015 12:15 PM
To: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150416/ea93eee5/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:32:16

- reply

📅 Original date posted:2015-03-27
📝 Original message: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:gmaxwell at gmail.com>
Sent: ‎27/‎03/‎2015 2:13 PM
To: Thy Shizzle<mailto:thyshizzle at outlook.com>
Cc: s7r at sky-ip.org<mailto:s7r at sky-ip.org>; Tom Harding<mailto:tomh at thinlink.com>; Bitcoin Development<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle <thyshizzle at outlook.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150327/d99c27f9/attachment.html>

2023-06-07 15:32:15

- reply

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

2023-06-07 15:32:05

- reply

📅 Original date posted:2015-03-27
📝 Original message: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<mailto:robert at mckay.com>
Sent: ‎28/‎03/‎2015 2:33 AM
To: Matt Whitlock<mailto:bip at mattwhitlock.name>
Cc: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at 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 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.
>> >> >>
>> >> >
>> >> > Can you clarify, the prover is hashing random blocks of
>> >> *decrypted*,
>> >> > as-in raw, blockchain data? What does this prove other than,
>> >> perhaps,
>> >> > fast random IO of the blockchain? (which is useful in its own
>> >> right,
>> >> > e.g. as a way to ensure only full-node IO-bound mining if baked
>> >> into
>> >> > the PoW)
>> >> >
>> >> > How is the verifier validating the response without possession
>> of
>> >> the
>> >> > full blockchain?
>> >>
>> >> You're right, It is incorrect. Not the decrypted blocks must be
>> >> sent,
>> >> but the encrypted blocks. There correct protocol is this:
>> >>
>> >> 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
>> >> the
>> >> encrypted blocks within a certain time bound. The verifier
>> decrypts
>> >> those blocks to check if they are part of the block-chain.
>> >>
>> >> But then there is this improvement which allows the verifier do
>> >> detect
>> >> non full-nodes with much less computation:
>> >>
>> >> 3. (prover pays a small cost, verifier smaller cost) The verifier
>> >> asks
>> >> the prover to send a Merkle tree root of hashes of encrypted
>> blocks
>> >> with
>> >> N indexes selected by a psudo-random function seeded by a
>> challenge
>> >> value, where each encrypted-block is previously prefixed with the
>> >> seed
>> >> before being hashed (e.g. N=100). The verifier receives the
>> Markle
>> >> Root
>> >> and performs a statistical test on the received information. From
>> >> the N
>> >> hashes blocks, it chooses M < N (e.g. M = 20), and asks the
>> proved
>> >> for
>> >> the blocks at these indexes. The prover sends the blocks, the
>> >> verifier
>> >> validates the blocks by decrypting them and also verifies that
>> the
>> >> Merkle tree was well constructed for those block nodes. This
>> proves
>> >> with
>> >> high probability that the Merkle tree was built on-the-fly and
>> >> specifically for this challenge-response protocol.
>> >>
>> >> > I also wonder about the effect of spinning disk versus SSD.
>> Seek
>> >> time
>> >> > for 1,000 random reads is either nearly zero or dominating
>> >> depending
>> >> > on the two modes. I wonder if a sequential read from a random
>> >> index is
>> >> > a possible trade-off,; it doesn't prove possession of the whole
>> >> chain
>> >> > nearly as well, but at least iowait converges significantly.
>> Then
>> >> > again, that presupposes a specific ordering on disk which might
>> >> not
>> >> > exist. In X years it will all be solid-state, so eventually
>> it's
>> >> moot.
>> >> >
>> >> Good idea.
>> >>
>> >> Also we don't need that every node implements the protocol, but
>> only
>> >> nodes that want to prove full-node-ness, such as the ones which
>> want
>> >> to
>> >> receive bitnodes subsidy.
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel
>> Website,
>> > sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your
>> > hub for all
>> > things parallel software development, from weekly thought
>> leadership
>> > blogs to
>> > news, videos, case studies, tutorials and more. Take a look and
>> join
>> > the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your
>> hub for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join
>> the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150328/91a39972/attachment.html>

2023-06-07 15:32:04

- reply

📅 Original date posted:2015-03-23
📝 Original message: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<mailto:sergiolerner at certimix.com>
Sent: ‎17/‎03/‎2015 3:45 AM
To: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at 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
to periodically perform protocol 1. Also new nodes may be allowed to
perform protocol 1 with a small index set, and increase the index set
over time, to get higher confidence.
The important difference between this protocol and classical remote
software attestation protocols, is that the time gap between a good peer
and a malicious peer can be made arbitrarily high, picking a larger p.
Maybe there is even another crypto primitive which is more asymmetric
than exponent 3 decryption (the LUC or NTRU cryptosystem?).
In GMaxwell proposal each peer builds a table for each other peer. In my
proposal, each peer builds a single table (the encrypted blockchain), so
it could be still possible to establish a thousands of connections to
the network from a single peer. Nevertheless, the attacker's IP will be
easily detected (he cannot hide under a thousands different IPs). It's
also possible to restrict the challenge-response to a portion of the
block-chain, the portion offset being derived from the hash of both IP
addresses and one random numbers provided by each peer. Suppose each
connection has a C-R space equivalent to 1% of the block-chain. Then
having 100 connections and responding to C-R on each connection means
storing approximate 1 copy of the block-chain (there may be overlaps,
which would need to be stored twice) , while having 1K connections would
require storing 10 copies of the blockchain.
Best regards,
Sergio
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150323/bc401ab6/attachment.html>

2023-06-07 15:31:58

- reply

📅 Original date posted:2015-03-23
📝 Original message: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.cyberguerrilla at riseup.net>
Sent: ‎23/‎03/‎2015 4:50 PM
To: Thy Shizzle<mailto:thyshizzle at outlook.com>
Cc: bitcoin-development at lists.sourceforge.net<mailto:bitcoin-development at lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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 which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.
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"
> <odinn.cyberguerrilla at riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM To:
> "bitcoin-development at lists.sourceforge.net"
> <bitcoin-development at lists.sourceforge.net> Subject: Re:
> [Bitcoin-development] Criminal complaints against "network
> disruption as a service" startups
>
> If you (e.g. Chainalysis) or anyone else are doing surveillance on
> the network and gathering information for later use, and whether or
> not the ultimate purpose is to divulge it to other parties for
> compliance purposes, you can bet that ultimately the tables will be
> turned on you, and you will be the one having your ass handed to
> you so to speak, before or after you are served, in legal parlance.
> Whether or not the outcome of that is meaningful and beneficial to
> any concerned parties and what is the upshot of it in the end
> depends on on what you do and just how far you decide to take your
> ill-advised enterprise.
>
> Chainalysis and similar operations would be, IMHO, well advised to
> cease operations. This doesn't mean they will, but guess what:
>
> Shot over the bow, folks.
>
> Jan Møller:
>> What we were trying to achieve was determining the flow of funds
>> between countries by figuring out which country a transaction
>> originates from. To do that with a certain accuracy you need
>> many nodes. We chose a class C IP range as we knew that bitcoin
>> core and others only connect to one node in any class C IP range.
>> We were not aware that breadwallet didn't follow this practice.
>> Breadwallet risked getting tar-pitted, but that was not our
>> intention and we are sorry about that.
>
>> Our nodes DID respond with valid blocks and merkle-blocks and
>> allowed everyone connecting to track the blockchain. We did
>> however not relay transactions. The 'service' bit in the version
>> message is not meant for telling whether or how the node relays
>> transactions, it tells whether you can ask for block headers only
>> or full blocks.
>
>> Many implementations enforce non standard rules for handling
>> transactions; some nodes ignore transactions with address reuse,
>> some nodes happily forward double spends, and some nodes forward
>> neither blocks not transactions. We did blocks but not
>> transactions.
>
>> In hindsight we should have done two things: 1. relay
>> transactions 2. advertise address from 'foreign' nodes
>
>> Both would have fixed the problems that breadwallet experienced.
>> My understanding is that breadwallet now has the same 'class C'
>> rule as bitcoind, which would also fix it.
>
>> Getting back on the topic of this thread and whether it is
>> illegal, your guess is as good as mine. I don't think it is
>> illegal to log incoming connections and make statistical analysis
>> on it. That would more or less incriminate anyone who runs a
>> web-server and looks into the access log. At lease one Bitcoin
>> service has been collecting IP addresses for years and given them
>> to anyone visiting their web-site (you know who) and I believe
>> that this practise is very wrong. We have no intention of giving
>> IP addresses away to anyone, but we believe that you are free to
>> make statistics on connection logs when nodes connect to you.
>
>> On a side note: When you make many connections to the network
>> you see lots of strange nodes and suspicious patterns. You can
>> be certain that we were not the only ones connected to many
>> nodes.
>
>> My takeaway from this: If nodes that do not relay transactions is
>> a problem then there is stuff to fix.
>
>> /Jan
>
>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike at plan99.net>
>> wrote:
>
>>> That would be rather new and tricky legal territory.
>>>
>>> But even putting the legal issues to one side, there are
>>> definitional issues.
>>>
>>> For instance if the Chainalysis nodes started following the
>>> protocol specs better and became just regular nodes that
>>> happen to keep logs, would that still be a violation? If so,
>>> what about blockchain.info? It'd be shooting ourselves in the
>>> foot to try and forbid block explorers given how useful they
>>> are.
>>>
>>> If someone non-maliciously runs some nodes with debug logging
>>> turned on, and makes full system backups every night, and
>>> keeps those backups for years, are they in violation of
>>> whatever pseudo-law is involved?
>>>
>>> I think it's a bit early to think about these things right
>>> now. Michael Grønager and Jan Møller have been Bitcoin hackers
>>> for a long time. I'd be interested to know their thoughts on
>>> all of this.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>
>>>
Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot
>>> Media, is your hub for all things parallel software
>>> development, from weekly thought leadership blogs to news,
>>> videos, case studies, tutorials and more. Take a look and join
>>> the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>
>>>
>
>
>> ------------------------------------------------------------------------------
>
>>
>
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net/
>
>
>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJVD6mmAAoJEGxwq/inSG8CkLUH/iWvn7kp6KW2fe5RFca1eAmH
L+5P+kNDzMARIRt8A3CvopoQQMZx44aZ8pMdErUk+78A7oeP/x+scYEkSiXE17Iv
saBWv43mO+qFxgVrU7y+9njwLJoywHitBymhLGisi3hv+H7lfIMdPK2dLVThwxel
bVO0Ga8Y9qDYAwtK23yEOCT7klj5mT0tG50U4HxDpIXaJj8kCnVUC2O1MdYhr1pP
93cDuhBmXOg7sOLAPpdWVhgfnz0Vm8M0ZWUIK+4FGzpQugWHcmdp3YUDCeczOYzD
u5zVdAqvdL6qQcWkUcGfkKaAqfJH3u5F2zeQvDUEJeeEz1lWnrsXuT7cCvcp/TU=
=6io6
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150323/1785fb92/attachment.html>

2023-06-07 15:31:57

- reply

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

2023-06-07 15:31:49

- reply

📅 Original date posted:2015-03-12
📝 Original message: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 (thyshizzle at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/cc4b0b02/attachment.html>

2023-06-07 15:31:48

- reply

📅 Original date posted:2015-03-12
📝 Original message: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?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/59ebeaf7/attachment.html>

2023-06-07 15:31:48

- reply

📅 Original date posted:2015-03-12
📝 Original message: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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/9272a63e/attachment.html>

2023-06-07 15:31:45

- reply

📅 Original date posted:2015-03-05
📝 Original message: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 <kgreenek at gmail.com> 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 <thashiznets at yahoo.com.au> 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150305/757e7714/attachment.html>

2023-06-07 15:31:44

- reply

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

2023-06-07 15:31:39

- reply

📅 Original date posted:2015-03-12
📝 Original message: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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/72515729/attachment.html>

2023-06-07 15:31:38

- reply

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

2023-06-07 15:31:37

- reply

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

2023-06-07 15:31:36

- reply

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

2023-06-07 15:31:35

- reply

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

2023-06-07 15:31:33

- reply

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

2023-06-07 15:30:42

- reply

📅 Original date posted:2015-02-19
📝 Original message: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 <thashiznets at yahoo.com.au> 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 |
| |
| |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/fe073169/attachment.html>

2023-06-07 15:30:41

- reply

📅 Original date posted:2015-02-19
📝 Original message: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 |
| |
| |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150219/5fcc1b44/attachment.html>