Multi-implementation client development

Chritchens

New Member
May 5, 2017
6
22
By the way, I've started implementing a Rust client based on parity-bitcoin. You can find it at https://github.com/chritchens/parity-bitcoin-unlimited. So far it has a size limit of 2Mb, and 40000 max sigops. It is tested by using the tx in savethechain.tx.

I'm also working on the Go implementation, based on btcd. So far it is incomplete, because they have their own damn way of doing serialization. In any case, this is the link: https://github.com/chritchens/btcd-unlimited. I won't push here without solving the problem first.
[doublepost=1494002084][/doublepost]I can increase the parity-bitcoin-unlimited size or add EC+AD, but first I think there is the need to have a consensus on the voting/signaling thing. It would be easier to implement and, IMHO, way much effective than AD or EC via rpc calls.
 
Last edited:

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@Chritchens - this is great!

I'm going to look at how to run the tests - never touched Parity so far.
If it looks good, we should get the word out to get more people testing!
 
  • Like
Reactions: Chritchens

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
Hi @Chritchens

IV been thinking about this a bit and I'd like to make a proposal. But first could you explain a little more. What are you thinking when you say:
consensus on the voting/signaling thing.
And

effective than AD or EC via rpc calls.
For a non programmer what is or isn't ideal with the existing way the Remote Procedure Calls are handled?

Also I have a Ubuntu computer available to run a remote test if that's of any benefit.
 

Chritchens

New Member
May 5, 2017
6
22
Hi @AdrianX,

for the `consensus-voting signaling thing`, I meant the current informal proposal on using the coinbase for signaling and voting future size increases. Both AD and EC makes use of rpc calls to asks and inform other nodes their preferences. It's not RPC per se, but to use it as a means to reach consensus. The problems with an rpc based consensus are that it's not faithful, because any participant may have the incentive to lie, it's not safe, because it may open the door to new man in the middle attacks, and it's difficult and slow to coordinate, because it's all up to how many peers nodes will contact and how much they will be willing to follow each others. While AD would mitigate this latter point, many don't like it.

On-chain voting has the main benefit that it defines clearly the times, place and order of the discussion, thanks to the fact that (eventually) the blockchain is like a single thread of a forum where few can actually write, and are selected according to how much they showed to care and how much they will be able to do for the network. This is ensured by the pow.

Join the parity-unlimited channel on bitcoinunlimited.slack.org, it's the more updated source.

To install rust:

apt-get update\
apt-get install -y g++ build-essential curl git file binutils libssl-dev pkg-config libudev-dev\
curl -sSf https://static.rust-lang.org/rustup.sh | sh\
echo "export PATH=$PATH:$HOME/.cargo/bin" >> $HOME/.bashrc\
source $HOME/.bashrc\
rustup toolchain install beta\
rustup toolchain install nightly;

To get and build parity-bitcoin-unlimited:

git clone https://github.com/chritchens/parity-bitcoin-unlimited\
cd parity-bitcoin-unlimited\
cargo build -p pbtc

To build the release version:

cargo build -p pbtc --release

To test it:

cargo test --all

To regtest it: we are working on it. I've added bitcoinj-unlimited to help in the process. We will be using a java script by TheBlueMatt that generates a blockchain used for regtesting. You can find bitcoinj-unlimited at https://github.com/bitcoinj-unlimited, while I've not pushed yet the fork to his script, which is located at https://github.com/TheBlueMatt/test-scripts.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@Chritchens :

Both AD and EC makes use of rpc calls to asks and inform other nodes their preferences
No, the only way that nodes exchange these preferences is via the useragent string (and miners put them in their coinbases). But they do not act upon this information from the outside world in any automated way yet in BU.

There is an RPC interface to set parameters like EB and AD via external scripts, but this has nothing to do with inter-node communication at the moment. Although of course, nodes could be made to communicate out of band and then set their EB/AD/whatever accordingly. I'm not suggesting this is a good idea, but to set up primitive governor scripts using the RPC is possible today.