Building the Next Generation of Crypto-Currency (developers required)

[bitfreak!]

so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right?

Yeah plenty of household computers in the US could handle it, but the US isn't the world, and we are designing a global crypto-currency which will be used by people all around the world, many of whom will have fairly slow connection speeds, especially upload speeds. One of the benefits of the mini-blockchain scheme is that mining doesn't have to become a highly specialized and centralized industry because almost anyone can handle the size of the mini-blockchain. The aim should be to exclude the minimal amount of nodes possible, meaning we need to take into consideration the connection speeds of people all around the world. So even though many people may be able to handle a huge number of transactions per second will still need to balance it and place a cap on it. This is why I believe a dynamic max block size is necessary, because this isn't something which will remain the same over time. In the future the majority of people will have much faster connection speeds.

[1714159855]

1714159855

[1714159855]

1714159855

[1714159855]

1714159855

[bitfreak!]

The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.

And bitcoinj code is far more documented. My first impression was wrong, bitcoinj seems to be more suited for our needs.

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

[daybyter]

I like Java...but only wrote trading software so far...

[bitfreak!]

I like Java...but only wrote trading software so far...

Well if you've written trading software in Java you should be able to help out with some of the coding, perhaps not the hardest parts but I'm sure there's a lot you could contribute.

BTW I want to thank who ever made that recent donation. When we create a website for the new coin we might need to add a section for recognizing donators.

[aaaxn]

Is 200 kB/s managable? That is like 400 txn per second for transmitting txns. And then blocks of about 100 MB every 10 minutes, so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right? I'm still not understanding the problem.

There is really no need to send full block to network. Most peers have already seen most txns which made it into block so just list of their hashes should be sufficient.

[lexxus]

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

That's an excellent decision.
While you are gathering a team, I will try to create an adhoc performance test for a database/tree-storage of "account tree", i.e. generate 100million accounts, pack in the Merkle tree, store them and run common queries.

Also I really-really wish to make it extendible from the beginning. For example, I think it's not hard to assume that you can have more than "account tree", mini-block chain, etc.

[daybyter]

Create a model for it...

Start with use cases (UML)...

[maco]

Is this your Github? Can I fork off of it to improve some functions and help out?

Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

[bitfreak!]

Is this your Github? Can I fork off of it to improve some functions and help out?

Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

No we haven't set up a main repository yet because we are still deciding on some of the details. If you read through the thread you'll see we decided to go with bitcoinj instead of bitsofproof, so if you want to start anywhere, start by looking at bitcoinj. Hopefully we'll have a repository set up soon so some of you can get to work, we also need to decided on a nice name for the coin before we can set it up.

[BitcoinAshley]

I like the idea of using bitcoinj to start with. Already we are a step up from the myriad bitcoin-qt copycats.

Silly name ideas:
EverCoin (already suggested by another poster, b/c coin is sustainable, forever)
SmallCoin
TinyCoin
LittleCoin
ShortCoin
OneCoin (the one coin, to rule them all!)
Ethercoin (because the rest of the blockchain just vanishes into the ether)
BalanceCoin (b/c entire ledger history is not necessary, just the balance!)

[cunicula]

Added a proposed feature to the netcoin wiki:

http://www.netcoin.io/wiki/Theft_Protection_through_Reversibility_and_Failsafe_Accounts

[lexxus]

Silly name ideas:
EverCoin (already suggested by another poster, b/c coin is sustainable, forever)
SmallCoin
TinyCoin
LittleCoin
ShortCoin
OneCoin (the one coin, to rule them all!)
Ethercoin (because the rest of the blockchain just vanishes into the ether)
BalanceCoin (b/c entire ledger history is not necessary, just the balance!)

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.

[daybyter]

BetterCoin ?
Better Crypto Currency => BCC ?

[r3wt]

if you need a name, how about NanoToken (NNO)

[bitfreak!]

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.

Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.

[moltenmich]

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.

Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the same unless someone thinks of something extremely clever which hasn't been used already.

Why hasn't anyone used the term "credits" yet? Is it because it assumes a debt relationship?  XCC- Exchange Credits sounds so universal tho. 

[bytemaster]

I believe that merged-mining was part of this next-gen crypto-currency,  I would like those following this thread to consider a new approach to scalable merged-mining that allows a 'fixed-size' proof-of-work regardless of the number of chains involved in merged-mining.

https://bitcointalk.org/index.php?topic=230120.0

[bitfreak!]

I believe that merged-mining was part of this next-gen crypto-currency

I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

[bytemaster]

I believe that merged-mining was part of this next-gen crypto-currency

I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

I have read a lot of different papers on this forum, so I may have gotten some parts confused.  I went back to re-read the white paper to check to see what I thought I rememberd and what I was actually thinking of was the 'proof-of-work chain' in this system.   I was suggesting that it could be updated to use the accumulator method to allow any number of 'proofs' to be stored in the same proof-of-work chain and therefore it would be usable by every blockchain out there without increasing the size.

The account tree structure and mini-block-chain approach is 100% the way I think things need to go.   I am attempting to implement a new blockchain and started designing something very similar to the white paper.   So on closer look, I have to give this approach strong backing.   

[bytemaster]

In order to make sure the same signed transaction isn't processed by the network more than
once, the signer of the transaction will need to include in the transaction the hash of any
accounts referenced as inputs for the transaction (we don't need to worry about the outputs
because we have no control over how those accounts change). After the transaction is
applied the accounts will have a different hash and therefore nodes will know not to accept
that same signed transaction again because they can see the account hashes don't match.

The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain.  It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.

To address this issue transactions will need to include an 'initial and final' block number that they may be stored in, then the hash of the transaction must be stored until the 'final' block number in which it will expire to prevent double-spends.   Otherwise you assume all transactions make it into the account any other changes to that account and no one person has control over all changes to an account (after all someone else could send the account funds at the same time you send your trx). 

Conclusion, all transactions must have an expiration block number and must be stored until that date.  This could be as simple as including all transactions in the 'mini-block-chain' until they fall of the end, though I suspect they would only need to be kept around for 48 hours or so.