Hey, no poop involved, I'm just trying to be useful and help.
Let's call it Fare transactions.
So why is it bad to have dynamic reward, block size, time and difficulty for different transactions if it only brings profit to everyone and the network actually decentralizes and not centralizes like today?
Topic: ///////////////////// (Read 1960 times)
Quote
... What do you think doing that will accomplish? Having some ~no difficulty odd block won't contribute to the security, and could be found basically instantly.
Currently miners prefer less tx because they want to be fast on mining the reward and if the price increases more this will be more obvious. Miners currently are benevolent. A lot of txs are below their costs I think. (In the sense that they are risking the block not to be propagated fast and it is better for them to have 1 tx and get the reward according to some analysis by Michael Gronager I think)
Also, you are describing a future bitcoin state when fee gets low enough. When reward gets low enough I hope they dont act like that and still process txs.
Quote
Worse, because they have no reward except in that they gate finding another block with a reward, fast mining consolidations would be incentivized to find them fast and keep them secret unless they find the next w/ reward block.
You might be right but in theory given a low enough difficulty they will want the fees and the fees will contribute to the security. For example if the fees are 1/100 of the reward and the difficulty might be 1/1000000 of the reward it can make sense for them! The difficulty will adjust to a value that people will want to get the fees. The fees market has a difficulty level that is economical to process them. Pegging the difficulty level to reward doesnt make sense for tx processing for me.
Quote
This really feels like development via oracle, where you fling poop at me until you find something I can't deflect.
lol
This is epic!!Quote
If you want to try out random speculative ideas, why not create an altcoin? The market is a better oracle than I am.
Makes sense and it should be first on an alt-chain. I am not sure who will care since the altcoins dont have the tx volume of bitcoin and they might want to implement other features that will attract people. They will wait for bitcoin devs to solve this problem I guess.
... What do you think doing that will accomplish? Having some ~no difficulty odd block won't contribute to the security, and could be found basically instantly. Worse, because they have no reward except in that they gate finding another block with a reward, fast mining consolidations would be incentivized to find them fast and keep them secret unless they find the next w/ reward block.
This really feels like development via oracle, where you fling poop at me until you find something I can't deflect. If you want to try out random speculative ideas, why not create an altcoin? The market is a better oracle than I am.
This really feels like development via oracle, where you fling poop at me until you find something I can't deflect.
If you want to try out random speculative ideas, why not create an altcoin? The market is a better oracle than I am.
In my view, this one is a good idea for scalability. One can lets say split the nodes to even and odd block numbers (or regular block number and block number plus some float just not to mess with the long term inflation) number and use the even block numbers for reward + transactions and odd block numbers for no reward + transactions. You can have the spacing between the two 5:5 minutes or 7.5:2.5 or 9:1 minutes. Since the reward block will not have many transactions it can propagate in 2.5 or 1 minute. The rest 7.5 lets say will be used to process the odd block which will not have any reward. The decentralization of the system will not be affected because the mining reward will be on the even block without many txs. The odd block (or float block) will have different difficulty to reflect the cost of propagation, tx fees etc (it can be a function of the last few blocks or whatever). It will be a great way to study the long term behavior of the system based without rewards on the odd block. The even block will ensure the security of the system and timestamp every 10 minutes as usual.
If the protocol is changed to force these two blocks alternate (both can be sha-256) miners will not care for the reward once even block number is found and will allocate the appropriate resources for tx hashing.
gmaxwell what is missing here?
If the protocol is changed to force these two blocks alternate (both can be sha-256) miners will not care for the reward once even block number is found and will allocate the appropriate resources for tx hashing.
gmaxwell what is missing here?
There is a way to transfer small amounts of nearly worthless coins quickly on an underutilized network with low fees, with much less protection against hashrate attacks and with such rules incompatible with Bitcoin's design. Alternate digital currencies.
Namecoin is probably the best non-scamcoin, it has nearly the hashrate protection of Bitcoin due to merged mining, and is currently valued at 0.00334 BTC. Anything you send is going to be included in the next block.
The rate at which blocks are generated is established by a compromise between user utility and orphan-block protection. Alt-coins that have tried to blindly alter thought-out Bitcoin protocols have had problems.
Namecoin is probably the best non-scamcoin, it has nearly the hashrate protection of Bitcoin due to merged mining, and is currently valued at 0.00334 BTC. Anything you send is going to be included in the next block.
The rate at which blocks are generated is established by a compromise between user utility and orphan-block protection. Alt-coins that have tried to blindly alter thought-out Bitcoin protocols have had problems.
Sorry, you haven't stated a coherent proposal— e.g. how these "smaller blocks" fit into the consensus or any other specific details, so I can't really comment on it. All I could do is guess at what you actually meant, and I expect you'd then reply that I'd gotten my guesses wrong.
Generally ideas like this are unworkable because even if a block is very small it takes time to propagate around the network due to latency (e.g. the speed of light is finite). If the time between blocks is not a substantial multiple of the time it takes for a block to reach ~all the nodes then blocks will frequently be found faster than the network has heard about the prior ones and the consensus will fragment and there will be frequent large reorganizations. Such a state makes transactions unsafe until they have many confirmations and provides an advantage to large consolidations of hash-power (e.g. an attacker) because they're less diluted by forks.
When talking about sharding you have to figure out how to handle transactions that cross shards. E.g. if you have small inputs in one consensus and large ones in another, what happens when a transaction which is written that spends from both. If you mean to split by the transactions actual value, then you don't get any scaling gain from splitting because any transaction's input could come from either of the prior consensuses.
Beyond that, as others noted— what you're describing sounds like too much a departure from the rules of bitcoin to get adoption... and also discriminating against transactions by value is arguably undesirable: Thats behavior characteristic of the bad rent-seeking behavior of classic payment networks. If you charge lower fees per resource used based on txn value then someone who wanted to make trouble could split their coins into lots of tiny pieces and use disproportional resources.
Generally ideas like this are unworkable because even if a block is very small it takes time to propagate around the network due to latency (e.g. the speed of light is finite). If the time between blocks is not a substantial multiple of the time it takes for a block to reach ~all the nodes then blocks will frequently be found faster than the network has heard about the prior ones and the consensus will fragment and there will be frequent large reorganizations. Such a state makes transactions unsafe until they have many confirmations and provides an advantage to large consolidations of hash-power (e.g. an attacker) because they're less diluted by forks.
When talking about sharding you have to figure out how to handle transactions that cross shards. E.g. if you have small inputs in one consensus and large ones in another, what happens when a transaction which is written that spends from both. If you mean to split by the transactions actual value, then you don't get any scaling gain from splitting because any transaction's input could come from either of the prior consensuses.
Beyond that, as others noted— what you're describing sounds like too much a departure from the rules of bitcoin to get adoption... and also discriminating against transactions by value is arguably undesirable: Thats behavior characteristic of the bad rent-seeking behavior of classic payment networks. If you charge lower fees per resource used based on txn value then someone who wanted to make trouble could split their coins into lots of tiny pieces and use disproportional resources.
Well, if we can not dictate this like I said, maybe still make smaller transaction with smaller difficulty to pass them faster.
And maybe make a lesser bounty in case of smaller fees or smaller difficulty?
And maybe make a lesser bounty in case of smaller fees or smaller difficulty?
You can do whatever you want.
You just have to get 51% of the processors to agree with you.
Still think bitcoin is "peer to peer"?
Why won't Bitcoin developers split smaller valued transactions (txs) in smaller blocks allowing lesser fees, smaller difficulty and smaller reward for them and turn on CPU processing in the clients for verification?
The larger the fee the bigger the verification requirement.
This will bring benefit to everyone and spur new business allowing larger transactions not to go through first - thus faster, but allow all transactions to go fast and everyone to profit from this.
So if you have a high value transaction and you want it to pass fast you pay larger fee, or else get into smallfee transactions which go to CPU/GPU nodes but with larger blocksize and thus higher difficulty and taking extra time to solve.
If you have small value transaction regardless of fee a CPU miner will pass it fast. Else you are stuck for a long time.
And if you pay high fee you get into fastest verifier nodes/pools capable of verifying and keeping a large block.
TL;DR: Fees and value determine the speed of transaction as well as block size, difficulty and verification process.
The larger the fee the bigger the verification requirement.
This will bring benefit to everyone and spur new business allowing larger transactions not to go through first - thus faster, but allow all transactions to go fast and everyone to profit from this.
So if you have a high value transaction and you want it to pass fast you pay larger fee, or else get into smallfee transactions which go to CPU/GPU nodes but with larger blocksize and thus higher difficulty and taking extra time to solve.
If you have small value transaction regardless of fee a CPU miner will pass it fast. Else you are stuck for a long time.
And if you pay high fee you get into fastest verifier nodes/pools capable of verifying and keeping a large block.
TL;DR: Fees and value determine the speed of transaction as well as block size, difficulty and verification process.
no one gets to dictate the behavior of miners, this is a feature not a bug apparently.
/.
Jump to: