Bitcoin Forum
April 25, 2024, 08:53:19 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 [1355] 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 ... 1557 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2032135 times)
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
June 22, 2015, 06:42:34 PM
 #27081

gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <gavinandresen@gmail.com>
  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.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714035199
Hero Member
*
Offline Offline

Posts: 1714035199

View Profile Personal Message (Offline)

Ignore
1714035199
Reply with quote  #2

1714035199
Report to moderator
1714035199
Hero Member
*
Offline Offline

Posts: 1714035199

View Profile Personal Message (Offline)

Ignore
1714035199
Reply with quote  #2

1714035199
Report to moderator
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 06:43:14 PM
 #27082


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.
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 06:46:35 PM
 #27083

gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <gavinandresen@gmail.com>
  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.
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 22, 2015, 06:51:39 PM
 #27084

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

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000



View Profile
June 22, 2015, 06:53:24 PM
 #27085

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.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1009



View Profile
June 22, 2015, 07:08:37 PM
 #27086

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.
Erdogan
Legendary
*
Offline Offline

Activity: 1512
Merit: 1005



View Profile
June 22, 2015, 07:29:31 PM
 #27087

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.
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 22, 2015, 07:30:02 PM
 #27088

The people fighting against the blocksize increase should learn from Bart:


Run Bitcoin Unlimited (www.bitcoinunlimited.info)
cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 07:33:53 PM
 #27089

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?
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 22, 2015, 07:36:33 PM
 #27090

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. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
June 22, 2015, 08:17:22 PM
Last edit: June 22, 2015, 08:45:32 PM by TPTB_need_war
 #27091

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.

Quote
One would prefer a completely decentralized process (thus in theory no politics) such that we didn't have to rely on some individuals holding the private keys for proceeds derived from the ICO. But as Monero and Bitcoin have demonstrated, a decentralized process lacks leadership and unless you are entirely done and all is on auto-pilot, then the lack of leadership leads to paralysis, fragmentation, dearth of innovation, etc.. Thus I see no other way to proceed to build an anonymous, bearer-style (a.k.a. permission-less autonomy) ecosystem other than to concentrate some investment from the ICO and then redistribute it with leadership.

The problem is who will do that leadership and the resultant vulnerabilities and pitfalls.

Ethereum made the huge mistake of having too many managers. And choosing a problem set that is arguably intractable (Turing complete on a replicated verification).

Blockstream is ostensibly much more well focused; they've delivered alpha code at breakneck speed.


Thus it is cleverly designed (seemingly with military precision of forethought) to disrupt the existing financial disorder (entropy) and converge it to one NWO controlled morass at the end game. I couldn't have designed it better for that purpose.

Whereas, if you want to create an alternative ecosystem, such as the Knowledge Age that I argue is replacing the dying Industrial Age NWO-directed, establishment system, then the coins must be distributed to the targeted ecosystem.

I hope this post is not lost in the shuffle because it may be one of the most poignant, salient, and critically important insights I have shared.

And I 100% agree with Adrian-X's point about anyone who has a point, needs to prove it in the market.

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.

cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 08:27:39 PM
 #27092

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.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
June 22, 2015, 08:31:56 PM
 #27093


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.
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
June 22, 2015, 08:33:20 PM
 #27094

gavin has just posted a bip on the btc dev mailing list

  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <gavinandresen@gmail.com>
  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.

judging from replies to gavin's initial post the discussion seems to be quite pragmatical and productive, let's see what happens in the next day or so.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
June 22, 2015, 08:34:46 PM
 #27095


Financial institutions can't trust each other perhaps. They are not the "banksters" if by that you mean the global elite helping to manage our self-chosen, NWO-directed path.

Until you understand who is the DEEP STATE and the way they are positioned in the establishment, you are hopelessly lost.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
June 22, 2015, 08:38:21 PM
Last edit: June 22, 2015, 08:50:59 PM by TPTB_need_war
 #27096

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.

Oh but smooth, please don't fret, the Lily pond is only 50% covered. The fish can still breath. Monoculture is not imminent. We can justus adjustus later.

(the lies our grandmothers never taught us)



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

Breathing is I admit quite the pedantic sort.

cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 08:42:34 PM
 #27097

hmm, spam's back:

cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 08:43:57 PM
 #27098

cypherdoc (OP)
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 22, 2015, 08:51:32 PM
 #27099

Zarathustra
Legendary
*
Offline Offline

Activity: 1162
Merit: 1004



View Profile
June 22, 2015, 08:54:46 PM
 #27100


Financial institutions can't trust each other perhaps. They are not the "banksters" if by that you mean the global elite helping to manage our self-chosen, NWO-directed path.

Until you understand who is the DEEP STATE and the way they are positioned in the establishment, you are hopelessly lost.

Skulls and Clowns?
Pages: « 1 ... 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 [1355] 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 ... 1557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!