Added a proposed feature to the netcoin wiki:
http://www.netcoin.io/wiki/Theft_Protection_through_Reversibility_and_Failsafe_Accounts
Topic: Building the Next Generation of Crypto-Currency (developers required) - page 7. (Read 23571 times)
June 08, 2013, 02:13:58 AM
June 07, 2013, 06:15:10 PM
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!)
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!)
June 07, 2013, 04:05:43 PM
Is this your Github? Can I fork off of it to improve some functions and help out?
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. 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.
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.
June 07, 2013, 02:49:26 PM
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.
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.
June 07, 2013, 02:09:35 PM
Create a model for it...
Start with use cases (UML)...
Start with use cases (UML)...
June 07, 2013, 09:26:18 AM
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.
June 07, 2013, 09:02:33 AM
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. Plenty of household computers in the US could handle this, right? I'm still not understanding the problem.
June 07, 2013, 06:41:03 AM
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.
June 07, 2013, 06:28:18 AM
I like Java...but only wrote trading software so far...
June 07, 2013, 05:45:01 AM
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. June 07, 2013, 05:07:45 AM
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. Plenty of household computers in the US could handle this, right?
June 07, 2013, 04:05:58 AM
blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.
bandwidth
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.
June 07, 2013, 03:26:03 AM
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. June 07, 2013, 02:29:43 AM
I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.
June 06, 2013, 06:19:56 PM
The problem with blockchain is that when transactions get more and more, the whole network will be stalled due to the same transaction must be broadcasted to the whole network no matter how small they are. I don't see how this new design can prevent that from happening
I agree that recording all the transactions is stupid, should be enough with a ledger of account balance
I agree that recording all the transactions is stupid, should be enough with a ledger of account balance
June 06, 2013, 02:47:50 PM
I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.
June 06, 2013, 02:36:12 PM
I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.I'm neutral between bitsofproof and bitcoinj.
June 06, 2013, 02:33:28 PM
blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.
What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.
bandwidth
June 06, 2013, 02:26:19 PM
I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.
I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us. June 06, 2013, 11:15:16 AM
Java is for chumps.
FORTRAN 4 EVER!
FORTRAN 4 EVER!
Jump to: