Author

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

legendary
Activity: 2968
Merit: 1198
June 22, 2015, 03:31:56 PM

Satoshi made a judgement at one time that 1 MB was an appropriate limit based on that vulnerability, considering the state of the technology, storage, propagation, etc.. What is the evidence for that vulnerability being sufficiently smaller now or in the near future that a 8x or 20x or 1000x is appropriate instead?


The evidence is the 3.5 billion market cap as compared to 0 back then (or the most optimistic estimate maybe 5M).

That's not evidence of anything.

For example, it could be evidence that the 1 MB block size limit is working great and shouldn't be changed.

I mean evidence based on analysis of the actual technology. Example: Someone on this thread or reddit (I don't remember which) claimed that laptop performance hadn't increased much in the past six years. Someone disputed that and pointed out that desktop performance had in fact increased by 2-3x. Now 2-3x is great but it isn't 8x or 20x, and that sort of data doesn't lend a lot of support for 1000x in 15 years either.
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 03:27:39 PM
It looks like he's proposed to increase the blocksize, not in steps like my figure from yesterday showed, but by linear ramps:

Code:
       // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate

How does that jive with miners periodically voting in increases via block versioning at the 75% level every 2y?

My understanding is that the miners only need to successfully vote once in order to activate the increase.  Once activated, future increases are on autopilot until 2036. 

i like it.  it smooths out the doubling jumps and the version voting only occurs once.
sr. member
Activity: 420
Merit: 262
June 22, 2015, 03:17:22 PM
Subsidies are great if you want to get applicants who qualify, It should be called a subsidiary not a reward for good reason, the problem is there are developers who feel the economics are wrong and Bitcoin needs to be fixed, I may not be able to express why but to my understanding the mechanism seems well balanced and considered in my view, the onus is on the people who have a problem with how Bitcoin works to prove its broken, and build a better mousetrap not change this one.

My position is that it would be great if we could have started Bitcoin up without a block subsidy, but since the currency has to be issued via some method, and since the only way to produce a truly optimal initial distribution would require an entity that was both omnipotent and omniscient, issuing the currency via block subsidy spread out over time is the least terrible way to do it.

Other than the wealth effect, much of the real capital (at least initially until the NWO-directed ecosystem was bootstrapped) went to the utility, hardware, and usury industry to which miners are beholden. If that was the optimum way to bootstrap an ecosystem, then it was correct.

In my view, it was the only way to build a global ecosystem amongst conflicting interests because it is unassailable until it scales to the point where it becomes distributed but centralized, then at that point it can only be assailed by the TPTB.

It's in my queue of articles that need to be written.

http://esr.ibiblio.org/?p=3514

Those who can’t build, talk
Posted on 2011-07-28 by Eric Raymond (progenitor of the term "open source")

One of the side-effects of using Google+ is that I’m getting exposed to a kind of writing I usually avoid – ponderous divagations on how the Internet should be and the meaning of it all written by people who’ve never gotten their hands dirty actually making it work. No, I’m not talking about users – I don’t mind listening to those. I’m talking about punditry about the Internet, especially the kind full of grand prescriptive visions. The more I see of this, the more it irritates the crap out of me. But I’m not in the habit of writing in public about merely personal complaints; there’s a broader cultural problem here that needs to be aired.

The following rant will not name names. But if you are offended by it, you are probably meant to be.

I have been using the Internet since 1976. I got involved in its engineering in 1983. Over the years, I’ve influenced the design of the Domain Name System, written a widely-used SMTP transport, helped out with RFCs, and done time on IETF mailing lists. I’ve never been a major name in Internet engineering the way I have been post-1997 in the open-source movement, but I was a respectable minor contributor to the former long before I became famous in the latter. I know the people and the culture that gets the work done; they’re my peers and I am theirs. Which is why I’m going to switch from “them” to “us” and “we” now, and talk about something that really cranks us off.

We’re not thrilled by people who rave endlessly about the wonder of the net. We’re not impressed by brow-furrowing think-pieces about how it ought to written by people who aren’t doing the design and coding to make stuff work. We’d be far happier if pretty much everybody who has ever been described as ‘digerati’ were dropped in a deep hole where they can blabber at each other without inflicting their pompous vacuities on us or the rest of the world.

In our experience, generally the only non-engineers whose net-related speculations are worth listening to are science-fiction writers, and by no means all of those; anybody to whom the label “cyberpunk” has been attached usually deserves to be dropped in that deep hole along with the so-called digerati. We do respect the likes of John Brunner, Vernor Vinge, Neal Stephenson, and Charles Stross, and we’re occasionally inspired by them – but this just emphasizes what an uninspiring lot the non-fiction “serious thinkers” attaching themselves to the Internet usually are.

There are specific recurring kinds of errors in speculative writing about the Internet that we get exceedingly tired of seeing over and over again. One is blindness to problems of scale; another is handwaving about deployment costs; and a third is inability to notice when a proposed cooperative ‘solution’ is ruined by misalignment of incentives. There are others, but these will stand as representative for why we very seldom find any value in the writings of people who talk but don’t build.

We seldom complain about this in public because, really, how would it help? The world seems to be oversupplied with publishers willing to drop money on journalists, communications majors, lawyers, marketers manqué, and other glib riff-raff who have persuaded themselves that they have deep insights about the net. Beneath their verbal razzle-dazzle and coining of pointless neologisms it’s extremely uncommon for such people to think up anything true that hasn’t been old hat to us for decades, but we can’t see how to do anything to dampen the demand for their vaporous musings. So we just sigh and go back to work.

Yes, we have our own shining visions of the Internet future, and if you ask us we might well tell you about them. It’s even fair to say we have a broadly shared vision of that future; design principles like end-to-end, an allergy to systems with single-point failure modes, and a tradition of open source imply that much. But, with a limited exception during crisis periods imposed by external politics, we don’t normally make a lot of public noise about that vision. Because talk is cheap, and we believe we teach the vision best by making it live in what we design and deploy.

Here are some of the principles we live by: An ounce of technical specification beats a pound of manifesto. The superior man underpromises and overperforms. Mechanism outlasts policy. If a picture is worth a thousand words, a pilot deployment is worth a million. The future belongs to those who show up to build it. Shut up and show us the code.

If you can live by these principles too, roll up your sleeves and join us; there’s plenty of work to be done. Otherwise, do everybody a favor and stop with the writing and the speeches. You aren’t special, you aren’t precious, and you aren’t helping.
legendary
Activity: 1162
Merit: 1007
June 22, 2015, 02:36:33 PM
It looks like he's proposed to increase the blocksize, not in steps like my figure from yesterday showed, but by linear ramps:

Code:
       // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate

How does that jive with miners periodically voting in increases via block versioning at the 75% level every 2y?

My understanding is that the miners only need to successfully vote once in order to activate the increase.  Once activated, future increases are on autopilot until 2036. 
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 02:33:53 PM
It looks like he's proposed to increase the blocksize, not in steps like my figure from yesterday showed, but by linear ramps:

Code:
       // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate

How does that jive with miners periodically voting in increases via block versioning at the 75% level every 2y?
legendary
Activity: 1162
Merit: 1007
June 22, 2015, 02:30:02 PM
The people fighting against the blocksize increase should learn from Bart:

legendary
Activity: 1512
Merit: 1005
June 22, 2015, 02:29:31 PM
I really don't understand why there has to be a hard limit. A soft limit will do (my node will accept X, and I will not mine larger blocks than X). X could be decided in a completely non-scary out of band collusion between the largest miners. If a soft limit can not be agreed on in a cartel, set X high enough that most blocks comply.
legendary
Activity: 1400
Merit: 1013
June 22, 2015, 02:08:37 PM
Subsidies are great if you want to get applicants who qualify, It should be called a subsidiary not a reward for good reason, the problem is there are developers who feel the economics are wrong and Bitcoin needs to be fixed, I may not be able to express why but to my understanding the mechanism seems well balanced and considered in my view, the onus is on the people who have a problem with how Bitcoin works to prove its broken, and build a better mousetrap not change this one.
My position is that it would be great if we could have started Bitcoin up without a block subsidy, but since the currency has to be issued via some method, and since the only way to produce a truly optimal initial distribution would require an entity that was both omnipotent and omniscient, issuing the currency via block subsidy spread out over time is the least terrible way to do it.

It's in my queue of articles that need to be written.
legendary
Activity: 1372
Merit: 1000
June 22, 2015, 01:53:24 PM
I will agree that market based fees are a fallacy while block subsidies are so high, but we're talking Bitcoin not just the situation today.  Vitalik isn't the best free market economics annalist I've ever read.  Bitcoin fees are set up to be a market system and its not a fallacy. Miners today can ignore the market because there reward is subsidized by 25BTC, but once this diminishes significantly the fees become all important. I've also pondered long and hard as to why fees are a monetary unit and not a percent, and I've come to the same conclusion as satoshi that it needs to be a free market fee ranging from 0 to the total value of the economy. 

Miners that ignore the macro economic data will not optimize and will either go bankrupt here are just the obvious ways fees will be optimized:  mining no free transactions (blocking free transactions = less velocity and lover value fees), or mining too many free transactions (subsidizing the Bitcoin velocity = less income and marginal benefit in value of fees) or mining block with insufficient transactions (over priced transaction fees = blocks too small) or mining blocks with too many transactions (under priced on average = blocks too big and orphaned) the market will find an equilibrium and it will happen at a pace that miners can plan and test, basically miners have a constant view of the situation as the urgency for planing is kept in sight by the forced block halving every 4 years.
The block subsidy really does distort mining, just like every other subsidy does in its respective market. The economics of Bitcoin mining are going to make a lot more sense once the block reward shrinks to negligable levels, or once the transaction volume grows large enough to render the reward negligable and thus the distortion insignifigant.

The first criteria is something over which we have no control - we just have to wait.

The second is something we can do something about.

Subsidies are great if you want to get applicants who qualify, It should be called a subsidiary not a reward for good reason, the problem is there are developers who feel the economics are wrong and Bitcoin needs to be fixed, I may not be able to express why but to my understanding the mechanism seems well balanced and considered in my view, the onus is on the people who have a problem with how Bitcoin works to prove its broken, and build a better mousetrap not change this one.
legendary
Activity: 1162
Merit: 1007
June 22, 2015, 01:51:39 PM
It looks like he's proposed to increase the blocksize, not in steps like my figure from yesterday showed, but by linear ramps:

Code:
        // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 01:46:35 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki


so is this a BIP to Core?  giving current core devs an opportunity to adopt into Core?

Yes it is. the XT patch/pull request is cited as a demo implementation.

well, he just eliminated another major objection.  we'll see.
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 01:43:14 PM

Satoshi made a judgement at one time that 1 MB was an appropriate limit based on that vulnerability, considering the state of the technology, storage, propagation, etc.. What is the evidence for that vulnerability being sufficiently smaller now or in the near future that a 8x or 20x or 1000x is appropriate instead?


The evidence is the 3.5 billion market cap as compared to 0 back then (or the most optimistic estimate maybe 5M).  The network can support a LOT more "spam" today and still be considered valuable and useful by its users.

And also experience has shown us that there is not much spam.  If there was, blocks would be 100% full all the time.  When we switch to 8, 20 MB or whatever blocks, its going to be much ado about nothing.  If the network was going to use that bandwidth right away, it would be using the full 1MB now.  

And unlike the case of email, blockchain spam is not even read by human beings so the inconvenience to the network per message is very small (esp. when pruning, etc starts).  You are trading the promise of a worldwide currency against the fear that some people might issue some frivolous txns!  Bitcoin is unlikely to stay at its current adoption level.  It is in a grow or die situation.

Someday there WILL be a fee market.  When there are 100x more users and 1000x more txns.


very well summarized.

one thing, that spam is not necessarily frivolous!  they're paying nice fees that miners are hoovering up.
legendary
Activity: 1260
Merit: 1008
June 22, 2015, 01:42:34 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki


so is this a BIP to Core?  giving current core devs an opportunity to adopt into Core?

Yes it is. the XT patch/pull request is cited as a demo implementation.
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 01:37:04 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki


so is this a BIP to Core?  giving current core devs an opportunity to adopt into Core?
legendary
Activity: 1764
Merit: 1002
June 22, 2015, 01:34:44 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki


Nice! 

Cypherdoc: did you capture an image of the last poll prior to changing it?  It seems that approval for the increase is higher than ever now.



no, unfortunately i forgot to do that but iirc the yes was around 73% before the switch to current poll
legendary
Activity: 1246
Merit: 1010
June 22, 2015, 01:32:16 PM

Satoshi made a judgement at one time that 1 MB was an appropriate limit based on that vulnerability, considering the state of the technology, storage, propagation, etc.. What is the evidence for that vulnerability being sufficiently smaller now or in the near future that a 8x or 20x or 1000x is appropriate instead?


The evidence is the 3.5 billion market cap as compared to 0 back then (or the most optimistic estimate maybe 5M).  The network can support a LOT more "spam" today and still be considered valuable and useful by its users.

And also experience has shown us that there is not much spam.  If there was, blocks would be 100% full all the time.  When we switch to 8, 20 MB or whatever blocks, its going to be much ado about nothing.  If the network was going to use that bandwidth right away, it would be using the full 1MB now.  

And unlike the case of email, blockchain spam is not even read by human beings so the inconvenience to the network per message is very small (esp. when pruning, etc starts).  You are trading the promise of a worldwide currency against the fear that some people might issue some frivolous txns!  Bitcoin is unlikely to stay at its current adoption level.  It is in a grow or die situation.

Someday there WILL be a fee market.  When there are 100x more users and 1000x more txns.
donator
Activity: 2772
Merit: 1019
June 22, 2015, 01:30:54 PM
Quote from: TPTB_need_war
Because I really must discipline myself to focus where I can make the most impact, which is coding and not talking.

Yes, please. Your ego has inflated well beyond the walls of this humble thread. Time to start your own.

Here's a working title: Anonymint's pedantic pontifications.

tbh: I would probably subscribe. It'd be nice to read his ramblings (which contain many intersting things) concentrated in one thread, not copy-pasted all over the place.
legendary
Activity: 1162
Merit: 1007
June 22, 2015, 01:30:15 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki


Nice! 

Cypherdoc: did you capture an image of the last poll prior to changing it?  It seems that approval for the increase is higher than ever now.

legendary
Activity: 1260
Merit: 1008
June 22, 2015, 01:21:54 PM
gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <[email protected]>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
legendary
Activity: 1400
Merit: 1013
June 22, 2015, 01:18:05 PM
I will agree that market based fees are a fallacy while block subsidies are so high, but we're talking Bitcoin not just the situation today.  Vitalik isn't the best free market economics annalist I've ever read.  Bitcoin fees are set up to be a market system and its not a fallacy. Miners today can ignore the market because there reward is subsidized by 25BTC, but once this diminishes significantly the fees become all important. I've also pondered long and hard as to why fees are a monetary unit and not a percent, and I've come to the same conclusion as satoshi that it needs to be a free market fee ranging from 0 to the total value of the economy. 

Miners that ignore the macro economic data will not optimize and will either go bankrupt here are just the obvious ways fees will be optimized:  mining no free transactions (blocking free transactions = less velocity and lover value fees), or mining too many free transactions (subsidizing the Bitcoin velocity = less income and marginal benefit in value of fees) or mining block with insufficient transactions (over priced transaction fees = blocks too small) or mining blocks with too many transactions (under priced on average = blocks too big and orphaned) the market will find an equilibrium and it will happen at a pace that miners can plan and test, basically miners have a constant view of the situation as the urgency for planing is kept in sight by the forced block halving every 4 years.
The block subsidy really does distort mining, just like every other subsidy does in its respective market. The economics of Bitcoin mining are going to make a lot more sense once the block reward shrinks to negligable levels, or once the transaction volume grows large enough to render the reward negligable and thus the distortion insignifigant.

The first criteria is something over which we have no control - we just have to wait.

The second is something we can do something about.
Jump to: