Announcing BitcoinUnlimited v0.12.0: Experimental Release

[theZerg]

the txn to your self issue -- or other core criticisms might be best posted as a new topic in the Unlimited forum...

WRT connections, I wonder if the DOS attack (which supposedly is targeted at BU nodes also) affected you. However, my nodes are still up and I added yours to my .conf so you should have gotten a connection from me.

How many connections do you have? I haven't tried lots of entries, but you should still get incoming...

 

[freetrader]

@Christoph Bergmann : I'm currently at 10 Unlimited peers, and my .conf has only 8 addnode statements in it.

Perhaps it's an idea to check in your logfile if you see anything interesting to do with peer behaviour, and if not maybe debug=net could show up something.

Any other parameters (e.g. maxconnections) that you have overridden?

 

[Peter Tschipper]

@Christoph Bergmann Are you running your node on a different port than 8333...I noticed there is one out there from someone on 8334, is that you? If you are running on a different port it will be difficult at first for other nodes to find you.

 

[Christoph Bergmann]

no, port 3334 is closed

I randomly look into my peer-window. Two or three times I discovered the "Why? Fuck you" guy. The unnecessary high number of peers did pop up my upstream, but since I limited it on the shaper, everything's ok. No sign of a dos.

I wonder what happens if I just move to tor? And ... does thinblocks help to run via slow tor? (marketing!)

The problem is more about understanding: If I start with no nodes in the configuration file it connects as slowly, but steady to 8 random nodes. Than it stopps connecting.

If I write nodes (IP) in the confguration file, it connects directly to as much of them as allowed. My maximum have been 100 peers (now I changed it to 8), so it connected to 20/22 "outgoing" peers. Ingoing connections are building slowly up.

I think it's senseles to connect to more than 20 unlimited nodes, since most of you are already. So I changed my peermax to 8. Now I should be connected only with unlimited nodes.

But it's slow to load. Verifying blocks is very (cpu at ~30%). Maybe because i restarted it too often today?

Urg. It's Sunday. What am I doing?

 

[Peter Tschipper]

@Christoph Bergmann You don't really need to connect to more than 8 or so nodes...but to answer you question, if you don't use addnode, the maximum number of outgoing connections in Core has always been hard coded to 8...so no problem there.

Sounds like you got a little DDOS there from mr "Why Fuck You" guy. And you said the rate limiting is working for that, great!

 

[sandakersmann]

Great work!

 

[Peter Tschipper]

@Christoph Bergmann wondering if you're still getting DDOs'd. and also whether you could post the logfile entry from that "why FU guy". There should be something there in the logfile about it.

Also, if you still get regularly DOS'd from him, i'd like you turn turn on debug=net so we can see what he's up to on the applevel, if anything.
[doublepost=1456690509][/doublepost]@Christoph Bergmann never mind, i found him in my logs too...looks like he's just doing some crawling, but i'll take a closer look.

 

[Christoph Bergmann]

Did you leave core's default mempool-limit of 300 MB?

As my mempool consumes currently 200 MB I wonder if I will find out soon.

@Peter Tschipper I don't think I've been ddos'd. My computer crashed at some time - usually my system is very stable - but out internet connection has never been effected. I didn't even noticed any performance reduction. If I'm right the botneter said he only attacked classic nodes (and he expressed sympathy with unlimited

I too think he was just crawling. Is it possibleto stopp his crawling by reducing the number of connections?

@all
I found out the connect command line overrides some other parameters like the dnsseeding.
With the following .conf my nodes runs like I want it to run - he searches for 6-8 other unlimited nodes while the rest is filled up by incoming connections.

maxconnections=16
debug=thin
port=8333
discover=1
dnsseed=1
listen=1
addnode=78.156.107.88
addnode=78.88.6.87
addnode=169.45.95.196
addnode=159.122.78.214
addnode=169.55.99.89
...

 

[sandakersmann]

You should also allocate more RAM to the database cache. I have 8GB total on my node and have set it to:

dbcache=2048

 

[Peter Tschipper]

@Christoph Bergmann nice...i always wondered about that, so by putting dnsseed=1 and listen=1 that fixes the problem...i think i might want to add that it to the connect-thinblock funcitonality , i'll look into it...thanks good finding

I think you should open up a bug report on GitHub if you can so we can track it and also when it gets fixed I"ll add you to the commit message.

 

[darkfur93]

I don't know if this has been answered before, but why do some v0.12 nodes have the protocol version set to 80000 while others are 80001?

 

[sickpig]

@darkfur93

@Peter Tschipper used version 80001 for a refined version of xthin/xvalidation code base you can find here:

https://github.com/ptschip/bitcoin.git
branch: buip010_spamblock

look for commit 10917cf413fcd78359e99f36b17698baa599d6f8

 

[Peter Tschipper]

@darkfur 80001 is the current code branch...we were using protocol version to keep unsupported functions from being triggered in the 80000 experimental release. When we release Xthins (soon) everyone will be on 80001.

 

[Erdogan]

I get a lot of:


2016-03-15 01:23:22 UpdateTip: new best=00000000000000000013e9712cfc1152d93a24cae3cd23d5ec78aef15390833f height=359620 log2_work=82.892943 tx=71113431
date=2015-06-06 03:47:20 progress=0.711580 cache=445.4MiB(251071tx)
2016-03-15 01:23:22 Acceptable block: ver:3 time:1433563233 size: 408253 Tx:836 Sig:2387
2016-03-15 01:23:25 LevelDB read failure: IO error: /home/xxxx/.bitcoin/chainstate/193099.ldb: Too many open files in system
2016-03-15 01:23:25 IO error: /home/xxxx/.bitcoin/chainstate/193099.ldb: Too many open files in system
2016-03-15 01:23:25 Error: Error reading from database, shutting down.
2016-03-15 01:23:25 Error reading from database: Database I/O error
2016-03-15 01:28:32

Sure you close everything after use?

 

[Peter Tschipper]

@Erdogan We haven't done any coding in the area of leveldb or reading writing to the database. Nothing has changed there in BU code that I'm aware of. We only use the same function calls as everybody else when handling a block. A couple of questions, what version of BU are you running? What's the size of your database cache setting? Your height says height=359620, are you still syncing the chain? And what OS are you on? Have you tried anything else, restarting, etc...do you have a lot of other processes running?

 

[YarkoL]

@Erdogan
Do you get something like "Deserialize or I/O error" in your log as well?

 

[Erdogan]

@Erdogan We haven't done any coding in the area of leveldb or reading writing to the database. Nothing has changed there in BU code that I'm aware of. We only use the same function calls as everybody else when handling a block. A couple of questions, what version of BU are you running? What's the size of your database cache setting? Your height says height=359620, are you still syncing the chain? And what OS are you on? Have you tried anything else, restarting, etc...do you have a lot of other processes running?

bitcoinUnlimited-0.12.0

dbcache=2048

Still synching.

Ubuntu
cat debian_version
jessie/sid
Linux perle 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

It could be that I run other things, another node and a tor exit node. I stopped the classic bitcoin node, and the unlimited seems to grind on. I have 1300 established tcp connections.

So it's probably nothing. Going to restart my classic node when I am in sync with unlimited.
[doublepost=1458040213][/doublepost]Do you get something like "Deserialize or I/O error" in your log as well?

No.

 

[theZerg]

Can you run lsof on the system and post results. Any time I can im you?

 

[Erdogan]

I get 5500 lines of output
limiting to lines cointaining ldb, I get

xxx@xxx:/etc$ lsof | grep ldb |wc
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
1598 15886 219946
xxx@xxx:/etc$

(I don't want to reveal too much info here)

 

[Peter Tschipper]

@Erdogan The fact that your'e still syncing means that you are not in Xthin mode. Xthins will only download when the chain is sync'd. So you are just downloading regualar blocks right now. 1300 Tcp connections seems like quite a lot to me. Have you tried restarting your machine and seeing how things run after?