[THREAD FOR ALTCOIN IDEAS]

[ArcCsch]

This thread is for anyone (newbies included) with new ideas for altcoins, the ideas need not be complete.
If you have a new idea, post Idea #X followed by your idea (edit post to add to it later), otherwise(if you are commenting on an existing idea), just post #X above your comment.
EDIT#1:
The ideas must be related to the development of new altcoins, not how to use them!
EDIT#2:
The purpose of this thread is to provide a repository of ideas to developers aiming to create new altcoins, please do not spam it with frivolous drivel.

[ArcCsch]

Idea #1
I will just provide a link since I already posted it, I may edit this post later.
https://bitcointalk.org/index.php?topic=1625704.0

[BitcoinNational]

Idea #2

The locked box.

An open source project.  
Simple exchange that anyone can install on a server.
Allows alt 2 alt trading.

Intent is to drastically reduce mtGox risk exposure.

There would be a central list of performance rankings.
Then client elects which server to deposit funds.

All withdraws are done via signature (no more email confirmations).
_{Thus only the depositor would ever be able to withdraw.}


Idea #3
Use envelopes containing Litecoin private keys as cash
https://bitcointalk.org/index.php?topic=1636688.0

[Spoetnik]

How about learn before spouting off here noob ?

PS:
@National

If they made a "The Box" coin all these guys would "open it' LOL

Imagine a coin you support for profit but it kills random people.
Would you take the one million cash ?
i bet you all would 

[BitcoinNational]

Idea #4

The Deadman Return.
by Spoetnik

Death Lotto.  Someone must die.  You win!

ps..
Love how Hollywood pre- scripts everything.

pss.
I know the barbarians would always be at the gates.  Thus, open source, any valid node/witness must prove their code.

[ArcCsch]

#2 #3 #4

All three ideas, specially #4, are off topic, I edited (added last line to) the first post to address that.

[ArcCsch]

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.

[ArcCsch]

#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.

[ArcCsch]

#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.

[ArcCsch]

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?

[glerant]

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.

[Cryptotraider16]

yeah,great ideas..lets post more and more..

[ArcCsch]

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.

[ArcCsch]

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?

[ArcCsch]

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.

[rapazev]

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.

[Spoetnik]

You don't need any "ideas" Junior..

There is only one.. currency.

/end

[ArcCsch]

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.

Maybe my statement was ill-stated, what I meant was more like:
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

[shinratensei_]

You don't need any "ideas" Junior..

There is only one.. currency.

/end

Nice dude. A word with thousand mean.

Actually, this will be going outside from his purpose be a digital currency.

[ArcCsch]

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.