Bitcoin Forum
December 16, 2017, 05:25:57 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: [ANN] BitEN - bitcoin erlang node  (Read 6630 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
April 01, 2013, 03:35:43 PM
 #81

trying to produce a 100% compatible version of Bitcoin from it is probably still not possible.

Why does the foundation set aside, a couple 100 bitcoins to get someone to document the protocol so 100% compatible clients can be written. What happens when bigger companies want to start developing bitcoin clients that can handle 1 millions of request? I mean right now I even have a hacky Java client that queues commands that I know can be queued and process commands that need to be proceed on the spot. Cause the client was freezing up too much.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
1513445157
Hero Member
*
Offline Offline

Posts: 1513445157

View Profile Personal Message (Offline)

Ignore
1513445157
Reply with quote  #2

1513445157
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513445157
Hero Member
*
Offline Offline

Posts: 1513445157

View Profile Personal Message (Offline)

Ignore
1513445157
Reply with quote  #2

1513445157
Report to moderator
1513445157
Hero Member
*
Offline Offline

Posts: 1513445157

View Profile Personal Message (Offline)

Ignore
1513445157
Reply with quote  #2

1513445157
Report to moderator
1513445157
Hero Member
*
Offline Offline

Posts: 1513445157

View Profile Personal Message (Offline)

Ignore
1513445157
Reply with quote  #2

1513445157
Report to moderator
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 01, 2013, 03:41:03 PM
 #82

There have been many, many threads on this topic. Look at the bitsofproof thread by grau for some long debates on it.

Basically, everyone who has worked on Bitcoin for a long time believes the code is so complicated that it isn't currently possible to document every weird quirk and edge case that must be supported correctly. Every time we think the spec is complete, someone discovers another piece of unexpected functionality or behaviour that then must be incorporated into the description. This leads to the question of how you know you've got it all written down, and precisely enough for re-implementation.

Eventually, you come to realize - wait. We already have a very precise specification of how Bitcoin behaves. That specification has as much detail as you'd ever need, because it's written in C++ and executed directly by the CPU. So if you have a question about the precise manner in which transactions that have invalid SIGHASH_SINGLE flags are treated, the best way to get an answer is just read the code. Then you know for sure. Reading an English language derivative of it means you can never be sure it was totally correct.
r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
April 01, 2013, 04:27:21 PM
 #83

And do you personally feel that keeping bugs in original code forever is the right thing? What's BF stance about it, especially "standardization of bitcoin" being major stated goal?

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 01, 2013, 04:46:34 PM
 #84

We've talked about cleaning up some of them after a hard fork. At the same time, hard forking is (currently) a fairly tricky thing to do, and there's a desire to avoid dumping "everything and the kitchen sink" into a forking event.

The way we seem to be going is - let's try and make hard forking easier and less intimidating. If we prove it can be done without lots of disruption, then suddenly fixing (known) bugs and quirks seems much less risky and lower cost. But it does have to be low cost because, frankly, there just isn't much point in fixing most of them. They aren't dangerous. Did you know the "Referer" field in HTTP is mis-spelled? Well, nobody ever tried to fix it because it's just not worth the hassle.

Even if some of these bugs were resolved and cleaned up, I'm not sure it'd change things much. Like I said, every time we think the "spec" is complete, someone discovers a new and unexpected quirk. So how do you know you got them all? Is C++ really such a terrible language for precisely specifying behaviour? Worse than English?
grau
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
April 01, 2013, 05:17:27 PM
 #85

Eventually, you come to realize - wait. We already have a very precise specification of how Bitcoin behaves. That specification has as much detail as you'd ever need, because it's written in C++ and executed directly by the CPU.

the Satoshi implementation is much much more than needed to describe the behavior crucial for consensus, worse it is a Spaghetti and gets extended with any feature the core dev team thinks fancy to ad. Just think of the latest UDP initiative of jgarzik. Satoshi client is a moving target to other implementations and even to itself as it evolves. Although it is standard by its number of installations, this does not seem to be able to hold, as requirements diverge with more advanced use. All major Bitcoin services use modifications of Satoshi, BitcoinJ (soon bitsofproof) or proprietary implementations of the protocol.

I plead for a standard defined by text, code examples and extensive set of tests. That standard should be derived and often purposefully extracted from Satoshi code but even future versions of Satoshi code should be measured on that testbed.

Wait - this is actually we move toward. The growing list of test cases passed by Satoshi, BitcoinJ and bitsofproof are the building blocks of that new standard!

And YES, the BF should use a lion share of its resources to define the standard set as its first goal at inception.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 01, 2013, 05:25:01 PM
 #86

Sure, I'd love it if the Bitcoin protocol was specified entirely by comprehensive tests. It's just really hard to get there with confidence.

By the way, UDP support isn't merged, it's just a proposal. So that isn't a great example.
grau
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
April 01, 2013, 05:36:25 PM
 #87

Sure, I'd love it if the Bitcoin protocol was specified entirely by comprehensive tests. It's just really hard to get there with confidence.

By the way, UDP support isn't merged, it's just a proposal. So that isn't a great example.

Yes it is hard to get the comprehensive tests, but insisting on the entire Satoshi client as reference is not sustainable.

UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1484


View Profile
April 01, 2013, 05:53:08 PM
 #88

UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.

UDP has the potential to deliver blocks and transactions more rapidly throughout the network.  The former benefits miners, and the latter benefits all bitcoin users.


Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own.
Visit bloq.com / metronome.io
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
grau
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
April 01, 2013, 05:57:52 PM
 #89

UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.
UDP has the potential to deliver blocks and transactions more rapidly throughout the network.  The former benefits miners, and the latter benefits all bitcoin users.

No doubt that it has a potential benefit. It would however have lowest priority on the wish list if ranked by commercial user.

If Satoshi client was not the reference but the reference was independent tests, then such extension was permissible. Now it would compound the problem for minuscule upside.
r.willis
Jr. Member
*
Offline Offline

Activity: 42


View Profile
April 18, 2013, 08:33:15 PM
 #90

Status update:
Implemented parallel blockchain download. For now, only headers are downloaded. Download time ~4 min, CPU-bounded (need to investigate exact cause). Works fine, but not resistant to malicious nodes.
Implemented some EC cryptography in pure Erlang. Slow, but easy to understand/verify.
Switched from OpenVZ to XEN hosting on development node (still 256 MB Ram, but now with swap). Memory usage <30 MB resident, 100 MB virtual.

Plans: download whole blocks and do actual validation. Maintain UTxO set, with rollback capability.

1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ BitEN - Bitcoin Erlang Node
tvbcof
Legendary
*
Offline Offline

Activity: 2352


View Profile
May 02, 2013, 05:53:31 PM
 #91


I am now even more interested in BitEN for this reason

  http://www.paracoin.org/home/depth_l1/network_mesh

Looking forward to updates, but will also be taking these from the repo pretty soon I hope.


Pages: « 1 2 3 4 [5]  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!