Bitcoin Forum
November 19, 2017, 10:14:42 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [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 ... 1300 1301 1302 1303 1304 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2009510 times)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 21, 2015, 01:49:02 PM
 #26981

One suggestion. Is it worth mentioning IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate. Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.
IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.
1511129682
Hero Member
*
Offline Offline

Posts: 1511129682

View Profile Personal Message (Offline)

Ignore
1511129682
Reply with quote  #2

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

Activity: 2408



View Profile
June 21, 2015, 02:19:48 PM
 #26982

One suggestion. Is it worth mentioning IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate. Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.
IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 21, 2015, 02:28:08 PM
 #26983

One suggestion. Is it worth mentioning IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate. Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.
IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.

Yes, you are right. But solex is presenting IBTL like it reduces bandwidth to 1/32
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 21, 2015, 02:30:37 PM
 #26984

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.
That particular benefit is not attributable to IBLT.

You can stop sending transactions twice by putting transaction hashes, rather than full transactions, in the block message.

IBLT allows miners to broadcast (information that can be used to construct) those hashes while they mine rather than waiting after they found the block to send everything.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 21, 2015, 03:17:13 PM
 #26985

One suggestion. Is it worth mentioning IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate. Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.
IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.

Yes, you are right. But solex is presenting IBTL like it reduces bandwidth to 1/32

Wouldn't IBLT drastically reduce the upload bit rate requirement for miners? 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 21, 2015, 03:19:35 PM
 #26986

Comparing a successful fork to a runaway sidechain.

A chain fork, while painful, will succeed only if the fork is better than the original. A bitcoiner need only do nothing to join the fork.

A sidechain will either be less valuable and therefore be very small, or more valuable and therefore run away. A bitcoiner might be left behind, unless he converts to the sidechain in time.

I prefer a chain fork to a runaway sidechain.

Yes, chain fork = (Peter R's) spin off, though the latter carries a connotation of being done in a somewhat less chaotic fashion. As I said before, spin offs make a lot more sense than side chains as a way to (potentially) upgrade bitcoin. Even Adam's one-way pegs are better than side chains, but spin offs are better than one way pegs.

But Blockstream's two-way pegged side chains don't runaway from your BTC value. Thus they are best, because they are not all-or-nothing choices, you can go back and forth, and your BTC value is protected.

Pegging two different, however slightly, money types together is a problem in theory and practice. As long as they are different, they will have different value. If the value is smaller, they will be converted to bitcoins. If the value is larger, they will be converted to sidecoins.

When a fiat system goes bust, a new one is created, and it is quite common to peg the value to for instance the dollar. This is to try to give people a reason to trust the new money. The reason to have local money at all, is to get the seigniorage, which otherwise would be wasted to another government. To peg the value, you need an institution to be the guarantor, that means a kind of bank with reserves in the other money type. In practice, exact pegging is not possible, because there will be leakage of value to speculants and money exchange services. Therefore there will be a band, where the value will be pegged to somewhere between the upper and lower limits. Even better, the exact limits are secret, to avoid speculation near the edge. This can go on for a while, until they have created too much (sometimes too little), the peg breaks and is set to another value.

If there is a mathematical peg defined by protocol and secured by the blockchain, the difference in value will have to escape somehow, and that is either the coins disappear if they are worth less than bitcoin, otherwise all bitcoins will be converted to sidecoins. It is not rocket science.

You are conflating a physical peg with a peg enforced by market exchange dominance. The latter is destined to fail when the dominator exhausts resources. The former fails only if the physical peg fails, i.e. the side chain breaks the protocol rules of the peg.

I do no  such thing. If you by physical peg mean an unbreakable peg - that means only that the difference in value will find another way to escape.

molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
June 21, 2015, 03:24:49 PM
 #26987

One suggestion. Is it worth mentioning IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate. Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.
IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.

Yes, you are right. But solex is presenting IBTL like it reduces bandwidth to 1/32

That's probably a misunderstanding. He said: "Obviously the real-time unconfirmed transaction overhead does remain. and is large long-term.".

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



View Profile
June 21, 2015, 03:27:11 PM
 #26988

That's false. IBLT almost halves the bandwidth requirement. Currently transactions are sent twice: once when broadcast and once as part of a block when mined. IBLT reduces the bandwidth requirement of the latter to a constant.
That particular benefit is not attributable to IBLT.

You can stop sending transactions twice by putting transaction hashes, rather than full transactions, in the block message.

IBLT allows miners to broadcast (information that can be used to construct) those hashes while they mine rather than waiting after they found the block to send everything.

When saying "IBLT" I'm talking about the proposal "O(1) Block Propagation" by Gavin.

Are we talking about the same thing?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 03:42:48 PM
 #26989


And that's precisely why we need to keep all those TX's on the mainchain.

Why ? If we split same amount of transactions into 10,000 chains then
a) you can mine all 10,000 chains (it will cost you same resources as 1 BIG chain)  -> big corporation
b) you can mine/verify only 1-3 small chains on your phone -> 99.9% ordinary people

i pointed out upthread how that will lead to tremendous centralization of mining as small miners with poor connectivity would be crushed trying to deal with 10000 chains at once in terms of resources, maintenance, coding reqs, etc.

not good.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 03:47:14 PM
 #26990

i just love these videos b/c it reminds me of when my jaw hit the floor going thru all the 2010 mining videos of kids in their basements mining from their cpu's.  this just clearly illustrates why non-Chinese gvts will never be able to shut down Bitcoin from a pure geographical standpoint.  it also makes those same gvts wonder why the Chinese gvt hasn't shut these places down yet.  in fact, they seem to be encouraging them.  do they know or desire something we don't?  

https://www.youtube.com/watch?v=jtp4gNeGTSw&feature=youtu.be
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 03:50:49 PM
 #26991

this am's twitter rant by Adam and other 1MB'ers shows the entrenchment these guys are in.  unfortunately, this is coming down to shove, not push:

https://twitter.com/CoinTelegraph/status/612578062593462272
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 04:02:44 PM
 #26992

clearly Adam considers Matonis key in this debate.  i didn't know this until this am and his rant. currently, Matonis doesn't get it.  since Adam follows me on Twitter, i'm sure he was very concerned with my convo with Matonis yesterday.  i'm surprised he didn't intervene:

https://twitter.com/KonradSGraf/status/612347123732992000

https://twitter.com/jonmatonis/status/612353958326054912

https://twitter.com/jonmatonis/status/611899668813910016
Erdogan
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 21, 2015, 04:24:50 PM
 #26993

There is a nonzero cost to adding a transaction to the blockchain, and there is a nonzero benefit to making a transaction - perfect for a market.

tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
June 21, 2015, 04:52:39 PM
 #26994


Get this guy a 'tute' so he can get XT up and running:




cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 04:57:04 PM
 #26995

There is a nonzero cost to adding a transaction to the blockchain, and there is a nonzero benefit to making a transaction - perfect for a market.


that is so simplistic that it's profound.

thank you.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 05:01:03 PM
 #26996

oh Lordy, now i'm having to educate TBI on digital gold:

https://twitter.com/twobitidiot/status/612652436126363648
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 21, 2015, 05:31:45 PM
 #26997

Here is a link to the Reddit post with the final graphic visualizing Gavin's recent code changes.  



I incorporated all the proposed improvements except adding notes on IBLTs and pruning.  I thought that discussion deserved a separate graphic.  

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

Activity: 1260



View Profile
June 21, 2015, 05:35:20 PM
 #26998


Wouldn't IBLT drastically reduce the upload bit rate requirement for miners? 

Yes, It can drastically reduce the upload in case the other side is also full node.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 05:43:41 PM
 #26999

this is going to drive Adam, et al bonkers:

BITCOIN BLOCK SIZE CONFLICT ENDS WITH LATEST UPDATE


An issue that has been the source for months of debate and rancor throughout the Bitcoin mining and developer community over Bitcoin's block size appears to have reached a long-awaited resolution. Within the most recent BitcoinXT update, Gavin Andresen has begun the process of revising the block chain individual block size from 1 MB to 8 MB starting next year. This is deemed necessary for the overall growth and usability of Bitcoin, as the current limits of seven transactions per second are becoming insufficient for the growing global community as consumer and business interest increases.

These impending updates were revealed on GitHub, and this is what is in store for the upcoming “hard fork”, taken directly from GitHub, posted by Gavin Andresen:

Implement hard fork to allow bigger blocks. Unit test and code for a bigger block hard fork.

Parameters are:

8MB cap
Doubling every two years (so 16MB in 2018)
For twenty years
Earliest possible chain fork: 11 Jan 2016
After miner supermajority (code in the next patch)
And grace period once miner supermajority achieved (code in next patch)
The 1 MB block size debate has been a constant issue for months, with Andresen and Mike Hearn discussing the need to upgrade the block size to as much as 20 MB. China's major exchanges and mining interests came out against any block size changes initially, deriding the extra operating costs and complexities involved with mostly empty blocks. After further review, the increase was deemed warranted to an 8 MB size, much smaller than the 20 MB requests by the Core Developers. An accord was reached, and the revisions will take effect next year.

We attempted to contact Hearn and Andresen for more information and will provide updated information as it becomes available. It seems some details are still to be sorted out in the next coding batch within the coming days. We’ll keep our readers informed of any further developments.

https://www.cryptocoinsnews.com/bitcoin-block-size-conflict-ends-latest-update/
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
June 21, 2015, 05:56:28 PM
 #27000

this is going to drive Adam, et al bonkers:

BITCOIN BLOCK SIZE CONFLICT ENDS WITH LATEST UPDATE


An issue that has been the source for months of debate and rancor throughout the Bitcoin mining and developer community over Bitcoin's block size appears to have reached a long-awaited resolution. Within the most recent BitcoinXT update, Gavin Andresen has begun the process of revising the block chain individual block size from 1 MB to 8 MB starting next year. This is deemed necessary for the overall growth and usability of Bitcoin, as the current limits of seven transactions per second are becoming insufficient for the growing global community as consumer and business interest increases.

These impending updates were revealed on GitHub, and this is what is in store for the upcoming “hard fork”, taken directly from GitHub, posted by Gavin Andresen:

Implement hard fork to allow bigger blocks. Unit test and code for a bigger block hard fork.

Parameters are:

8MB cap
Doubling every two years (so 16MB in 2018)
For twenty years
Earliest possible chain fork: 11 Jan 2016
After miner supermajority (code in the next patch)
And grace period once miner supermajority achieved (code in next patch)
The 1 MB block size debate has been a constant issue for months, with Andresen and Mike Hearn discussing the need to upgrade the block size to as much as 20 MB. China's major exchanges and mining interests came out against any block size changes initially, deriding the extra operating costs and complexities involved with mostly empty blocks. After further review, the increase was deemed warranted to an 8 MB size, much smaller than the 20 MB requests by the Core Developers. An accord was reached, and the revisions will take effect next year.

We attempted to contact Hearn and Andresen for more information and will provide updated information as it becomes available. It seems some details are still to be sorted out in the next coding batch within the coming days. We’ll keep our readers informed of any further developments.

https://www.cryptocoinsnews.com/bitcoin-block-size-conflict-ends-latest-update/


It is not yet consensus. We will see in January.
Pages: « 1 ... 1300 1301 1302 1303 1304 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 ... 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!