Topic: [ANN] BitEN - bitcoin erlang node - page 2. (Read 6899 times)

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.

I sent you a donation btw, just wanted to make sure you saw it. Cool project.

http://www.mail-archive.com/[email protected]/msg01567.html

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?

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)

Payment protocol? What's this? Is there BIP or at least discussion thread?

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. 

Yes, this would fail due to binning.

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.

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."

I didnt say a few PCs could bring down the network, but the nature of DDoS is that the more PCs you get, the worse you can make things.  And thanks to some properties of bitcoin that we can't change (eg requiring ECDSA verification on things), Bitcoin could be more susceptible to DDoS than other more standard applications.  That said, even BitTorrent can pretty effectively be taken down by a few attackers in a swarm.

Please define "invalid transaction".
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:
Which documents?
Actually, the only document I found (wiki) defines it in this manner:

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.

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).  

Full verification or SPV verification? In any case, that is very good news.

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.

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.

"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.

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.

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).

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.

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 find

No disagreement here.

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.