Author

Topic: Gold collapsing. Bitcoin UP. - page 112. (Read 2032248 times)

hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
July 16, 2015, 10:34:43 PM
Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

Honestly, I'm the last person who wants to see the limit increased and a host of other problems appear. My original opinion was that an adaptive, dynamic block size limit was best, just like you argued all along. It was only when Gavin preferred a fixed scheduled increasing limit that I went with that, for the reason that any workable solution to the 1MB is better than no solution at all, and finally we are seeing with BIP 102 what must be the lowest common denominator in this whole saga. Even BIP 102 is a hell of a lot better than doing nothing.

Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size at the protocol level and this needs to go in with any >1MB change?

I really like the anti-fragility aspect of Bitcoin which is amazing because every curve ball sent its way gets dealt with in the software making it stronger in the future.

I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
July 16, 2015, 09:58:09 PM
Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).

Honestly, I'm the last person who wants to see the limit increased and a host of other problems appear. My original opinion was that an adaptive, dynamic block size limit was best, just like you argued all along. It was only when Gavin preferred a fixed scheduled increasing limit that I went with that, for the reason that any workable solution to the 1MB is better than no solution at all, and finally we are seeing with BIP 102 what must be the lowest common denominator in this whole saga. Even BIP 102 is a hell of a lot better than doing nothing.

Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size limit at the protocol level and this needs to go in with any >1MB change?

I really like the anti-fragility aspect of Bitcoin which is amazing because every curve ball sent its way gets dealt with in the software making it stronger in the future.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
July 16, 2015, 08:51:21 PM
Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset.  It isn't as though we are out of the woods.  The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).
sr. member
Activity: 406
Merit: 252
July 16, 2015, 08:31:13 PM
To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

We do know why Satoshi felt it necessary to limit the size in the way he did. Mike gives the background here: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Quote
The limit was intended to be removed. In fact, Satoshi intended it to be removed as soon as SPV wallets were developed.

I know this because at the end of 2010 I emailed him to ask about it. He responded,

A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.


So, the 1MB was a "sanity check" later described as a general spam limiting measure. When Satoshi did the commits to put this limit in everyone who used bitcoins had to run a full node. Many of them had low-power hardware and were just learning about his new form of electronic money. He did not want a rogue miner to create a series of large blocks which were >1000x the prevailing average block size, and put people off at such a delicate time. Also, the first mention of FPGA mining on bitcointalk was made then.

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.

Thank you for clarifying things.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
July 16, 2015, 08:16:50 PM
A bad thing is when people like cypherdoc derive from the conflict of interest malicious intents without proof other than "I don't trust them"
What actually happened is that when Blockstream was announced multiple noted that it created the appearance of a potential conflict of interest.

Instead of acknowledging this potential (fairly standard practice in many business situations!), the Blockstream founders took the bizarre route of denying even the possibility of a conflict of interest.

That choice of actions is what lead to ongoing concern about their motives, not the founding of Blockstream itself.
I had not seen this comment until it was pointed out to me today:

https://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/clhy7kk?context=1

There clearly were some accurate acknowledgements of potential conflicts of interests in that Reddit post.

I'd not seen it either, and it is a bit reassuring.
It would be nice to see some method for evaluating and accommodating if it is really something they recognize.
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
July 16, 2015, 08:14:51 PM
To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

We do know why Satoshi felt it necessary to limit the size in the way he did. Mike gives the background here: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

Quote
The limit was intended to be removed. In fact, Satoshi intended it to be removed as soon as SPV wallets were developed.

I know this because at the end of 2010 I emailed him to ask about it. He responded,

A higher limit can be phased in once we have actual use closer to the limit and make sure it’s working OK.
Eventually when we have client-only implementations, the block chain size won’t matter much. Until then, while all users still have to download the entire block chain to start, it’s nice if we can keep it down to a reasonable size.


So, the 1MB was a "sanity check" later described as a general spam limiting measure. When Satoshi did the commits to put this limit in everyone who used bitcoins had to run a full node. Many of them had low-power hardware and were just learning about his new form of electronic money. He did not want a rogue miner to create a series of large blocks which were >1000x the prevailing average block size, and put people off at such a delicate time. Also, the first mention of FPGA mining on bitcointalk was made then.

Clearly, a rogue miner using FPGA tech was the thing Satoshi feared at that time. Satoshi did not always explain his actions and one reason for this is that detailing an attack vector increases the probability that it will be acted upon.
sr. member
Activity: 406
Merit: 252
July 16, 2015, 07:35:43 PM
i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and [email protected].

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

As I said before, until there is some other replacement mechanism added to guard against the attack vector identified by satoshi which motivated the 1 MB limit, there is no rational basis for removing or radically increasing that limit. (I don't see anything wrong with a modest increase in line with hardware improvements since 2009-10, which is maybe something like 3x; the exact ratio depends on which of the relevant hardware resources you consider important or most important.)

I've wondered about this, as well. Some people have opined that satoshi chose arbitrary values for some aspects of bitcoin's design, but I am more inclined towards the opposite view, despite us not fully understanding why he chose some figures.
sr. member
Activity: 406
Merit: 252
July 16, 2015, 07:28:13 PM
i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and [email protected].

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.
You give Hearn far more benefit of the doubt than I do. I think he knows better. Malice? I wouldn't go so far. Hubris, perhaps. I don't know what Hearn's ulterior motives are, but I'd wager more than a few bitcoins than he has a long-term stratagem in the back of his mind. Is he the bad cop to Gavin's good cop? Are Wlad and company on board with Hearn? Are the other devs naïve? I can only speculate, and I prefer to give the devs the benefit of the doubt, but Hearn is the only dev that regularly leaves me disconcerted. At this point, I defer to Gavin's opinion over Hearn's.

EDIT: Nick Szabo recently tweeted, "Hearn's views in this debate are very far from Bitcoin developer mainstream."
https://twitter.com/NickSzabo4/status/621773448298147840
legendary
Activity: 2968
Merit: 1198
July 16, 2015, 07:15:23 PM
i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and [email protected].

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge."  

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.

To this day, nobody has explained why satoshi felt it was necessary to limit block size to prevent DoS yet suddenly today because there is more usage the threat of DoS no longer exists (?) and we should have huge/no/exponentially-growing block limits.

As I said before, until there is some other replacement mechanism added to guard against the attack vector identified by satoshi which motivated the 1 MB limit, there is no rational basis for removing or radically increasing that limit. (I don't see anything wrong with a modest increase in line with hardware improvements since 2009-10, which is maybe something like 3x; the exact ratio depends on which of the relevant hardware resources you consider important or most important.)
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
July 16, 2015, 07:06:16 PM
i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/

Oh how nice to hear the view from 2865 Sand Hill Road, courtesy of In-Q-Tel (AKA CIA) partner A16 and [email protected].

27 seconds in, and we've already being treated to hard-selling, counterfactual exaggeration in the form of "there not much time left to make changes before Bitcoin blockchain capacity runs out."

"1MB kludge"  No, wrong, a sanity check/DOS regulator is not a "kludge." 

 Angry  FFS, I'm struggling to not attribute to malice what can be explained by ignorance, but Hearn should know better.  Especially as Gavin as told us the sky will not fall because of full 1MB blocks.
legendary
Activity: 1764
Merit: 1002
July 16, 2015, 04:54:25 PM
i'm glad the VC's are starting to focus in on what the real problem is:

https://a16z.com/2015/07/13/a16z-podcast-bitcoins-growing-pains-and-possibilities/
legendary
Activity: 1414
Merit: 1000
July 16, 2015, 04:03:04 PM
The guy comes back and we drop down into the $270's.  Go figure.

+1

I posted this message to show him mirror. In (cypherdoc's)reality it is "The core devs and Blockstream" who suppressed the bitcoin price. :-)
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
July 16, 2015, 03:46:56 PM

i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.
...

The guy comes back and we drop down into the $270's.  Go figure.

yeah, and you're full of shit.  when i got back it was already down to $292 and dropping.  do you enjoy being such an idiot?

Sometimes.


LOL rekt
legendary
Activity: 4690
Merit: 1276
July 16, 2015, 03:44:37 PM

i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.
...

The guy comes back and we drop down into the $270's.  Go figure.

yeah, and you're full of shit.  when i got back it was already down to $292 and dropping.  do you enjoy being such an idiot?

Sometimes.

legendary
Activity: 1764
Merit: 1002
July 16, 2015, 03:42:46 PM
i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.


BOO!!!


The guy comes back and we drop down into the $270's.  Go figure.



yeah, and you're full of shit.  when i got back it was already down to $292 and dropping.  do you enjoy being such an idiot?
legendary
Activity: 1764
Merit: 1002
July 16, 2015, 03:41:43 PM
so it appears that the Cripplecoiners do in fact want to see centralization of tx fee determination by core dev:


    18:47:13 gavinandresen: Pierre_Rochard: So, lets say we do see fees rise. How far do we let them rise? Who decides?

    18:48:37 Pierre_Rochard: gavinandresen: at some point they stop rising because they’re too high for the marginal transactor

    18:49:03 Pierre_Rochard: gavinandresen: in theory the miners would decide, in practice the core devs


http://bitstein.org/blog/pierre-rochard-and-gavin-andresen-discuss-the-block-size-limit/
legendary
Activity: 4690
Merit: 1276
July 16, 2015, 03:39:23 PM
i'll be offline for the next 3d camping.  have fun with your new Master "iCEBlow"  et al!

2d without your FUD and bitcoin is at $318.


BOO!!!


The guy comes back and we drop down into the $270's.  Go figure.

legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
July 16, 2015, 01:37:11 PM
My definition of actual congestion is "appropriately competitive fees no longer prioritizing their tx."

What is your definition?

1.  mempool:  57000 0conf-Statoshi,  11000 Tradeblock
2.  avg wait time for 0confs=45-60 min Chain.so
3.  Mycelium no longer able to prioritize fees
4.  continued complaints on Reddit of stuck tx's even with higher fees.
5.  continuous stream of full blocks and functioning full nodes indicative that the capacity for bigger blocks exists today.
6.  TPS able to spike to >100 when needed indicative of greater bandwidth than initially thought.
7.  continued lack of wallet development for fee feedback.
8.  full blocks creating new deviant behavior.

That's an ad hoc (IE non-generalizable) mish-mash of random observations, not an objective definition.

a single self applied metric for a simpleton's mind.  is you.

yes, i'm using a overall survey of the marketplace to make my determination that we indeed have congestion.  you can't do so otherwise.

Brevity is the soul of wit; thus my definition is concise, objective, and not "self-applied" (whatever that means).

I asked for your (preferably objective) definition of BTC network congestion, not a garbled survey of ephemeral trivia.

When you look in a dictionary, you see objective, generalizable definitions, not subjective ad hoc surveys of transitory variables.

My distaste for your Free Shit Army draft and fetishization of African boys, as possessing magical powers to imbue Bitcoin with their own special kind of value, has nothing to do with my independent desire to see them (and Afghan girls, etc.) benefit from Bitcoin's ascendancy.
legendary
Activity: 4690
Merit: 1276
July 16, 2015, 01:16:07 PM

1.  mempool:  57000 0conf-Statoshi,  11000 Tradeblock
2.  avg wait time for 0confs=45-60 min Chain.so
3.  Mycelium no longer able to prioritize fees
4.  continued complaints on Reddit of stuck tx's even with higher fees.
5.  continuous stream of full blocks and functioning full nodes indicative that the capacity for bigger blocks exists today.
6.  TPS able to spike to >100 when needed indicative of greater bandwidth than initially thought.
7.  continued lack of wallet development for fee feedback.
8.  full blocks creating new deviant behavior.

Each of these is neutral reality to deal with, or great things that we should be thankful for.  Mostly the latter.  I'll defer on enumerating a reason for each at the moment.

What I will say is that when a toilet is getting clogged one can usually tell that something is up before the problem finally comes to a head and water threatens to overflow with turds and toilet paper and the like floating inches away from the rim.  At that point one breaks out the plunger and gives the the thing a few good plunges.  The obstruction cleared, the water, shit, soggy shit-stained toilet paper, vanishes never to be seen again.

This happy solution works when the pipes are in good shape but the system was simply not designed for certain kinds of abuse.  A more significant (but still solvable) problem exists when there are infrastructure failures.  Happily Bitcoin has very clear pipes (complements of the simplicity and 1MB setting) and simply needs a quick fix to a problem brought about by kids playing around and not using the system appropriately.  The solution is to give the kids a slap on the ass, a talking to, and something else to play with.  The distributed crypto-currency ecosystem has evolved to where both of these remedial activities are easily accomplished.
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
July 16, 2015, 01:04:45 PM
My definition of actual congestion is "appropriately competitive fees no longer prioritizing their tx."

What is your definition?

1.  mempool:  57000 0conf-Statoshi,  11000 Tradeblock
2.  avg wait time for 0confs=45-60 min Chain.so
3.  Mycelium no longer able to prioritize fees
4.  continued complaints on Reddit of stuck tx's even with higher fees.
5.  continuous stream of full blocks and functioning full nodes indicative that the capacity for bigger blocks exists today.
6.  TPS able to spike to >100 when needed indicative of greater bandwidth than initially thought.
7.  continued lack of wallet development for fee feedback.
8.  full blocks creating new deviant behavior.

That's an ad hoc (IE non-generalizable) mish-mash of random observations, not an objective definition.

"Complaints on Reddit?"

Oh dear sweet Jahbulon, please have mercy on those you have cursed with intelligence...   Cry

a single self applied metric for a simpleton's mind.  is you.

yes, i'm using a overall survey of the marketplace to make my determination that we indeed have congestion.  you can't do so otherwise.

If only that survey was objective and not full of misconstruction and sometimes outright false statements.

1. Mempool appears perfectly fine as we speak
3. Seems you still don't understand the problem with Mycelium
4. Source?
5. Tradeblock shows the avg blocks are hardly full
7. Wtf does this have to do with network congestion?
8. Source?

Jump to: