Pages:
Author

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

jr. member
Activity: 42
Merit: 11
March 30, 2013, 10:35:26 AM
#69
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.
full member
Activity: 174
Merit: 100
Posts made Jan-March 2017 are not by me
March 30, 2013, 07:25:57 AM
#68
I sent you a donation btw, just wanted to make sure you saw it. Cool project.
full member
Activity: 196
Merit: 116
Entrepreneur, coder, hacker, pundit, humanist.
March 29, 2013, 02:21:52 AM
#66

Yes, there have been very extensive discussions of payment protocol work recently


Where? Is this on the dev mailing list? Or IRC?
jr. member
Activity: 42
Merit: 11
March 29, 2013, 02:08:31 AM
#65
Discussion is good, but don't protocol change/extension needs to go through BIP procedure?
hero member
Activity: 755
Merit: 515
March 29, 2013, 02:05:54 AM
#64
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)
jr. member
Activity: 42
Merit: 11
March 29, 2013, 01:57:11 AM
#63
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?
hero member
Activity: 755
Merit: 515
March 28, 2013, 04:46:00 PM
#62
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. 
hero member
Activity: 755
Merit: 515
March 28, 2013, 04:41:52 PM
#61
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.

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:
Quote
1    NODE_NETWORK    This node can be asked for full blocks instead of just headers.
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
"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.
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.
jr. member
Activity: 42
Merit: 11
March 28, 2013, 02:33:15 PM
#60
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
jr. member
Activity: 42
Merit: 11
March 28, 2013, 01:04:50 PM
#58
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:
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.
hero member
Activity: 755
Merit: 515
March 28, 2013, 09:06:40 AM
#57
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.
legendary
Activity: 4690
Merit: 1276
March 28, 2013, 03:25:46 AM
#56
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'.

jr. member
Activity: 42
Merit: 11
March 28, 2013, 03:07:58 AM
#55
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.
full member
Activity: 196
Merit: 116
Entrepreneur, coder, hacker, pundit, humanist.
March 28, 2013, 02:04:27 AM
#54
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".
jr. member
Activity: 42
Merit: 11
March 28, 2013, 12:55:34 AM
#53
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).
staff
Activity: 4242
Merit: 8672
March 27, 2013, 11:35:51 PM
#52
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.
full member
Activity: 154
Merit: 100
March 27, 2013, 10:52:07 PM
#51
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.

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.
hero member
Activity: 755
Merit: 515
March 27, 2013, 10:18:54 PM
#50
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 find

It 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.
Pages:
Jump to: