Bitcoin Forum
August 17, 2017, 09:33:37 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
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 ... 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 [1539] 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1953163 times)
pa
Hero Member
*****
Offline Offline

Activity: 503


View Profile
August 16, 2015, 08:49:51 PM
 #30761

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"
1503005617
Hero Member
*
Offline Offline

Posts: 1503005617

View Profile Personal Message (Offline)

Ignore
1503005617
Reply with quote  #2

1503005617
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503005617
Hero Member
*
Offline Offline

Posts: 1503005617

View Profile Personal Message (Offline)

Ignore
1503005617
Reply with quote  #2

1503005617
Report to moderator
sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 16, 2015, 08:59:54 PM
 #30762

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

This follows from the idea that, strictly speaking, there is no need for a hard block limit at all. There is enough information in the network ( difficulty, recent block sizes, number tx's, fee level, etc.) o be able to calculate an 'on the fly' block limit  that responds to changing needs in a manner not dissimilar to block difficulty.

Rising costs of creating a block ( increased difficulty) can be matched with revenue (fees, subsidy) while allowing for growth to support a greater tx throughput.

But for now, we are having enough difficulty trying to get some people to accept that we need a bigger block at all, so first steps first.

We must make money worse as a commodity if we wish to make it better as a medium of exchange
pa
Hero Member
*****
Offline Offline

Activity: 503


View Profile
August 16, 2015, 09:06:00 PM
 #30763

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

Also: https://twitter.com/NickSzabo4/status/633015499316551680

"A rapid block size increase is a huge security risk: a reckless act to be performing on a $4 billion system." -- Nick Szabo
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
August 16, 2015, 09:08:50 PM
 #30764

But I don't agree that 75% of hashrate or whatever is network consensus.
I predict that miners won't (vote to) change unless there is network consensus.

one down UP:

https://www.reddit.com/r/bitcoinxt/comments/3h6lk8/toomim_bros_supports_democracy_and_bitcoin_xt/

Got to correct you there cypher.

--------------------

This whole debate hinges on what is acceptable main-chain scaling. Core Dev (especially BS) are gloomy about Satoshi's original VISA-scale main-chain volume projections. To an extent they have a point because it is only subsequent dev work which has made Satoshi's original code 100x more robust and more efficient, and it would have failed under today's volumes without all that improvement.

So they are focussed on 2nd-level solutions, and maybe the chance for profit has shifted that focus too far. There is no good reason why main-chain scaling cannot keep up with improvements in technology, which is what Gavin has effectively put a ceiling on with BIP 101. I suspect that another BIP will get adopted by both Core and XT which is more like Jeff's BIP 100 and works within the constraint of BIP 101. Gavin has said that he likes the idea of a belt-and-braces block size limit, i.e. a high, but steadily increasing hard-limit, and a lower dynamic limit. That dynamic limit could reflect incentives to reduce UTXOs.

When Gavin raised BIP 101 he made the promise not to commit it to Core using his own access without consensus. IMHO this constitutes a pact. It means that Core cannot commit a different BIP (like Pieter's) which has minimal main-chain scaling i.e. just 1.17MB by Jan 1st 2018. So Core are duty bound to only commit a BIP that has Gavin's approval as well as Jeff's.

So, as Core's node count diminishes, and miners shift UP, I expect a sensible dynamic BIP proposal from Core which works within BIP 101 and both BIPs get committed to Core and XT. The risk for Core is that the longer they delay with a sensible BIP allowing main-chain scaling the more likely that BIP 101 will stand alone and that it will get 90+% of the ecosystem, nodes and miners.

sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 16, 2015, 09:15:19 PM
 #30765

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

Also: https://twitter.com/NickSzabo4/status/633015499316551680

"A rapid block size increase is a huge security risk: a reckless act to be performing on a $4 billion system." -- Nick Szabo

Increasing the limit does not mean that blocks will be that size immediately. He doesnt really define the scales he is talking about.

Satoshi's 1mb limit was an order of magnitude greater than the average block size of the time. 5 years later we are only getting near to it. Yet there has been no talk of security risk up to this?

We must make money worse as a commodity if we wish to make it better as a medium of exchange
Erdogan
Hero Member
*****
Offline Offline

Activity: 770



View Profile
August 16, 2015, 09:18:30 PM
 #30766

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

Also: https://twitter.com/NickSzabo4/status/633015499316551680

"A rapid block size increase is a huge security risk: a reckless act to be performing on a $4 billion system." -- Nick Szabo

Can you ask this guy to come over and discuss it directly? Thanks.

Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 16, 2015, 09:22:00 PM
 #30767

I combined the Sickpig's idea that the block size limit is a transport limitation that crept into the consensus layer, with Smooth's observation that the Bitcoin white paper never mentions a block size limit, and rolled it into a toned-down version of the "moderators-throwing-their-swords" story:

https://www.reddit.com/r/Bitcoin/comments/3h73ws/the_morning_after_the_moderation_mistake_thoughts/

It looks like my post has been removed from r/bitcoin (it had 172 up-votes in 8 hours).  It was near the top of the first page, and then 5 minutes later it was nowhere to be found.  

Both cartoons by /u/raisethelimit were removed too (and one was the second highest post).

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

Activity: 1162


View Profile
August 16, 2015, 09:36:28 PM
 #30768

..and all pro XT and angry censorship postings are removed from the front of /r/bitcoin. Disgraceful.
Wexlike
Hero Member
*****
Offline Offline

Activity: 943



View Profile
August 16, 2015, 09:42:07 PM
 #30769

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

Also: https://twitter.com/NickSzabo4/status/633015499316551680

"A rapid block size increase is a huge security risk: a reckless act to be performing on a $4 billion system." -- Nick Szabo

Increasing the limit does not mean that blocks will be that size immediately. He doesnt really define the scales he is talking about.

Satoshi's 1mb limit was an order of magnitude greater than the average block size of the time. 5 years later we are only getting near to it. Yet there has been no talk of security risk up to this?

Without a hard block cap, a pool could send millions of small transactions(spam - with a transaction fee too low for other pools) and mine it in their own block. Thus increasing the propagation time and having a small edge on their own mining for the next block. Just a thought, that came to my head a minute ago.

Could this really cause problems in that scenario ?

Something else: it's unbelievable how much they are censoring /bitcoin.
sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 16, 2015, 09:49:56 PM
 #30770

..and all pro XT and angry censorship postings are removed from the front of /r/bitcoin. Disgraceful.

Indeed. They will be making "A List' next....

We must make money worse as a commodity if we wish to make it better as a medium of exchange
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 16, 2015, 09:52:04 PM
 #30771

Without a hard block cap, a pool could send millions of small transactions(spam - with a transaction fee too low for other pools) and mine it in their own block. Thus increasing the propagation time and having a small edge on their own mining for the next block. Just a thought, that came to my head a minute ago.

Could this really cause problems in that scenario ?

Publishing a large block has a cost to the miner.  I tried to illustrate this effect in Fig. 8:



Even with a propagation impedance of 2 sec/MB (which I'm confident is faster than the present network average), it still costs 1,000 BTC to produce a single 1 GB spam block.  

Indeed, you get a small head start on the next block but it won't balance out the orphan cost.  Furthermore, other miners can SPV mine on your block header (while downloading and verifying the rest of the block) to take away this advantage.

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

Activity: 2044


LEALANA Monero Physical Silver Coins


View Profile
August 16, 2015, 09:56:33 PM
 #30772

439 Bitcoin XT nodes (supporting bigger blocks)     6404 Total nodes

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
sickpig
Legendary
*
Offline Offline

Activity: 1190


View Profile
August 16, 2015, 10:07:17 PM
 #30773

Nick Szabo on Twitter: https://twitter.com/NickSzabo4/status/633011973634961408

"A much more reasonable block size proposal, following historical growth rates in a "limiting nutrient" resource: https://t.co/RRapcLSm6j"

fwiw sipa's proposal introduce a block size increase of ~18%/year starting from 2017.
this was based on a Rusty Russell's estimate (1). it's worth noting that such estimate has been raised to 30% recently (2).

(1) http://rusty.ozlabs.org/?p=551
(2) http://rusty.ozlabs.org/?p=493

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

Activity: 943



View Profile
August 16, 2015, 10:11:01 PM
 #30774

Without a hard block cap, a pool could send millions of small transactions(spam - with a transaction fee too low for other pools) and mine it in their own block. Thus increasing the propagation time and having a small edge on their own mining for the next block. Just a thought, that came to my head a minute ago.

Could this really cause problems in that scenario ?

Publishing a large block has a cost to the miner.  I tried to illustrate this effect in Fig. 8:

*skip*

Even with a propagation impedance of 2 sec/MB (which I'm confident is faster than the present network average), it still costs 1,000 BTC to produce a single 1 GB spam block.  

Indeed, you get a small head start on the next block but it won't balance out the orphan cost.  Furthermore, other miners can SPV mine on your block header (while downloading and verifying the rest of the block) to take away this advantage.


Thank you Peter, it's always a great pleasure to read your posts.
But I just don't understand the cost of 1000 BTC for a 1 GB spam block. In my example a mining pool could create the spam on their own and include the transactions in their own block, thus mining their own transaction fees. This action should cost them almost nothing. (But when mining just on the block header works without any disadvantages, then this is anyway a non issue.)
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 16, 2015, 10:15:33 PM
 #30775

Without a hard block cap, a pool could send millions of small transactions(spam - with a transaction fee too low for other pools) and mine it in their own block. Thus increasing the propagation time and having a small edge on their own mining for the next block. Just a thought, that came to my head a minute ago.

Could this really cause problems in that scenario ?

Publishing a large block has a cost to the miner.  I tried to illustrate this effect in Fig. 8:

*skip*

Even with a propagation impedance of 2 sec/MB (which I'm confident is faster than the present network average), it still costs 1,000 BTC to produce a single 1 GB spam block.  

Indeed, you get a small head start on the next block but it won't balance out the orphan cost.  Furthermore, other miners can SPV mine on your block header (while downloading and verifying the rest of the block) to take away this advantage.


Thank you Peter, it's always a great pleasure to read your posts.
But I just don't understand the cost of 1000 BTC for a 1 GB spam block. In my example a mining pool could create the spam on their own and include the transactions in their own block, thus mining their own transaction fees. This action should cost them almost nothing. (But when mining just on the block header works without any disadvantages, then this is anyway a non issue.)


It costs them 1000 BTC because, according to the laws of statistics, they would have to attempt it 40 times before one "stuck."  On average, a 1 GB block (at 2 sec/MB) will be orphaned 39 out of 40 times.  Does that make sense?

This is still true with SPV mining.  Say the other miners receive the header for my spam block slightly before they received a smaller block in full.  As soon as they receive the smaller block in full, they'll switch to mining on this one because there's a 100% chance that that block is valid while my spam block is risky because it could include an invalid TX.  

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

Activity: 1750


Support SEGWIT on 8/1/17 https://github.com/UASF


View Profile WWW
August 16, 2015, 10:21:05 PM
 #30776


And the executives of any business which loses money by sticking their neck out in the first wave of XT acceptance are going to be sued into the ground by its furious shareholders.

Can you imagine explaining to your VC backers that you blew their investments in some extremely risky, easily avoided, political/ideological, e-peen measuring, nerd fight?  The corporate veil would be swiftly pierced and you would be sued personally.  You'd lose your house, and might even wind up in jail with roommates (ironically) nicknamed "Tiny" and "Little Bubba."

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
August 16, 2015, 10:21:25 PM
 #30777



7-1/2% and climbing. 


In other news, the guy (/u/raisethelimit) who posted the cartoons of the thermos was apparently banned for 30 days for trolling: 



https://www.reddit.com/r/bitcoin_uncensored/comments/3h8tf2/uraisethelimit_was_banned_for_30_days_for_posting/

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

Activity: 1750


Support SEGWIT on 8/1/17 https://github.com/UASF


View Profile WWW
August 16, 2015, 10:24:53 PM
 #30778


I don't see anything that XT is doing other than allowing people a choice to switch their client to one that supports bigger blocks (and a few other minor things).


Ask Frap.doc to check your eyes, since you should be able to see this:

Activating a hardfork based on what miners do is really bad. You could easily have a situation where 75% of miners support XT but none of the big Bitcoin exchanges or businesses do. Then miners would start mining coins that they couldn't spend anywhere useful, and SPV users would find that they can't transact with the businesses they want to deal with. The currency would be split, and in this case XT would be in a far weaker position than Bitcoin.

The possibility of this sort of network/currency split is what makes XT not a "legitimate hardfork", but rather the programmed creation of an altcoin. A consensus hardfork can only go forward once it has been determined that it's nearly impossible for the Bitcoin economy to split in any significant way. Not every Bitcoin user on Earth has to agree, but enough that there won't be a noticeable split.


The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
Wexlike
Hero Member
*****
Offline Offline

Activity: 943



View Profile
August 16, 2015, 10:26:56 PM
 #30779

It costs them 1000 BTC because, according to the laws of statistics, they would have to attempt it 40 times before one "stuck."  On average, a 1 GB block (at 2 sec/MB) will be orphaned 39 out of 40 times.  Does that make sense?

This is still true with SPV mining.  Say the other miners receive the header for my spam block slightly before they received a smaller block in full.  As soon as they receive the smaller block in full, they'll switch to mining on this one [/i]because there's a 100% chance that that block is valid[/i] while my spam block is risky because it could include an invalid TX.  

Thank you, that makes sense ! Smiley
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1750


Support SEGWIT on 8/1/17 https://github.com/UASF


View Profile WWW
August 16, 2015, 10:31:48 PM
 #30780

Unbelievable. Did anyone in this environment ever destroy himself even faster than that Thermos?

Sorry, I've lost count.  Which has been declared destroyed/dooomed/dead more times, Thermos or Bitcoin?

If you don't like Thermos, why don't you fuck off his forum and sub, and go some place more welcoming of contentious/hostile/malicious/parasitic hard forks?

I hear https://voat.co/v/bitcoinxt is nice this time of year.  It's not crowded either!   Grin

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
Pages: « 1 ... 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 [1539] 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!