Gold collapsing. Bitcoin UP.

[TPTB_need_war]

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.

[1714125676]

1714125676

[1714125676]

1714125676

[1714125676]

1714125676

[1714125676]

1714125676

[Adrian-x]

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.

[Odalv]

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]

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  

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?

[justusranvier]

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]

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.

[Odalv]

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]

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]

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? 

[Erdogan]

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]

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

[molecular]

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?

[cypherdoc]

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]

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]

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]

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]

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]

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

[cypherdoc]

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]

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

https://twitter.com/twobitidiot/status/612652436126363648