Topic: Gold collapsing. Bitcoin UP. - page 209. (Read 2032248 times)

Quote from: TPTB_need_war on June 20, 2015, 02:01:38 PM

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.".

Erdogan

legendary

Activity: 1512

Merit: 1005

Quote from: Erdogan on June 20, 2015, 09:48:06 AM

Quote from: TPTB_need_war on June 19, 2015, 05:51:26 PM

Quote from: smooth on June 19, 2015, 04:23:05 PM

Quote from: Erdogan on June 19, 2015, 03:46:12 PM

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.

Peter R

legendary

Activity: 1162

Merit: 1007

Quote from: Odalv on June 21, 2015, 09:28:08 AM

Quote from: molecular on June 21, 2015, 09:19:48 AM

Quote from: justusranvier on June 21, 2015, 08:49:02 AM

Quote from: molecular on June 21, 2015, 09:19:48 AM

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?

justusranvier

legendary

Activity: 1400

Merit: 1013

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.

Odalv

legendary

Activity: 1414

Merit: 1000

Quote from: molecular on June 21, 2015, 09:19:48 AM

Quote from: justusranvier on June 21, 2015, 08:49:02 AM

Quote from: justusranvier on June 21, 2015, 08:49:02 AM

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

molecular

donator

Activity: 2772

Merit: 1019

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.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: smooth on June 20, 2015, 11:57:11 PM

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.

Peter R

legendary

Activity: 1162

Merit: 1007

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).

Quote from: smooth on June 20, 2015, 11:57:11 PM

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.

Quote from: Adrian-x on June 21, 2015, 01:36:00 AM

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

Quote from: cypherdoc on June 21, 2015, 01:13:20 AM

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?

Odalv

legendary

Activity: 1414

Merit: 1000

Quote from: cypherdoc on June 20, 2015, 10:54:06 PM

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

Adrian-x

legendary

Activity: 1372

Merit: 1000

Quote from: cypherdoc on June 21, 2015, 01:35:07 AM

Quote from: Adrian-x on June 21, 2015, 01:30:13 AM

Quote from: smooth on June 21, 2015, 01:38:01 AM

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.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

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.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: cypherdoc on June 21, 2015, 01:35:07 AM

Quote from: Adrian-x on June 21, 2015, 01:30:13 AM

Quote from: Peter R on June 20, 2015, 10:06:22 PM

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

Activity: 420

Merit: 262

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.

Adrian-x

legendary

Activity: 1372

Merit: 1000

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.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Adrian-x on June 21, 2015, 01:30:13 AM

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

Activity: 1372

Merit: 1000