Pages:
Author

Topic: Building the Next Generation of Crypto-Currency (developers required) - page 7. (Read 23562 times)

legendary
Activity: 1050
Merit: 1003
sr. member
Activity: 448
Merit: 250
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!)


legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
sr. member
Activity: 294
Merit: 250
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.
legendary
Activity: 965
Merit: 1000
Create a model for it...

Start with use cases (UML)...
sr. member
Activity: 309
Merit: 250
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.
sr. member
Activity: 359
Merit: 250
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.
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
legendary
Activity: 965
Merit: 1000
I like Java...but only wrote trading software so far...

legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
legendary
Activity: 1050
Merit: 1003

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.


sr. member
Activity: 359
Merit: 250
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.
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
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.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
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
full member
Activity: 126
Merit: 100
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.
sr. member
Activity: 309
Merit: 250
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.
legendary
Activity: 1722
Merit: 1217

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
sr. member
Activity: 359
Merit: 250
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.
member
Activity: 100
Merit: 10
Java is for chumps. 
FORTRAN 4 EVER!
Pages:
Jump to: