Gold collapsing. Bitcoin UP.

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
A little more on the layers of the system and how they are being unbundled.


Bitcoin has three layers: the ledger, the chains/protocols that service it, and the implementations that service those chains.

BU, ABC, etc. unbundle the protocol rule-setting from the implementations. All adjustable blocksize cap implementations* allow users to freely choose their preferred ruleset(s) without having to leave their preferred dev team.

Spinoffs unbundle the ledger from the chains that result from those protocol rules. As more spinoffs happen, such as @Richy_T's idea, one's choice of protocol rules will become fully unbundled from the choice of ledger, allowing users to use and invest in any coin type they want without ever having to leave the ledger of civilization.** This enables all ideas to move freely on the market even as (pre-August 1st) Bitcoin holders benefit from any and all successes.

*More generally: implementations that enable convenient adjustability for any and all contentious protocol rules

**That is, Bitcoin; though if you're an Ethereum maximalist, then the same applies to Ethereum or whatever your preferred ledger is.
 
Last edited:

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Doesn't the tragedy of the commons not apply here, due to the fact that hashrate is not a finite resource? If it was uneconomical for miners to include zero fee transactions then the ones who do will operate at a loss. Am I missing something obvious?
the limited resource is the fee paying TXs. miners will act in there own self interest and include all the fee paying TX they can in their block.

and the profitability limit for a including a TX is really really low, I'm thinking its something like <500$ / GB ( provided there are a few improvements in the software, which there will be soon )

this means without a blocksize limit, it makes scenes for miners to start creating GB blocks filled with spam.

what is spam? a TX that isn't willing to pay more then even half a cent we can probably safely label as spam... i would guess...
[doublepost=1511793715,1511792823][/doublepost]
The block size limit breaks bitcoin because it makes transaction delivery unpredictable, it makes fees unpredictable and it leaves no excess capacity for when it's needed. It completely wrecks the market forces that guide Bitcoin. That's awfully broken by my measuring. If for some reason the consensus is that transaction throughput needs to be limited, let's find another way. One that lets the market do what it does best.
if blocksize wasn't hardcoded, and miners typically increased block size such that 1cent fee was 99% sure of getting in the next block 0.5cent fee was 50% ( only during heavy vol. would <0.5cent fees take a back seat, type thing )

that type for "limit" wouldn't break bitcoin to badly.


One thing I'd like to see more investigation on and possibly even a fork for investigative purposes is the idea of miners being able to select their own difficulty but the reward being based on that difficulty.
At X diff. the block can only have a max of Y (block-reward ?+ TX fees?)
interesting.
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
if blocksize wasn't hardcoded, and miners typically increased block size such that 1cent fee was 99% sure of getting in the next block 0.5cent fee was 50% ( only during heavy vol. would <0.5cent fees take a back seat, type thing )
That's not really a block size limit though. That's a fee-based limit.
[doublepost=1511794548][/doublepost]
At X diff. the block can only have a max of Y (block-reward ?+ TX fees?)
interesting.
Yes. It would allow miners to take a smaller reward to get fees when transaction creation was high. A block size limit might even work in that scenario since extra capacity could come online. Though it might break down as the reward went away.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@Norway

ya but you'd probably be willing to pay more.
my definition of spam is TX that can't exist unless fees are less then 1/2 a cent.
you'd of paid 1cent if that was required...

i choose the 1cent level, because i believe it will include micro TX, but exclude spam.

bitcoin is p2p cash, not multi purpose p2p database, if your TX arnt willing to pay 1cent your probably not using the blockchain as p2p cash. if you want to use bitcoin as something else then p2p cash, then you need to be willing to pay what cash TX are willing to pay >1cent.
[doublepost=1511794871][/doublepost]
That's not really a block size limit though. That's a fee-based limit.
yes, i just dont think a fee limit will ever really work, one miner will always go and grab ALL the TX and not respect the "fee limit" ( unless the fee limti becomes a protocal rule?! but that sounds nutty )

i think a market-driven-block-limit must be used to enforce a fee limit.
[doublepost=1511795301,1511794647][/doublepost]what i'm worried about is the same thing they were worried about when they put the 1MB limit in place. if its true that for a miner the orphan-risk-cost of including 1GB of data is <1000$, then the blockchain is in danger of being spammed into producing huge blocks, prematurely.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@adamstgbit I don't think it's spam, even if I'm willing to pay more. I have paid a lot more on the BTC chain to dump them.

It's a market with two sides. I want the fee as low as I can get it, the miner wants it to be as high as he can get. Supply and demand. No magic number at 0.5 cent.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@Norway
imagine someone comes up with a game that produces TX on bitcoin cash, it become popular and its producing 1GB of TX every 10mins, the game devs are making ~600$ / 10mins, they are willing to pay 500$/GB in TX fees, but their game can't be profitable unless fee are <600$/GB.

1 silly use case producing 1GB blocks.
is that spam?
is this the type of use case bitcoin cash wants to attract?

is their any other way to prevent this "spam attack" other then a blocksize limit
 
Last edited:
  • Like
Reactions: Norway

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@Norway
imagine someone comes up with a game that produces TX on bitcoin cash, it become popular and its producing 1GB of TX every 10mins, the game devs are making ~600$ / 10mins, they are willing to pay 500$/GB in TX fees, but their game can't be profitable unless fee are <600$/GB.

1 silly use case producing 1GB blocks.
is that spam?
is this the type of use case bitcoin cash wants to attract?

is their any other way to prevent this "spam attack" other then a blocksize limit
I don't understand how you think. You can't control what kind of use is behind the transactions. That's kind of the point with bitcoin. There is no "silly" use.

1GB block is about 2500 * 1000 = 2.5 million transactions. $600 / 2.5 million is $ 0,00024 USD per transaction. A very low value. If it's too low for the miners, they will not include them in the block.

What makes a transaction too cheap for a miner?
Storage
Bandwidth
Processing capacity
Propagation delay/orphan risk
Maybe more factors I haven't thought about.

But one thing is sure: Transactions are going to be a lot cheaper than current fiat solutions.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
@Norway

after all the factors are calculated, $ 0,00024 USD per transaction might be enough to justify processing that TX.

storing/processing/propagating 1GB blocks might be relatively easy for miners, but for the over all network maybe not.... as core would say, what about the poor little fullnode :unsure:

I agree that blocks should be allowed to grow, even if that means some poor little full nodes are going to get pushed off the network. but i'm only willing to do that if their is a good reason.
and 1 game that produces 2.5 million TX / 10mins and is paying 600$ for block space is NOT a good enough reason.

i guess i'm not a "big blocker", maybe i'm a " medium blocker" :ROFLMAO:

I don't want to control what TX are considered spam, i want the market to do that, by agreeing on a new blocksize limit, as needed, using EC
 
Last edited:
  • Like
Reactions: Norway