Announcing BitcoinUnlimited v0.12.0: Experimental Release

[solex]

Announcing BitcoinUnlimited v0.12.0

Experimental BU Client Release - Focus on Main-chain Scaling​

BitcoinUnlimited v0.12.0 Highlights are:

Core v0.12.0 code-base

Enhancements:

Effective block limit via emergent network consensus

• BUIP001 Fixed block limit made obsolete
• BU follows the blockchain with most PoW as per the original Nakamoto Consensus
• Separation of the mining block size (default 1MB) from the non-mining block acceptance size (default 16MB)
• Block size limits and acceptance depth individually configurable
• Classic block version for mining

Public notification of individual settings

• BUIP005 User agent subversion text

Xtreme Thinblocks

• BUIP010 Reduces real-time block propagation sizes by an average of 15x (i.e. 1MB down to 70KB) returning the network overhead for newly mined blocks to the state it was in June 2012

Xpress Validation

• BUIP010 Superfast block validation leverages the earlier validation of transactions which are in the mempool so that only previously unseen transactions in a block need full validation.

Traffic-shaping

• BUIP001 Users can easily configure how much bandwidth should be used for Bitcoin, allowing the BU client to run unobtrusively in a home network.

Disabled:

Replace-by-fee

• BUIP004 Community vote determines that there is no consensus for a feature which undermines the 0-confirmation use-case

Acknowledgements with special thanks for coding and testing:

Andrew Stone
Peter Tschipper
Sickpig
YarkoL
​

Download location:
http://www.bitcoinunlimited.info/download

 

[solex]

Chart of average block sizes (7-day) showing the historical situation.
https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=

 

[AdrianX]

Do you have a list of changes from the previous Core base to the new 0.12 base that are still active?

I don't like the solution for mem pool limiting, I would prefer an incentive based solution like bigger blocks and relaying only valid transaction that meet an objective rule set.

I don't like the idea of relaying or supporting RBF info.

I was also wondering if there is any 3rd party verification on the effectiveness of libsecp256k1 from outside on the bitcoin community?

And most importantly are TX's with 0 fees relayed by default, and are TX's from old unspent outputs with no fee still relayed and processed or rejected and not relayed if blocks are full?

 

[Peter Tschipper]

@theZerg I wonder if we should update the release notes in the doc folder. It still shows reference to NODE_BLOOM being used as well as RBF.
[doublepost=1456445635][/doublepost]@theZerg I was wondering too if we should make the minrelaytxfee =0 in the next release....probably too late for this release...currently it's set to:

static const unsigned int DEFAULT_MIN_RELAY_TX_FEE = 1000;
[doublepost=1456445671][/doublepost]@AdrianX RBF is commented out in this release of BU

 

[solex]

@AdrianX

The items listed in Core's v0.12.0 release notes are valid for this BU release except for RBF which is commented out. We would need a new BUIP to do changes to tx fee policy. If you have suggestions in this area please raise a BUIP and we can begin to push the fee handling in a direction that is not "settlement layer / full blocks" focussed.

With respect to libsecp256k1 there are already 730 nodes running this and Classic will incorporate it unchanged. IMHO, I think this library should be allowed the benefit of the doubt but I do welcome the opinion from independent experts (of which there cannot be many in the world) that the code is simply an optimization.

 

[AdrianX]

thanks for the responce and this suggestion @solex

We would need a new BUIP to do changes to tx fee policy. If you have suggestions in this area please raise a BUIP and we can begin to push the fee handling in a direction that is not "settlement layer / full blocks" focussed.

given the current default Core 0.12 fee policy and the lack of RBF it looks to me transactions could get stuck with no ability to free them so long as blocks are full. not knowing exactly how it works I'll give it some thought, i'm sure most of the work has already been done already.

 

[Christoph Bergmann]

Hi there,

thanks for the release. This seems to be the perfect client to run.

I tried to follow the instructions to activate / support thinblocks and added the following to my bitcoin.conf

connect-thinblock=<78.156.107.88>
connect-thinblock=<78.88.6.87>
connect-thinblock=<169.45.95.196>
connect-thinblock=<159.122.78.214>
connect-thinblock=<108.44.192.182>
connect-thinblock=<169.55.99.89>
connect-thinblock=<104.197.99.28>
connect-thinblock=<96.54.102.88>

addnode=<78.156.107.88>
addnode=<78.88.6.87>
addnode=<169.45.95.196>
addnode=<159.122.78.214>
addnode=<108.44.192.182>
addnode=<169.55.99.89>
addnode=<104.197.99.28>
addnode=<96.54.102.88>

But looking in the debug windows to my peers I have not a single bitcoin unlimited 0.12 peer.

Do I already use thinblocks?

Another, maybe stupid question about thinblocks: Do I still send blocks to other peers, or do I just send headers as long as my peer doesn't use thinblocks? And is miner's relaying of blocks a pull-process (so that I already can say "hei, I just need the header, thank you"), or have the miners to use thinblocks for it to have an effect?

(I mean, downloading blocks is not a problem, uploading is)

 

[freetrader]

@Christoph Bergmann :
According to the instructions I found on reddit, it's not necessary to use both "connect-thinblock" and "addnode" statements at the same time.

Try using only the "addnode" section - that worked for me.
"connect-thinblock" enforces a thinblock mode of operation for a peer - i.e. no fallback to the standard relaying mode.

Also, I think you need to run with "-debug=thin" to actually see xthin outputs in your debug.log.
Search for "thin" or "Reassembled" in the log after a while.
If you don't see any of those, let's investigate further using the BU Slack channel (you're on there too, right?)

I'll try to answer your other questions according to my (insufficient) knowledge, hoping that others will correct me if I'm wrong:

If a peer can't do xthinblocks, then it will still receive blocks as usual with the standard relaying so that there is no degradation in the service.

The standard relaying works like this: Miners normally announce their new block headers using inv, interested peers pull the block data using getdata. See Fig.2 in here

http://diyhpl.us/~bryan/papers2/bitcoin/Information propagation in the Bitcoin network.pdf

Either @Peter R or @Peter Tschipper recently posted a diagram similar to Fig.2 for the xthin case, showing how generally it does not introduce an extra roundtrip (in addition to the huge space savings due to passing back only the parts of the block that the requestor is lacking).

 

[Christoph Bergmann]

Thank you,

I noticed I also had the wrong syntax. Now I outcommented the connect-thins and wrote
addnode=96.54.102.88, without "<>" (using ubuntu)

I also integrated -debug=thin in my .conf.

It now looks like this

- debug=thin

#connect-thinblock=78.156.107.88:8333
#connect-thinblock=78.88.6.87:8333
#connect-thinblock=169.45.95.196:8333
#connect-thinblock=159.122.78.214:8333
#connect-thinblock=108.44.192.182:8333
#connect-thinblock=169.55.99.89:8333
#connect-thinblock=104.197.99.28:8333
#connect-thinblock=96.54.102.88:8333
#connect-thinblock=85.3.93.45:8333

addnode=78.156.107.88:8333
addnode=78.88.6.87:8333
addnode=169.45.95.196:8333
addnode=159.122.78.214:8333
addnode=108.44.192.182:8333
addnode=169.55.99.89:8333
addnode=104.197.99.28:8333
addnode=96.54.102.88:8333
addnode=85.3.93.45:8333

Still have no connection to an unlimited 0.12 node. Maybe they are bussy? In the debug-file I didn't find "thin".
[doublepost=1456483737][/doublepost]One more thing

""connect-thinblock" enforces a thinblock mode of operation for a peer - i.e. no fallback to the standard relaying mode."

--> is it possible to force a peer to do this? So, is he able to accept thinblocks?

 

[freetrader]

Don't use the -debug with a minus sign in your .conf - just write "debug=thin".
I was referring to its use as a command line option.

It's not really possible that all the BU nodes are too busy - one of them listed is my node and I know for a fact that I still have open slots.
So it must be a different problem.

Try removing the :8333 from your addnode lines, because it's not necessary since they are on the standard port. I don't have that :8333 in my.conf , and it still works.

---

You can only "force" a peer to talk xthin to YOUR node if the peer supports it and is prepared to talk to you in that way. I don't know if there are other criteria which may make a peer decide that it's NOT going to talk xthin with your node, but it is theoretically possible (e.g. the peer might decide using some performance metric that xthin with your node would be worse than another way, or the peer might be in some kind of "warming-up" phase where xthin is not its preferred way. I don't know if that could be the case with the actual implementation right now - haven't studied the code, sorry).

 

[Christoph Bergmann]

Sorry for spamming this thread (currently writing on a review for my blog).

One more question about Xpress Validation

"BUIP010 Superfast block validation leverages the earlier validation of transactions which are in the mempool so that only previously unseen transactions in a block need full validation."

This sounds great, since it should reduce cpu-requirements immediately without needing peers running unlimited. But is it not unnecessary with Xtreme Thinblocks?

 

[sgbett]

Hello, slightly n00b question...

pulled release "0.12bu" from github at https://github.com/BitcoinUnlimited/BitcoinUnlimited.git

did a configure && make && make install that failed with:

make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

Have i missed something stupid...

 

[Christoph Bergmann]

Hu, I'm completely noobish with ubuntu and regularly desperated, but maybe I can help:

I downloaded and unpacked the linux-32 files form the unlimited website, loaded the directory home/bitcoinUnlimited-0.12.0/bin and then startet it with "nohup ./bitcoin-qt &". It's working.

(just like the unlimited website told me with the old version).


Update /thinblocks:

I removed the ports from the .conf, restarted, but still don't connect to another unlimited-0.12 node

wrote

addnode =79.221.214.224 for example.

Edit: I was able to connect manuelly by using "addnode "ip" "onetry"" in the console. Now I'm connected, but not ingoing, just outgoing.

Can I enforce the addnode with some method?

Edit: did still not find "thin" in debug.log. (but maybe thats no wonder since I have no unlmited-peers)

 

[freetrader]

Hello, slightly n00b question...

pulled release "0.12bu" from github at https://github.com/BitcoinUnlimited/BitcoinUnlimited.git

did a configure && make && make install that failed with:

make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

Have i missed something stupid...

That sounds like your "configure" failed - therefore no Makefile has been created.
A closer look at the config.log would be advised.

Remember also: you should always use "./configure && make" (the dot slash can be very important)

P.S. what's the exact OS and its version? (e.g. Ubuntu 14.04 or sth)
[doublepost=1456486109][/doublepost]@Christoph Bergmann :

What does 'bitcoin-cli getnetworkinfo' show for your node?

 

[freetrader]

Now I'm connected, but not ingoing, just outgoing.

How did you assess this?

If you're able to put your debug.log onto pastebin or sth, that might help a lot with the troubleshooting.
Also, what does "bitcoin-cli getnetworkinfo" show for your node?

 

[Christoph Bergmann]

What does 'bitcoin-cli getnetworkinfo' show for your node?

(console, "getnetworkinfo")

"version": 120000,
"subversion": "/BitcoinUnlimited:0.12.0(EB16; AD4)/",
"protocolversion": 80000,
"localservices": "0000000000000005",
"timeoffset": 0,
"connections": 20,
"networks": [

How did you assess this?

I looked at the peers in my debug window.

The strange this is, after I added 8 peers from "addnode" of my .conf-file and kicked some other outgoing nodes my node fill it. Like it wants to have 8 outgoing peers independently of the manuelly added peers.

If you're able to put your debug.log onto pastebin or sth, that might help a lot.

Since the file is too big for pastebin (not pro), I just loaded it into google drive


Thank you!

Cool - it is shown in the forum. Great!

 

[sickpig]

Hello, slightly n00b question...

pulled release "0.12bu" from github at https://github.com/BitcoinUnlimited/BitcoinUnlimited.git

did a configure && make && make install that failed with:

make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.

Have i missed something stupid...

building from a cloned github repo require the execution of

./autogen.sh

as first step

 

[freetrader]

Sorry for spamming this thread (currently writing on a review for my blog).

One more question about Xpress Validation

"BUIP010 Superfast block validation leverages the earlier validation of transactions which are in the mempool so that only previously unseen transactions in a block need full validation."

This sounds great, since it should reduce cpu-requirements immediately without needing peers running unlimited. But is it not unnecessary with Xtreme Thinblocks?

I remember asking @Peter Tschipper about this, and he mentioned that Xpress Validation only applies to blocks reconstructed by the Xtreme Thinblocks code path, and not to blocks received in other ways (at least at the time of our discussion, which was a few weeks ago I think). If you want I can try to find his explanation - it was on this forum.

I could try to look at the code and figure out if it still only applies to xthinblocks, but it's not as fast as @theZerg or @Peter Tschipper pointing us to the truth.
--

For reference, the Pull Request is #14:
https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/14

and the merge commit for xpress validation is:

https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/735ebad06885f97fca6ffeb6dca736c152e441d2

 

[Peter Tschipper]

@Christoph Bergmann Is it working for you? Two things if not, first you will only get xthins if your chain is withing 2 blocks of syncing, make sure you have debug=thin turned on, and also if you're still not sure if you're getting xthins use connect-thinblock=<ip> rather than addnode

 

[freetrader]

(console, "getnetworkinfo")

I looked at the peers in my debug window.

The strange this is, after I added 8 peers from "addnode" of my .conf-file and kicked some other outgoing nodes my node fill it. Like it wants to have 8 outgoing peers independently of the manuelly added peers.

Do you ever see any incoming peers?
If not, you have to unblock port 8333 on your firewall and/or let it through your router (set up port forwarding for TCP port 8333)

The file on your Google Drive is not showing up for me. Could it be that it only works locally?