Topic: [ANN] BitEN - bitcoin erlang node (Read 6940 times)
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.
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.
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.
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.
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.
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.
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.
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.
By the way, UDP support isn't merged, it's just a proposal. So that isn't a great example.
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.
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?
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?
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?
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.
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.
Just be aware of the usual warnings. If you produce something that seems to theoretically "work" but doesn't match the behaviour of the C++ client exactly (including bugs), you can get split off the chain or end up being banned by the anti-DoS code.
Over time the documentation has improved a lot, but trying to produce a 100% compatible version of Bitcoin from it is probably still not possible.
Over time the documentation has improved a lot, but trying to produce a 100% compatible version of Bitcoin from it is probably still not possible.
Cool though Erlang is, I'm not sure it has many benefits for something like Bitcoin. Of course you're welcome to disagree. When I look at the causes of inefficiency in the current C++ codebase, it's not clear that the language has anything to do with it. There are various things we could optimise to make propagation of data faster, although it doesn't seem to be Bitcoin's biggest problem at the moment.
I agree that it doesn't solve any efficiency issues or make anything faster (it is hard to beat C++ there). Erlang is very much aimed at reliability, so I'm more hoping for a bulletproof, crashless, seamlessly upgradable implemementation.Functional languages like Erlang or Scala are best suited to create robust multithreaded programs since their patterns avoid mutable objects and side effects. Using such language definitely helps writing thread-safe validation and service of lots of parallel requests.
A Bitcoin node performance however is constrained by block storage and EC signature validation, if you use some low level implementations for those, you get best of both worlds.
This is what I also did in bits of proof using LevelDB (native C++) and plan to use for EC.
Cool though Erlang is, I'm not sure it has many benefits for something like Bitcoin. Of course you're welcome to disagree. When I look at the causes of inefficiency in the current C++ codebase, it's not clear that the language has anything to do with it. There are various things we could optimise to make propagation of data faster, although it doesn't seem to be Bitcoin's biggest problem at the moment.
I agree that it doesn't solve any efficiency issues or make anything faster (it is hard to beat C++ there). Erlang is very much aimed at reliability, so I'm more hoping for a bulletproof, crashless, seamlessly upgradable implemementation.
Well, example version message on the wiki has incorrect checksum - was beating my head against the wall for a hour.
Parsing was really easy (thanks for Erlang binary pattern matching), in this respect docs are ok. It's a little lacking in protocol details like state diagrams, timeouts, mempool algorithms, but I think I'll manage to produce something working (maybe not very compatible) from the spec.
Parsing was really easy (thanks for Erlang binary pattern matching), in this respect docs are ok. It's a little lacking in protocol details like state diagrams, timeouts, mempool algorithms, but I think I'll manage to produce something working (maybe not very compatible) from the spec.
Quote
It seems that there is absolutely no desire by the core dev team to ever have more than one client,
Incorrect. Gavin actively encourages alternative implementations, and I've written two alternate implementations. At least one was linked earlier in this thread.
Yeah you have written two, but the documentation is the worst no outside developers stands a chance, it takes so much time cause you have to do trial and error to get even the simplest connection.
Seems to me Bitcoin's biggest problem at the moment is that there is only one implementation.
Incorrect. There are several implementations.
Quote
It seems that there is absolutely no desire by the core dev team to ever have more than one client,
Incorrect. Gavin actively encourages alternative implementations, and I've written two alternate implementations. At least one was linked earlier in this thread.
... although it doesn't seem to be Bitcoin's biggest problem at the moment.
Seems to me Bitcoin's biggest problem at the moment is that there is only one implementation. It seems that there is absolutely no desire by the core dev team to ever have more than one client, since that would actually require freezing and documenting the protocol long enough and doing interop testing.
So instead, we will continue to have a mono-culture where there is no bitcoin protocol, other than "whatever some specific version of bitcoind currently speaks".
For that reason alone, I think it is important to back this and other project and if necessary completely ignore the developers who have little interest in standardization or interoperability with more than one implementation. "Bitcoin" the standard, should be a protocol, a money API, and a clean, minimal reference implementation, not a chunk of C++ code that does everything from node to GUI.
Of course, the usual answer is: go build it yourself. I notice those who try get shouted down or thwarted by a moving target, because the dev team is off pursuing a new extension, fad or GUI feature, instead of standardizing the existing protocol.
Yeah, let's disagree.
Just wanted to echo Matt's comments here. When he talks about "verifying transactions", that is another way to say "write a full Bitcoin implementation". As many people have discovered, that is a huge amount of very difficult work. If you don't verify transactions then simply connecting to lots of nodes and blasting messages out doesn't actually achieve anything (I know this is unintuitive).
The reason is, as Matt noted, the variance in transaction propagation time doesn't seem to be to do with insufficiently dense connectivity but rather things like not all transactions that are broadcast actually being valid, skew in relay/IsStandard rules, and a few other things (old nodes hurt too but they'll be slowly evicted from the system come May 15th anyway).
Without verifying transactions just echoing them around will result in your nodes eventually getting banned, because connections that send invalid data are assumed to be malicious.
Cool though Erlang is, I'm not sure it has many benefits for something like Bitcoin. Of course you're welcome to disagree. When I look at the causes of inefficiency in the current C++ codebase, it's not clear that the language has anything to do with it. There are various things we could optimise to make propagation of data faster, although it doesn't seem to be Bitcoin's biggest problem at the moment.
The reason is, as Matt noted, the variance in transaction propagation time doesn't seem to be to do with insufficiently dense connectivity but rather things like not all transactions that are broadcast actually being valid, skew in relay/IsStandard rules, and a few other things (old nodes hurt too but they'll be slowly evicted from the system come May 15th anyway).
Without verifying transactions just echoing them around will result in your nodes eventually getting banned, because connections that send invalid data are assumed to be malicious.
Cool though Erlang is, I'm not sure it has many benefits for something like Bitcoin. Of course you're welcome to disagree. When I look at the causes of inefficiency in the current C++ codebase, it's not clear that the language has anything to do with it. There are various things we could optimise to make propagation of data faster, although it doesn't seem to be Bitcoin's biggest problem at the moment.
I like the idea of using the Erlang platform for bitcoin. It sounds like a perfect fit, a safe language aimed at distributed systems.
I received two donations so far: 2013-03-27 and 2013-03-18.
Thank you for your support. I'll spend coins on additional VPS hosting to help people download blocks and toss tx around, once I have verification working.
Thank you for your support. I'll spend coins on additional VPS hosting to help people download blocks and toss tx around, once I have verification working.
Make it three.
I see great potential value in the work you are attempting if Bitcoin ever comes under widespread attack, and have seen erlang used to great effect for complex problems.
I received two donations so far: 2013-03-27 and 2013-03-18.
Thank you for your support. I'll spend coins on additional VPS hosting to help people download blocks and toss tx around, once I have verification working.
Thank you for your support. I'll spend coins on additional VPS hosting to help people download blocks and toss tx around, once I have verification working.
I sent you a donation btw, just wanted to make sure you saw it. Cool project.
Yes, there have been very extensive discussions of payment protocol work recently
Where? Is this on the dev mailing list? Or IRC?
Discussion is good, but don't protocol change/extension needs to go through BIP procedure?
Payment protocol? What's this? Is there BIP or at least discussion thread?
Yes, there have been very extensive discussions of payment protocol work recently, though none of it on bitcointalk (most devs havent tried to use bitcointalk for any real work for....a long time) If you are dealing with a merchant which accepts transactions without waiting for blocks, you should be using a payment protocol (coming probably in 0.9) instead anyway.
Payment protocol? What's this? Is there BIP or at least discussion thread? Do you have some hard data on this? I have some, suggesting otherwise. https://bitcointalksearch.org/topic/transaction-propagation-speed-experimental-results-160326
Note that I didnt say propagation speeds are fast. But that doesn't matter in Bitcoin. I pointed out that the Bitcoin P2P network propagation speeds for blocks doesnt matter all that much since miners tend to (whether they're aware or not) propagate blocks in other ways too. For transactions, you have to wait for blocks before your transaction is confirmed anyway, so transaction propagation speed isnt really relevant. If you are dealing with a merchant which accepts transactions without waiting for blocks, you should be using a payment protocol (coming probably in 0.9) instead anyway. Matt Corallo, thank you for your kind words.
What if I want not 100, but 1000 incoming connections - can I open 10 (100, 1000) listening ports and announce all of them via addr messages - will it increase likelihood of other peers selecting me as their peer or would it fail due to binning? Or is the only viable alternative getting more IPs from different bins?
Yes, this would fail due to binning.What if I want not 100, but 1000 incoming connections - can I open 10 (100, 1000) listening ports and announce all of them via addr messages - will it increase likelihood of other peers selecting me as their peer or would it fail due to binning? Or is the only viable alternative getting more IPs from different bins?
As for verification, I'm planning to do full verification eventually.
If you just want things to work for now, you can of course use a bitcoind with only two connections to localhost to do the verification for you. Or if you really hate bitcoind, there are multiple other implemented full verification engines you could use for that.Actually, the only document I found (wiki) defines it in this manner:
Hmm...let me rephrase, the documents should clearly define NODE_NETWORK as "does full verification and can relay full blocks to you if you ask."Quote
1 NODE_NETWORK This node can be asked for full blocks instead of just headers.
Quote
"Impact of my DDoS tool is very small, as long as only a few people are running my DDoS tool." You see the problem here...
If I wanted to make DDoS tool, I'd make one. I did not ask people to run it, people asked for code. If bitcoin network can be brought down by couple weak PCs, then something needs to be done to "standard client". There I see the problem.
Please define "invalid transaction".
Quote
Furthermore, propagation speed isnt an issue in today's Bitcoin network.
Do you have some hard data on this? I have some, suggesting otherwise. https://bitcointalksearch.org/topic/transaction-propagation-speed-experimental-results-160326
Matt Corallo, thank you for your kind words.
What if I want not 100, but 1000 incoming connections - can I open 10 (100, 1000) listening ports and announce all of them via addr messages - will it increase likelihood of other peers selecting me as their peer or would it fail due to binning? Or is the only viable alternative getting more IPs from different bins?
As for verification, I'm planning to do full verification eventually.
UPD:
Actually, the only document I found (wiki) defines it in this manner:
What if I want not 100, but 1000 incoming connections - can I open 10 (100, 1000) listening ports and announce all of them via addr messages - will it increase likelihood of other peers selecting me as their peer or would it fail due to binning? Or is the only viable alternative getting more IPs from different bins?
As for verification, I'm planning to do full verification eventually.
UPD:
Quote
Actually, the client (and other documents) clearly define
Which documents?Actually, the only document I found (wiki) defines it in this manner:
Quote
1 NODE_NETWORK This node can be asked for full blocks instead of just headers.
Quote
"Impact of my DDoS tool is very small, as long as only a few people are running my DDoS tool." You see the problem here...
If I wanted to make DDoS tool, I'd make one. I did not ask people to run it, people asked for code. If bitcoin network can be brought down by couple weak PCs, then something needs to be done to "standard client". There I see the problem. Yes, I'm aware of possible misuses of my software, and I told about them earlier in the thread. It does not check TX it relies. This is bad, and out-of spec, or is it? (Oh, wait, spec is the Satoshi client code, need to check what it says about it).
Actually, the client (and other documents) clearly define the nServices bit NODE_NETWORK to indicate verification and full node status. Though you may end up relaying crap and getting banned as a DoS'er by full nodes, if you just did SPV verification and relayed without NODE_NETWORK it would technically be within spec (though non-optimal). Verifying TX is my next goal.
Full verification or SPV verification? In any case, that is very good news.There is connection limit (in config.erl, it's 1000 by default). It does have incoming connection support (not limited, counted towards 1000). For it to work, you must configure your external IP in config.erl.
OK, I did not see that it could accept incoming connections, in any case, that is very nice. I would, however, like to point out that the two types of connections represent two completely different purposes:Incoming connections allow you to serve data to other peers who need connections. It helps the network by using your bandwidth to provide relaying.
That said, we cant purely rely on incoming connections because there is no way to know if they are all connections from one attacker. So we make a few outbound connections to make sure we have diversity.
I'd like to note that more outbound connections by everyone does not result in greater propagation speed. It eats /tons/ more bandwidth and you will end up shooting yourself in the foot.
How many nodes does testnet have? I'm interested in maintaining thousands of connections to reduce network diameter and propagation speed. I'm sure network part will work with 10 (or 100) nodes.
Again, attempting to create more connections to reduce network diameter ends up shooting yourself in the foot, it actually wont end up decreasing propagation speed. Furthermore, propagation speed isnt an issue in today's Bitcoin network. Sure, miners want the best propagation speed they can find so they dont mine stale blocks, but the large pools mostly have private peering with other large miners to ensure that it is never a problem for them. P2Pool also relays the minimum data required to relay blocks found to all p2pool nodes in addition to announcing them on the Bitcoin network at the same time, ensuring the blocks get introduced to the Bitcoin network at many points at once. Finally, if you simply allow incoming connections, you will almost always get around a hundred nodes after a day or two, which results in really damn fast relaying for anything you generate.It does not do more than 1 connection per host:port pair, and tries such pairs only once in lifetime. So, impact on each node is minimal (as long there is not many of nodes running my software).
"Impact of my DDoS tool is very small, as long as only a few people are running my DDoS tool." You see the problem here...Again, no one has issues with some of the ideas of this project, its some of its specific implementation details that are broken.
This is really orthogonal, as is the code uses 125x network resources compared to normal node software. That should be changed. Otherwise no big deal.
I think it is very much the problem. Look at the attitude displayed from the very get go, on a thread where someone is contributing code.
Insular is the perfect description, of that response, the attitude of some of the devs and the resulting code.
Where in the spec does it say what the maximum nodes should be? Oh, right - there is no spec. Just the "normal node software".
Off hand I would suspect that 'reducing network diameter and propagation speed' might have a variety of advantages and dev might want to start thinking about the ramifications if this happened to become the 'new normal'.
For now, I'v complied with gmaxwell's suggestion and changed default number of peers to 10.
After verification code is in working shape, we will discuss this once more.
After verification code is in working shape, we will discuss this once more.
This is really orthogonal, as is the code uses 125x network resources compared to normal node software. That should be changed. Otherwise no big deal.
I think it is very much the problem. Look at the attitude displayed from the very get go, on a thread where someone is contributing code.
Insular is the perfect description, of that response, the attitude of some of the devs and the resulting code.
Where in the spec does it say what the maximum nodes should be? Oh, right - there is no spec. Just the "normal node software".
Yes, I'm aware of possible misuses of my software, and I told about them earlier in the thread. It does not check TX it relies. This is bad, and out-of spec, or is it? (Oh, wait, spec is the Satoshi client code, need to check what it says about it).
Verifying TX is my next goal.
There is connection limit (in config.erl, it's 1000 by default). It does have incoming connection support (not limited, counted towards 1000). For it to work, you must configure your external IP in config.erl.
How many nodes does testnet have? I'm interested in maintaining thousands of connections to reduce network diameter and propagation speed. I'm sure network part will work with 10 (or 100) nodes.
It does not do more than 1 connection per host:port pair, and tries such pairs only once in lifetime. So, impact on each node is minimal (as long there is not many of nodes running my software).
Verifying TX is my next goal.
There is connection limit (in config.erl, it's 1000 by default). It does have incoming connection support (not limited, counted towards 1000). For it to work, you must configure your external IP in config.erl.
How many nodes does testnet have? I'm interested in maintaining thousands of connections to reduce network diameter and propagation speed. I'm sure network part will work with 10 (or 100) nodes.
It does not do more than 1 connection per host:port pair, and tries such pairs only once in lifetime. So, impact on each node is minimal (as long there is not many of nodes running my software).
Insular attitudes make insular code which makes fragile and brittle code.
This is really orthogonal, as is the code uses 125x network resources compared to normal node software. That should be changed. Otherwise no big deal.
To be fair, r.willis acknowledged the issue earlier, before he released the code. Perhaps it was the reason he was reluctant to release the source to soon.
Or maybe the plan was indeed to have no verification in order to reduce transaction and block propagation time.
But if it does not verify transactions/blocks it relays, I effectively becomes threat to network, as if there is many such nodes, spammers can use them to amplify their abilities to flood nodes with malformed/fraudulent transactions.
Or maybe the plan was indeed to have no verification in order to reduce transaction and block propagation time.
I am surprised you would discourage code contributions in other languages when the current network is so dangerously mono-culture and susceptible to major problems because of bugs.
No, I totally agree with such sentiment, but there is a difference between doing that and creating something that blindly relays any messages to every peer it can findIt seems to me that bitcoind does a fine job DoS-ing itself every now and then
No disagreement here.and that fact that there are no alternative clients may have something to do with it.
Not sure about this, but I certainly agree it would help prevent some simple attacks. Again, I have to say, I like the idea, it just needs to be modified a bit to avoid being a distributed DOS client.
Writing clients that are capable of relaying tons of verified messages and helping the network is great. But this doesnt actually do that. Making a few outbound connections and listening for tons of inbound connections is hugely useful for the network, the opposite is just a DoS.
You're the CI/jenkins tester for bitcoind, right? Thanks for that, it's a very important contribution.
I am surprised you would discourage code contributions in other languages when the current network is so dangerously mono-culture and susceptible to major problems because of bugs. It seems to me that bitcoind does a fine job DoS-ing itself every now and then, and that fact that there are no alternative clients may have something to do with it.
Insular attitudes make insular code which makes fragile and brittle code.
Writing clients that are capable of relaying tons of verified messages and helping the network is great. But this doesnt actually do that. Making a few outbound connections and listening for tons of inbound connections is hugely useful for the network, the opposite is just a DoS.
Dont be confused, add some basic anti-DoS verification and change one or two constants to limit the maximum outbound connection count and this would be a really awesome project, as-is, however....
Dont be confused, add some basic anti-DoS verification and change one or two constants to limit the maximum outbound connection count and this would be a really awesome project, as-is, however....
So...this is some kind of way to try to DoS bitcoin?
It connects to tons of nodes, eating listening sockets on them all, without listening to add more to the pool.
Does it relay things? It would appear that it relays unchecked objects, so anyone can use a node of this to amplify its bandwidth when attacking the network.
It connects to tons of nodes, eating listening sockets on them all, without listening to add more to the pool.
Does it relay things? It would appear that it relays unchecked objects, so anyone can use a node of this to amplify its bandwidth when attacking the network.
It should be run on testnet, ok. But DoS? Come on!
This is working bitcoin code in a language that scales massively and you're looking the gift horse in the mouth.
If someone wants to DoS bitcoin, there are far easier ways to do it, all of which won't succeed or do much for long. None that involve this much coding effort.
So...this is some kind of way to try to DoS bitcoin?
It connects to tons of nodes, eating listening sockets on them all, without listening to add more to the pool.
Does it relay things? It would appear that it relays unchecked objects, so anyone can use a node of this to amplify its bandwidth when attacking the network.
It connects to tons of nodes, eating listening sockets on them all, without listening to add more to the pool.
Does it relay things? It would appear that it relays unchecked objects, so anyone can use a node of this to amplify its bandwidth when attacking the network.
Interested. Sorry for the spam, but I would rather have thread updates as replied vs. watchlist.
Start time..2013.03.27 22:50:33 UTC
Cur time....2013.03.27 23:29:55 UTC
Connects:...3281
Connected:..1199
Accepted:...24
Answers:....1197
Cur peers...1001
Relayed TX:.204155
Mempool:
inv table..49
req table..20
tx table...571
peer table.49
check inv..0.0003 s
clean inv..0.0002 s
clean req..0.0001 s
clean tx...0.0005 s
Errors:
timeout:...1612
refused:...289
unreach:...167
other:.....5
No signs of lags, etc. This is on my low-end VPS with 256 MB RAM without swap.
Cur time....2013.03.27 23:29:55 UTC
Connects:...3281
Connected:..1199
Accepted:...24
Answers:....1197
Cur peers...1001
Relayed TX:.204155
Mempool:
inv table..49
req table..20
tx table...571
peer table.49
check inv..0.0003 s
clean inv..0.0002 s
clean req..0.0001 s
clean tx...0.0005 s
Errors:
timeout:...1612
refused:...289
unreach:...167
other:.....5
No signs of lags, etc. This is on my low-end VPS with 256 MB RAM without swap.
I think I fixed it.
Please test. Pull latest version, recompile, then:
Later I'll add copy of erlsha2 library to my repository.
Please test. Pull latest version, recompile, then:
Code:
git clone git://github.com/vinoski/erlsha2.git
cd erlsha2
rebar compile
cd /path/to/biten
erl -pa ebin -pa /path/to/erlsha2/ebin
application:start(sasl).
application:start(biten).
Do not think he will be impressed - it's my first "real" OTP project. I hope it will be able to run more than 24h without problems - right now after 2-3 hours it terminates.
He is impressed when people know about and try to use erlangOTP. Heck, I'm impressed too.
Working code. That's all that matters. The rest is only a matter of time. Thank goodness Linus didn't say: It's only a floppy driver a screen driver and a kernel that keeps crashin, I'd better not show it to anyone until it's "ready". I downloaded that "piece of shit" in 1993 on 210 floppy disks. I hear Linux turned out ok.
Code:
5> Start time..2013.03.27 20:44:01 UTC
Cur time....2013.03.27 21:18:05 UTC
Connects:...61110
Connected:..433
Accepted:...1
Answers:....433
Cur peers...320
Relayed TX:.37001
Mempool:
exception: exit:{timeout,{gen_server,call,[mempool,get_stats]}}
Errors:
timeout:...24231
refused:...3412
unreach:...1873
other:.....30466
Quote
same here, it just dies...
Can you show output ofstat:print() ~5 min and ~30 min after start?
Code:
Start time..2013.03.27 20:44:01 UTC
ok
Cur time....2013.03.27 20:45:22 UTC
Connects:...2190
4> Connected:..149
Accepted:...0
Answers:....149
Cur peers...131
Relayed TX:.482
Mempool:
inv table..111
req table..10
tx table...119
peer table.111
check inv..0.0168 s
clean inv..0.0005 s
clean req..0.0001 s
clean tx...0.0006 s
Errors:
timeout:...167
refused:...160
unreach:...91
other:.....762
Quote
same here, it just dies...
Can you show output ofstat:print() ~5 min and ~30 min after start?
Do not think he will be impressed - it's my first "real" OTP project. I hope it will be able to run more than 24h without problems - right now after 2-3 hours it terminates.
same here, it just dies... 
Do not think he will be impressed - it's my first "real" OTP project. I hope it will be able to run more than 24h without problems - right now after 2-3 hours it terminates.
$ git clone git://github.com/r-willis/biten.git
ON IT!
I'm meeting a real ErlangOTP *expert* (phds, patents, the whole 9) next week who recently got interested in bitcoin. Perfect timing to introduce your code...
Good luck with your exams.
thank you 
Quote
It seems like there are some malicious nodes on the network, which send thousands of inv messages. As biten have no anti-DoS features, it causes memory exhaustion and erlang VM termination. I hope to push quick-fix today.
they are not malicious, just stress testing the network. 
Good luck with your exams.
It seems like there are some malicious nodes on the network, which send thousands of inv messages. As biten have no anti-DoS features, it causes memory exhaustion and erlang VM termination. I hope to push quick-fix today.
P.S. I decided to drop extra "T" from name, so it's biten.
EDIT: pushed some fixes and improvements.
Next: download block headers and organize them into trees.
It seems like there are some malicious nodes on the network, which send thousands of inv messages. As biten have no anti-DoS features, it causes memory exhaustion and erlang VM termination. I hope to push quick-fix today.
P.S. I decided to drop extra "T" from name, so it's biten.
EDIT: pushed some fixes and improvements.
Next: download block headers and organize them into trees.
So, anyone tried it? Does it even work for you?
no, i have exams. if i begin playing with bitten, i gonna fail them...
So, anyone tried it? Does it even work for you?
You should check twitcoin.net also implemented a bitcoin wallet in erlang
no it does not, in only interfaces with bitcoind
Thanks for the link, I'll check it.
You should check twitcoin.net also implemented a bitcoin wallet in erlang
Awesome! 
code perving now.
code perving now.
Thank you for your support.
Please check how it works yourself. There is no documentation (and almost no comments), no tests.
There are some lurking bugs, but it mostly works. Codebase is really small (~1000 lines + ~500 lines SHA2 by third-party), so do not expect much.
Some tunable parameters (build-time) in include/config.erl
$ git clone git://github.com/r-willis/biten.git
than check README for instructions.
UPD: here is one-liner for updating stats every 10 sec:
3> T1 = timer:apply_interval(10*1000, stat, print, []).
Please check how it works yourself. There is no documentation (and almost no comments), no tests.
There are some lurking bugs, but it mostly works. Codebase is really small (~1000 lines + ~500 lines SHA2 by third-party), so do not expect much.
Some tunable parameters (build-time) in include/config.erl
$ git clone git://github.com/r-willis/biten.git
than check README for instructions.
UPD: here is one-liner for updating stats every 10 sec:
3> T1 = timer:apply_interval(10*1000, stat, print, []).
Thanks for testing. Can you also test if getdata works properly with transasctions?
Also, can you explain about inv and anonymity? For now I send inv to all peers when I get new tx.
i don't know, think its only meaningful to do it when you are also sending your own transactions, blending you own in with others.Also, can you explain about inv and anonymity? For now I send inv to all peers when I get new tx.
the satoshi client sends them in groups.
getdata seems to work fine.
Code:
__main__ - connecting to 192.210.207.147:8333
__main__ - connected to 192.210.207.147:8333
__main__ - sending version to
__main__ - recvived version from
{'nonce': 3571260833056950700, 'finalblock': 212672, 'sender': {'services': 1, 'ip': '0.0.0.0', 'port': 0}, 'version': 60002, 'time': 1355854353, 'services': 1, 'useragent': '/ebtcd:0.0.1/', 'type': 'version', 'reciever': {'services': 1, 'ip': '0.0.0.0', 'port': 0}}
__main__ - sending verack to
__main__ - recvived verack from
__main__ - recvived addr from
{'type': 'addr', 'addrs': [{'services': 1, 'timestamp': 1364132948, 'port': 8333, 'ip': '192.210.207.147'}]}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '8d9efc6660ca76282198f71a8b21936b98e419630672ad54b51f0e467844c3da'}], 'type': 'inv'}
__main__ - sending getdata to
__main__ - recvived tx from
__main__ - got tx: 8d9efc6660ca76282198f71a8b21936b98e419630672ad54b51f0e467844c3da
{'inputs': [{'script': u'483045022100ceb6b8a311b8a14d3930dc004ce4ff6dda34beda87c21f19046c82361b1604b802200887b99e45626b87e522a0badca447a6c19ee64e9741b6134eb62428df1cf5d00141049a20d6a2eb15336c1622b9498183d18c0c5ab1aa685f1a09612a4c6c242809850321a944ef01b133aceb6022bef2aa16d5d036a75c4b3d601e5b553a32d8f566', 'outpoint': {'index': 0, 'tx': 'a5930653e67df69033299b8fb9570212b07ffb620d02b509c3d220acec793896'}, 'sequence': 4294967295}, {'script': u'493046022100be02b679976e7aebe165b8d4bcd3bbbdbbd45970f8832416e299942cd2280be9022100aa96403e5a93ebebb0508e933d7473414f1a6a5f4c61289fdb51e577f688bc8b0141049a20d6a2eb15336c1622b9498183d18c0c5ab1aa685f1a09612a4c6c242809850321a944ef01b133aceb6022bef2aa16d5d036a75c4b3d601e5b553a32d8f566', 'outpoint': {'index': 1, 'tx': '1211f69fb8ca81ea8e4480e58eb90bb9ef411e02feca506ab8c326311b54d47a'}, 'sequence': 4294967295}, {'script': u'47304402200099e0ee8e79392ccee8e5f26c05ae55f5708962994319f258cd16f1690f5f2d022061bf3e0e9c72180719b5f8bbac840f7ff64ed48de234b6e681cad2fdeb09b73a0141049a20d6a2eb15336c1622b9498183d18c0c5ab1aa685f1a09612a4c6c242809850321a944ef01b133aceb6022bef2aa16d5d036a75c4b3d601e5b553a32d8f566', 'outpoint': {'index': 0, 'tx': 'e52cd1077b757833251292422f5dcf9163f9617dbdeb8e7046afd5bb2693ee7d'}, 'sequence': 4294967295}], 'locktime': 0, 'version': 1, 'outputs': [{'amount': 22230000, 'script': u'76a91465c44378dca92c950c63d4fb6f977af0e5160ceb88ac'}, {'amount': 13624834, 'script': u'76a914e2737bad9136729f77388e07b45fbdf9d796b16288ac'}]}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '56b3b0fff13bf3fee18c895864e2fd8ee14486c81a10fec10f28441e4ebc8597'}], 'type': 'inv'}
__main__ - sending getdata to
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '449c5f1e0a3612099f5cea95957a08bf61ed611ba4f3498742568c6fbb5c56ca'}], 'type': 'inv'}
__main__ - sending getdata to
__main__ - recvived tx from
__main__ - got tx: 56b3b0fff13bf3fee18c895864e2fd8ee14486c81a10fec10f28441e4ebc8597
{'inputs': [{'script': u'47304402205486ae189aeea4eb338881b0c626a4d0eda9f00a5fba31309a75cddb8b3f8b3a02207948a13ba612985f86c2f8189ce2aaffe1df91aab8780c8a9d61f9379ef919080141048cc0b94178715f03ed3d0bceb368191d0fdd7fc16d806567f6f2c45aecafb8f53e5ef849564072189b9b4f8bfe1564da776567ba359cfb0c05e839bcf65371ab', 'outpoint': {'index': 1, 'tx': '43613865df3c6aba0a25e6e5d19681c23f0e84d9246dc75ad8cfe85c9f404689'}, 'sequence': 4294967295}, {'script': u'493046022100fa3f82633d1f581d597949c5ffe80bb9491c7ac3c3c843c8d0ebd1a753782ba0022100addfa96baf88c4f7a5cf951cc691b497e5431ed0f98920e39fefb24c1d34a448014104e9147ece1c26d3319f6b7b5dbad45ab33429f77668857b9b4f3c7422632d6794a826c8e89791c6a2efb7fc4f2e1b3428a10e470315ff096a547f2e3bf91703e6', 'outpoint': {'index': 1, 'tx': '97f979a98c403555d840c70887a9b547671d4666f10b0650b3b7de2475e04c81'}, 'sequence': 4294967295}], 'locktime': 0, 'version': 1, 'outputs': [{'amount': 40076960, 'script': u'76a914d2f0ad0cbbbbca9a9697de43629e38d9a40ebb7688ac'}, {'amount': 125654756, 'script': u'76a914e8c753e1d147dc1594f60033239d982e9e373a4188ac'}]}
__main__ - recvived tx from
__main__ - got tx: 449c5f1e0a3612099f5cea95957a08bf61ed611ba4f3498742568c6fbb5c56ca
{'inputs': [{'script': u'483045022100c823fe360e8ec170d3f7807f779217cc73b4df815114eb20d4ff3501292546f902204f26b4a9995dc591d1d9edd5e08ef643a0ceb3274c4c0de759d32c8bcc7b49bf01210293d3f89b799d0d85ee68753853aba3a8dc9f3eac82ac3f7a002cfac165aeb824', 'outpoint': {'index': 1, 'tx': '1d5a9eb96afb43e69de6e7391910304191742b4b1b517e4bdd5992e8143de07f'}, 'sequence': 4294967295}], 'locktime': 0, 'version': 1, 'outputs': [{'amount': 7950000, 'script': u'76a914e074a32f36dbafe229f8ae8c730615d62f48b40d88ac'}, {'amount': 8000000, 'script': u'76a91406f1b6703d3f56427bfcfd372f952d50d04b64bd88ac'}]}
Thanks for testing. Can you also test if getdata works properly with transasctions?
Also, can you explain about inv and anonymity? For now I send inv to all peers when I get new tx.
Also, can you explain about inv and anonymity? For now I send inv to all peers when I get new tx.
my log:
you should group your invs to improve anonymity and save bandwidth. only sending a inv once a 5 second.
Code:
__main__ - connecting to 192.210.207.147:8333
__main__ - connected to 192.210.207.147:8333
__main__ - sending version to
__main__ - recvived version from
{'nonce': 11750267548999325335L, 'finalblock': 212672, 'sender': {'services': 1, 'ip': '0.0.0.0', 'port': 0}, 'version': 60002, 'time': 1355854353, 'services': 1, 'useragent': '/ebtcd:0.0.1/', 'type': 'version', 'reciever': {'services': 1, 'ip': '0.0.0.0', 'port': 0}}
__main__ - sending verack to
__main__ - recvived verack from
__main__ - recvived addr from
{'type': 'addr', 'addrs': [{'services': 1, 'timestamp': 1364119710, 'port': 8333, 'ip': '192.210.207.147'}]}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '8b8f619892f0c673947721ac850a82739abe7e7908a76519af1ca373e72a0e5e'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'd0db4c6499740c10cf7e5b39fe5d92d1983bc53f0c25ffbcab92636d4d73f6a1'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '6a05170eb01f8bcacf42ccec6a397f1fdc160fa152859d9cfe450ab32954c5bc'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'e4564170c2bbb448934184643cac1aacb0113befe0f0be46db1c06f346959e36'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '97108906ba10ee3ba04eebb8af465dccec3412fdd88be6e8c3bc812f396a8a67'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'b5ecd365f85b9850310e14848d5d139545243d5f34a12dc4fc92b9a22d83edb9'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '98aa22cdadeb60ab539a1e99225a39117d068f70f2c64f869edb0f2d20c55faf'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '1fc9cf75c25f0f669331cb5acaea00f6daafea2f9bde43e4033723957a63f380'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'da14d97f6c95bff17e693b0f87fe2caf1c56b1cda2f1a93170cbf56efed8fc93'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'a883d7aa04e0db9539ef0631795277bf983ed78e1aa0b9d3aad922a4a14e566f'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'e32ebbae43fc0d7dd665a9d8e71b893a16393a2e35b5995078d45c7c87f8a8d8'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'a9ee0df7375396834bb9fd78adbb93a024127feddd4aa0c8f12bf03b54bde1e3'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'f7cc5a5011c1ad73310eb010989d64a3970f1e2b96520997c051a7de5275f7c4'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '107ff21c6a6d69ac9f3208084e9fcfdbb96d6917169371dd0314bb6575e2aaf4'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': 'acd3dcd564cdc7c4dde43cd0b69a5fbf4fd6f702167d957dfcee9432c6b89478'}], 'type': 'inv'}
__main__ - recvived inv from
{'objs': [{'objtype': 1, 'hash': '8a936cad5c3d820627d8e7eb6caf0a31fe8c36202acbf1963f148c1133411211'}], 'type': 'inv'}
you should group your invs to improve anonymity and save bandwidth. only sending a inv once a 5 second.
I really like BITTEN/BITEN. Release is coming.
Can anybody check 198.23.147.4:8333 and tell me if tx relaying works ok?
After handshake, host wll notify peers with inv and respond to getdata (type 1 (tx) only).
Can anybody check 198.23.147.4:8333 and tell me if tx relaying works ok?
After handshake, host wll notify peers with inv and respond to getdata (type 1 (tx) only).
Maybe the name Erlnode
Bite BITcoin Erlang
BED = Bitcoin Erlang Daemon, nice and simple.
Usage: "Hey Carla, we're running "BED", are you using bitcoin-js at your startup?"
BITTEN : BITcoin Erlang Node
without acronyms:
The Bitscale Node - Makes Bitcoin Scale
CoinOTP
BED = Bitcoin Erlang Daemon, nice and simple.
Usage: "Hey Carla, we're running "BED", are you using bitcoin-js at your startup?"
BITTEN : BITcoin Erlang Node
without acronyms:
The Bitscale Node - Makes Bitcoin Scale
CoinOTP
System is live at 192.210.207.147:8333
Accepts connection and does handshake. Nothing fancy yet. Transaction routing and block download/serving are next.
Accepts connection and does handshake. Nothing fancy yet. Transaction routing and block download/serving are next.
It's hilarious... I'll consider it.
Before github, I need cool name for project. Any ideas?
"The first and only true bitcoin erlang deamon" or TFAOTBED?How about:
The Committee for the Liberation and Integration of Terrifying Organisms and their Rehabilitation Into Society
CLITORIS
(had to, sorry
) Before github, I need cool name for project. Any ideas?
"The first and only true bitcoin erlang deamon" or TFAOTBED?
Before github, I need cool name for project. Any ideas?
Conversion to OTP mostly done.
Plans for tomorrow: limit rate at which outgoing connections are created. After this, accept incoming connections and advertise own address via addr message.
Plans for tomorrow: limit rate at which outgoing connections are created. After this, accept incoming connections and advertise own address via addr message.
and then: github
Conversion to OTP mostly done.
Plans for tomorrow: limit rate at which outgoing connections are created. After this, accept incoming connections and advertise own address via addr message.
Plans for tomorrow: limit rate at which outgoing connections are created. After this, accept incoming connections and advertise own address via addr message.
i am also devloping a bitcoin client, pycoin. although i have not done much lately on it.
If you like python, check out https://github.com/jgarzik/python-bitcoinlib/ and the bitcoin client that uses it, https://github.com/jgarzik/pynode/
I'm trying to encourage everyone to use python-bitcoinlib for their python projects. It fully verifies the blockchain, and passes many reference client tests.
Very interesting.
You should open source even if it is early stage, please! I'd love to
I've done some Erlang and OTP and I'm looking at core-daemon (full node) implementations.
Don't be shy, open it!
You should open source even if it is early stage, please! I'd love to
I've done some Erlang and OTP and I'm looking at core-daemon (full node) implementations.
Don't be shy, open it!
i am also devloping a bitcoin client, pycoin. although i have not done much lately on it.
If you like python, check out https://github.com/jgarzik/python-bitcoinlib/ and the bitcoin client that uses it, https://github.com/jgarzik/pynode/
I'm trying to encourage everyone to use python-bitcoinlib for their python projects. It fully verifies the blockchain, and passes many reference client tests.
And that Python, generally, is cool.
i am also devloping a bitcoin client, pycoin. although i have not done much lately on it.
If you like python, check out https://github.com/jgarzik/python-bitcoinlib/ and the bitcoin client that uses it, https://github.com/jgarzik/pynode/
I'm trying to encourage everyone to use python-bitcoinlib for their python projects. It fully verifies the blockchain, and passes many reference client tests.
If you think so, I can implement routing and release code. Let's stress-test network.
I think on 8Gb (right now, without optimisations) machine daemon can connect to every connectable node in network (I estimate it's around 60k peers) + some incoming connections.
I think on 8Gb (right now, without optimisations) machine daemon can connect to every connectable node in network (I estimate it's around 60k peers) + some incoming connections.
i don't think so... the satoshi client have some ban system, if your node began to send malformed txs they would just disconnect from your node.
Of course it has, but it but before it kicks in, you can spend several megs of some someone's bandwidth. Multiply by some thousands peers, and by number of servers (whatever it is). I just not very comfortable with this.i am also devloping a bitcoin client, pycoin. although i have not done much lately on it.
i don't think so... the satoshi client have some ban system, if your node began to send malformed txs they would just disconnect from your node.
Of course it has, but it but before it kicks in, you can spend several megs of some someone's bandwidth. Multiply by some thousands peers, and by number of servers (whatever it is). I just not very comfortable with this.Keep up, but be prepared for a very long trip.
Yes, I read your thread about bitsofproof. I hope it will be interesting journey. Now it's in the early stage of development. I'm trying to implement protocol not looking into bitcoind source, ...
From this I can tell that this must be really early stage. Keep up, but be prepared for a very long trip.
Unfortunately documentation available is very far from being sufficient input for an implementation, and in Bitcoin world there is no half-way compatibility.
But if it does not verify transactions/blocks it relays, I effectively becomes threat to network, as if there is many such nodes, spammers can use them to amplify their abilities to flood nodes with malformed/fraudulent transactions.
i don't think so... the satoshi client have some ban system, if your node began to send malformed txs they would just disconnect from your node. please make the source public, og remove [ANN] from the thread subject... i was expecting to see awesome code, but was disappointed.
You are right, so [ANN] gone for now.Code is in no way awesome now. It's a bunch of loosely connected modules and processes. Current code is proof-of-concept that you can make "very-well-connected" node on low-end virtual server. Right now I'm converting code to OTP (Erlang framework for robust, industrial-grade applications).
I'd expect code release in a week or two.
Why I (we) want node with many peers? Because it greatly reduces network "diameter", reduces propagation times, helping miners and makes many attacks not feasible.
But if it does not verify transactions/blocks it relays, I effectively becomes threat to network, as if there is many such nodes, spammers can use them to amplify their abilities to flood nodes with malformed/fraudulent transactions.
please make the source public, og remove [ANN] from the thread subject... i was expecting to see awesome code, but was disappointed.
Any chance you going to put it on gihub?
Hello all!
For some time I was working on bitcoin daemon implementation in erlang.
Now it's in the early stage of development. I'm trying to implement protocol not looking into bitcoind source, but using specification from https://en.bitcoin.it/wiki (found one bug so far), original paper and looking at the protocol messages which I get from peers.
My goal is to make scalable bitcoin daemon, capable of serving many thousands of peers on relatively low-end servers.
At current state it's capable of connecting and parsing messages from 3000+ peers on 256M RAM VPS without swap. It does not do much besides protocol parsing and peer discovery now, but it's only several days old. Chances are that it connected to your machine - check for /ebtcd:0.0.1/ user-agent in logs.
Short term pans: accept incoming connections, announce own address via addr message.
Mid term plans: add validation and routing (test on testnet), release source under open license (AGPL sounds good).
Long term: full-featured daemon.
P.S. In case someone wants to encourage me with some BTC, I set up donation adress:
1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ
UPD:
git clone git://github.com/r-willis/biten.git
For some time I was working on bitcoin daemon implementation in erlang.
Now it's in the early stage of development. I'm trying to implement protocol not looking into bitcoind source, but using specification from https://en.bitcoin.it/wiki (found one bug so far), original paper and looking at the protocol messages which I get from peers.
My goal is to make scalable bitcoin daemon, capable of serving many thousands of peers on relatively low-end servers.
At current state it's capable of connecting and parsing messages from 3000+ peers on 256M RAM VPS without swap. It does not do much besides protocol parsing and peer discovery now, but it's only several days old. Chances are that it connected to your machine - check for /ebtcd:0.0.1/ user-agent in logs.
Short term pans: accept incoming connections, announce own address via addr message.
Mid term plans: add validation and routing (test on testnet), release source under open license (AGPL sounds good).
Long term: full-featured daemon.
P.S. In case someone wants to encourage me with some BTC, I set up donation adress:
1GVmS56pvVL7YZA7YqMBXmaDedCoputKuJ
UPD:
git clone git://github.com/r-willis/biten.git
Jump to: