Bitcoin Forum
December 05, 2016, 06:55:58 PM *
News: Latest stable version of Bitcoin Core: 0.13.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 ... 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 1401 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804734 times)
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
June 21, 2015, 06:30:13 AM
 #27001

Smooth, you've made a good point about spam however how do we weigh up the trade offs between limiting money velocity and spam?

I think you may have slightly misunderstood my point. It isn't that spam itself needs to be limited, it is that the system is vulnerable to a sort of denial of service from having too much data (whether that happens to be spam or "real" data, although obviously spam is less desirable) stuffed into it. 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?

I'm sorry but I just see a lot of wishful thinking going on. Of course, we all want it to scale, but instead of actually improving how it scales, the proposal today is to simply push back the safety limit and change not much else. (A bit like ripping out the airbags and safety belts from a car to cut weight and make it go faster.)


I like the car analogies they've worked well for me. So "spam " just being a term for denial of service or an overload of inappropriately priced transaction data, leaves me thinking it isn't quite wishful thinking making room for it.

Reflecting on the  issue has lead real smart people to find solution that I think are nonsense (picking on Sidechains here) in my experience sometimes jumping in the deep end and being overwhelmed leaving one focused on solving the issue as they happen necessity is the mother of invention and I think allowing it is a great way to do RnD, something I feel is partly in keeping with the spirit of Bitcoin.


Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 21, 2015, 06:35:07 AM
 #27002

Smooth, you've made a good point about spam however how do we weigh up the trade offs between limiting money velocity and spam?

I think you may have slightly misunderstood my point. It isn't that spam itself needs to be limited, it is that the system is vulnerable to a sort of denial of service from having too much data (whether that happens to be spam or "real" data, although obviously spam is less desirable) stuffed into it. 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?

I'm sorry but I just see a lot of wishful thinking going on. Of course, we all want it to scale, but instead of actually improving how it scales, the proposal today is to simply push back the safety limit and change not much else. (A bit like ripping out the airbags and safety belts from a car to cut weight and make it go faster.)


I like the car analogies they've worked well for me. So "spam " just being a term for denial of service or an overload of inappropriately priced transaction data, leaves me thinking it isn't quite wishful thinking making room for it.

Reflecting on the  issue has lead real smart people to find solution that I think are nonsense (picking on Sidechains here) in my experience sometimes jumping in the deep end and being overwhelmed leaving one focused on solving the issue as they happen necessity is the mother of invention and I think allowing it is a great way to do RnD, something I feel is partly in keeping with the spirit of Bitcoin.



I mean heck, if the "spam" is paying full TX fees, how can you fault that? How do you even tell it's spam? Either way the miners will be made healthy.
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
June 21, 2015, 06:36:00 AM
 #27003



If anyone can see a mistake in the above chart, please let me know.  I'd like to post it to r/bitcoin once I'm confident it's correct.
Still loving the graph thanks.

Some other data that may be relevant in presenting the opportunity for TX fees is actually including the projected block halving and mark each halving with the relative inflation rate at each occasion.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 21, 2015, 06:36:18 AM
 #27004

What is funny to me is you haven't considered that if a very popular application of anonymity arises which demands millions of transactions per day, Bitcoin can not fill this market.

That market if it exists will leave Bitcoin behind.

And there is nothing you can say which will change that fact.

Black swans are not easy for people to see.

smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
June 21, 2015, 06:38:01 AM
 #27005

Smooth, you've made a good point about spam however how do we weigh up the trade offs between limiting money velocity and spam?

I think you may have slightly misunderstood my point. It isn't that spam itself needs to be limited, it is that the system is vulnerable to a sort of denial of service from having too much data (whether that happens to be spam or "real" data, although obviously spam is less desirable) stuffed into it. 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?

I'm sorry but I just see a lot of wishful thinking going on. Of course, we all want it to scale, but instead of actually improving how it scales, the proposal today is to simply push back the safety limit and change not much else. (A bit like ripping out the airbags and safety belts from a car to cut weight and make it go faster.)


I like the car analogies they've worked well for me. So "spam " just being a term for denial of service or an overload of inappropriately priced transaction data, leaves me thinking it isn't quite wishful thinking making room for it.

Reflecting on the  issue has lead real smart people to find solution that I think are nonsense (picking on Sidechains here) in my experience sometimes jumping in the deep end and being overwhelmed leaving one focused on solving the issue as they happen necessity is the mother of invention and I think allowing it is a great way to do RnD, something I feel is partly in keeping with the spirit of Bitcoin.



I mean heck, if the "spam" is paying full TX fees, how can you fault that? How do you even tell it's spam? Either way the miners will be made healthy.

"full TX fees" is a meaningless concept given that there is no set fee, it can be arbitrarily low. Just paying enough to motivate one (who happens to be the most accommodating) miner doesn't cover the entire cost to everyone on the network. Vitalik wrote about this once. Let me find it...okay here you go:

https://blog.ethereum.org/2014/02/01/on-transaction-fees-and-the-fallacy-of-market-based-solutions/

Adrian-x: I'll agree there is some merit to your idea of jump into the deep end and then figure out how to swim. Dangerous as fuck, but definitely a strong motivation to Get It Done.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
June 21, 2015, 06:44:12 AM
 #27006


Bottom line is scaling will not accompany decentralization in Bitcoin.

So just go ahead already and increase the block size and accept that Bitcoin is not going to remain decentralized. And someone will make a decentralized side chain for all those knowledge capitalists to escape to.

Or fight for a Core that is decentralized with small blocks and very high txs fees, and let the side chains be centralized for the high volume. But this option appears to be doomed because it doesn't have anonymity and 100% censorship-free attributes. So much better we go the other route. Let Gavinmike have their NWOcoin.

Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
June 21, 2015, 06:45:18 AM
 #27007

Smooth, you've made a good point about spam however how do we weigh up the trade offs between limiting money velocity and spam?

I think you may have slightly misunderstood my point. It isn't that spam itself needs to be limited, it is that the system is vulnerable to a sort of denial of service from having too much data (whether that happens to be spam or "real" data, although obviously spam is less desirable) stuffed into it. 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?

I'm sorry but I just see a lot of wishful thinking going on. Of course, we all want it to scale, but instead of actually improving how it scales, the proposal today is to simply push back the safety limit and change not much else. (A bit like ripping out the airbags and safety belts from a car to cut weight and make it go faster.)


I like the car analogies they've worked well for me. So "spam " just being a term for denial of service or an overload of inappropriately priced transaction data, leaves me thinking it isn't quite wishful thinking making room for it.

Reflecting on the  issue has lead real smart people to find solution that I think are nonsense (picking on Sidechains here) in my experience sometimes jumping in the deep end and being overwhelmed leaving one focused on solving the issue as they happen necessity is the mother of invention and I think allowing it is a great way to do RnD, something I feel is partly in keeping with the spirit of Bitcoin.



I mean heck, if the "spam" is paying full TX fees, how can you fault that? How do you even tell it's spam? Either way the miners will be made healthy.

I image it would be a failure of the market mainly miners overwhelming nodes and charging inappropriate fees. I feel it won't just be simple, that's why we really need to preserve the risk of orphaning bigger blocks so miners are incentivized take the bird in hand than risk bigger blocks, but there is always the last resort the nodes can fight back if it ever becomes a problem.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 21, 2015, 07:24:11 AM
 #27008


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

Activity: 938



View Profile
June 21, 2015, 07:41:59 AM
 #27009

1. There is nothing in the chart that relates the growth rate to any underlying technological limits at all. It is like a chart of global population extrapolating unlimited growth forward without any consideration of food supply, water, population density, etc.

Thanks for the feedback, Smooth.  I agree.  Perhaps I should call that curve the "optimistic scenario" and show other possible scenarios like (a) slow growth, and (b) failure/collapse (perhaps in a fainter colour).

2. Why would you increase the slope starting now? If anything one should be conservative about sustainable growth rates going forward relative to the past, in the absence of clear knowledge of what scaling bottlenecks might exist.

Good eye. I did this just because I like round numbers (too much) and the two slopes are exactly 100% growth per year and 100% growth every two years.  If I add the two less optimistic curves, I'll keep this the same.  Otherwise, I'll reduce the slope to match the current growth rate precisely.

I would like to see one more white label. The introduction of the 1MB limit to limit spam.
maller blocks that propagate fast, and later once block subsidies have diminished there is a pressure to include and optimize fees.

Thanks for the feedback, Adrian.  I agree.  Annotating the introduction of the 1MB limit as an anti-spam measure gives context to why the limit exists in the first place (a point Konrad Graf made in the post Cypherdoc linked to).  

Some other data that may be relevant in presenting the opportunity for TX fees is actually including the projected block halving and mark each halving with the relative inflation rate at each occasion.

Yes, I think this would be good too. TPTB_need_war was already confused thinking that the block subsidy would have become "so minuscule it has essentially stopped funding mining" by 2032  Wink

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.

Well if he's gonna mention IBLT he might as well mention pruning...

Thanks Solex and Cypherdoc.  Any ideas how something about IBLTs and pruning could be included?

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

Activity: 1400



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

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

Activity: 2128



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

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: 1064



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

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
 #27013

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: 938



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

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: 714



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

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: 2128



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

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: 2128



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

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
 #27018


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
 #27019

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
 #27020

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
Pages: « 1 ... 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 1401 ... 1560 »
  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!