I like the idea. It is in some ways similar to something I was daydreaming about at a time when I had given up on Bitcoin as being already wrecked as a backing store (probably around the Satoshi-dice spam pollution timeframe.) I called it 'bakcoin'. The idea/hope would remain tiny and be carried around (and supported) within every crypto-currency system which wanted to use it.
I anticipated 'bakcoin' remaining lite-weight by fairly brutal discrimination and by growing/shrinking based on whether it was being used by crypto-currencies which were successes or failures. To sweeten the deal, I anticipated it providing some modest services to user currencies (e.g., a small scratchpad which, by the nature of the solution, was supported by all user-currencies.)
The main problem I had was how to keep bakcoin from becoming valuable and in demand for that reason. I felt it detrimental to it's goal, but in honesty I never could put my finger on exactly why I felt that way. The later 'paracoin' idea solved this problem by off-loading the value part to some other solution (Bitcoin in this case) by simply being one.
---
I think that relatively few people grasp that if a crypto-currency uses a backing store which is sufficiently protected by something like POW, then they don't have to do so. In other words, one can trade a lot of the hassles and risks associated with mining for reliance on a backing store...but only if the backing store is reliable of course. The main dis-advantage would be that one could not very easily do a pre-mined pump-n-dump scam on such a system so it is not popular in the alt sphere.
Topic: A proposal to decrease the blocksize limit (Read 1611 times)
Anyway.. It would be in their best interest to increment and hash a nonce on their own because that is much less costly than receiving nonce values and hashes from their peers. In other words, distributed computing is much slower than local computing.
Irrelevant. They have to hash to validate anyway but currently they get diddly squat for doing it. Your last phrase I find ironic for a supposedly distributed system.
You can't rely on nodes having the same transactions in a cache, that's what PoW is trying to find consensus on to begin with, so without that how do you enforce "they only try 1 nonce"?
You don't need to enforce it. It is for the clients benefit so they do not replicate work they have tried before. Thinking a bit more about this aspect, they may want to try again if they see the same transaction, but with a new random nonce. The purpose behind the increment is just to give an indication as to whether it is worth trying to find a hash or not while covering the key space. Maybe it should be an incrementing coinbase hash too so that effectively each client is one (or more) "try" that a miner would do.Anyway.. It would be in their best interest to increment and hash a nonce on their own because that is much less costly than receiving nonce values and hashes from their peers. In other words, distributed computing is much slower than local computing.
Nodes would just increment the nonce on a single transaction until they succeeded.
That is fine. They are just like normal miners burning CPU and electricity but with very little chance of finding anything. The idea is that it is an opportunistic attempt that they have a very small chance of finding a block as each transaction is broadcast and passes through them. Sheer numbers of clients increase the probability that one of them might find one rather than a single client brute forcing. Dedicated miners may still find most blocks, but clients have a chance and their numbers scale up the competition rather than individual hashing power.If miners were to pull the plug and disappear completely , then the difficulty would drop and the clients would be running the network and getting the bounty
In other words. Miners would still be king of the hill, but we could live without them quite happily 
You say that there are "no blocks" and then you say they get to "lay down the next block", so either this method would be equivalent to one transaction blocks, or blocks with no transaction limit. I'm not sure which.
Yes. Poor terminology on my part. I mean they don't hash 1MB (or greater) blocks of transactions. Just a transaction that has been broadcast by another client. So it is a block of 1 transaction, if you like, that should be inconsequential in term of overhead for a lightweight client. So the former.You can't rely on nodes having the same transactions in a cache, that's what PoW is trying to find consensus on to begin with, so without that how do you enforce "they only try 1 nonce"?
You don't need to enforce it. It is for the clients benefit so they do not replicate work they have tried before. Thinking a bit more about this aspect, they may want to try again if they see the same transaction, but with a new random nonce. The purpose behind the increment is just to give an indication as to whether it is worth trying to find a hash or not while covering the key space. Maybe it should be an incrementing coinbase hash too so that effectively each client is one (or more) "try" that a miner would do.
What do you think about "Proof of Network Work"
Every client mines transactions except they only try 1 nonce. So when they receive a broadcast transaction, they increment the nonce and calculate a random coinbase nonce then calculate the hash. If the hash doesn't result in a valid block, they re-transmit the transaction with the new nonce and move on to another transaction. Each client keeps a cache of the last N transactions and if the transaction has been seen before, then an attempt to "solve" is only tried if the incoming transaction nonce is higher than they saw before.
Therefore every client is a miner but only solving one transaction at a time (no blocks) and doing so as part of their re-transmission broadcast and verification. Whoever solves the transaction puzzle gets to lay down the next block (and gets the reward), just like the miners currently do.
Every client mines transactions except they only try 1 nonce. So when they receive a broadcast transaction, they increment the nonce and calculate a random coinbase nonce then calculate the hash. If the hash doesn't result in a valid block, they re-transmit the transaction with the new nonce and move on to another transaction. Each client keeps a cache of the last N transactions and if the transaction has been seen before, then an attempt to "solve" is only tried if the incoming transaction nonce is higher than they saw before.
Therefore every client is a miner but only solving one transaction at a time (no blocks) and doing so as part of their re-transmission broadcast and verification. Whoever solves the transaction puzzle gets to lay down the next block (and gets the reward), just like the miners currently do.
The best thing to do would probably be to change the mining algorithm, which would be a shame, really.
So you change the algo to produce blocks every few seconds instead of 10 mins and make it proof of burn, i.e. all spends are to null. Each "miner" is generating his own coin per transaction and can use that to send other transactions. These transactions are proxies for transactions on the bitcoin chain.
Which end of the egg do you crack?
Either is fine as long as it's consistent..The main problem I see with your solution is that the blockchain storing the ultimate hash value must be the most secure one, with the most mining power and nodes. Currently, that is Bitcoin's. The only way to surpass Bitcoin would be to offer higher incentives to miners than Bitcoin does, but Bitcoin has a huge market cap in the billions of dollars.
The best thing to do would probably be to change the mining algorithm, which would be a shame, really.At the core of it Factom seems to have a similar idea going for it. Though there's a lot you have to go through to get to that core..
You mean a blockchain the only function of which is proof of existence? Insofar as it can only store one hash value per block, it might be ideal for what I described in the Ultimate Hash Value, which would be the hash of all public information, including every cryptocurrency's blockchain.
The main problem I see with your solution is that the blockchain storing the ultimate hash value must be the most secure one, with the most mining power and nodes. Currently, that is Bitcoin's. The only way to surpass Bitcoin would be to offer higher incentives to miners than Bitcoin does, but Bitcoin has a huge market cap in the billions of dollars.
The main problem I see with your solution is that the blockchain storing the ultimate hash value must be the most secure one, with the most mining power and nodes. Currently, that is Bitcoin's. The only way to surpass Bitcoin would be to offer higher incentives to miners than Bitcoin does, but Bitcoin has a huge market cap in the billions of dollars.
Which end of the egg do you crack?
I've gotten a bit bored of all these block size increase proposals so here's a proposal to extremely decrease block sizes.
So let's say we take our good ol' blocks and we just just chop them down so there are no scripts, nor does a transaction even hold any numerical data. All a transaction is, is an arbitrary packet of data, which would probably be most useful as a hash, more on that later.
tiny-Block;
Field | Description | Size
Magic no | identifies network | 4 bytes
Blockheader | consists of 6 items | 77 bytes
transaction | the transaction | 4 bytes
Because we know the transaction size ahead of time, and the block size is also uniform, those fields have been removed entirely.
tiny-Block Header;
Field | Purpose | Updated when... | Size (Bytes)
Version Block version number | You upgrade the software and it specifies a new version | 1
hashPrevBlock | 256-bit hash of the previous block header | A new block comes in | 32
hashMerkleRoot | 256-bit hash based on all of the transactions in the block | A transaction is accepted | 32
Time | Current timestamp as seconds since started | Every few seconds | 4
Bits | Current target in compact format | The difficulty is adjusted | 4
Nonce | 32-bit number (starts at 0) | A hash is tried (increments) | 4
I reduced the version field to 1 byte, but left the rest of the block header the same.
That leaves us with some nice 85 byte blocks. So we could have this blockchain running on almost every device that exists, and over a 200 year period, there would be about 10518980 transactions, or about a 894MB blockchain.
I suspect technology should be able to keep up with this storage capacity requirement.
At first consideration this whole thing seems totally silly, after all, what could we possibly do with a system that can only accept 1 transaction per 10 minutes, and does zero verification of the transactions it's accepting?
As it turns out, I think there's quite a bit that could be accomplished with this kind of system.
I would suggest that this root block chain would be the hashpower provider of larger data structures, so for example, if we wanted to attach Bitcoin to this, all we would need to do is mine a block on this tiny-blockchain which contains a hash of a Bitcoin block.
The new Bitcoin block header might look like this;
Field | Purpose | Updated when... | Size (Bytes)
Version | Block version number | You upgrade the software and it specifies a new version | 4
tiny-hashPrevBlock | 32-bit FNV-1a hash of the previous block header | A new block comes in | 4
tiny-hashMerkleRoot | 32-bit FNV-1a hash based on all of the transactions in the block | A transaction is accepted | 4
The Time, Bits, and Nonce fields can all be removed because this is all provided by the tiny-blockchain. The hashes can also be dramatically reduced because the hash does not have to be cryptographically secure, all it needs to do is be fairly resistance to collisions. Note that the tiny-blockchain is storing a hash of potentially very large Bitcoin blocks.
A miner would run the tiny blockchain software, but not necessarily the Bitcoin software. A miner may be configured, by extension, to accept a hash along with a promise of payment of bitcoins. (What that "promise" looks like, could vary widely.)
Now a Bitcoin "miner" would necessarily run both it's own software along with the tiny-blockchain software and wait for a tiny-blockchain block to roll in (or mine one itself).
Then it will wait for a block to come in that matches the hash in the tiny-blockchain block (or create one itself, if it self-mined a tiny-block).
Then it will verify that this block legitimately follows the rules, if it does not then the block is ignored (Or broadcasts it's own blocks).
Since the Bitcoin software fully verifies the blocks, there is no danger of a bad tiny-blockchain block forking the Bitcoin chain, and we have the same level of confidence in the integrity of the Blockchain as we do now.
However, it would necessarily mean that "bad" blocks are permanently stored on the tiny-blockchain.
I don't think this is a big deal. The sheer cost of putting a bad block in the tiny-blockchain should heavily mitigate this sort of behavior.
The biggest problem with this, is that it requires a reasonable degree of certainty that the tiny-blockchain node will be paid, even though the tiny-blockchain node might not necessarily be running cryptocurrency software it's being paid in.
The most straightforward way to resolve this problem is to rely on something I'll call a "Payment Authority" which is just an entity that verifies that payment will occur before it passes the hash onto the tiny-blockchain nodes. On the flipside, the nodes would whitelist the Payment Authorities they trust.
This does not mean that the tiny-blockchain nodes must trust these third parties, as a last resort they can always run the full cryptocurrency software itself and verify the blocks that way.
I know that's not an ideal solution, but off-the-cuff it should at least show that it's not an intractable problem.
There are at least three major advantages to this kind of system.
Since the tiny-blockchain is completely abstracted from the underlying protocols that are providing the hashes it's storing, it is trivial to swap out protocols, or even run more than one at the same time, without forking the tiny-blockchain.
It is also extremely small, so there is a much greater ability to decentralize the proof of the accuracy of any kind of data-set amongst many nodes.
A cryptocurrency could also be highly centralized while proof of it's state is highly decentralized, whereas at the moment those attributes are tightly coupled.
Maybe food for thought, or maybe totally crazy. I'm not so sure myself.
https://en.bitcoin.it/wiki/Block
So let's say we take our good ol' blocks and we just just chop them down so there are no scripts, nor does a transaction even hold any numerical data. All a transaction is, is an arbitrary packet of data, which would probably be most useful as a hash, more on that later.
tiny-Block;
Field | Description | Size
Magic no | identifies network | 4 bytes
Blockheader | consists of 6 items | 77 bytes
transaction | the transaction | 4 bytes
Because we know the transaction size ahead of time, and the block size is also uniform, those fields have been removed entirely.
tiny-Block Header;
Field | Purpose | Updated when... | Size (Bytes)
Version Block version number | You upgrade the software and it specifies a new version | 1
hashPrevBlock | 256-bit hash of the previous block header | A new block comes in | 32
hashMerkleRoot | 256-bit hash based on all of the transactions in the block | A transaction is accepted | 32
Time | Current timestamp as seconds since started | Every few seconds | 4
Bits | Current target in compact format | The difficulty is adjusted | 4
Nonce | 32-bit number (starts at 0) | A hash is tried (increments) | 4
I reduced the version field to 1 byte, but left the rest of the block header the same.
That leaves us with some nice 85 byte blocks. So we could have this blockchain running on almost every device that exists, and over a 200 year period, there would be about 10518980 transactions, or about a 894MB blockchain.
I suspect technology should be able to keep up with this storage capacity requirement.
At first consideration this whole thing seems totally silly, after all, what could we possibly do with a system that can only accept 1 transaction per 10 minutes, and does zero verification of the transactions it's accepting?
As it turns out, I think there's quite a bit that could be accomplished with this kind of system.
I would suggest that this root block chain would be the hashpower provider of larger data structures, so for example, if we wanted to attach Bitcoin to this, all we would need to do is mine a block on this tiny-blockchain which contains a hash of a Bitcoin block.
The new Bitcoin block header might look like this;
Field | Purpose | Updated when... | Size (Bytes)
Version | Block version number | You upgrade the software and it specifies a new version | 4
tiny-hashPrevBlock | 32-bit FNV-1a hash of the previous block header | A new block comes in | 4
tiny-hashMerkleRoot | 32-bit FNV-1a hash based on all of the transactions in the block | A transaction is accepted | 4
The Time, Bits, and Nonce fields can all be removed because this is all provided by the tiny-blockchain. The hashes can also be dramatically reduced because the hash does not have to be cryptographically secure, all it needs to do is be fairly resistance to collisions. Note that the tiny-blockchain is storing a hash of potentially very large Bitcoin blocks.
A miner would run the tiny blockchain software, but not necessarily the Bitcoin software. A miner may be configured, by extension, to accept a hash along with a promise of payment of bitcoins. (What that "promise" looks like, could vary widely.)
Now a Bitcoin "miner" would necessarily run both it's own software along with the tiny-blockchain software and wait for a tiny-blockchain block to roll in (or mine one itself).
Then it will wait for a block to come in that matches the hash in the tiny-blockchain block (or create one itself, if it self-mined a tiny-block).
Then it will verify that this block legitimately follows the rules, if it does not then the block is ignored (Or broadcasts it's own blocks).
Since the Bitcoin software fully verifies the blocks, there is no danger of a bad tiny-blockchain block forking the Bitcoin chain, and we have the same level of confidence in the integrity of the Blockchain as we do now.
However, it would necessarily mean that "bad" blocks are permanently stored on the tiny-blockchain.
I don't think this is a big deal. The sheer cost of putting a bad block in the tiny-blockchain should heavily mitigate this sort of behavior.
The biggest problem with this, is that it requires a reasonable degree of certainty that the tiny-blockchain node will be paid, even though the tiny-blockchain node might not necessarily be running cryptocurrency software it's being paid in.
The most straightforward way to resolve this problem is to rely on something I'll call a "Payment Authority" which is just an entity that verifies that payment will occur before it passes the hash onto the tiny-blockchain nodes. On the flipside, the nodes would whitelist the Payment Authorities they trust.
This does not mean that the tiny-blockchain nodes must trust these third parties, as a last resort they can always run the full cryptocurrency software itself and verify the blocks that way.
I know that's not an ideal solution, but off-the-cuff it should at least show that it's not an intractable problem.
There are at least three major advantages to this kind of system.
Since the tiny-blockchain is completely abstracted from the underlying protocols that are providing the hashes it's storing, it is trivial to swap out protocols, or even run more than one at the same time, without forking the tiny-blockchain.
It is also extremely small, so there is a much greater ability to decentralize the proof of the accuracy of any kind of data-set amongst many nodes.
A cryptocurrency could also be highly centralized while proof of it's state is highly decentralized, whereas at the moment those attributes are tightly coupled.
Maybe food for thought, or maybe totally crazy. I'm not so sure myself.
https://en.bitcoin.it/wiki/Block
Jump to: