Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2013-11-06 Thread Mike Hearn
Very cool, thanks Matt.

I was actually thinking this morning, maybe we should require all nodes to
go through the inv/getdata dance. Otherwise it's possible to improve your
chances at racing a block by mining a block, waiting to see a block inv
from another node, then blasting out your block while other nodes are still
waiting on their getdatas.


On Wed, Nov 6, 2013 at 6:50 AM, Matt Corallo bitcoin-l...@bluematt.mewrote:

 Recently, there has been a reasonable amount of discussion about the
 continued fragility of the public Bitcoin network on IRC and elsewhere
 (1). To this extent, I'm organizing a system of peering between nodes in
 the network by creating a system of high-speed relay nodes for miners
 and merchants/exchanges. This system will a) act as a fallback in the
 case that the public Bitcoin network encounters issues and b) decrease
 block propagation times between miners.
 It is NOT designed to in any way replace or decrease the need for the
 public Bitcoin P2P network. It is NOT any kind of attempt at
 centralization, and I still encourage interested parties to establish
 their own private peering agreements with large miners as needed.

 Currently the network consists of one specially-designed relay node, but
 I hope to bring more online in the coming days.

 This network is open to everyone via a few public relay nodes, but also
 will have nodes which are made available only to large miners and
 merchants/exchanges to mitigate the ability of malicious parties to DoS
 the network.

 To peer with the public relay nodes, simply select the closest region
 out of us-west (West Coast US), us-east (East Coast US), eu (Western
 Europe), au (Australia), or jpy (Japan) and add
 public.REGION.relay.mattcorallo.com to your addnode list. Note that
 since all of the relay nodes will relay between each other, you gain no
 latency advantage by peering with more than the closest node to you (and
 currently all the regions map to one node, so there they're redundant
 anyway).

 For each relay node, you can connect to either port 8334 or 8335.
 Connecting on port 8334 will relay only blocks, and port 8335 will relay
 both blocks and transactions. The relay nodes will request any
 transactions which appear in your invs no matter which port you connect to.

 Relay node details:
  * The relay nodes do some data verification to prevent DoS, but in
 order to keep relay fast, they do not fully verify the data they are
 relaying, thus YOU SHOULD NEVER mine a block building on top of a
 relayed block without fully checking it with your own bitcoin validator
 (as you would any other block relayed from the P2P network).
  * The relay nodes do not follow the standard inv-getdata-tx/block flow,
 but instead relay transactions/blocks immediately after they have done
 their cursory verification. They do keep some track of whether or not
 your nodes claim to have seen the transactions/blocks before relaying,
 but you may see transactions/blocks being sent which you already have
 and have not requested, if this is a problem for you due to bandwith
 issues, you should reconsider your bandwith constraints and/or are
 peering with too many nodes.
  * The relay nodes will all relay among themselves very quickly, so
 there is no advantage to peering with as many relay nodes as you can
 find, in fact, the increased incoming bandwidth during block relay
 spikes may result in higher latency for your nodes.
  * The relay nodes are NOT designed to ensure that you never miss data,
 and may fail to relay some transactions. Additionally, because the relay
 nodes do not respond to standard getdata requests, if you miss a relay
 and then reconnect, that data will not be sent again by the relay nodes.
 The relay nodes are NOT a replacement for having peers on the standard
 P2P network, they are only there to augment the existing P2P network.

 If you are a merchant/exchange/large miner/other important node operator
 and wish to gain access to additional domain names which map to relay
 nodes with fewer peers, please fill out the form at

 https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform

 You can find the source for the relay nodes at
 https://github.com/TheBlueMatt/RelayNode

 If you have any comments/concerns/suggestions, please do not hesitate to
 email bitcoin-peer...@mattcorallo.com

 Thanks,
 Matt


 (1) There has been extended discussion on #bitcoin-wizards as well as
 #bitcoin-dev of the very small number of active, listening nodes.
 Additionally, because many of those nodes are versions prior to 0.8.4,
 it seems very likely that maliciously creating network splits or at
 least drastically reducing the number of peers for most nodes would not
 be particularly challenging in the current network. Also,

 http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
 noted that they were able to single-handledly decrease the network-wide
 orphan rate by around 50% by improving 

Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Frank F
The problem with academics is that they don't have to worry about the real
world. They get paid to publish things, not to be helpful to society.


On Tue, Nov 5, 2013 at 11:33 PM, kjj bitcoin-de...@jerviss.org wrote:

 One of the things that really gets me going is when someone devises a
 model, tests it against itself, and then pretends that they've learned
 something about the real world.

 Naturally, the Selfish Mining paper is exactly this sort of nonsense.
 Their model is one with no latency, and one where the attacker has total
 visibility across the network.  An iterated FSM is not a suitable
 simulation of the bitcoin system.  The bitcoin network does not have
 states, and to the extent that you can pretend that we do, you can't
 simulate transitions between them with static probabilities.

 The authors understand this deep down inside, even though they didn't
 work out the implications.  They handwave the issue by assuming a total
 sybil attack, and in true academic spirit, they don't realize that the
 condition necessary for the attack is far, far worse than the attack
 itself.

 Greg said he'd like to run some simulations, and I'm thinking about it
 too.  Unfortunately, he is busy all week, and I'm lazy (and also busy
 for most of tomorrow).

 If neither of us get to it first, I'm willing to pitch in 1 BTC as a
 bounty for building a general bitcoin network simulator framework. The
 simulator should be able to account for latency between nodes, and
 ideally within a node.  It needs to be able to simulate an attacker that
 owns varying fractions of the network, and make decisions based only on
 what the attacker actually knows.  It needs to be able to simulate this
 attack and should be generic enough to be easily modified for other
 crazy schemes.

 (Bounty offer is serious, but expires in one year [based on the earliest
 timestamp that my mail server puts on this email], and /may/ be subject
 to change if the price on any reputable exchange breaks 1000 USD per BTC
 in that period.)

 Basically, the lack of a decent network simulator is what allowed this
 paper to get press.  If the author had been able to see the importance
 of the stuff he was ignoring, we wouldn't be wasting so much time
 correcting him (and sadly the reporters that have no way to check his
 claims).

 https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663




 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
*MONEY IS OVER!*
IF YOU WANT IThttp://www.zeitgeistmovie.com/
=
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Jeff Garzik
I will contribute 1 BTC to this bounty, under same terms and expiration.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2013-11-06 Thread Tier Nolan
On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo bitcoin-l...@bluematt.mewrote:

 Relay node details:
  * The relay nodes do some data verification to prevent DoS, but in
 order to keep relay fast, they do not fully verify the data they are
 relaying, thus YOU SHOULD NEVER mine a block building on top of a
 relayed block without fully checking it with your own bitcoin validator
 (as you would any other block relayed from the P2P network).


Wouldn't this cause disconnects due to misbehavior?

A standard node connecting to a relay node would receive
blocks/transactions that are not valid in some way and then disconnect.

Have you looked though the official client to find what things are
considered signs that a peer is hostile?  I assume things like double
spending checks count as misbehavior and can't be quickly checked by a
relay node.

Maybe another bit could be assigned in the services field as relay.  This
means that the node doesn't do any checking.

Connects to relay nodes could be command line/config file only.  Peers
wouldn't connect to them.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Christophe Biocca
I might try building this sometime soon. I think it may also serve an
educational purpose when trying to understand the whole network's behaviour.

What level of accuracy are we looking for though? Obviously we need to
fully emulate the steps of the network protocol, and we need to be able to
specify time taken for transmission/processing for each node. Do we care
about the actual contents of the messages (to be able to simulate double
spend attempts, invalid transactions and blocks, SPV node communication),
and their validation (actual signatures and proof of work)?

I imagine the latter is pretty useless, beyond specifying that the
signature/proof of work is valid/invalid.

If we could build up a set of experiments we'd like to run on it, it would
help clarify what's needed.

Off the top of my head:

- Peter Todd's miner strategy of sending blocks to only 51% of the
hashpower.
- Various network split conditions, and how aware of the split nodes would
be (and the effect of client variability).
- Testing the feasability of network race double spends, or Finney attacks.
- Various network partition scenarios.
- Tricking SPV nodes.
On Nov 6, 2013 6:37 AM, Jeff Garzik jgar...@bitpay.com wrote:

 I will contribute 1 BTC to this bounty, under same terms and expiration.


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Jouke Hofman
bounty++

On 06-11-13 06:33, kjj wrote:
 One of the things that really gets me going is when someone devises a 
 model, tests it against itself, and then pretends that they've learned 
 something about the real world.
 
 Naturally, the Selfish Mining paper is exactly this sort of nonsense.  
 Their model is one with no latency, and one where the attacker has total 
 visibility across the network.  An iterated FSM is not a suitable 
 simulation of the bitcoin system.  The bitcoin network does not have 
 states, and to the extent that you can pretend that we do, you can't 
 simulate transitions between them with static probabilities.
 
 The authors understand this deep down inside, even though they didn't 
 work out the implications.  They handwave the issue by assuming a total 
 sybil attack, and in true academic spirit, they don't realize that the 
 condition necessary for the attack is far, far worse than the attack itself.
 
 Greg said he'd like to run some simulations, and I'm thinking about it 
 too.  Unfortunately, he is busy all week, and I'm lazy (and also busy 
 for most of tomorrow).
 
 If neither of us get to it first, I'm willing to pitch in 1 BTC as a 
 bounty for building a general bitcoin network simulator framework. The 
 simulator should be able to account for latency between nodes, and 
 ideally within a node.  It needs to be able to simulate an attacker that 
 owns varying fractions of the network, and make decisions based only on 
 what the attacker actually knows.  It needs to be able to simulate this 
 attack and should be generic enough to be easily modified for other 
 crazy schemes.
 
 (Bounty offer is serious, but expires in one year [based on the earliest 
 timestamp that my mail server puts on this email], and /may/ be subject 
 to change if the price on any reputable exchange breaks 1000 USD per BTC 
 in that period.)
 
 Basically, the lack of a decent network simulator is what allowed this 
 paper to get press.  If the author had been able to see the importance 
 of the stuff he was ignoring, we wouldn't be wasting so much time 
 correcting him (and sadly the reporters that have no way to check his 
 claims).
 
 https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663
 
 
 
 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most 
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Peter Todd
On Wed, Nov 06, 2013 at 01:06:47PM -0500, Christophe Biocca wrote:
 I might try building this sometime soon. I think it may also serve an
 educational purpose when trying to understand the whole network's behaviour.
 
 What level of accuracy are we looking for though? Obviously we need to
 fully emulate the steps of the network protocol, and we need to be able to
 specify time taken for transmission/processing for each node. Do we care
 about the actual contents of the messages (to be able to simulate double
 spend attempts, invalid transactions and blocks, SPV node communication),
 and their validation (actual signatures and proof of work)?
 
 I imagine the latter is pretty useless, beyond specifying that the
 signature/proof of work is valid/invalid.
 
 If we could build up a set of experiments we'd like to run on it, it would
 help clarify what's needed.
 
 Off the top of my head:
 
 - Peter Todd's miner strategy of sending blocks to only 51% of the
 hashpower.

Speaking of, I hadn't gotten around to doing up the math behind that
strategy properly; turns out 51% I was overly optimistic and the actual
threshold is 29.3%

Suppose I find a block. I have Q hashing power, and the rest of the
network 1-Q. Should I tell the rest of the network, or withhold that
block and hope I find a second one?

Now in a purely inflation subsidy environment, where I don't care about
the other miners success, of course I should publish. However, if my
goals are to find *more* blocks than the other miners for whatever
reason, maybe because transaction fees matter or I'm trying to get
nLockTime'd announce/commit fee sacrifices, it gets more complicated.


There are three possible outcomes:

1) I find the next block, probability Q
2) They find the next block, probability 1-Q
2.1) I find the next block, probability Q, or (1-Q)*Q in total.
2.2) They find the next block, probability (1-Q)^2 in total.

Note how only in the last option do I lose. So how much hashing power do
I need before it is just as likely that the other miners will find two
blocks before I find either one block, or two blocks? Easy enough:

Q + (1-Q)*Q = (1-Q)^2 - Q^2 - Q + 1/2 - Q = (1 - \sqrt(2))/2

Q ~= 29.2%

So basically, if I'm trying to beat other miners, once I have 29.3% of
the hashing power I have no incentive to publish the blocks I mine!

But hang on, does it matter if I'm the one who actually has that hashing
power? What if I just make sure that only 29.3% of the hashing power
has that block? If my goal is to make sure that someone does useless
work, and/or they are working on a lower height block than me, then no,
I don't care, which means my original send blocks to 51% of the
hashing power analysis was actually wrong, and the strategy is even
more crazy: send blocks to 29.3% of the hashing power (!)


Lets suppose I know that I'm two blocks ahead:

1) I find the next block: Q(3:0)
2) They find the next block: (1-Q) (2:1)
2.1) I find the next block: (1-Q)*Q(3:1)
2.2) They find the next block: (1-Q)^2 (2:2)
2.2.1) I find the next block: (1-Q)^2 * Q  (3:2)
2.2.2) They find the next block: (1-Q)^3   (2:3)

At what hashing power should I release my blocks? So remember, I win
this round on outcomes 1, 2.1, 2.2.1 and they only win on 2.2.2:

Q + (1-Q)*Q + (1-Q)^2*Q = (1-Q)^3 - Q = 1 - 2^-3

Q ~= 20.6%

Interesting... so as I get further ahead, or to be exact the group of
miners who have a given block gets further ahead, I need less hashing
power for my incentives to be to *not* publish the block I just found.
Conversely this means I should try to make my blocks propagate to less
of the hashing power, by whatever means necessary.

Now remember, none of the above strategy requires me to have a special
low-latency network or anything fancy. I don't even have to have a lot
of hashing power - the strategy still works if I'm, say, a 5% pool. It
just means I don't have the incentives people thought I did to propagate
my blocks widely.

The other nasty thing about this, is suppose I'm a miner and recently
got a block from another miner: should I forward that block, or not
bother? Well, it depends: if I have no idea how much of the hashing
power has that block, I should forward the block. But again, if my goal
is to be most likely to get the next block, I should only forward in
such a way that 30% of the hashing power has the block.

This means that if I have some information about what % already has that
block, I have less incentive to forward! For instance, suppose that
every major miner has been publishing their node addresses in their
blocks - I'll have a pretty good idea of who probably has that most
recent block, so I can easily make a well-optimized decision not to
forward. Similarly because the 30% hashing power figure is the
*integral* of time * hashes/second, if miners are forwarding
near-target-headers, I might as well wait a few seconds and see if I see
any near-target-headers; if I do for 

Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Kyle Jerviss
You are ignoring the gambler's ruin. We do not operate on an infinite 
timeline.  If you find a big pool willing to try this, please give me 
enough advance warning to get my popcorn ready.


Peter Todd wrote:

On Wed, Nov 06, 2013 at 01:06:47PM -0500, Christophe Biocca wrote:

I might try building this sometime soon. I think it may also serve an
educational purpose when trying to understand the whole network's behaviour.

What level of accuracy are we looking for though? Obviously we need to
fully emulate the steps of the network protocol, and we need to be able to
specify time taken for transmission/processing for each node. Do we care
about the actual contents of the messages (to be able to simulate double
spend attempts, invalid transactions and blocks, SPV node communication),
and their validation (actual signatures and proof of work)?

I imagine the latter is pretty useless, beyond specifying that the
signature/proof of work is valid/invalid.

If we could build up a set of experiments we'd like to run on it, it would
help clarify what's needed.

Off the top of my head:

- Peter Todd's miner strategy of sending blocks to only 51% of the
hashpower.

Speaking of, I hadn't gotten around to doing up the math behind that
strategy properly; turns out 51% I was overly optimistic and the actual
threshold is 29.3%

Suppose I find a block. I have Q hashing power, and the rest of the
network 1-Q. Should I tell the rest of the network, or withhold that
block and hope I find a second one?

Now in a purely inflation subsidy environment, where I don't care about
the other miners success, of course I should publish. However, if my
goals are to find *more* blocks than the other miners for whatever
reason, maybe because transaction fees matter or I'm trying to get
nLockTime'd announce/commit fee sacrifices, it gets more complicated.


There are three possible outcomes:

1) I find the next block, probability Q
2) They find the next block, probability 1-Q
2.1) I find the next block, probability Q, or (1-Q)*Q in total.
2.2) They find the next block, probability (1-Q)^2 in total.

Note how only in the last option do I lose. So how much hashing power do
I need before it is just as likely that the other miners will find two
blocks before I find either one block, or two blocks? Easy enough:

Q + (1-Q)*Q = (1-Q)^2 - Q^2 - Q + 1/2 - Q = (1 - \sqrt(2))/2

Q ~= 29.2%

So basically, if I'm trying to beat other miners, once I have 29.3% of
the hashing power I have no incentive to publish the blocks I mine!

But hang on, does it matter if I'm the one who actually has that hashing
power? What if I just make sure that only 29.3% of the hashing power
has that block? If my goal is to make sure that someone does useless
work, and/or they are working on a lower height block than me, then no,
I don't care, which means my original send blocks to 51% of the
hashing power analysis was actually wrong, and the strategy is even
more crazy: send blocks to 29.3% of the hashing power (!)


Lets suppose I know that I'm two blocks ahead:

1) I find the next block: Q(3:0)
2) They find the next block: (1-Q) (2:1)
2.1) I find the next block: (1-Q)*Q(3:1)
2.2) They find the next block: (1-Q)^2 (2:2)
2.2.1) I find the next block: (1-Q)^2 * Q  (3:2)
2.2.2) They find the next block: (1-Q)^3   (2:3)

At what hashing power should I release my blocks? So remember, I win
this round on outcomes 1, 2.1, 2.2.1 and they only win on 2.2.2:

Q + (1-Q)*Q + (1-Q)^2*Q = (1-Q)^3 - Q = 1 - 2^-3

Q ~= 20.6%

Interesting... so as I get further ahead, or to be exact the group of
miners who have a given block gets further ahead, I need less hashing
power for my incentives to be to *not* publish the block I just found.
Conversely this means I should try to make my blocks propagate to less
of the hashing power, by whatever means necessary.

Now remember, none of the above strategy requires me to have a special
low-latency network or anything fancy. I don't even have to have a lot
of hashing power - the strategy still works if I'm, say, a 5% pool. It
just means I don't have the incentives people thought I did to propagate
my blocks widely.

The other nasty thing about this, is suppose I'm a miner and recently
got a block from another miner: should I forward that block, or not
bother? Well, it depends: if I have no idea how much of the hashing
power has that block, I should forward the block. But again, if my goal
is to be most likely to get the next block, I should only forward in
such a way that 30% of the hashing power has the block.

This means that if I have some information about what % already has that
block, I have less incentive to forward! For instance, suppose that
every major miner has been publishing their node addresses in their
blocks - I'll have a pretty good idea of who probably has that most
recent block, so I can easily make a well-optimized decision not to
forward. Similarly because the 30% hashing 

Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Peter Todd
On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
 You are ignoring the gambler's ruin. We do not operate on an
 infinite timeline.  If you find a big pool willing to try this,
 please give me enough advance warning to get my popcorn ready.

Gamblers ruin has nothing to do with it.

At every point you want to evaluate the chance the other side will get
ahead, vs. cashing in by just publishing the blocks you have. (or some
of them) I didn't mention it in the analysis, but obviously you want to
keep track of how much the blocks you haven't published are worth to
you, and consider publishing some or all of your lead to the rest of the
network if you stand to lose more than you gain.

Right now it's a mostly theoretical attack because the inflation subsidy
is enormous and fees don't matter, but once fees do start to matter
things get a lot more complex. An extreme example is announce/commit
sacrifices to mining fees: if I'm at block n+1, the rest of the network
is at block n, and there's a 100BTC sacrifice at block n+2, I could
easily be in a situation where I have zero incentive to publish my block
to keep everyone else behind me, and just hope I find block n+2. If I
do, great! I'll immediately publish to lock-in my winnings and start
working on block n+3


Anyway, my covert suggestion that pools contact me was more to hopefully
strike fear into the people mining at a large pool and get them to
switch to a small one. :) If everyone mined solo or on p2pool none of
this stuff would matter much... but we can't force them too yet.

-- 
'peter'[:-1]@petertodd.org
0005713cac303bd2d529ebeffa82fff60be5307010a83933698d


signature.asc
Description: Digital signature
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Kyle Jerviss
What I want is configurable 1/10/100 millisecond ticks, and accurate 
flow of information.


It doesn't seem necessary to really emulate the whole protocol, nor to 
be overly concerned with the content of messages, nor to simulate every 
little housekeeping step or network message.


I'm not looking for a bitcoin-network-in-a-bottle, I just want to see 
flows.  In the current situation, how often does a miner win if they 
hold their block until they see another one?  How does that change with 
various numbers of remote sensors?


Other applications in the future could very well involve transaction 
spread, double spends, network partitions, transaction replacement, etc.


If the simulation run in question involves blocks, I'd like realistic 
latencies for blocks.  If it is about transactions, the latencies should 
be realistic for transactions.


What is realistic for those?  That brings me to...

I'll kick in another 1 BTC for an instrumentation package for the 
reference client.  Same conditions as before.  A runtime option, 
disabled by default, that collects data for the simulator.  If this 
creates an uproar, I'll also accept a compile-time option. Support 
dumping to a file that can be uploaded to a parser as the bare minimum, 
and if you are feeling clever, add automatic uploads to a server 
specified in the conf file, or whatever.  All data should be anonymous, 
of course.  Local file should be in a format that humans can read (JSON, 
XML, CSV, etc) so that people can verify that the data is indeed anonymous.


I want stats on peers (number, turnover, latency, in/out, etc), stats on 
local operations (I/O stats, sigs per second when verifying a block, 
fraction of sig cache hits when validating, etc) and whatever else might 
be useful to a simulator.  Each parameter should collect min, max, mean, 
std. deviation, etc so that the simulator can provide realistic virtual 
nodes.


Also, I don't want anyone to think that they need to satisfy me 
personally to collect on either of these two bounties.  I will pay mine 
for a product that is generally along the lines I have laid out, if a 
couple of the core devs (Gavin, Greg, Jeff, sipa, Luke, etc) agree that 
your work is useful.



Christophe Biocca wrote:


I might try building this sometime soon. I think it may also serve an 
educational purpose when trying to understand the whole network's 
behaviour.


What level of accuracy are we looking for though? Obviously we need to 
fully emulate the steps of the network protocol, and we need to be 
able to specify time taken for transmission/processing for each node. 
Do we care about the actual contents of the messages (to be able to 
simulate double spend attempts, invalid transactions and blocks, SPV 
node communication), and their validation (actual signatures and proof 
of work)?


I imagine the latter is pretty useless, beyond specifying that the 
signature/proof of work is valid/invalid.


If we could build up a set of experiments we'd like to run on it, it 
would help clarify what's needed.


Off the top of my head:

- Peter Todd's miner strategy of sending blocks to only 51% of the 
hashpower.
- Various network split conditions, and how aware of the split nodes 
would be (and the effect of client variability).
- Testing the feasability of network race double spends, or Finney 
attacks.

- Various network partition scenarios.
- Tricking SPV nodes.

On Nov 6, 2013 6:37 AM, Jeff Garzik jgar...@bitpay.com 
mailto:jgar...@bitpay.com wrote:


I will contribute 1 BTC to this bounty, under same terms and
expiration.



--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming
models. Explore
techniques for threading, error checking, porting, and tuning. Get
the most
from the latest Intel processors and coprocessors. See abstracts
and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
mailto:Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development