Bitcoin Forum
December 11, 2017, 02:35:30 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: Building the Next Generation of Crypto-Currency (developers required)  (Read 23202 times)
aaaxn
Full Member
***
Offline Offline

Activity: 224



View Profile WWW
June 06, 2013, 12:14:49 PM
 #61

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow
I would add that application have typically only small portion of code which must be really optimized (in bitcoin it is probably tx verification) and if our coin would become so widely used so that would become bottleneck this small part can always be rewritten in C without modifying anything else.

But that's the whole idea of the proof-chain. You can verify the proof-of-work without needing the whole block.
Of cause if you start mining the next block and you just have the previous proof-cell and not the transactions, you could only include transactions which are not very old to be sure that they were not already included in the previous block.
Yes you can verify proof of work, but you cannot verify what node was working on Wink
If you don't know which tx were included in previous block you cannot verify if tx is valid (maybe account was emptied in previous block?) and you don't have previous ledger state so cannot compute new ledger state for next block.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Anon136
Legendary
*
Offline Offline

Activity: 1344



View Profile
June 06, 2013, 12:20:59 PM
 #62

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.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
aaaxn
Full Member
***
Offline Offline

Activity: 224



View Profile WWW
June 06, 2013, 12:24:49 PM
 #63

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.
Blockchain bloat is not only about storage. Every node must verify every tx ever done from block 0 in order to synchronize with network it can take a lot of time. As for tps limit I think we can make single transaction significantly smaller than in bitcoin (2-3x reduction for average tx) so we can get more tps with same block size limit.
cunicula
Hero Member
*****
Offline Offline

Activity: 798


Stack-overflow Guru


View Profile WWW
June 06, 2013, 12:55:20 PM
 #64


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.

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        AltCoinInternalExperts                Get Your Altcoin Promoted On Social Media       
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


electronic [r]evolution


View Profile WWW
June 06, 2013, 12:57:53 PM
 #65

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow


Yes, it is certainly a problem.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:01:58 PM
 #66

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.
The Bitcoin client is artificially limited to 7 tps because of blockchain bloat. If the transaction rate was much higher the blockchain would grow extremely quickly and no one would be able to handle the growth. But with a mini-blockchain which is trimmed we don't have to worry about that problem so much and we can increase the transaction rate by a lot. And also as aaaxn mentioned, each transaction should be reasonably smaller in size.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
lexxus
Sr. Member
****
Offline Offline

Activity: 322


View Profile
June 06, 2013, 01:12:07 PM
 #67

Any little change can cause some serious bugs. And we are not planning to do little changes.
That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow


Yes, it is certainly a problem.

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

1. It's almost the same speed as C/C++ (worst case it's 3x slower only)
2. It's objectively the most secure, battle-hardened, portable virtual machine ever created
3. It has a huge set of libraries to boost the development (p2p, cryptography, UI, etc)
4. It supports a lot of languages Java, Scala, Clojure, JRuby, etc.


bitfreak!
Legendary
*
Offline Offline

Activity: 1535


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:23:58 PM
 #68

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Full Member
***
Offline Offline

Activity: 224



View Profile WWW
June 06, 2013, 01:30:46 PM
 #69

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
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.
lexxus
Sr. Member
****
Offline Offline

Activity: 322


View Profile
June 06, 2013, 01:35:03 PM
 #70

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
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.

There is also http://code.google.com/p/bitcoinj/


Quote
bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.
bitfreak!
Legendary
*
Offline Offline

Activity: 1535


electronic [r]evolution


View Profile WWW
June 06, 2013, 01:49:40 PM
 #71

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:
What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.
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.
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.

There is also http://code.google.com/p/bitcoinj/


Quote
bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.
You do also make a valid point about having to re-write the payment verification part. And I do like the GUI of the MultiBit client (it uses bitcoinj). I would definitely be open to using this because I know it has a lot of testing.

If you guys are really set on making this in Java I could accept using bitsofproof or bitcoinj as long as the other develops who come along agree with it. Personally I would prefer to go with bitcoinj if we did go with one of them.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
scooter
Member
**
Offline Offline

Activity: 100


View Profile
June 06, 2013, 04:15:16 PM
 #72

Java is for chumps. 
FORTRAN 4 EVER!
aaaxn
Full Member
***
Offline Offline

Activity: 224



View Profile WWW
June 06, 2013, 07:26:19 PM
 #73

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.
Anon136
Legendary
*
Offline Offline

Activity: 1344



View Profile
June 06, 2013, 07:33:28 PM
 #74


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

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
lexxus
Sr. Member
****
Offline Offline

Activity: 322


View Profile
June 06, 2013, 07:36:12 PM
 #75

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.
nomailing
Full Member
***
Offline Offline

Activity: 126


View Profile
June 06, 2013, 07:47:50 PM
 #76

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.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
June 06, 2013, 11:19:56 PM
 #77

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

bitfreak!
Legendary
*
Offline Offline

Activity: 1535


electronic [r]evolution


View Profile WWW
June 07, 2013, 07:29:43 AM
 #78

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.

XCN: CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz | BTC: 18MWPVJA9mFLPFT3zht5twuNQmZBDzHoWF
Cryptonite - 1st mini-blockchain altcoin | BitShop - digital shop script
Web Developer - PHP, SQL, JS, AJAX, JSON, XML, RSS, HTML, CSS
aaaxn
Full Member
***
Offline Offline

Activity: 224



View Profile WWW
June 07, 2013, 08:26:03 AM
 #79

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.
cunicula
Hero Member
*****
Offline Offline

Activity: 798


Stack-overflow Guru


View Profile WWW
June 07, 2013, 09:05:58 AM
 #80


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.



▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        AltCoinInternalExperts                Get Your Altcoin Promoted On Social Media       
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!