Bitcoin Forum
May 06, 2024, 08:48:37 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: [ANN] BitEN - bitcoin erlang node  (Read 6837 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.
r.willis (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 11


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

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?
1715028517
Hero Member
*
Offline Offline

Posts: 1715028517

View Profile Personal Message (Offline)

Ignore
1715028517
Reply with quote  #2

1715028517
Report to moderator
1715028517
Hero Member
*
Offline Offline

Posts: 1715028517

View Profile Personal Message (Offline)

Ignore
1715028517
Reply with quote  #2

1715028517
Report to moderator
In order to achieve higher forum ranks, you need both activity points and merit points.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


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

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
Merit: 1021


bits of proof


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

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
Merit: 1129


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

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
Merit: 1021


bits of proof


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

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: 1596
Merit: 1091


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

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
Merit: 1021


bits of proof


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

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 (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 11


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

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

Activity: 4592
Merit: 1276


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


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.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!