Hi Phil, This thread appears to be dead since 2014, but I have been thinking of building something that is similar to your system outlined in your PDF (great work by the way). Just asking if are you actively working on implementing something like this?
cheers ={-)
Topic: Another approach on side chains (Read 4313 times)
More readable format with pictures
http://philchampagne.github.io/xsidechain/Side_Chain_without_Bitcoin_modification.pdf
One issue I can see unless I've misunderstood.
When the winning block on the Bitcoin network is published, what's stopping me picking that up and publishing it onto the sidechain, even if I didn't mine it.
When the winning block on the Bitcoin network is published, what's stopping me picking that up and publishing it onto the sidechain, even if I didn't mine it.
Indeed, the devil is in the detail. Good point! Thanks for bringing that up
The easy solution is, as a requirement, the side chain block must be signed with the private key corresponding to the bitcoin address of the winning miner (or runner up). In the case of runner up, it's not really required since it will not be published as opposed to the winning block as you stated.
One issue I can see unless I've misunderstood.
When the winning block on the Bitcoin network is published, what's stopping me picking that up and publishing it onto the sidechain, even if I didn't mine it.
When the winning block on the Bitcoin network is published, what's stopping me picking that up and publishing it onto the sidechain, even if I didn't mine it.
When you say the lowest hash do you mean the hash with the least integer value or the hash with the greatest difficulty ? i.e. most proceeding zeros ?
I'm referring to the hash output to satisfy the mining algorithm - ie: must have the most leading zeros to satisfy difficulty.
While the miners are running the hash race, they need to have the hash with a certain amount of leading zeros. But if they don't meet it, right now they throw away this result, increment the nonce and rung it again. But here they remember the result and if a better result (with higher amount of leading zeros) comes later, they replace it with this one and take note of the corresponding nonce.
Once a miner discover the hash with the required leading zero on the Bitcoin protocol, the others on the side chain broadcast their best result on the side chain. The closest contender wins on the side chain. Proof required: broadcast the block that would have been added if they were the one with the required leading zeros.
Of course, if the winner of the block on the Bitcoin block chain happens to be a participant on this side chain, it will be the winner there too.
PS: BTW, I'm rewriting this up with more content and figures. It should be an easier read.
Bitcoins using one-way peg could also be used on that side chain, but rewarding operators of the side chain with Bitcoin on the main block chain will limit the requirement for sending bitcoins on the sidechain to a minimum. Using one-way peg wouldn't require a modification of Bitcoin.
(And of course, an alternative is for the side chain to have its own currency for experimentation as well on contracts, etc, without losing any bitcoins to this side chain with the one way peg).
When you say the lowest hash do you mean the hash with the least integer value or the hash with the greatest difficulty ? i.e. most proceeding zeros ?
I've edited the original text for clarity.
But working on PDF doc with figures.
A few other points - that I had to go through after a few excellent questions from Jameson Lopp (https://twitter.com/lopp)
In regards to scalability (to avoid the broadcasting of all blocks at the same time to determine the winner):
In the process of determining the winner of the side chain block, Bitcoin Miners would only broadcast their lowest hash while they were working on the last block they just lost on the block chain. Once confirmed they have the lowest, they would be sending their whole block that would have been the latest block in the Bitcoin block chain had the hash output met the difficulty level.
Also, a random delay between 1 second and 2 minutes could be incorporated by each (to avoid sudden broadcast near the same time), and those who didn't sent their hash yet (because of said delay), would not send it if they receive an hash output lower then their own.
We could have only a few Bitcoin miners participating and it would still work, but the more the better indeed.
But I think there would be enough incentive for Bitcoin miners to participate (since it's barely a bit more work than what they do now) as long as the transaction record fees amount to an interesting amount. So, even if they don't win the next Bitcoin block, they might be winning on this side chain block (or one of those side chain, if there are more than one and he participate in multiple of them)
-Phil Champagne
In regards to scalability (to avoid the broadcasting of all blocks at the same time to determine the winner):
In the process of determining the winner of the side chain block, Bitcoin Miners would only broadcast their lowest hash while they were working on the last block they just lost on the block chain. Once confirmed they have the lowest, they would be sending their whole block that would have been the latest block in the Bitcoin block chain had the hash output met the difficulty level.
Also, a random delay between 1 second and 2 minutes could be incorporated by each (to avoid sudden broadcast near the same time), and those who didn't sent their hash yet (because of said delay), would not send it if they receive an hash output lower then their own.
We could have only a few Bitcoin miners participating and it would still work, but the more the better indeed.
But I think there would be enough incentive for Bitcoin miners to participate (since it's barely a bit more work than what they do now) as long as the transaction record fees amount to an interesting amount. So, even if they don't win the next Bitcoin block, they might be winning on this side chain block (or one of those side chain, if there are more than one and he participate in multiple of them)
-Phil Champagne
{edited for clarity - will have figures later}
More readable format with pictures
http://philchampagne.github.io/xsidechain/Side_Chain_without_Bitcoin_modification.pdf
Another approach on side chain
By Phil Champagne
July 12th, 2014
The concept of a side chain gives the ability to run a separate block chain from the official Bitcoin protocol allowing for various experiments as well as providing an entirely new set of services and benefits. Ideally, it would piggy back on the back of the existing Bitcoin protocol with little or no changes to it. There is a very conservative approach to the Bitcoin software and as such, so far entirely new currencies have to be created to provide new concepts. Ideally, the existing bitcoin currency and CPU Hash power would still be used on those other block chain (side chains) and so far, proposals require a modification of the existing Bitcoin software to allow for that. The proposed method here would allow the creation of side chains that would not modify the existing Bitcoin software. Operators of the side chain (“miners”) are compensated in BTC by the users of the side chain. This side chain would have a dependency on the Bitcoin network and block chain while the Bitcoin network would be left unaware of its existence.
Bitcoin’s block chain has the benefit of the proof-of-work has a method for securing its integrity over this decentralized distributed peer-to-peer network. A side chain will also need to have its data secured and its integrity maintained. Bitcoin uses its own currency has a method to reward the nodes who won the proof-of-work. The currency’s well-being depends on the protocol being respected by the majority of the nodes. Equivalently, the aggregate of all those nodes want to maintain the currency’s value since they are rewarded with it. As opposed to alt coins which are operating an entirely new protocol with its own currency, a side chain will still use BTC to reward nodes for processing and handling the side chain which involves bandwidth usage and disk storage. How can we arrange to maintain the side chain’s integrity using BTC without modifying the existing Bitcoin protocol? At its core, what we need is a way to compensate the nodes in BTC for the maintenance of this separate network.
Just as with Bitcoin, a single node will be responsible for creating the next block of the side chain. With Bitcoin, the node (miner) creating a block is compensated out of this block by creating the new bitcoins as well as being allowed to collect the transaction fees out of the sum of all transactions. Those fees are not sent to a particular bitcoin address, but the winning node (miner) simply adds the sum of those fees to his own bitcoin address. Bitcoin’s block chain acts as the accounting book and since the node is responsible to update it, it can easily make the accounting modification in favor of his very own bitcoin address as part of creating this new block it controls. In the case of the side chain, we cannot assume the node creating the latest block of Bitcoin’s block chain is also involved with this side chain unless the Bitcoin protocol is updated to dictate so. Therefore, we need a method in which the node creating the latest block of the side chain is compensated in bitcoin even though this node may have no involvement with Bitcoin’s protocol, other than as a user receiving and sending Bitcoin transactions.
Users of the side chain would be sending a transaction which will contain a transaction fee. However, let’s call it a Transaction Record to emphasis that this side chain may not necessarily be sending a transaction but rather general information such as a contract to be recorded publicly. There is a big challenge if the selected node who will be recording this side chain’s next block is to be compensated out of the transaction fees of that very same block. Since the winning node (miner) of the current Bitcoin’s block may not be involved in handling the side chain, compensating the side chain node requires sending bitcoin using regular transactions on the Bitcoin network. And this must be done by sending them to this specific node’s very own Bitcoin address.
So, two networks are involved. The Bitcoin network is used by the users of the side chain as a way to compensate the side chain nodes. The second network being the side chain network itself on which the Transaction Records are sent. The side chain nodes will only handle Transaction Records for which transaction fees have been sent on the Bitcoin network. Considering it takes up to about 10 minutes before a transaction is recorded in the Bitcoin network and at least 6 blocks (or 60 minutes) before firm confirmation is done, how can a side chain node be compensated immediately as it is the case in the Bitcoin network?
The immediate payment is not really the requirement; it is more the certainty of the compensation that the side chain nodes are looking for. As such, one solution is asking to be compensated after they created the block. The winning node would be adding a bitcoin address that it owns within the side chain block it creates, which would indicate to users where to send the payments. One approach could have the users of the side chain paying *after* their block has been recorded. In other words, users send their Transaction Records, wait to see when it is recorded in the latest side chain block, look up the bitcoin address of this side chain and make payment on the Bitcoin network for the required transaction fee. The complication arrives in the case of non-payment in which case the side chain network would need to remove any Transaction Records for which no corresponding payments had been made.
But there is another easier approach. Is it that crucial that the node who included a given Transaction Record be the very same one being compensated by the owner of that Transaction Record? I do not believe so, and it opens the case where users for which Transaction Record will be recorded in the next block are actually compensating the winning node that created the prior block (See Figure 1).
Figure 1
But there is another significant part of the Bitcoin network that we haven’t addressed yet. One of the features of the Bitcoin network is that it provides to anyone the ability to access any of the prior blocks of the Bitcoin block chain which a copy is kept by every node. In order to perform their operation, they are obligated to keep a copy of it at all time in order to make sure other nodes have a proper copy of the block chain. Doing so, they can approve newly created blocks by verifying all new transactions are in accordance with prior recorded transactions. But so far, the description we have given does not indicate any incentive for nodes to keep any of the prior side chain blocks. Just as with the Bitcoin network that requires nodes to share prior block to make sure their future block can be approved, the same principle must apply for this side chain. But then the question is, how?
When a new side chain block is created, the side chain nodes will have the requirement to run the hash algorithm that takes, as input, the content of a prior side chain block selected randomly as well as the preceding one. A side chain block header will contain the following:
1. The bitcoin address that this node wants payment to be sent to be compensated.
2. The hash of the previous side chain block
3. The block number of the latest Bitcoin block
4. The hash created with using for input, the content of a prior block of the side chain (see below for formula) combined with this side chain block number and the hash of the latest Bitcoin block chain.
5. The list of transaction
6. This side chain hash.
The hash created for item 4 above requires the full content of a previous side chain block that is unknown by all nodes until now. The formula for the selection requires the use of the hash of the latest Bitcoin’s block. The last 4 bytes of this hash (those bytes on the left side, least significant in value) are used as input number.
Figure 2
The formula is as follow:
P = Prior side chain block number
H = The last 4 bytes of the latest Bitcoin block hash output.
C = Current side chain block number
P = H modulo C
The use of the hash from the latest block of the Bitcoin block chain provides the randomness required.
The item 4 listed above will use, as input to an hash algorithm (SHA-256 for example), the full content of side chain block #242 combined with this current block number (5354) and the hash of the Bitcoin block that was used.
Note that as opposed to the Bitcoin protocol that requires the full block chain be available forever, a specific side chain might have a lighter requirement regarding the length of time that blocks must be kept by nodes, for example only 1 year. In such case, the formula would be slightly modified. Say only the last 1000 blocks are required to be kept by nodes; the formula would be as follow:
P = C – 1000 + (H modulo 1000)
Determining the winning node
Existing Bitcoin nodes that are willing to participate in this side chain would run the extra software to operate the side chain protocol. As they are mining the current block on the Bitcoin network, these participating side chain nodes will take note of the lowest hash value (along with its corresponding nonce) they have obtained so far while racing to mine the current Bitcoin block. Not all miners on the Bitcoin network might decide to participate in this side chain network and as such, the best runner up to the Hash race on the Bitcoin network is chosen. When a block satisfying the difficulty level has been published on the Bitcoin network, these participating miners published their respective block that would have been selected as the latest block of the Bitcoin block chain had their lowest hash value had met the current difficulty level of the Bitcoin protocol. The miner who publishes the Bitcoin block with the lowest hash becomes the winner who will produce the next side chain block. That side chain block will contain the bitcoin address of this miner. Of course, if the publisher of the latest Bitcoin block is among the participants on this side chain, he will be the winner of the side chain as well, and collecting the transaction fees for the next block of the side chain.
To avoid issues related to orphan blocks, either the side chain applies the same rules regarding block splits as the Bitcoin protocol, or alternatively, there is a lag of 10 blocks of on the Bitcoin network before establishing the winner and publishing the new side chain.
Now this winner will start receiving payments to his bitcoin address by current users of the side chain network who will have their transaction recorded included in the next side chain block.
Incorporating Transaction Records
To have its transaction record processed in the side chain, the user must send a certain amount of bitcoins – using the Bitcoin network – to the bitcoin address listed in the latest side chain. The user will “sign” his transaction record with the private key corresponding to the bitcoin address that was used to send the bitcoins to the published bitcoin address. This will confirm payment has been made for this transaction record on the side chain. Like we said earlier, miners (or side chain “operators”) are paid from the transaction record fees of the next side chain block after theirs.
When splits and orphan blocks happen on the Bitcoin block chain, it would be handled in the same way on the side chain. However, if this side chain block happens not often (like once every 24 hour), one implementation could introduce a sufficient delay of 6 to 10 blocks of the Bitcoin block chain could be introduced to establish the winner.
Case study #1: a block every 24 hour
Let’s assume we want to create a side chain that only requires a new block every 24 hours which records public documents, or contracts. It could be established that it is the winner of the first Bitcoin block created after midnight GMT that will create this block. The Bitcoin miners who competed to obtain the hash output satisfying the difficulty level kept a record of their best hash output result (lowest value) along with its corresponding nonce. They now broadcast just their hash output to each other. If required, a random delay between 1 and 30 seconds could be implemented so that not all nodes are flooding the network with packets at the same time. If a node receives a hash output with a lower value than he has, it does not have to bother sending his own.
Once the winning runner up node has been established, it starts to work on creating the side chain block by incorporating all the transaction records that have been received during the last 24 hours.
Case study #2: a block every 1 minute
A side chain implementation could have a shorter period than the Bitcoin protocol. In this case, the winning miner is responsible for the next 10 or perhaps 20, 30 or 60 blocks. It is sort of like splitting the block in multiple blocks over an established period of time.
Extra:
Note 1:
Another twist might be to have side chain miners doing own proof-of-work on this side chain block. Miners are competing for the proof-of-work with the hash of the side chain block. Just as with the Bitcoin protocol, the hash of the side chain block must be below a certain level which is adjusted based on rapidity of calculation by the overall network. The downside is that extra hash power must be dedicated to this side chain.
Note 2:
Originally, instead of the particularity of having the miner collecting the reward of the future block, I was considering the miner collecting the reward of the existing block. However, since transaction fees are collected at the time of transmission, it requires sending it to an established bitcoin address. I envisioned it could be a multisig address of 6 out of 10 miners (the winner and 9 runner-up). These miners would be co-signing multiple transactions, 1 to the winner, and a smaller amount to each of the 9 runner up. But the issue of a collecting the transaction fees for a future block are not necessarily an issue. On the long run, it should be about the same, a stable number of transactions. Even if it was not, say, the side chain was on 24 hour, and on the Sunday, there was very little traffic but Monday a peak, the interest for winning and operating on Sunday would be higher than the payment collected on that day. Equivalently, Friday winning miners might have a lot of transactions but very little pay out from the Saturday block.
More readable format with pictures
http://philchampagne.github.io/xsidechain/Side_Chain_without_Bitcoin_modification.pdf
Another approach on side chain
By Phil Champagne
July 12th, 2014
The concept of a side chain gives the ability to run a separate block chain from the official Bitcoin protocol allowing for various experiments as well as providing an entirely new set of services and benefits. Ideally, it would piggy back on the back of the existing Bitcoin protocol with little or no changes to it. There is a very conservative approach to the Bitcoin software and as such, so far entirely new currencies have to be created to provide new concepts. Ideally, the existing bitcoin currency and CPU Hash power would still be used on those other block chain (side chains) and so far, proposals require a modification of the existing Bitcoin software to allow for that. The proposed method here would allow the creation of side chains that would not modify the existing Bitcoin software. Operators of the side chain (“miners”) are compensated in BTC by the users of the side chain. This side chain would have a dependency on the Bitcoin network and block chain while the Bitcoin network would be left unaware of its existence.
Bitcoin’s block chain has the benefit of the proof-of-work has a method for securing its integrity over this decentralized distributed peer-to-peer network. A side chain will also need to have its data secured and its integrity maintained. Bitcoin uses its own currency has a method to reward the nodes who won the proof-of-work. The currency’s well-being depends on the protocol being respected by the majority of the nodes. Equivalently, the aggregate of all those nodes want to maintain the currency’s value since they are rewarded with it. As opposed to alt coins which are operating an entirely new protocol with its own currency, a side chain will still use BTC to reward nodes for processing and handling the side chain which involves bandwidth usage and disk storage. How can we arrange to maintain the side chain’s integrity using BTC without modifying the existing Bitcoin protocol? At its core, what we need is a way to compensate the nodes in BTC for the maintenance of this separate network.
Just as with Bitcoin, a single node will be responsible for creating the next block of the side chain. With Bitcoin, the node (miner) creating a block is compensated out of this block by creating the new bitcoins as well as being allowed to collect the transaction fees out of the sum of all transactions. Those fees are not sent to a particular bitcoin address, but the winning node (miner) simply adds the sum of those fees to his own bitcoin address. Bitcoin’s block chain acts as the accounting book and since the node is responsible to update it, it can easily make the accounting modification in favor of his very own bitcoin address as part of creating this new block it controls. In the case of the side chain, we cannot assume the node creating the latest block of Bitcoin’s block chain is also involved with this side chain unless the Bitcoin protocol is updated to dictate so. Therefore, we need a method in which the node creating the latest block of the side chain is compensated in bitcoin even though this node may have no involvement with Bitcoin’s protocol, other than as a user receiving and sending Bitcoin transactions.
Users of the side chain would be sending a transaction which will contain a transaction fee. However, let’s call it a Transaction Record to emphasis that this side chain may not necessarily be sending a transaction but rather general information such as a contract to be recorded publicly. There is a big challenge if the selected node who will be recording this side chain’s next block is to be compensated out of the transaction fees of that very same block. Since the winning node (miner) of the current Bitcoin’s block may not be involved in handling the side chain, compensating the side chain node requires sending bitcoin using regular transactions on the Bitcoin network. And this must be done by sending them to this specific node’s very own Bitcoin address.
So, two networks are involved. The Bitcoin network is used by the users of the side chain as a way to compensate the side chain nodes. The second network being the side chain network itself on which the Transaction Records are sent. The side chain nodes will only handle Transaction Records for which transaction fees have been sent on the Bitcoin network. Considering it takes up to about 10 minutes before a transaction is recorded in the Bitcoin network and at least 6 blocks (or 60 minutes) before firm confirmation is done, how can a side chain node be compensated immediately as it is the case in the Bitcoin network?
The immediate payment is not really the requirement; it is more the certainty of the compensation that the side chain nodes are looking for. As such, one solution is asking to be compensated after they created the block. The winning node would be adding a bitcoin address that it owns within the side chain block it creates, which would indicate to users where to send the payments. One approach could have the users of the side chain paying *after* their block has been recorded. In other words, users send their Transaction Records, wait to see when it is recorded in the latest side chain block, look up the bitcoin address of this side chain and make payment on the Bitcoin network for the required transaction fee. The complication arrives in the case of non-payment in which case the side chain network would need to remove any Transaction Records for which no corresponding payments had been made.
But there is another easier approach. Is it that crucial that the node who included a given Transaction Record be the very same one being compensated by the owner of that Transaction Record? I do not believe so, and it opens the case where users for which Transaction Record will be recorded in the next block are actually compensating the winning node that created the prior block (See Figure 1).
Figure 1
But there is another significant part of the Bitcoin network that we haven’t addressed yet. One of the features of the Bitcoin network is that it provides to anyone the ability to access any of the prior blocks of the Bitcoin block chain which a copy is kept by every node. In order to perform their operation, they are obligated to keep a copy of it at all time in order to make sure other nodes have a proper copy of the block chain. Doing so, they can approve newly created blocks by verifying all new transactions are in accordance with prior recorded transactions. But so far, the description we have given does not indicate any incentive for nodes to keep any of the prior side chain blocks. Just as with the Bitcoin network that requires nodes to share prior block to make sure their future block can be approved, the same principle must apply for this side chain. But then the question is, how?
When a new side chain block is created, the side chain nodes will have the requirement to run the hash algorithm that takes, as input, the content of a prior side chain block selected randomly as well as the preceding one. A side chain block header will contain the following:
1. The bitcoin address that this node wants payment to be sent to be compensated.
2. The hash of the previous side chain block
3. The block number of the latest Bitcoin block
4. The hash created with using for input, the content of a prior block of the side chain (see below for formula) combined with this side chain block number and the hash of the latest Bitcoin block chain.
5. The list of transaction
6. This side chain hash.
The hash created for item 4 above requires the full content of a previous side chain block that is unknown by all nodes until now. The formula for the selection requires the use of the hash of the latest Bitcoin’s block. The last 4 bytes of this hash (those bytes on the left side, least significant in value) are used as input number.
Figure 2
The formula is as follow:
P = Prior side chain block number
H = The last 4 bytes of the latest Bitcoin block hash output.
C = Current side chain block number
P = H modulo C
The use of the hash from the latest block of the Bitcoin block chain provides the randomness required.
The item 4 listed above will use, as input to an hash algorithm (SHA-256 for example), the full content of side chain block #242 combined with this current block number (5354) and the hash of the Bitcoin block that was used.
Note that as opposed to the Bitcoin protocol that requires the full block chain be available forever, a specific side chain might have a lighter requirement regarding the length of time that blocks must be kept by nodes, for example only 1 year. In such case, the formula would be slightly modified. Say only the last 1000 blocks are required to be kept by nodes; the formula would be as follow:
P = C – 1000 + (H modulo 1000)
Determining the winning node
Existing Bitcoin nodes that are willing to participate in this side chain would run the extra software to operate the side chain protocol. As they are mining the current block on the Bitcoin network, these participating side chain nodes will take note of the lowest hash value (along with its corresponding nonce) they have obtained so far while racing to mine the current Bitcoin block. Not all miners on the Bitcoin network might decide to participate in this side chain network and as such, the best runner up to the Hash race on the Bitcoin network is chosen. When a block satisfying the difficulty level has been published on the Bitcoin network, these participating miners published their respective block that would have been selected as the latest block of the Bitcoin block chain had their lowest hash value had met the current difficulty level of the Bitcoin protocol. The miner who publishes the Bitcoin block with the lowest hash becomes the winner who will produce the next side chain block. That side chain block will contain the bitcoin address of this miner. Of course, if the publisher of the latest Bitcoin block is among the participants on this side chain, he will be the winner of the side chain as well, and collecting the transaction fees for the next block of the side chain.
To avoid issues related to orphan blocks, either the side chain applies the same rules regarding block splits as the Bitcoin protocol, or alternatively, there is a lag of 10 blocks of on the Bitcoin network before establishing the winner and publishing the new side chain.
Now this winner will start receiving payments to his bitcoin address by current users of the side chain network who will have their transaction recorded included in the next side chain block.
Incorporating Transaction Records
To have its transaction record processed in the side chain, the user must send a certain amount of bitcoins – using the Bitcoin network – to the bitcoin address listed in the latest side chain. The user will “sign” his transaction record with the private key corresponding to the bitcoin address that was used to send the bitcoins to the published bitcoin address. This will confirm payment has been made for this transaction record on the side chain. Like we said earlier, miners (or side chain “operators”) are paid from the transaction record fees of the next side chain block after theirs.
When splits and orphan blocks happen on the Bitcoin block chain, it would be handled in the same way on the side chain. However, if this side chain block happens not often (like once every 24 hour), one implementation could introduce a sufficient delay of 6 to 10 blocks of the Bitcoin block chain could be introduced to establish the winner.
Case study #1: a block every 24 hour
Let’s assume we want to create a side chain that only requires a new block every 24 hours which records public documents, or contracts. It could be established that it is the winner of the first Bitcoin block created after midnight GMT that will create this block. The Bitcoin miners who competed to obtain the hash output satisfying the difficulty level kept a record of their best hash output result (lowest value) along with its corresponding nonce. They now broadcast just their hash output to each other. If required, a random delay between 1 and 30 seconds could be implemented so that not all nodes are flooding the network with packets at the same time. If a node receives a hash output with a lower value than he has, it does not have to bother sending his own.
Once the winning runner up node has been established, it starts to work on creating the side chain block by incorporating all the transaction records that have been received during the last 24 hours.
Case study #2: a block every 1 minute
A side chain implementation could have a shorter period than the Bitcoin protocol. In this case, the winning miner is responsible for the next 10 or perhaps 20, 30 or 60 blocks. It is sort of like splitting the block in multiple blocks over an established period of time.
Extra:
Note 1:
Another twist might be to have side chain miners doing own proof-of-work on this side chain block. Miners are competing for the proof-of-work with the hash of the side chain block. Just as with the Bitcoin protocol, the hash of the side chain block must be below a certain level which is adjusted based on rapidity of calculation by the overall network. The downside is that extra hash power must be dedicated to this side chain.
Note 2:
Originally, instead of the particularity of having the miner collecting the reward of the future block, I was considering the miner collecting the reward of the existing block. However, since transaction fees are collected at the time of transmission, it requires sending it to an established bitcoin address. I envisioned it could be a multisig address of 6 out of 10 miners (the winner and 9 runner-up). These miners would be co-signing multiple transactions, 1 to the winner, and a smaller amount to each of the 9 runner up. But the issue of a collecting the transaction fees for a future block are not necessarily an issue. On the long run, it should be about the same, a stable number of transactions. Even if it was not, say, the side chain was on 24 hour, and on the Sunday, there was very little traffic but Monday a peak, the interest for winning and operating on Sunday would be higher than the payment collected on that day. Equivalently, Friday winning miners might have a lot of transactions but very little pay out from the Saturday block.
Jump to: