March 2018

Hello people!

@zoranc greetings!

I am trying to get into libbitcoin development by making witness_address class. So I am looking at payment_address for guidance and most of it is clear. However I have hard time understanding the extract_input() and extract_output() functions...

which parts in particular? the src/chain/script code does often require a closer look

extraction is the process of matching a "standard" script to obtain its corresponding payment address.

👍

The witness_address class would be used for native segwit addressing, with encoding in base_32...

what i don't understand for instance is why the extract_input in the sign_key_hash case has two possible addresses? isn't it the hash of the public key the correct address?

It also differs from payment_address in that there are two distint byte lengths (for the pre-encoded value).

(i suck at slack thumbs up myself - lol)

🙂

in the payment_address code the return statement has an array of two values because of ambiguity

That's a consequence of ambiguity for an input script.

from where comes the ambiguity? isn't it always two pushes?

The script matches two patterns.

ow

yeah, it sucks

i guess the second line is the p2pkh case, right?

{ bitcoin_short_hash(script.back().data()), p2sh_version } <= p2sh

looking at the next case that's wrong

Note that it is also possible for a script to be sign_script_hash without being sign_key_hash.

thanks for the explanation!

np, thanks for the help!

one last question: is this correct code for the 1. case: { ec_public{ script.back().data() }, p2kh_version }

@evoskuil was the zmq tarball patch meant to be backported to v3? i just realized running install.sh still uses the 'bad' version and corrupts the store on shutdown

bad version?

You mean it's using the current zmq build? I assume it can be backported, that's been phillip's thing.

the master branch of zmq has a regression that causes a bad bs exit and corrupts the store. the zmq tarball fix was to 1) avoid that, and 2) lock in something stable and known working. i consider the current master repo state to be a 'bad version'

grr, sourceforge has been having some issues lately, so our installer is failing to download source tarballs like boost ...

I tried this once via github, which had some issues but I forget what exactly.

Hi @evoskuil @neillm, I'm working on the EC documentation chapter and reliving a bit of Bitcoin history whilst looking at recoverable sigs. I gather this was discussed around 2011 by core devs, but obviously DERs still in use (consensus). Was this implemented in Libbitcoin in anticipation of potential hardfork back then? potentially eliminating redundant PubKey in TX? Or are recoverable sigs used anywhere else in Bitcoin?

With a recent update to the address index (server only), the size has been reduced from 86 GiB to 44GiB.

👍 nice work!

I have drafted a EC/Signature chapter and added both existing chapters to the wiki and wiki menu so anybody can edit. Thanks for the help so far, I enjoyed making this: https://github.com/libbitcoin/libbitcoin/wiki/Elliptic-Curve-Operations-&-Signing Feedback welcome! Next step: (hd) wallet chapter, integrate examples as tests

This is too hard:

myScalar1_add <= this is a mix of camel casing and lower casing. libbitcoin strictly uses lower cased identifiers, with the exception of macros (upper case) and template arguments (Pascal cased). Good to use the same style in examples.

Hello,my friends

Hello

Hi Eric, I don't know why, but wallet::decode_mnemonic(my_word_list, my_string) won't compile with the 2nd string (passphrase) parameter. In the source code, the preprocessor directive #ifdef WITH_ICU precedes the specific function signature with 2 args in question. Could it be that I am building it wrong? wallet::decode_mnemonic(my_word_list) with single argument no probs. https://github.com/libbitcoin/libbitcoin/blob/master/include/bitcoin/bitcoin/wallet/mnemonic.hpp#L78-L87

@James C. yes, it requires an icu build (i.e. --with-icu --build-icu)

ah! great thank you, what does icu stand for?

yes its in the readme as well

in short, the mnemonic dictionaries and passphrases can be in multiple languages, so we rely on icu to normalize them to match the specifications of bip-39

The dependency is conditional because it is vary large yet is required for only a tiny fraction of the codebase and scenarios. Same for qrcode/png.

Wallet Chapter is drafted: https://github.com/libbitcoin/libbitcoin/wiki/Addresses-&-HD-Wallets Let me know what you think! Fixes & Ideas appreciated! Next: P2PKH transactions...

👍👍

I recommend splitting this into two topics. I think same for the previous.

I agree -> came out to be more than I initially thought ...

How do you think UPnp?🙂

Hello everybody, I am working on the p2sh tx documentation chapter (& slicing prev chap into smaller ones). I don't quite understand the active_forks argument in script.to_string(active_forks). It seems this argument is the same as the block version miner signaling for softforks, but as far as I can tell, only affects "nop2->CLTV" or "nop3->CSV" in the returned string. So to get CLTV or CSV as the string output, I have to explicitly input the uin32_t active_fork argument with the respective bit activated. Q: Why only specifically these 2 cases, and only for the tx script.to_string method? Thanks in advance!!

Because these are the only opcodes that change behavior as the result of supported forks. The arguments is not the block version number, it’s the set of active forks.

Ah ok, got it! Interesting, only two op_code (re)assignments so far? I will read-up on these two BIPs ...

Right, two NOPs have been converted.

I will check out interpreter files, haven't looked into it yet. I was looking at this: https://github.com/libbitcoin/libbitcoin/blob/master/src/machine/opcode.cpp#L312-L316 Thanks Eric!

NP, that code is the serializer, but the interpreter shows why it’s that way. The design of the script machine is intended so that c++ beginners can follow it, but with little performance loss. Lemee know how we did :).

i can't comment on the script machine yet, but overall its has a been a real case study for me on how to properly structure a library👍👍 Still, so much to learn!

Nice to hear. I’m always focused on what’s wrong with it :).

I have drafted the chapter on building transactions: https://github.com/libbitcoin/libbitcoin/wiki/Building-Transactions Feedback welcome! I feel it is developing a bit in the direction of: Bitcoin + Libbitcoin doc, but maybe that's ok or a good thing. Next: Slicing previous chapters into smaller ones. Other topics: P2SH/Segwit/Stealth Addresses ... moving examples into tests(once I revise the earlier chapters).

Can all community server update to the latest v3 code? We'd like to make these the default seed nodes for libbitcoin going forward

Building 3.5 now

The top of master is versioned 3.5 but with changes pending a 3.6 release tag. Thanks for supporting the community server pool Lucas!

I can also run master otherwise The server is mostly for me to gain experience, so far

Oops, I meant to say the top of Version3.

Ok 👍

Either the build metadata is out of date or the code generation was not run prior to tagging. But you need to build from head in any case.

You mean latest of branch version3 instead of tag 3.5 ?

Yes, to get latest address protocol updates.

ok, rebuilding

As a community server you should generally build from release branch head (default install.sh) so that we get changes fully vetted in live environments before tagging release.

Ok, running now with version3 branch HEAD

👍

DNS works but I only have a mainnet instance running bx fetch-height tcp://mainnet4.libbitcoin.net:9091 513485

Yes

ok, will do that

Soon we can do that with litecoin, feathercoin ;)

Seeding on mainnet is working very well for me, using all 4 community servers. If anyone sees any issue, let us know

Syncing testnet now

👍

Hello everybody, I am working on documenting segwit TXs, but this part has been killing me, stuck on it for a while: Would like to create a witness for P2WSH(multisig): [][sig1][sig2][witnessScript] The problem happens when I try to push on [witnessScript] onto the oplist... witness_oplist.push_back(operation(witness_script.to_data(false))); ...it adds a OP_PUSHDATA1/76/Hex(4c) in front of it. Why does it add the 4c opcode? That doesn't seem to happen if I push back, lets say operation(to_chunk(my_hash_digest)) Here is just the [witnessScript], a 2/3 multisig, parses fine with bx script-decode: 5221026ccfb8061f235cc110697c0bfb3afb99d82c886672f6b9b5393b25a434c0cbf32103befa190c0c22e2f53720b1be9476dcf11917da4665c44c9c71c3a2d28a933c352102be46dc245f58085743b1cc37c82f0d63a960efa43b5336534275fc469b49f4ac53ae After pushing it to the operation::list, I serialise it and get: 4c695221026ccfb8061f235cc110697c0bfb3afb99d82c886672f6b9b5393b25a434c0cbf32103befa190c0c22e2f53720b1be9476dcf11917da4665c44c9c71c3a2d28a933c352102be46dc245f58085743b1cc37c82f0d63a960efa43b5336534275fc469b49f4ac53ae (notice the leading hex(4c)) Any help much appreciated!

Scripts consist only of opcodes 0-255. Some opcodes have associated data. When you create an operation from data the data opcode is determined for you. Given that there are potentially multiple choices of data opcode (based on length) it will chose the "minimal" (shortest mapping) opcode. The other convention is to use the "nominal" (simpler mapping) data opcode. You'll see both terms in the comments and parameter names. The construction you are using is: operation(data_chunk&& uncoded, bool minimal=true).

Hmm, this is new to me: I am now looking at https://github.com/libbitcoin/libbitcoin/blob/master/include/bitcoin/bitcoin/impl/machine/operation.ipp#L212-L219 So data lengths beyond 0x4b will require a preceding opcode OP_PUSHDATA1 , OP_PUSHDATA2 depending on the data size? I will have a closer look to better understand the multiple possible mappings you mentioned. But there are still 2 observations I cannot explain: 1) Looking at a P2SH(P2WSH) example from the BIP143 proposal, I noticed the [witnessScript] data in the witnessScript simply has a preceding cf to indicate the number of following data bytes, but no OP_PUSHDATA. I noticed cf>4b. 2) When I try to pass the script object /w the data operation OP_PUSHDATA1 to the witness object: witness my_witness(script.to_data(false), false);, it remains empty. Witness objects constructed from scripts with simple data pushes, such as [number of bytes][data bytes], work fine. Based on the BIP143 example and my troubles with the above witness object, I am guessing the witness doesn't work with the OP_PUSHDATA opcode. Could that be? Thanks in advance!

A witness is not a script, it’s a data stack.

Ok I understand now! 🙂 I will populate a data stack for the witness object, rather than passing in a serialised script. Somehow I was looking at the serialised format of the witness and thinking that it was basically a script. Thx a lot Eric, was stuck on this for (way to long)!

It’s a bit odd that a different serialization was created. I initially implemented as a script, and then as a common base class, but in the end I decided that was more complex that a distinct type.

$ bx fetch-height tcp://mainnet1.libbitcoin.net:9091 514353 $ bx fetch-height tcp://mainnet2.libbitcoin.net:9091 514353 $ bx fetch-height tcp://mainnet3.libbitcoin.net:9091 514353 $ bx fetch-height tcp://mainnet4.libbitcoin.net:9091 514353 $ bx fetch-height tcp://mainnet1.libbitcoin.net:9081 "0HxgF^7dEzWu)$R^YE/q7mm0=t@o7RDUT}K.@oY@" 514353 $ bx fetch-height tcp://mainnet2.libbitcoin.net:9081 "}[YQ:ks:iKd0F1!ycPgj:4CVzfV-=jsF}x&%ff=/" 514353 $ bx fetch-height tcp://mainnet3.libbitcoin.net:9081 "f!qCf4(YHm3rp/J15Q+!l>{jz>>eUkW9}6&pc0tB" 514353 $ bx fetch-height tcp://mainnet4.libbitcoin.net:9081 "8=mvk8!F=+>$k&-.65NCPp}4e4j)<N3wk{+N!*hM" 514353 $ bx fetch-height tcp://testnet1.libbitcoin.net:19091 1288674 $ bx fetch-height tcp://testnet2.libbitcoin.net:19091 1288674 $ bx fetch-height tcp://testnet3.libbitcoin.net:19091 1288674 $ bx fetch-height tcp://testnet4.libbitcoin.net:19091 1288674 $ bx fetch-height tcp://testnet1.libbitcoin.net:19081 ")nNv4Ji=CU:}@<LOu-<QvB)b-PIh%PX[)?mH>XAl" 1288674 $ bx fetch-height tcp://testnet2.libbitcoin.net:19081 "M>dfC.16SBU&O9hA@rUWP:k]>DF=xTJ73Iw}HE0g" 1288674 $ bx fetch-height tcp://testnet3.libbitcoin.net:19081 "ZW4K2g{E>*a@n>NqZ<VeI^2ANqw.7Ub<?>UgSiNq" 1288674 $ bx fetch-height tcp://testnet4.libbitcoin.net:19081 "8=mvk8!F=+>$k&-.65NCPp}4e4j)<N3wk{+N!*hM" 1288674

😄

@James C. uploaded a file: piping_bx_witness.jpg and commented: Regarding script vs witness: I made the mistake of naively piping the witness into bx script-encode and assuming it was script 🙂 Thanks for pointing that out. Thats not a criticism of bx in any way, bx has been awesome in analysing/learning serialised formats.

👍

Draft of Segwit Documentation Sections are up: https://github.com/libbitcoin/libbitcoin/wiki/Segwit-P2WPKH https://github.com/libbitcoin/libbitcoin/wiki/Segwit-P2SH(P2WPKH) https://github.com/libbitcoin/libbitcoin/wiki/Segwit-P2WSH https://github.com/libbitcoin/libbitcoin/wiki/Segwit-P2SH(P2WSH) Corrections & feedback welcome! Next: Redrafting of previous chapters, and associated examples, rethink these to fit into tests.

Please avoid crappy Satoshi terminology (ie scriptSig, scriptPubKey). These aren’t used in the code as they really just don’t make sense. We have input.script and output.script in code.

👻

We also don’t use the term “segwit”. It’s a portmanteau of two abbreviations. Just use “witness”, as in the code. Segregation is redundant.

👻

redeem_script vs. redeemscript

hello, nice to see everybody here. I've created a docker image for cross compiling apps for Android using libbitcoin and Qt: https://polyteknik.org/docker-dw.html

dockerfile for my setup https://github.com/narodnik/lbdocker

Hello everyone, I made a pull request for adding ec_sum to math/ https://github.com/libbitcoin/libbitcoin/pull/922

@evoskuil Sorry, i just accidentally requested a code review on github from you, please ignore.

👍

Cool! I forgot you were attending this

I met satoshi!!

👻

I was too nervous to ask him for a selfie though.

wow

I love how troubled you looked talking about hash collisions... like it was a matter of life and death you didn't get that optimization

Yeah, it was more that I felt like I had fucked up the explanation. I didn’t want people to think we were using the tx/header hashes as hash table keys. Really it wasn’t important enough to worry about. But yeah, the nonoptimal bucket counts bugs me.

I know you don't look nietzsche, but you're the superman

we actually made the gateway in old dw to translate zmq to websockets so good news it will be included in v4

👍

I also enjoyed the video yesterday. There's still so much technical details i wasnt able to understand as of yet

Me too! :)

thanks james for https://github.com/libbitcoin/libbitcoin/wiki/Pedersen-Commitments-in-EC-Form

👍Thank you for ec_sum. I'm not definitely not there where I can explain how pedersen commitments are used for confidential transactions yet...but working on it, that would be cool 🙂