Idea #C
Additional incentives to mine, like a bitmessage type system or reserved space in blocks, those incentives have a marginal utility that declines quickly with amount, reducing the incentive for large centralized mining farms, those incentives must somehow be impossible to transfer or outsource. This would give normal people an incentive to mine.
Topic: [THREAD FOR ALTCOIN IDEAS] (Read 1521 times)
Idea #B:
This idea is related to the Bitcoin Tic-Tac Coopetition mining thread.
The idea is to use multiple types of PoW (SHA2-256, SHA3, scrypt, my scheme from idea #A) for the same blockchain, but to enforce the PoW to cycle over the blocks.
For example, the first block must be SHA2-256, the second must be SHA3 the third must be scrypt, the forth must be my scheme from idea #A, the fifth must be SHA2-256 again, and so on cyclically.
This supports the same idea as the Tic-Tac proposal, namely that specialized hardware must lay fallow for most of the time, and a 51% attacker must have a lot of each type of hardware.
This also allows unspecialised hardware to have a chance, as it can switch from one kind of mining to another.
This idea is related to the Bitcoin Tic-Tac Coopetition mining thread.
The idea is to use multiple types of PoW (SHA2-256, SHA3, scrypt, my scheme from idea #A) for the same blockchain, but to enforce the PoW to cycle over the blocks.
For example, the first block must be SHA2-256, the second must be SHA3 the third must be scrypt, the forth must be my scheme from idea #A, the fifth must be SHA2-256 again, and so on cyclically.
This supports the same idea as the Tic-Tac proposal, namely that specialized hardware must lay fallow for most of the time, and a 51% attacker must have a lot of each type of hardware.
This also allows unspecialised hardware to have a chance, as it can switch from one kind of mining to another.
Yours is based on two incorrect, flawed ideas:
https://bitcointalksearch.org/topic/m.17158224
https://bitcointalksearch.org/topic/m.17159826
Please n00bs stop trying to think you are any where near expert enough to design a secure consensus ordering system.
Have the block only be produced with a special dev signing key ?
"Hello federal reserve system!"i like a coin that can solve completely the size of the blockchain by resume the blockchain from a previous more recent point without the need of pruning and with the possibility of using different wallet after you activate this not like pruning where you need to resync again, i also like faster confirmation but not with orpahn and more anonymous coin like zcash/zcoin
i have been tackling the first idea you mentioned. I tried running it on a testnet, but my idea is incomplete. So far online wallets have no trouble with the transition, but new wallets have trouble with syncing.
I'll highlight the problems
1) the new block created as a "balances checkpoint" must be dead accurate
2) How do we prevent a miner from manipulating balances in this block
-- Maybe have local machines audit the data ? or
-- Have the block only be produced with a special dev signing key ?
3) New wallets
they just start from the last "balances checkpoint"?-- If so how do they ensure they are on the right chain ? Genesis block isn't enough, since attackers can create a fork just as long or even longer than active chain.
4) In case of catastrophic re-org / fork , what then ?
i like a coin that can solve completely the size of the blockchain by resume the blockchain from a previous more recent point without the need of pruning and with the possibility of using different wallet after you activate this not like pruning where you need to resync again, i also like faster confirmation but not with orpahn and more anonymous coin like zcash/zcoin
Idea #B:
This idea is related to the Bitcoin Tic-Tac Coopetition mining thread.
The idea is to use multiple types of PoW (SHA2-256, SHA3, scrypt, my scheme from idea #A) for the same blockchain, but to enforce the PoW to cycle over the blocks.
For example, the first block must be SHA2-256, the second must be SHA3 the third must be scrypt, the forth must be my scheme from idea #A, the fifth must be SHA2-256 again, and so on cyclically.
This supports the same idea as the Tic-Tac proposal, namely that specialized hardware must lay fallow for most of the time, and a 51% attacker must have a lot of each type of hardware.
This also allows unspecialised hardware to have a chance, as it can switch from one kind of mining to another.
In particular, for an attacker, the rate of getting blocks at some difficulty is proportional to:
1/(1/a+1/b+1/c+1/d+...)
Therefore, an attacker must have higher 1/(1/a+1/b+1/c+1/d+...) than the rest of the network to launch an attack, in particular, an attacker (or large miner to some degree) must diversify, but small miners can specialize on one kind of hardware.
A disadvantage of this is that timestamps can be inaccurate, and this can make it difficult to adjust the difficulty.
Another disadvantage is the difficulty of comparing forks.
This idea is related to the Bitcoin Tic-Tac Coopetition mining thread.
The idea is to use multiple types of PoW (SHA2-256, SHA3, scrypt, my scheme from idea #A) for the same blockchain, but to enforce the PoW to cycle over the blocks.
For example, the first block must be SHA2-256, the second must be SHA3 the third must be scrypt, the forth must be my scheme from idea #A, the fifth must be SHA2-256 again, and so on cyclically.
This supports the same idea as the Tic-Tac proposal, namely that specialized hardware must lay fallow for most of the time, and a 51% attacker must have a lot of each type of hardware.
This also allows unspecialised hardware to have a chance, as it can switch from one kind of mining to another.
In particular, for an attacker, the rate of getting blocks at some difficulty is proportional to:
1/(1/a+1/b+1/c+1/d+...)
Therefore, an attacker must have higher 1/(1/a+1/b+1/c+1/d+...) than the rest of the network to launch an attack, in particular, an attacker (or large miner to some degree) must diversify, but small miners can specialize on one kind of hardware.
A disadvantage of this is that timestamps can be inaccurate, and this can make it difficult to adjust the difficulty.
Another disadvantage is the difficulty of comparing forks.
You don't need any "ideas" Junior..
There is only one.. currency.
/end
Nice dude. A word with thousand mean. There is only one.. currency.
/end
Actually, this will be going outside from his purpose be a digital currency.
The ideas must be related to the development of new altcoins, not how to use them!
does that make sense? because to me doenst..in any development we need to make both questions.
something like "what we need?"and then "how to do it?".
you cant answer the second without thinking about the first.
This thread is dedicated to the technical aspects of cryptocurrencies, not to trading or physical coins.
You don't need any "ideas" Junior..
There is only one.. currency.
/end
There is only one.. currency.
/end
You don't need any "ideas" Junior..
There is only one.. currency.
/end
There is only one.. currency.
/end
The ideas must be related to the development of new altcoins, not how to use them!
does that make sense? because to me doenst..in any development we need to make both questions.
something like "what we need?"and then "how to do it?".
you cant answer the second without thinking about the first.
Idea #A Why not use hexadecimal?
Simple memory-hard PoW that is relatively easy to check.
Scrypt is a system with some advantages, however, it has one key fault:
To check the PoW, a node must generate the whole table and do all the lookups, a time consuming process.
The core of this system is a table, that is of a large size, and is agreed on by all.
This table is generated via a moderately intensive process, that produces the whole table "at once" as the result of a rather-simple script.
With "at once" I mean that it is not practical for an attacker to store a reduced version, and to quickly produce distinct parts on demand.
One way to achieve this is to repeatedly run over an initialized list with a sponge hash, continually replacing the data with bits squeezed from the sponge and absorbing data into the sponge.
Once the table is created, it can be either reduced using a Merkle tree or combined into an accumulator (first combined with the array indexes).
The script used to create the table, as well as the final hash result, are included in node software, and a new node, before downloading the block-chain, runs the script and checks the result against the value it has.
To preform PoW, a miner combines new block data into a hash, tacks on a nonce, and hashes the result.
The miner then repeatedly uses the first several bits as an array index, looks up the element, combines it with the first hash, and hashes the result.
After several stages, the miner checks the final hash against the difficulty, if this fails, the miner starts over with a new nonce.
If this is successfully, the miner publishes the block data and nonce, and also all the array entries looked up, with their respective Merkle paths.
The node checking the PoW does not have to create the table, but to only verify the Merkle paths.
If an accumulator is used instead of a tree, the size and checking difficulty of the PoW is cut down considerably.
Simple memory-hard PoW that is relatively easy to check.
Scrypt is a system with some advantages, however, it has one key fault:
To check the PoW, a node must generate the whole table and do all the lookups, a time consuming process.
The core of this system is a table, that is of a large size, and is agreed on by all.
This table is generated via a moderately intensive process, that produces the whole table "at once" as the result of a rather-simple script.
With "at once" I mean that it is not practical for an attacker to store a reduced version, and to quickly produce distinct parts on demand.
One way to achieve this is to repeatedly run over an initialized list with a sponge hash, continually replacing the data with bits squeezed from the sponge and absorbing data into the sponge.
Once the table is created, it can be either reduced using a Merkle tree or combined into an accumulator (first combined with the array indexes).
The script used to create the table, as well as the final hash result, are included in node software, and a new node, before downloading the block-chain, runs the script and checks the result against the value it has.
To preform PoW, a miner combines new block data into a hash, tacks on a nonce, and hashes the result.
The miner then repeatedly uses the first several bits as an array index, looks up the element, combines it with the first hash, and hashes the result.
After several stages, the miner checks the final hash against the difficulty, if this fails, the miner starts over with a new nonce.
If this is successfully, the miner publishes the block data and nonce, and also all the array entries looked up, with their respective Merkle paths.
The node checking the PoW does not have to create the table, but to only verify the Merkle paths.
If an accumulator is used instead of a tree, the size and checking difficulty of the PoW is cut down considerably.
Idea #9
A dark coin scheme that...does not work.
In standard bitcoin transactions, the sum of all the outputs (I count the fee as an output) must be the sum of all the inputs, this conserves the number of coins.
My idea is to have the product of the inputs equal the product of the outputs, this conserves the sum of the logarithms of the output quantities, which is their actual value.
Thus, if a user is sending x coins, the value in the output would actually be the exponential of the value in the input, in an elliptic curve group.
Since the logarithms in question are discrete, deducing the number of coins from the blockchain is equivalent to solving the discrete logarithm problem in an elliptic curve group.
To ensure that the recipient knows the amount of coins received, they can be encrypted by the sender using the receivers public key, possibly a different key pair then that used to sign transactions (to allow a "secretary" to view the received coins).
The flaw in this scheme is not in an attacker guessing the amounts, that can be fixed trivially by setting the total number of coins to something astronomically high like ~2^512, allowing a sender to inject entropy into a transaction by overpaying by an absolutely negligible random value.
The flaw is in the value overflow bug, a malicious user can create a transaction with the total number of sent coins being the total number of received coins, plus a multiple of the exponentiation base. This transaction would verify normally, but would create an enormous amount of new coins and, by the dark properties of the system, no-one would know about it.
Is there any way to fix this scheme?
A dark coin scheme that...does not work.
In standard bitcoin transactions, the sum of all the outputs (I count the fee as an output) must be the sum of all the inputs, this conserves the number of coins.
My idea is to have the product of the inputs equal the product of the outputs, this conserves the sum of the logarithms of the output quantities, which is their actual value.
Thus, if a user is sending x coins, the value in the output would actually be the exponential of the value in the input, in an elliptic curve group.
Since the logarithms in question are discrete, deducing the number of coins from the blockchain is equivalent to solving the discrete logarithm problem in an elliptic curve group.
To ensure that the recipient knows the amount of coins received, they can be encrypted by the sender using the receivers public key, possibly a different key pair then that used to sign transactions (to allow a "secretary" to view the received coins).
The flaw in this scheme is not in an attacker guessing the amounts, that can be fixed trivially by setting the total number of coins to something astronomically high like ~2^512, allowing a sender to inject entropy into a transaction by overpaying by an absolutely negligible random value.
The flaw is in the value overflow bug, a malicious user can create a transaction with the total number of sent coins being the total number of received coins, plus a multiple of the exponentiation base. This transaction would verify normally, but would create an enormous amount of new coins and, by the dark properties of the system, no-one would know about it.
Is there any way to fix this scheme?
Idea #8
An Extension of Merkle Signatures to Large Amounts of Messages.
This version of the Merkle signature allows the creation of many distinct signatures, that are resistant against an attacker who can submit arbitrary messages to be signed, the amount of messages is bound by the signer refusing to take over 2^96 hashes, and is trying to generate a false signature an a new message, it is assumed that the attacker cannot find preimeges or second preimages in the underlying 256 bit hash function but can find collisions. The privite key and public key for this scheme are only 256 bits long, but, even with my optimizations, the signature is inpracticably large for most applications.
The public and private key pairs are generated as follows:
A random 256 bit string is chosen, this is the preterite key Pr.
The function H is a strong hash function with arbitrary input and 256 bit output, I recommend SHA3-256.
All hashes of the form H(Pr||x||y||z) are taken, where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1.
This list ordered by x, then by y, then by z (the most logical way to order it).
Every element in this list is hashed, to create a new list of hashes.
This list is hashed with a Merkle tree, with adjacent elements combined first and ajacent hashes combined first until one string is obtained.
This string is the public key Pu.
Now, the signer can forget everything except the private key Pr.
To sign a message M, the signer first computes a random 256 bit string A.
Then, the signer recomputes the original table from Pr.
Then the signer splits A into the following form:
A=a1||a2||a3||a4||...||a30||a31||a32
a1 through a32 are 8 bits long.
Now the signer computes a similar hash table of the form H(Pr||a1||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a1 of the original (zeroeth) table, and provides the partial Merkle roots necessary to link part a1 to Pu.
Now the signer computes a similar hash table of the form H(Pr||a1||a2||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a2 of the first table (the one generated with a1) , and provides the partial Merkle roots necessary to link part a2 to the string signed with the previous table.
Now the signer computes a similar hash table of the form H(Pr||a1||a2||a3||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a3 of the second table (the one generated with a1 and a2) , and provides the partial Merkle roots necessary to link part a3 to the string signed with the previous table.
The signer repeats this procedure for 31 values except a32, then continues as follows:
The signer computes a hash H(M||A) of the message and uses part a32 the last table (the one generated with a1 through a32) to compute a Lamport signature, and provides the partial Merkle roots necessary to link part a32 to the string signed with the previous table.
A actually does not have to be random, it can be derived from the message and private key using A=H(M||Pr).
To do this, the signer must preform the following number of hashes:
2 to reduce the message and generate A.
2*256*256 to generate each private Lamport key.
2*256*256 to generate each public Lamport key.
2*256*256-1 to hash each Lamport key down to a single string.
Total:
2+32*(2*256*256+2*256*256+2*256*256-1)=12582882
The signature consists of:
A 256
The first Lamport Signature (256*256*2)=131072
The partial roots of it (8*258)=2048
The other 31 signatures and trees 2095104
Total 4260096=532512*8
To verify the message, the verifier starts from the bottom, first taking the hash H(M,A), then hashing the last Lambort signature, using the last 8 bits of A and the partial roots to get the string signed by the previous stage. This procces is repeated 32 times, and eventually Pu should be the result, if so, the signature is valid.
Hashes to verify:
1 to find H(M,A).
256 to find each Lamport public key.
512 to hash it to a single string.
8 to hash in the partial roots.
Total:
1+32*(256+512+8)=24833.
I claim that this is secure against an attacker who can:
Get as many messages signed as is feasible using a classical computer.
And who can find 256 bit hash collisions but not preimages or second preimages.
An Extension of Merkle Signatures to Large Amounts of Messages.
This version of the Merkle signature allows the creation of many distinct signatures, that are resistant against an attacker who can submit arbitrary messages to be signed, the amount of messages is bound by the signer refusing to take over 2^96 hashes, and is trying to generate a false signature an a new message, it is assumed that the attacker cannot find preimeges or second preimages in the underlying 256 bit hash function but can find collisions. The privite key and public key for this scheme are only 256 bits long, but, even with my optimizations, the signature is inpracticably large for most applications.
The public and private key pairs are generated as follows:
A random 256 bit string is chosen, this is the preterite key Pr.
The function H is a strong hash function with arbitrary input and 256 bit output, I recommend SHA3-256.
All hashes of the form H(Pr||x||y||z) are taken, where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1.
This list ordered by x, then by y, then by z (the most logical way to order it).
Every element in this list is hashed, to create a new list of hashes.
This list is hashed with a Merkle tree, with adjacent elements combined first and ajacent hashes combined first until one string is obtained.
This string is the public key Pu.
Now, the signer can forget everything except the private key Pr.
To sign a message M, the signer first computes a random 256 bit string A.
Then, the signer recomputes the original table from Pr.
Then the signer splits A into the following form:
A=a1||a2||a3||a4||...||a30||a31||a32
a1 through a32 are 8 bits long.
Now the signer computes a similar hash table of the form H(Pr||a1||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a1 of the original (zeroeth) table, and provides the partial Merkle roots necessary to link part a1 to Pu.
Now the signer computes a similar hash table of the form H(Pr||a1||a2||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a2 of the first table (the one generated with a1) , and provides the partial Merkle roots necessary to link part a2 to the string signed with the previous table.
Now the signer computes a similar hash table of the form H(Pr||a1||a2||a3||x||y||z) where x ranges over all 8 bit strings, y ranges over all 8 bit strings and z is 0 or 1. As before, the table is hashed down to a single string.
Now the signer computes a Lamport signature of this string using part a3 of the second table (the one generated with a1 and a2) , and provides the partial Merkle roots necessary to link part a3 to the string signed with the previous table.
The signer repeats this procedure for 31 values except a32, then continues as follows:
The signer computes a hash H(M||A) of the message and uses part a32 the last table (the one generated with a1 through a32) to compute a Lamport signature, and provides the partial Merkle roots necessary to link part a32 to the string signed with the previous table.
A actually does not have to be random, it can be derived from the message and private key using A=H(M||Pr).
To do this, the signer must preform the following number of hashes:
2 to reduce the message and generate A.
2*256*256 to generate each private Lamport key.
2*256*256 to generate each public Lamport key.
2*256*256-1 to hash each Lamport key down to a single string.
Total:
2+32*(2*256*256+2*256*256+2*256*256-1)=12582882
The signature consists of:
A 256
The first Lamport Signature (256*256*2)=131072
The partial roots of it (8*258)=2048
The other 31 signatures and trees 2095104
Total 4260096=532512*8
To verify the message, the verifier starts from the bottom, first taking the hash H(M,A), then hashing the last Lambort signature, using the last 8 bits of A and the partial roots to get the string signed by the previous stage. This procces is repeated 32 times, and eventually Pu should be the result, if so, the signature is valid.
Hashes to verify:
1 to find H(M,A).
256 to find each Lamport public key.
512 to hash it to a single string.
8 to hash in the partial roots.
Total:
1+32*(256+512+8)=24833.
I claim that this is secure against an attacker who can:
Get as many messages signed as is feasible using a classical computer.
And who can find 256 bit hash collisions but not preimages or second preimages.
yeah,great ideas..lets post more and more..
Idea #7
Blockchain pruning/scalability
In addition to POW nodes or staking nodes you could have archive nodes which are themselves POW or Staking.
Every so often (at a predetermined block counts) a snapshot of the Blockchain state is taken and is used by archive nodes to start the next chain with the new genesis block. The network would ensure that the last designated block would have to be won by an archive node and the winning archive node could get a super reward for this. Or the reward could be split into shares and distributed according to how much work archive nodes have contributed over the lifetime of the old chain. If the snapshot and genesis generated by the winning archive node is disputed by 51% of the archive nodes on the network then the last block will be up for grabs again. Blocks, other than the first or last block on a chain are verified by all nodes that are POW or staking.
Archive nodes are able to store the blockchains older than x iterations to BD media or similar. Archive nodes cannot validate with the network unless they have local realtime access to ALL previous chains on whatever local media. (So the disks or BD must remain online). Archive nodes enjoy enhanced POW or Staking rewards during normal block creation. Archive nodes can offer full blockchain analytics and searches via web or api services for a fee.
The aim would be to keep each blockchain to a size manageable by modest platforms including SBCs - say 8GB but allowing vastly greater block sizes or frequencies.
Blockchain pruning/scalability
In addition to POW nodes or staking nodes you could have archive nodes which are themselves POW or Staking.
Every so often (at a predetermined block counts) a snapshot of the Blockchain state is taken and is used by archive nodes to start the next chain with the new genesis block. The network would ensure that the last designated block would have to be won by an archive node and the winning archive node could get a super reward for this. Or the reward could be split into shares and distributed according to how much work archive nodes have contributed over the lifetime of the old chain. If the snapshot and genesis generated by the winning archive node is disputed by 51% of the archive nodes on the network then the last block will be up for grabs again. Blocks, other than the first or last block on a chain are verified by all nodes that are POW or staking.
Archive nodes are able to store the blockchains older than x iterations to BD media or similar. Archive nodes cannot validate with the network unless they have local realtime access to ALL previous chains on whatever local media. (So the disks or BD must remain online). Archive nodes enjoy enhanced POW or Staking rewards during normal block creation. Archive nodes can offer full blockchain analytics and searches via web or api services for a fee.
The aim would be to keep each blockchain to a size manageable by modest platforms including SBCs - say 8GB but allowing vastly greater block sizes or frequencies.
Idea #6
Someone has probably thought of this before.
In a conventional Merkle Tree, each node is the hash of the nodeshashes
My idea is to make a self-pruning tree with the hashing function being (x=H(y,z) xor H(0,0)), this lets nodes quickly eliminate empty branches.
Is this useful?
Is this new?
Is this secure?
Someone has probably thought of this before.
In a conventional Merkle Tree, each node is the hash of the nodeshashes
My idea is to make a self-pruning tree with the hashing function being (x=H(y,z) xor H(0,0)), this lets nodes quickly eliminate empty branches.
Is this useful?
Is this new?
Is this secure?
#5
How long (at most) does it take for transactions to reach all miners from any point on the network?
How long (at most) does it take for blocks to reach all miners after being relayed?
How long would it take a lump to be relayed all over the network and reach all miners?
I think it would be as fast as transactions, maybe even faster because nodes only have to take one hash and a few comparisons, no signature validation, input verification, or searches for double-spend attempts. Also, if blobs have priority over transactions, they would have almost no overload lag (no waiting for transactions to be processed). Blocks should have priority over blobs since those blobs are orphaned anyway (if they are not already included in the block) since honest miners never mine from a block that already has descendants.
How long (at most) does it take for transactions to reach all miners from any point on the network?
How long (at most) does it take for blocks to reach all miners after being relayed?
How long would it take a lump to be relayed all over the network and reach all miners?
I think it would be as fast as transactions, maybe even faster because nodes only have to take one hash and a few comparisons, no signature validation, input verification, or searches for double-spend attempts. Also, if blobs have priority over transactions, they would have almost no overload lag (no waiting for transactions to be processed). Blocks should have priority over blobs since those blobs are orphaned anyway (if they are not already included in the block) since honest miners never mine from a block that already has descendants.
#5
One improvement that can simplify the whole "hash matching" thing:
The blobs are numbered in the merkle tree by the miner (a distinct 16 bit string is assigned to each one before hashing), and if the lump's hash ends in an included index, the lump is a block and the blob with that index is the "winning blob." The strings must somehow be assigned before hashing (to avoid a miner favouring his/her own blobs) and some safeguard must prevent repeating the same lump with different indexes.
This achieves the same as in the previous post, but avoids the problem of conflicting blobs.
Also, you may be asking, "how is this better then all those ultra-fast scam-coins?," the answer is that the finely chopped proof of work (lumps and blocks are equally weighted) increases security (security starts increasing quickly after the first confirmation) while the lack of conflict between blobs prevents extensive branching.
I am not sure if rewards should be issued for each lump (more lumps confirmed=more reward for block and winning lump), or a constant amount (more blobs confirmed-> easier block mining but same block reward), in each case, an average miner gets half his/her revenue from blobs and half from blocks.
An attacker who withholds blobs, loses in the cases where someone else mines a block with this blob the winner, and as far as I know gains close to nothing in return.
An attacker who rejects blobs, loses in the case he/she mines a potential block if the other blocks were included, has the same chance af winning the block, this is equivalent to discarding finished blocks.
One improvement that can simplify the whole "hash matching" thing:
The blobs are numbered in the merkle tree by the miner (a distinct 16 bit string is assigned to each one before hashing), and if the lump's hash ends in an included index, the lump is a block and the blob with that index is the "winning blob." The strings must somehow be assigned before hashing (to avoid a miner favouring his/her own blobs) and some safeguard must prevent repeating the same lump with different indexes.
This achieves the same as in the previous post, but avoids the problem of conflicting blobs.
Also, you may be asking, "how is this better then all those ultra-fast scam-coins?," the answer is that the finely chopped proof of work (lumps and blocks are equally weighted) increases security (security starts increasing quickly after the first confirmation) while the lack of conflict between blobs prevents extensive branching.
I am not sure if rewards should be issued for each lump (more lumps confirmed=more reward for block and winning lump), or a constant amount (more blobs confirmed-> easier block mining but same block reward), in each case, an average miner gets half his/her revenue from blobs and half from blocks.
An attacker who withholds blobs, loses in the cases where someone else mines a block with this blob the winner, and as far as I know gains close to nothing in return.
An attacker who rejects blobs, loses in the case he/she mines a potential block if the other blocks were included, has the same chance af winning the block, this is equivalent to discarding finished blocks.
Idea #5
Somewhat like Lumpcoin, only instead of a random lump being the block, the block is determined as follows.
Each lump looks like this:
Version Difficulty PreviousBlockHash MinerAddress Timestamp TransactionRoot BlobRoot Nonce
The hash looks like this:
000...determined by difficulty...000XXX...A bunch of bits...XXXYYY...Last N bits...YYY
Each lump has a certain value for the last few bits of the hash (maybe N=16 bits), determined after it is mined, to make a block, the lump must contain a blob with the same value.
So, for example:
Hash of lump 1 ends in ...1101 1110 0110 1111
Hash of lump 2 ends in ...1100 1010 1110 1100
Hash of lump 3 ends in ...1011 0011 1000 1100
Hash of lump 4 ends in ...1110 0100 0011 1000
Hash of lump 5 ends in ...0011 1100 1110 0110
Hash of lump 6 ends in ...1101 1000 0100 1001
Hash of lump 7 ends in ...1010 1011 1000 1101
Hash of lump 8 ends in ...1100 1010 1101 0101
Hash of lump 9 ends in ...1011 0011 1000 1100
Notice that 3 ends in the same bits as 9, this gives 9 the right to be a block, and be broadcast with the entire blob tree (the presene of 3 in the blob tree proves 9 is a block) and transaction tree (otherwise, only the roots are broadcast).
The block confirms new transactions and is added to the chain.
Each lump generates a reward (new coins!) and all those coins are collected, transaction fees are added on, and the result split (evenly?) between the winning blob address and the block address.
If N=16 and lumptime is 1 second, in theory, the average block time is 321.349 seconds, however, there is network latency.
The reward system can be the one mentioned in my original LumpCoin thread (link in first reply).
I believe this is reasonably robust against selfish mining and ping time advantages, one question that remains is:
What to do if two lumps with the same hash value occur in quick succession (neither contains the other)?
If this post is confusing or not comprehensive, I will edit it.
Somewhat like Lumpcoin, only instead of a random lump being the block, the block is determined as follows.
Each lump looks like this:
Version Difficulty PreviousBlockHash MinerAddress Timestamp TransactionRoot BlobRoot Nonce
The hash looks like this:
000...determined by difficulty...000XXX...A bunch of bits...XXXYYY...Last N bits...YYY
Each lump has a certain value for the last few bits of the hash (maybe N=16 bits), determined after it is mined, to make a block, the lump must contain a blob with the same value.
So, for example:
Hash of lump 1 ends in ...1101 1110 0110 1111
Hash of lump 2 ends in ...1100 1010 1110 1100
Hash of lump 3 ends in ...1011 0011 1000 1100
Hash of lump 4 ends in ...1110 0100 0011 1000
Hash of lump 5 ends in ...0011 1100 1110 0110
Hash of lump 6 ends in ...1101 1000 0100 1001
Hash of lump 7 ends in ...1010 1011 1000 1101
Hash of lump 8 ends in ...1100 1010 1101 0101
Hash of lump 9 ends in ...1011 0011 1000 1100
Notice that 3 ends in the same bits as 9, this gives 9 the right to be a block, and be broadcast with the entire blob tree (the presene of 3 in the blob tree proves 9 is a block) and transaction tree (otherwise, only the roots are broadcast).
The block confirms new transactions and is added to the chain.
Each lump generates a reward (new coins!) and all those coins are collected, transaction fees are added on, and the result split (evenly?) between the winning blob address and the block address.
If N=16 and lumptime is 1 second, in theory, the average block time is 321.349 seconds, however, there is network latency.
The reward system can be the one mentioned in my original LumpCoin thread (link in first reply).
I believe this is reasonably robust against selfish mining and ping time advantages, one question that remains is:
What to do if two lumps with the same hash value occur in quick succession (neither contains the other)?
If this post is confusing or not comprehensive, I will edit it.
#2 #3 #4
All three ideas, specially #4, are off topic, I edited (added last line to) the first post to address that.
All three ideas, specially #4, are off topic, I edited (added last line to) the first post to address that.
Jump to: