To answer some of the sentiments here, I can't foresee a way this could ever replace either proof of work or proof of stake. You have to have miners of some form to run the chain and only then would transactions work. So this isn't a replacement only an addition.
One way to look at it is that it can reward people for sending transactions, like participating in a lottery. Sending a transaction would be like buying a lottery ticket.
The mining pool wouldn't be able to make free attempts at this, at least not at a reasonable level because only after the blockhash is made (after hashing together all the block data) will you know if anything is a winner. So creating a transaction id is just a ticket and any winners will not be able to be determined until all of the block has been created and preferably even if that block gets accepted by the rest of the network, so perhaps even include the hash of the next block. So that would require hashing the transaction with the blockhash of that block and a future block. Perhaps even go 10 blocks deep before knowing if a transaction is a winner.
The miner would not get the PoTx reward. The rule would be that the person making/mining the block would have to give the past PoTx reward to the address that sent the transaction. They would have to include it in the coinbase transaction output. The consensus of nodes would enforce this.
I think it would be cool feature of bitcoin, but ultimately it could also be powerful in defi, where you can tune the difficulty so every 1 million transactions or so new coins are minted and added to liquidity, or a big airdrop of coins is dropped on every holder or something. And these airdrops would scale in frequency based on how popular the network became and how high the transaction volume becomes. If people aren't using it, few coins are minted, but as people use it a lot, more tokens would be minted, potentially acting as a form of decentralized price stabilizer.
Topic: Proof of Transaction (PoTx) mining method (Read 130 times)
I don't think it will work the way you intend, because the miner would always get the block reward plus the transaction reward. In addition to finding the hash for a block, the miner would create transactions until she found a winner.
Also, your implementation doesn't resolve the case of multiple winners.
Finally, do we really need to incentivize more transactions? People will create transactions just to win the transaction award (if you can figure out how to prevent the miner from always winning it).
Also, your implementation doesn't resolve the case of multiple winners.
Finally, do we really need to incentivize more transactions? People will create transactions just to win the transaction award (if you can figure out how to prevent the miner from always winning it).
You would do this for every transaction in the block. Or just the winning one?
But basically this is stil PoW, as far as I see it.?
But basically this is stil PoW, as far as I see it.?
I wouldn't be surprised if it already doesn't already partially exist in mining hashes. The guessed hash+nonce from mining hashes aren't exactly random but based on something prior (plus a few clever equations), even if they seem random. If only there was a way to test this..
Overall, I agree with the sentiment. The group of miners who could guess a mining hash based on previous transactions would have an advantage. They would contribute to the health of the network by spending coins and contributing to others' mining fees. They would also put themselves at risk for losing funds from human errors during transaction or other miners winning the mining hash first. In my ideal world, there would be a combination of proof of work and proof of transaction, because both would serve the health of the network. Each alone has problems: proof of work results in excess energy waste but allows anyone to jump in at any time, while proof of transaction rewards those who were earlier. A combination of both seems ideal.
Overall, I agree with the sentiment. The group of miners who could guess a mining hash based on previous transactions would have an advantage. They would contribute to the health of the network by spending coins and contributing to others' mining fees. They would also put themselves at risk for losing funds from human errors during transaction or other miners winning the mining hash first. In my ideal world, there would be a combination of proof of work and proof of transaction, because both would serve the health of the network. Each alone has problems: proof of work results in excess energy waste but allows anyone to jump in at any time, while proof of transaction rewards those who were earlier. A combination of both seems ideal.
Proof of Transaction (PoT or PoTx) will likely be a supplemental mining method in blockchains and tokens.
Transactions have a provable cost in terms of transaction fee. So why not use it as a method of mining?
We could look at Transaction ID, which is the hash of all the transaction info. If the txid meets a difficulty requirement (like it contains a certain number of leading zero's) then we could say that was proof that many transactions were sent in order to hit that lucky number. But this would be false. Getting a txid does NOT mean that the transaction was broadcast to the network. So an attacker could just keep changing the transaction data and get a winning txid before ever sending a transaction to the network.
So how do we verify that the transactions are sent before they are determined a winner? Well we would need to make sure it was included in a block. So one workable solution would be to look at not the transaction id, but the hash of the transaction id together with the block hash of the block the transaction was included in. So say we concatenate the txid and blockhash and hash them together. If a certain number of leading zeroes are found, then the transaction is a winner.
In order to reward this in Bitcoin or other blockchains the best way would be to then require the miner of the next block to include the address that sent the winning transaction some of the coinbase reward. In smart contract tokens, a smart contract for the token could mint and distribute rewards to all holders if desired, add liquidity, and/or reward the address that sent the winning transaction. This would likely have to be called by a special function, or require every transaction to check the last block for a winner. With auto-liquidity or reflection tokens the % transaction fee is another way to prevent spamming transactions trying to win, and a minimum number of tokens sent could be required to have a chance to win.
Why do this? It opens up a new way for mining and incentivizes transaction creation and thus volume. We all know bitcoin will eventually have to survive on fees alone so this would be a way to increase demand for blockspace. In bitcoin, the winning transaction would get delegated some of the next block's reward; whether the block reward is emission or just entirely fees.
In other tokens this method could be used to create randomized drops of fresh minted tokens, and these drops would scale in frequency with the volume. So the higher the volume the more coins get minted for example.
This method could also power a bitcoin layer 2 token, simply look at the bitcoin blockchain and mint a token to the address of the creator of the winning transaction.
Transactions have a provable cost in terms of transaction fee. So why not use it as a method of mining?
We could look at Transaction ID, which is the hash of all the transaction info. If the txid meets a difficulty requirement (like it contains a certain number of leading zero's) then we could say that was proof that many transactions were sent in order to hit that lucky number. But this would be false. Getting a txid does NOT mean that the transaction was broadcast to the network. So an attacker could just keep changing the transaction data and get a winning txid before ever sending a transaction to the network.
So how do we verify that the transactions are sent before they are determined a winner? Well we would need to make sure it was included in a block. So one workable solution would be to look at not the transaction id, but the hash of the transaction id together with the block hash of the block the transaction was included in. So say we concatenate the txid and blockhash and hash them together. If a certain number of leading zeroes are found, then the transaction is a winner.
In order to reward this in Bitcoin or other blockchains the best way would be to then require the miner of the next block to include the address that sent the winning transaction some of the coinbase reward. In smart contract tokens, a smart contract for the token could mint and distribute rewards to all holders if desired, add liquidity, and/or reward the address that sent the winning transaction. This would likely have to be called by a special function, or require every transaction to check the last block for a winner. With auto-liquidity or reflection tokens the % transaction fee is another way to prevent spamming transactions trying to win, and a minimum number of tokens sent could be required to have a chance to win.
Why do this? It opens up a new way for mining and incentivizes transaction creation and thus volume. We all know bitcoin will eventually have to survive on fees alone so this would be a way to increase demand for blockspace. In bitcoin, the winning transaction would get delegated some of the next block's reward; whether the block reward is emission or just entirely fees.
In other tokens this method could be used to create randomized drops of fresh minted tokens, and these drops would scale in frequency with the volume. So the higher the volume the more coins get minted for example.
This method could also power a bitcoin layer 2 token, simply look at the bitcoin blockchain and mint a token to the address of the creator of the winning transaction.
Jump to: