Bitcoin Forum
May 24, 2019, 04:16:23 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   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 ... 1299 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2028356 times)
smooth
Legendary
*
Offline Offline

Activity: 2142
Merit: 1129



View Profile
June 21, 2015, 05:55:32 AM
Last edit: June 21, 2015, 06:08:01 AM by smooth
 #26961

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.)
GET 25 FREE SPINS AT REGISTRATION
GET 100% BONUS ON FIRST DEPOSIT
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558714583
Hero Member
*
Offline Offline

Posts: 1558714583

View Profile Personal Message (Offline)

Ignore
1558714583
Reply with quote  #2

1558714583
Report to moderator
Adrian-x
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000



View Profile
June 21, 2015, 06:00:01 AM
 #26962

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

That can't be overstated, Bitcoin won't / can't securely scale if those fees move somewhere else.
Federated Sidechains are ok as people trust the server owner enough to do business with them, there is a balance risk reward.

But changing the Bitcoin rules to make tools to move those fees of the blockchain and calling it an upgrade to the Bitcoin protocol  is short sited or just plain evil.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1000


100 satoshis -> ISO code


View Profile
June 21, 2015, 06:06:54 AM
 #26963



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.

Another great chart Peter.

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.

Just as during the 1MB debate so many people kept confusing the block size limit as the average block size, so is the case with Gavin's doubling schedule. These big block sizes are disk block sizes, the bandwidth-using blocks will be far smaller.

Full blocks will only need to be sent between nodes on resync and bootstrapping, not a normal state for most nodes. Even then, future Bitsat-type blockchain download services should mean that nodes catching up have a faster option than relying on terrestrial broadband.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 255


View Profile
June 21, 2015, 06:09:44 AM
 #26964

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

That can't be overstated, Bitcoin won't / can't securely scale if those fees move somewhere else.
Federated Sidechains are ok as people trust the server owner enough to do business with them, there is a balance risk reward.

But changing the Bitcoin rules to make tools to move those fees of the blockchain and calling it an upgrade to the Bitcoin protocol  is short sited or just plain evil.

Unless the mining on the side chain does not require fees (which can be accomplished in numerous ways!), in which case, maybe it wasn't going to be paid on the Core chain either.

Remember you all want unlimited size blocks right? So that means transaction fees should approach 0 (as the cost of bandwidth and CPU is probably insignificant).

And you are thus encouraging a power vacuum where cartels and monopolies come to raise scarcity and pricing.

All this shit is way more complex than all the silly, simpleton "sound bite" summaries.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 21, 2015, 06:13:20 AM
 #26965



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.

Another great chart Peter.

One suggestion. Please mention IBLT because by the time 16MB blocks are being mined they will likely be taking up just 500KB of bandwidth overhead to propagate.

Just as during the 1MB debate so many people kept confusing the block size limit as the average block size, so is the case with Gavin's doubling schedule. These big block sizes are disk block sizes, the bandwidth-using blocks will be far smaller.

Full blocks will only need to be sent between nodes on resync and bootstrapping, not a normal state for most nodes. Even then, future Bitsat-type blockchain download services should mean that nodes catching up have a faster option than relying on terrestrial broadband.


Well if he's gonna mention IBLT he might as well mention pruning because that is now. As in available now and probably in the next release. That's almost more exciting to me. I'm looking to add about a dozen more XT nodes to my portfolio once I figure out how to set that set up.
solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1000


100 satoshis -> ISO code


View Profile
June 21, 2015, 06:18:58 AM
 #26966

Yep. I will be running my node as XT, but waiting for the patch before changing.
I still hope that Core Dev just adds the patch to BitcoinCore and they get on with normal dev work, rather than sulking about it.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
June 21, 2015, 06:30:06 AM
 #26967

Yep. I will be running my node as XT, but waiting for the patch before changing.
I still hope that Core Dev just adds the patch to BitcoinCore and they get on with normal dev work, rather than sulking about it.

Unfortunately, they are going to remain entrenched until they see a cross over in XT vs Core nodes in Bitnodes. And or a majority of XT version blocks.

The gamble they make is if they wait too long their core dev positions probably come into jeopardy as Gavin will probably want to clean house at that point. Can you blame him?
Adrian-x
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000



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

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
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



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

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: 1372
Merit: 1000



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



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
Merit: 255


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

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: 2142
Merit: 1129



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

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
Merit: 255


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


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: 1372
Merit: 1000



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

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: 1288
Merit: 1000



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


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: 1162
Merit: 1007



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

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
Merit: 1006



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

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: 2688
Merit: 1010



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

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: 1288
Merit: 1000



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

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
Merit: 1006



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

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.
Pages: « 1 ... 1299 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 ... 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!