Gold collapsing. Bitcoin UP.

[tvbcof]

blocksize has nothing to do with DDOS.
transaction fees, on the other hand..
they are just bound to skyrocket at some point - but that would ensure safety and integrity of the network, regardless of blocksize.

bitcoin is a privilege, bitcoin is a worldwide decentralized network.

it wont save neither greece, nor the "africans" (such fucking racist argument BTW..).
you wont be able to buy frappucinos with bitcoins, nor any other immediate useless consumption carp..
remember: p-r-i-v-i-l-e-g-e

we lucky - & screw the mass

Distributed crypto-currency solutions have the potential to support 'the masses' no matter what their position in life by taking over certain functions of government when and organized and 'standard' government fails to serve the people.

Bitcoin will hopefully end up being a part of this process, but will fail and will in fact become part of the problem if it is subverted.  The most likely way this subversion would happen would be that it is induced to outgrow itself and centralize.  That concept is the source of my desire to see things 'go slow and with caution' with respect to the blocksize (and other things.)

In other words, it is absolutely the lesser of two evils to reserve the use of Bitcoin itself to those who are positioned to support it in a net-positive manner and plan on Bitcoin being a key element in a foundation upon which solutions which can realistically support disadvantaged people can be built.

To me, and I suspect many others, the 'restriction' in native used of Bitcoin via fees or anything else is pretty much exactly the opposite of 'screw the masses'.  It's just that there is an added layer of complexity which might make it look that way to the casual observer.

[1714092926]

1714092926

[1714092926]

1714092926

[1714092926]

1714092926

[1714092926]

1714092926

[1714092926]

1714092926

[Adrian-x]

Finally got around to listening to it while having my morning coffee (which tends to last until afternoon and was not bought with BTC.)

another productive member of society dispersers into the wild after realizing bitcoin profit, while he doesn't buy coffee with Bitcoin ( unlike Adam Back who advocates bitcoin should be good for coffee) it's unclear if he left the proverbial note: "Who is John Galt?" before embarking.

 

[tvbcof]

Finally got around to listening to it while having my morning coffee (which tends to last until afternoon and was not bought with BTC.)

another productive member of society dispersers into the wild after realizing bitcoin profit, while he doesn't buy coffee with Bitcoin ( unlike Adam Back who advocates bitcoin should be good for coffee) it's unclear if he left the proverbial note: "Who is John Galt?" before embarking.

 

I agree that 'bitcoin should be good for coffee' with the caveat that it should be done (in cup-sized quantities) by use of a proxy.  Exactly the type of thing that Blockstream seems to be working on in fact.

[cypherdoc]

you can't say stocks don't give you a chance to get out.  get ready for the next roll:

Indeed, yesterday there were hundreds New-52-week-Lows while big indexes had a great day and VIX went down to 12... The kind of short opportunity you get every few months.

glad to see you see the light.

and it makes sense, if you believe TPTB intervene in the markets to manipulate upwards.  they buy the $DJI, the most easily manipulable and high profile index to sway public opinion.

[NewLiberty]

solex, where do you go to get your mempool size info?  there seems to be discrepancies btwn sources.

Lately I am using tradeblock as their site is fast and informative. https://tradeblock.com/blockchain
For some reason the leadership at blockchain.info has become rudderless and their site is often not keeping up and development there seems static. My impression anyway.

you're referring to the 1MB single tx block that f2pool constructed as a non std tx to help reduce the UTXO set?

why was that a bad thing?  it was a one off to help consolidate all that dust and required that a miner self construct this type of block and transmit it.  that wouldn't be a repeatable, viable attack to inflict on the network by a rogue miner looking to gain an advantage over other miners for the following reasons:

1.  constructing an 8MB bloat block while the rest of the network is making 1MB blocks runs the severe risk of orphaning
2.  if the pool consists mainly of hashers, they would react by redirecting their hash away from the attacking pool to preserve the network
3.  if it was coming out of China from a large miner, that miner runs even more risk of orphaning due to the GFC.
4.  other miners receiving such a bloat block could react defensively by switching to mining a 0 tx block during the validation process.
5.  game theory suggests a miner wouldn't even begin to do this attack for preservation of BTC value and his hardware investment.

Yes. The block which reduced the utxo set. That was the good part (though Greg posted on irc that it could have been constructed much more efficiently). Anyway, the bad part is that validation took 25 secs (because of all the inputs). Bitcoin full nodes have no way at present to look at a block and decide to orphan it in advance because it is a "bloat block" that will take too long to validate, they will all chug through the block first.You are probably right bloat blocks would not propagate fast enough and get orphaned.

I think something is being missed here.  The block is not a 'bloat block' more of a 'bloat transaction'.
It will propagate just as fast as the other blocks, the size is not the issue so much as the construction.

This issue arises when larger blocks are permitted.  Though even at 1mb block construction can be made to be disadvantageous to other miners in order to increase the validation time.

I am not pretending that there is no resolution to this, only that there is not yet one implemented.  It is more important to develop in order rather than rush in a fix to 1mb block limits for which we are not ready, or one which is poorly designed.

[Odalv]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

[cypherdoc]

solex, where do you go to get your mempool size info?  there seems to be discrepancies btwn sources.

Lately I am using tradeblock as their site is fast and informative. https://tradeblock.com/blockchain
For some reason the leadership at blockchain.info has become rudderless and their site is often not keeping up and development there seems static. My impression anyway.

you're referring to the 1MB single tx block that f2pool constructed as a non std tx to help reduce the UTXO set?

why was that a bad thing?  it was a one off to help consolidate all that dust and required that a miner self construct this type of block and transmit it.  that wouldn't be a repeatable, viable attack to inflict on the network by a rogue miner looking to gain an advantage over other miners for the following reasons:

1.  constructing an 8MB bloat block while the rest of the network is making 1MB blocks runs the severe risk of orphaning
2.  if the pool consists mainly of hashers, they would react by redirecting their hash away from the attacking pool to preserve the network
3.  if it was coming out of China from a large miner, that miner runs even more risk of orphaning due to the GFC.
4.  other miners receiving such a bloat block could react defensively by switching to mining a 0 tx block during the validation process.
5.  game theory suggests a miner wouldn't even begin to do this attack for preservation of BTC value and his hardware investment.

Yes. The block which reduced the utxo set. That was the good part (though Greg posted on irc that it could have been constructed much more efficiently). Anyway, the bad part is that validation took 25 secs (because of all the inputs). Bitcoin full nodes have no way at present to look at a block and decide to orphan it in advance because it is a "bloat block" that will take too long to validate, they will all chug through the block first.You are probably right bloat blocks would not propagate fast enough and get orphaned.

I think something is being missed here.  The block is not a 'bloat block' more of a 'bloat transaction'.
It will propagate just as fast as the other blocks, the size is not the issue so much as the construction.

This issue arises when larger blocks are permitted.  Though even at 1mb block construction can be made to be disadvantageous to other miners in order to increase the validation time.

the above 2 statements appear to be inconsistent.  the bloat tx does indeed take longer to propagate; 25 sec:

http://rusty.ozlabs.org/?p=522

Rusty got a bit overzealous in his pessimism as was pointed out in the comments by Dusty, who may be the Dusty who pops in here every once in a while:

Dusty | July 9, 2015 at 11:28 pm

> “If you can mine one of those, you can keep competitors off your heels forever, and own the bitcoin network… Well, probably not.”

In fact not: if a block takes too long to be verified nobody builds on it and your block get orphaned (miners build only on blocks they’ve verified… or at least they should).

So you lose the time you hashed and your reward: next time you’ll probably learn the lesson and create a smaller block

I am not pretending that there is no resolution to this, only that there is not yet one implemented.  It is more important to develop in order rather than rush in a fix to 1mb block limits for which we are not ready, or one which is poorly designed.

i wonder if that is true.  it's possible that everything exists in the protocol now along with the game theory, as it stands, to encourage miners not to bloat blocks for the fear of orphaning and preservation of network value.

[NewLiberty]

I see your confusion.  You've confused propagation with verification.

Again, this isn't about creating a too-big block, or even an especially large one (though the larger it is the longer the verification time can be).
It is about creating blocks of acceptable size with valid but complex transactions.

Yes, other miners may decide to implement some trap for blocks that take a long time to verify.  Doing so runs the risk that not everyone else will do that, and get stuck mining on the not-longest chain.

If the block is discarded and they continue on the previous, then they are forking at risk of orphaning.  Either way the miners have a risk and the complicated TX miner has an advantage... unless everyone does the same thing (and they won't).

[cypherdoc]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

[TheRealSteve]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

Just the usual suspects.

[Odalv]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

This is also evidence that we are currently using 20% of network capacity. (and 80% of load was only temporary spamming)

[cypherdoc]

I see your confusion.  You've confused propagation with verification.

Again, this isn't about creating a too-big block, or even an especially large one (though the larger it is the longer the verification time can be).
It is about creating blocks of acceptable size with valid but complex transactions.

Yes, other miners may decide to implement some trap for blocks that take a long time to verify.  Doing so runs the risk that not everyone else will do that, and get stuck mining on the not-longest chain.

If the block is discarded and they continue on the previous, then they are forking at risk of orphaning.  Either way the miners have a risk and the complicated TX miner has an advantage... unless everyone does the same thing (and they won't).

does your above argument depend on the existence of the relay network or not?

[cypherdoc]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

This is also evidence that we are currently using 20% of network capacity. (and 80% of load was only temporary spamming)

first off, my argument that miners can control spam and bloated blocks trumps your argument.

second, it's clear that the spamming started at about 50% of full blocks:



third, i agree that there is spamming going on by attackers wanting to disrupt user growth, imo.  the fact that the network responded well to weeks of full blocks w/o breaking down is yet again an argument for bigger blocks; we're perfectly capable of handling them

fourth, b/c the network is perfectly capable of handling the extra load, idealistically, tx's should be kept on MC to feed miners long term as we transition away from block rewards to fee based security.  this is needed for maximum decentralization and security.

[Odalv]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

This is also evidence that we are currently using 20% of network capacity. (and 80% of load was only temporary spamming)

first off, my argument that miners can control spam and bloated blocks trumps your argument.

second, it's clear that the spamming started at about 50% of full blocks:



third, i agree that there is spamming going on by attackers wanting to disrupt user growth, imo.  the fact that the network responded well to weeks of full blocks w/o breaking down is yet again an argument for bigger blocks; we're perfectly capable of handling them

fourth, b/c the network is perfectly capable of handling the extra load, idealistically, tx's should be kept on MC to feed miners long term as we transition away from block rewards to fee based security.  this is needed for maximum decentralization and security.

 - Bitcoin transaction fee market. (requires pressure on fees)
 - Increased fees will be forcing new services to be built. So there is no need to change/centralize bitcoin protocol.

[solex]

I see your confusion.  You've confused propagation with verification.

Again, this isn't about creating a too-big block, or even an especially large one (though the larger it is the longer the verification time can be).
It is about creating blocks of acceptable size with valid but complex transactions.

Yes, other miners may decide to implement some trap for blocks that take a long time to verify.  Doing so runs the risk that not everyone else will do that, and get stuck mining on the not-longest chain.

If the block is discarded and they continue on the previous, then they are forking at risk of orphaning.  Either way the miners have a risk and the complicated TX miner has an advantage... unless everyone does the same thing (and they won't).

does your above argument depend on the existence of the relay network or not?

The debate might be helped with a graphic of network topology types. Bitcoin is the bottom right "irregular" type, except far larger and messier than the simple example here. This makes it infinitely more robust than all the other types. Call that Satoshi genius or simply an emergent property of decentralization or both.



Let's say that a "rogue" block gets mined by a node and sent to its peers. For illustration this might be too big for most bandwidth e.g. 100MB (leaving aside the message size limits) or a deviously constructed bloated tx block of 5MB which takes 3 hours to validate. If this rogue block can't be efficiently handled then it borks the node's immediate peers for a period of time. However, the rest of the network continues in a viable state. If the block is finally processed the invs to the next peers get ignored because the chain has moved on and the rogue block orphaned.

We immediately see that a fully-connected network has a far higher risk of systemic failure because a rogue block could seize up all nodes simultaneously, yet an irregular (mesh or multi-hop) network will be largely unaffected. Each node having just a dozen connections means that the other 6000 nodes keep on tracking oblivious to the rogue block. This is a reason why "5 nodes worldwide" is useless, and thousands are best.

This design feature is compromised if nodes forward blocks without validation, or if a central block transmission method exists which makes the mining topology more like a bus or star. That's one reason why I really like IBLT as a block propagation efficiency method: it retains the inherent robustness of an irregular topology when all nodes participate in being able to encode (mine) and decode (read, verify).

[cypherdoc]

I see your confusion.  You've confused propagation with verification.

Again, this isn't about creating a too-big block, or even an especially large one (though the larger it is the longer the verification time can be).
It is about creating blocks of acceptable size with valid but complex transactions.

Yes, other miners may decide to implement some trap for blocks that take a long time to verify.  Doing so runs the risk that not everyone else will do that, and get stuck mining on the not-longest chain.

If the block is discarded and they continue on the previous, then they are forking at risk of orphaning.  Either way the miners have a risk and the complicated TX miner has an advantage... unless everyone does the same thing (and they won't).

does your above argument depend on the existence of the relay network or not?

The debate might be helped with a graphic of network topolgy types. Bitcoin is the bottom right "irregular" type, except far larger and messier than the simple example here. This makes it infinitely more robust than all the other types. Call that Satoshi genius or simply an emergent property of decentralization or both.



Let's say that a "rogue" block gets mined by a node and sent to its peers. For illustration this might be too big for most bandwidth e.g. 100MB (leaving aside the message size limits) or a deviously constructed bloated tx block of 5MB which takes 3 hours to validate. If this rogue block can't be efficiently handled then it borks the node's immediate peers for a period of time. However, the rest of the network continues in a viable state. If the block is finally processed the invs to the next peers get ignored because the chain has moved on and the rogue block orphaned.

We immediately see that a fully-connected network has a far higher risk of systemic failure because a rogue block could seize up all nodes simultaneously, yet an irregular (mesh or multi-hop) network will be largely unaffected. Each node having just a dozen connections means that the other 6000 nodes keep on tracking obvious of the rogue block. This is a reason why "5 nodes worldwide" is useless, and thousands are best.

This design feature is compromised if nodes forward blocks without validation, or if a central block transmission method exists which makes the mining topology more like a bus or star. That's one reason why I really like IBLT as a block propagation efficiency method: it retains the inherent robustness of an irregular topology when all nodes participate in being able to encode (mine) and decode (read, verify).

i think this is the right answer, relay network or not, as we see that it can't even help the Chinese miners trapped behind the GFC thus preventing the long FUD'd large miner, large block attack on small miners.

you're right that a complex block nor a bloated block can be progated along by full nodes if it takes too long to validate thus causing orphaning.  that's a good thing and a check on miner attacks even tho game theory suggests they wouldn't want to do this attack anyways b/c of the repercussions to their bottom line.

[cypherdoc]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

This is also evidence that we are currently using 20% of network capacity. (and 80% of load was only temporary spamming)

first off, my argument that miners can control spam and bloated blocks trumps your argument.

second, it's clear that the spamming started at about 50% of full blocks:



third, i agree that there is spamming going on by attackers wanting to disrupt user growth, imo.  the fact that the network responded well to weeks of full blocks w/o breaking down is yet again an argument for bigger blocks; we're perfectly capable of handling them

fourth, b/c the network is perfectly capable of handling the extra load, idealistically, tx's should be kept on MC to feed miners long term as we transition away from block rewards to fee based security.  this is needed for maximum decentralization and security.

 - Bitcoin transaction fee market. (requires pressure on fees)
 - Increased fees will be forcing new services to be built. So there is no need to change/centralize bitcoin protocol.

1.  the timing is wrong-way too early in Bitcoin's history to force a fee mkt before major adoption and decentralization has been achieved
2.  the implementation is wrong-enforced by a centralized core dev trying to guess where the proper block size should be which we all know is impossible.  let the free mkt interaction btwn the involved players determine fees, ie, btwn miners and users and remove core dev from central planning by removing the limit.

[Cconvert2G36]

Looks like miners are refusing to process spam. A lot of small blocks 130k-250k

365759    11 minutes    443    4,100.18 BTC    F2Pool    245.87
365758    18 minutes    395    1,025.98 BTC    BW.COM    926.96
365757    18 minutes    241    2,372.34 BTC    BTCChina Pool    130.5
365756    22 minutes    464    4,485.79 BTC    BTCChina Pool    242.17
365755    29 minutes    1107    15,025.43 BTC    F2Pool    627.49
365754    43 minutes    253    1,468.09 BTC    F2Pool    244.03

that is evidence that miners can indeed control spam or bloated blocks that attempt to attack the network.

lift the limit entirely.

This is also evidence that we are currently using 20% of network capacity. (and 80% of load was only temporary spamming)

first off, my argument that miners can control spam and bloated blocks trumps your argument.

second, it's clear that the spamming started at about 50% of full blocks:



third, i agree that there is spamming going on by attackers wanting to disrupt user growth, imo.  the fact that the network responded well to weeks of full blocks w/o breaking down is yet again an argument for bigger blocks; we're perfectly capable of handling them

fourth, b/c the network is perfectly capable of handling the extra load, idealistically, tx's should be kept on MC to feed miners long term as we transition away from block rewards to fee based security.  this is needed for maximum decentralization and security.

 - Bitcoin transaction fee market. (requires pressure on fees)
 - Increased fees will be forcing new services to be built. So there is no need to change/centralize bitcoin protocol.

1.  the timing is wrong-way too early in Bitcoin's history to force a fee mkt before major adoption and decentralization has been achieved
2.  the implementation is wrong-enforced by a centralized core dev trying to guess where the proper block size should be which we all know is impossible.  let the free mkt interaction btwn the involved players determine fees, ie, btwn miners and users and remove core dev from central planning by removing the limit.

I'm with you on much of this, but a full removal introduces too many untested variables. Hell, lets start with BIP 102, see what happens, analyze the data gleamed from it. No question that 3 tps is too low in the mid term, but 6 tps will give plenty of time. I haven't lost all faith in the community in the hope of calculated reason to prevail, in fact it's good that these things are very difficult to do. 

[cypherdoc]

ouch:

https://www.reddit.com/r/Bitcoin/comments/3dovjp/wsj_lets_be_honest_about_gold_its_a_pet_rock/

[NewLiberty]

I see your confusion.  You've confused propagation with verification.

Again, this isn't about creating a too-big block, or even an especially large one (though the larger it is the longer the verification time can be).
It is about creating blocks of acceptable size with valid but complex transactions.

Yes, other miners may decide to implement some trap for blocks that take a long time to verify.  Doing so runs the risk that not everyone else will do that, and get stuck mining on the not-longest chain.

If the block is discarded and they continue on the previous, then they are forking at risk of orphaning.  Either way the miners have a risk and the complicated TX miner has an advantage... unless everyone does the same thing (and they won't).

does your above argument depend on the existence of the relay network or not?

The debate might be helped with a graphic of network topology types. Bitcoin is the bottom right "irregular" type, except far larger and messier than the simple example here. This makes it infinitely more robust than all the other types. Call that Satoshi genius or simply an emergent property of decentralization or both.



Let's say that a "rogue" block gets mined by a node and sent to its peers. For illustration this might be too big for most bandwidth e.g. 100MB (leaving aside the message size limits) or a deviously constructed bloated tx block of 5MB which takes 3 hours to validate. If this rogue block can't be efficiently handled then it borks the node's immediate peers for a period of time. However, the rest of the network continues in a viable state. If the block is finally processed the invs to the next peers get ignored because the chain has moved on and the rogue block orphaned.

We immediately see that a fully-connected network has a far higher risk of systemic failure because a rogue block could seize up all nodes simultaneously, yet an irregular (mesh or multi-hop) network will be largely unaffected. Each node having just a dozen connections means that the other 6000 nodes keep on tracking oblivious to the rogue block. This is a reason why "5 nodes worldwide" is useless, and thousands are best.

This design feature is compromised if nodes forward blocks without validation, or if a central block transmission method exists which makes the mining topology more like a bus or star. That's one reason why I really like IBLT as a block propagation efficiency method: it retains the inherent robustness of an irregular topology when all nodes participate in being able to encode (mine) and decode (read, verify).

Agree on the resiliency of topology, but consider...

This threat is not from a bandwidth attack with a big block, for it to work, the block size of the "rogue" has to be acceptable, the transactions valid.
Implementation of IBLT helps only if this rogue is not done intentionally by a miner (and not broadcasting the long-validation-time transactions until included in the winning block).

It gets interesting when the verification takes longer than the propagation which as we've seen can be done with a high volume of outputs and inputs, and possibly more so by ordering inputs/outputs within the TXs and block to avoid validation and processing shortcuts.

Consider further that this is merely a single edge case threat.  When it comes to corner cases (multiple edge cases), you can get other failure conditions in more rare circumstances.  Any hard fork presents at least one additional edge case.

The relay network topology may matter in picking the degree of complexity to have the desired effect, (even a 25 second validation gives about a 5% head start on the 10 minutes, which may be enough to increase profit above the competition).  The relay network topology can also be utilized by picking your peers to make the method more likely to succeed.


I'm a fan of increasing the transaction rate, but I'm more interested in the Bitcoin Experiment being successful in the long run.  I think we'll get there, but don't be so impatient as to stumble over the things to do first.