Bitcoin full node and query server

April 2019

Archive of the libbitcoin Slack #general channel.

Monday, April 1, 2019

jungly08:26
I missed that @neillm - which one is it?

Tuesday, April 2, 2019

N
narodnik21:39
strange

Thursday, April 4, 2019

J
James14:49
Hi everyone, I like to discuss an API question with you, first topic and background: We're working out segwit templates (P2WPKH and P2WSH) and segwit addresses for LibBitcoin, looking forward to contribute this code to LB.
To do this well and systematically, we thought, how should this stuff be done from the perspective of the LibBitcoin C++ API user, and therefore we figured that we should write a C++ usecase-example program that illustrates what a user normally wants to use the LibBitcoin API for with respect to non-segwit templates and addresses (P2PKH and P2SH), and then design the segwit additions out of a motivation that they should mean gentle variations to the non-segwit usecase code, or at least be symmetric.
The usecases we figured are: * from a public key (and mainnet vs testnet choice), generate P2PKH address * parse P2PKH or P2SH address - confirm valid, confirm testnet vs mainnet, print binary dump of payload * generate a Bitcoin TX output payload from a P2PKH or P2SH address * generate a Bitcoin TX input payload according to P2PKH template, from a private key, a TXID and output index * generate an unsigned Bitcoin TX input payload according to P2SH template, from a script * generate a Bitcoin TX, with one signed input according to P2PKH template, from a private key, a TXID and output index, and an output to a P2PKH address * generate a Bitcoin TX, with one signed input according to P2SH template, from a script, pushdata constants, a TXID and output index, and an output to a P2SH address * check if an Bitcoin TX input or output payload matches the p2pkh or p2sh pattern * extract Bitcoin address (always zero or one in count isn't it??) from Bitcoin TX input or output payload * ??? WIF serialization ??? * ??? HD wallet xprv serialization ??? * get list of transactions from txindex for given p2pkh/p2sh address
Here follows the C++ code for the usecases, eventually this should end up on GitHub as an illustrative example of how LB is used:
Normal non-segwit LibBitcoin C++ API usecases code, will end up on Github later C++ · 23.2 KB
#include <iostream>
#include <vector>
#include <string>
#include <cstdint>
#include <bitcoin/system.hpp>
#include <secp256k1.h>
 
 
// http://aaronjaramillo.org/libbitcoin-building-a-raw-transaction
// https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki
// the obvious stuff that should be covered by the usecase example would be
// (first out we do for P2PKH & P2SH, THEN we extend to all the other four: native & P2SH-wrapped P2WPKH & P2WSH):
/*
 
g++ \
    -std=c++11 \
    -o conceptual_usecase_script \
    conceptual_usecase_script.cpp \
    -fpermissive \
    $(pkg-config --cflags libbitcoin-system --libs libbitcoin-system) 
*/
 
using namespace bc; 
using namespace bc::system; 
using namespace bc::system::chain; 
using namespace bc::system::wallet; 
using namespace bc::system::machine; 
int main(int argc, char const *argv[])
{
    //  * (unrelated to segwit:) generate an HD wallet
    std::cout << std::endl << std::endl << std::setw(40) << std::setfill('-') << "-" << std::endl;
    std::cout << std::endl << "* (unrelated to segwit:) generate an HD wallet" << std::endl;
    {
        data_chunk hd_entropy{16};
        pseudo_random_fill(hd_entropy);
        data_chunk hd_seed = to_chunk(decode_mnemonic(create_mnemonic(hd_entropy)));
        hd_private hd_private_key{hd_seed, hd_private::testnet};
        hd_public hd_public_key = hd_private_key.to_public();
 
        std::cout << "\nHd private key: " << std::endl;
full file
Now one thing that sticks out here, that I like to start our discussion with is, where in LB to implement the segwit addresses (i.e. P2WPKH and P2WSH). All layers of LibBitcoin (e.g. client/server API etc.) use payment_address for describing a Bitcoin address. With segwit, Bitcoin address now doesn't only mean P2PKH and P2SH, but also native (as bech32) and P2SH-wrapped (as p2sh) P2WPKH and P2WSH address. Expectably of course the bech32 P2WPKH and P2WSH will be the more common addresses. Our first thought was, let's make a witness_address class to describe this stuff. But, second thought is, isn't Bitcoin a segwit phenomenon altogether now so we can as well just extend payment_address with segwit functionality? As all LibBitcoin tooling does, and most dependencies likely do, want segwit template and address support, then with its introduction there will be code updates spread over all LB and dependency codebases anyhow. payment_address can become a hybrid structure for both non-segwit and segwit addresses. What are your thoughts on this topic? Is there a goal, or not, in having LibBitcoin compile-able without segwit support and a separate witness_address class being needed for some such reason?
After having gotten clarified how the segwit (P2WPKH and P2WSH in bech32 and p2sh-wrapped variants) should be represented by LibBitcoin, we look forward to going into figuring how to implement the transaction templates, both inputs and outputs. The P2W* inputs will of course differ fundamentally from their non-segwit counterparts in that they have the witness structure too, so there will be some fundamental differences between how to do non-segwit and segwit stuff - here the transaction format is different right, and the ability to process non-segwit (witness-free) transactions will remain with LB, right.
neillm15:02
Hey James, all good questions. I don't think that last point is a particular goal (re: compile-out segwit), but not sure. I also have very scattered thoughts on this whole topic regarding structure and usage, and also a private branch with working BIP142 support and tests and partial BIP 173 support (but broken at the moment -- not even sure of the current state to be honest). The approach I was taking there was with a derived witness_address class, but figured it would be re-factored later during review. Given that this code is incomplete and a bit stale, I'm certainly not attached to it either, so I'd really like to see a solid implementation surface. I'm only pointing out that you've asked good questions and it's not clear to me at the moment either.
J
James15:02
When studying this I think I recall an instance where we realized that WIF encoding is needed for segwit addresses, and, there is a BIP that suggests how to do that, and that is BIP 178, https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki . Does LibBitcoin want to support it?
neillm15:03
Re: BIP 178, pull requests are always welcome 🙂
J
James15:05
Neill, thanks for your response. I understand your work with BIP 173 (= bech32 segwit addresses) didn't complete, indeed how to implement it is non-trivial.
For me I need bech32 support ASAP. And, that is the kind of functionality that really topically belongs in the LibBitcoin repo itself, so I thought I should talk to you,
so ideally any contribution made now also supports the project as a whole, through this early discussion, I and you and whoever can design this in a way everyone likes.
Maybe a fundamental question is, does anyone have any yeys or nays about the choice of either: extend payment_address with segwit addresses, meaning payment_address would be a "hybrid" or "dual content" structure which would be either a witness address or a non-witness address. this payment_address class then would support both bech32, and nonsegwit base58, addresses. or: leave payment_address as it is, make a new witness_address class which is either hybrid/dualcontent, or bech32-only (and then what about p2sh segwit)
For completeness, does anyone see any third option? magic wakeup noise @evoskuil @narodnik and everyone 🙂
neillm15:13
The approach that I was taking was the latter, but as I was doing that, I kept in mind that usage would probably prefer the former. I don't think it's unreasonable that payment_address can parse all of the different types, but the derived approach allowed me to test things out separately, so I figured it was a fair place to start.
J
James15:14
aha.
neillm15:16
It potentially confuses the API though in that you can encode the data of a single payment address in ways that you probably shouldn't, so that could be an argument against. But when it comes to stack usage of payment_address, having a separate alternative appears a bit unwieldy (particularly at the bx level).
I figured if I could produce working code, @evoskuil would use his re-factoring talents and clean it all up 🙂 I realize that's not the best plan though ...
neillm15:23
For what it's worth, not sure if you've looked at the src/formats/base32 code -- that's actually bech32 code.
J
James15:25
Right, the underlying bech32 algorithm is implemented already, indeed.
Would you mind sharing the witness_address class you implemented before?
neillm15:26
I'll see about cleaning it up and sending, not sure when though. What does 'asap' mean for you, btw?
J
James15:29
oh great question.. so what's going on on my side is, i'd like to make a P2WPKH-funded+change transaction ASAP, say, this month = April.
it's not a whole lot of code to do this using homemade hacks and such, but, it would be better to add the actual segwit templates functionality to LibBitcoin now when dealing with this problem domain anyhow.
looking at these implementation details and discussing withyou, maybe brings forth a realization that even while these are fundamental problems, actually implementing it accross the whole LB code base may Take A While?
On our side, we did implement some segwit address+transaction template logics, which meant changes to these files: ec_private.cpp ec_private.hpp ec_public.cpp ec_public.hpp input.cpp input.hpp payment_address.cpp payment_address.hpp script.cpp script.hpp script_pattern.hpp witness_address.cpp witness_address.hpp
A complete implementation will also involve segwit address extraction, so that addresses go into the transaction index.
👍 1
@neillm, are you aware of any previous attempts at implementing helpers for the P2WPKH and P2WSH transaction templates?
neillm15:37
In libbitcoin? No
Some people had expressed interest in the past, but not much since
J
James15:37
aha. do you have any thoughts about how this should be done?
neillm15:38
Thoughts yes, a clean design/integration path, no.
J
James15:38
Would you mind sharing your thoughts? We'll try to work out some code here, also have some code already.
👍 1
@evoskuil @neillm for pull requests, do you want whole pieces of functionality, or contributions that are "obvious fits" but are only pieces in the puzzle, are those welcome also? - we have a script_pattern.hpp updated with Segwit templates here, should we PR it?
evoskuil15:40
I don’t like the idea of overloading payment_address for witness addressing. It’s a question of code organization, not whether segwit is integral to bitcoin. payment_address may be overly general now as a name, but can always be renamed.
J
James15:41
aha, so rename "payment_address" to "p2x_address", and then create a new "p2wx_address" 🙂
neillm15:43
I think something along those lines can work nicely from higher levels too, as payment_address is being replaced from the bx level since we changed the way payments are indexed in v4
J
James15:43
@neillm oh really, what about it, why did you drop payment_address in bx?
neillm15:44
Sorry, it's not dropped, but the usage would be more like: bx address-to-key <ADDR> | bx some-other-command
But that would more easily allow say bx witness-to-key or something into the same command(?)
evoskuil15:46
We avoid creating acronyms and minimize their use generally, witness_address is sufficient. I’m not in a rush to rename payment_address.
J
James15:47
aha.
evoskuil15:51
witness is used consistently in libbitcoin to refer to things segwit.
J
James16:06
aha.
@evoskuil @neillm may the native/bech32 as well as p2sh-contained segwit addresses turn out to be contained in some pragmatic format?
lower level
anyhow, now talking to you about this, it seems it will take time for this functionality to get into LibBitcoin, as very deep design choices are involved, and also the whole LibBitcoin codebase will need adaptations in all of the possible implementation routes
neillm16:10
I agree chatting about this helps make things more clear. As for full stack usage, I think the biggest user of payment_address is system/explorer, so perhaps not as bad as it seems
In any case, I hope this discussion wasn't discouraging 😉
J
James16:11
i think getting segwit addresses in particular into LB will take months.
actually i gained the clarity now that for the stuff I do now, i should just make own local shortcuts in my code for now,
the updates to LibBitcoin needed are simply too deep to say "oh, i'll give a weekend or two to implementing it in LB so we be done with it"
that's not how it works
instead i'll make bech32 address generation and parsing code locally in my code, based on LB's base32 class,
and comment out "// Today LibBitcoin doesn't do this, later it will, so this piece will be subject to change."
and same for p2wpkh templates
neillm16:16
I'm not sure you're right -- but I'm not sure you're wrong. It may not be as far off as you think, but you're right that it definitely needs some more time put into it. Even talking about it now is more than has been done on it previously (as far as I know), so mapping out the path to integration is probably most of the battle. The actual code isn't too difficult
But I agree that you should do what suits you best at the moment, can always come back to this later
J
James16:34
How is V4 going?
evoskuil16:35
Witness address support is not a big job, but I suppose it depends on your perspective.
J
James17:03
How stable is V4 now?
neillm17:05
How do you mean? It doesn't crash for me ... do you mean how stable is the API?

Saturday, April 6, 2019

J
James12:12
@neillm I meant, does the header-first sync work well V4 was in the making all 2018, i guess it matured finally then 😃

Monday, April 8, 2019

evoskuil01:13
It works but it’s not yet optimal.
Daniel Krawisz22:06
Hey I need some help. I'm trying to install libbitcoin-system and I get the error messages src/.libs/libbitcoin-system.so: undefined reference to `secp256k1_ecdsa_recover' src/.libs/libbitcoin-system.so: undefined reference to `secp256k1_ecdsa_sign_recoverable' src/.libs/libbitcoin-system.so: undefined reference to `secp256k1_ecdsa_recoverable_signature_serialize_compact' src/.libs/libbitcoin-system.so: undefined reference to `secp256k1_ecdsa_recoverable_signature_parse_compact'
Alternatively, if you use install.sh, it does that for you.
38 replies · Daniel Krawisz, neillm, evoskuil · last Apr 14, 2019
Daniel Krawisz22:08
Thanks, but this is what I was using already.
Daniel Krawisz22:08
I'll try install.sh
neillm22:09
Ok. In particular, you've already added the --enable-module-recovery switch?
Daniel Krawisz22:16
I tried but I didn't know where to add it.
neillm22:16
Add it to the ./configure line (but if you're going to install.sh, that's the preferred way to install anyway)
Daniel Krawisz22:17
I tried install.sh and it says "/usr/local/include/boost/test/tools/old/impl.hpp:130: undefined reference to `boost::test_tools::tt_detail::equal_impl(wchar_t const*, wchar_t const*)"
Daniel Krawisz22:19
When I ran "./configure --enable-module-recovery" it says "configure: WARNING: unrecognized options: --enable-module-recovery"
neillm22:19
Maybe you didn't use the --build-boost arg? install.sh is best when it builds all dependencies and doesn't require system libs (to avoid version conflicts, etc).
Daniel Krawisz22:20
Thanks, trying install.sh with --build-boost
neillm22:20
It's for the secp256k1 configure script, btw.
neillm22:21
install.sh will build the required version (you can see that it passes the args there when building if you take a peek at install.sh).
Daniel Krawisz22:24
compiling now.
Daniel Krawisz22:27
src/.libs/libbitcoin-system.so: undefined reference to `boost::re_detail_106900::put_mem_block(void*)
neillm22:29
Can't say without seeing the system, but the 2 things I'd recommend when using install.sh: 1) Make sure the --prefix=/path path doesn't exist (or rm- rf it if it does), 2) If it looks like system boost is still being picked up by configure (I've seen this on some, but not all systems), use PKG_CONFIG_PATH=/home/me/install-path/lib/pkgconfig ./install.sh --prefix=/home/me/install-path --build-boost
(edited)
neillm22:31
A few edits there, but I think I got that right there 😉
Daniel Krawisz22:31
Hmm ok but won't that install it in my home directory?
neillm22:32
That example would install it in $HOME/install-path. You can pick wherever of course
neillm22:33
It's not recommended to install to system as root, but I know some people that do that. It can cause future build issues when conflicts arise
neillm22:34
I realize the docs literally say to do the sudo make install, so let me clarify that I don't recommend that, as it causes issues on future builds
Daniel Krawisz00:28
How do I uninstall from root?
neillm00:29
Not sure, personally, I haven't had to do that. You can try the standard 'make uninstall' from each of the repos I suppose(?)
(edited)
Daniel Krawisz00:29
Oh ok
Daniel Krawisz00:34
Ok trying again
Daniel Krawisz00:56
Aha it worked. Thank you!
👍 1
evoskuil03:12
Boost is problematic because it gets installed in so many variations by so many apps. DLL hell on Linux. The trick is to isolate it to a prefix dir, as you’ve done.
Daniel Krawisz13:42
Can you tell me about what's going on with libsecp256k1? what does --enable-module-recovery actually do?
neillm13:54
Cryptography Stack Exchange
It is possible to recover the public key from an ECDSA signature values $(r,s)$? Please explain how this works.
Daniel Krawisz14:26
Ahh thanks.
Daniel Krawisz16:34
How does libbitcoin-blockchain work without libbitcoin-consensus?
evoskuil16:35
It uses its native script implementation in libbitcoin-system.
Daniel Krawisz16:36
Oh ok
Daniel Krawisz16:41
Does it work WITH libbitcoin-consensus? I'm asking because I just noticed something in libbitcoin-blockchain that says verify_script automatically fails if use_libconsensus is true!
neillm18:13
I haven't tested it recently in master, but there are at least 2 version3 mainnet servers, and 1 of them runs with consensus, the other without. The last I did test it in master, it was also working well.
evoskuil15:23
I think you are misinterpreting the source.
evoskuil05:38
The failure only occurs if attempting to use libconsensus when it has not been compiled and linked.

Tuesday, April 9, 2019

skaht03:06

Wednesday, April 17, 2019

N
narodnik14:29
@Daniel Krawisz you need to configure secp256k1 with --enable-recovery flag
🐛 1
--enable-module-recovery

Thursday, April 18, 2019

J
James04:19
@evoskuil which points about V4 are not yet optimal? By the way, if i'd like to try headers-only sync, where in the code would i need to change something to altogether turn off block data retrievals?
evoskuil06:54
Just detach the block-in protocol in the sessions.
A
adys08:36
Hi ,I am trying to build on windows, clone all repo, build the solutions by the recommended order. BX solution complied and working, but I don't have bitcoin.hpp and other generated files, so new project that I created is not compiling when including <bitcoin/bitcoin.hpp>. What I need to do to generate them? Also, where do I see all the include files? All I see is $(MSBuildThisFileDirectory)include\;%(AdditionalIncludeDirectories), I want to know how to add it properly for my new project. Thanks!
(edited)
evoskuil08:38
Are you building a new project or BX?
Oh, nvm
A
adys08:39
BX is ok. I want to compile James examples on windows. On mac and Ubuntu no issues, but unfortunately at work I am with windows...
evoskuil08:39
If you just need libbitcoin-system I recommend starting by modifying its examples project.
You need to properly import the props file, which is demonstrated by that project.
(edited)
A
adys08:41
Yes, there is not project, so I wanted to create one for each example, for windows.
I will look in the props file, didn't knew that (been a while since I created cpp project from scratch 🙂 ) . Thanks
But the main question - how to generate those files? bitcoin.hpp etc?
evoskuil08:43
There in not an examples project?
A
adys08:43
I copied them from ubuntu but that raise diff compile issue
evoskuil08:43
You download them, they are in the repo.
A
adys08:43
no, no project for windows
evoskuil08:43
??
Download the repo to a windows folder and open the solution.
A
adys08:49
I downloaded, build all solutions successfully (manually in vs2017, one by one) , there is not a bitcoin.hpp on my computer.
so, all uses of #include <bitcoin/bitcoin.hpp> are not working...
(edited)
👍 1
evoskuil08:52
That’s not possible
A
adys08:55
Searched again on all disk - not such file on my computer ( I have it on ubuntu and mac both - not on windows)
I don't see any use of it in the repo I complied, also search for it, all the reops I downloaded are comping - but they don't use bitcoin.hpp - I double searched
evoskuil08:58
Don’t know what to tell you. The files in the repo are the same no matter what OS you use.
A
adys08:58
What repo?
system?
evoskuil08:58
It’s in the libbitcoin-system repo, which is a dependency of all others.
A
adys08:59
there is not such file in this repo, also on github
Its suppose to be a generate file, no?
cause no such file in the repo, I am checking now in github
evoskuil09:00
No
A
adys09:00
Maybe I wansnt clear enough - I am talking about this file:
/////////////////////////////////////////////////////////////////////////////// // Copyright (c) 2014-2015 libbitcoin developers (see COPYING). // // GENERATED SOURCE CODE, DO NOT EDIT EXCEPT EXPERIMENTALLY // /////////////////////////////////////////////////////////////////////////////// #ifndef LIBBITCOIN_BITCOIN_HPP #define LIBBITCOIN_BITCOIN_HPP /** * API Users: Include only this header. Direct use of other headers is fragile * and unsupported as header organization is subject to change. * * Maintainers: Do not include this header internal to this library. */ #include <bitcoin/bitcoin/compat.h> #include <bitcoin/bitcoin/compat.hpp> #include <bitcoin/bitcoin/constants.hpp> #include <bitcoin/bitcoin/define.hpp> #include <bitcoin/bitcoin/error.hpp> #include <bitcoin/bitcoin/handlers.hpp> #include <bitcoin/bitcoin/version.hpp>
now such file as bitcoin.hpp...
do I need to clone other way? what am I missing here?
evoskuil09:05
Oh, in V4 it’s system.hpp
Again, if you simply modify the examples project it will work, and it demonstrates proper import and Unicode integration.
A
adys09:11
Ok I see. I understand now what happened. in mac and ubuntu I used the v3 script, and no such script in windows as I just took the latest repo and complied one by one. Any way to get the same behave on windows - to get fully V3 working?
evoskuil09:13
Download the v3 repo, compile it, and modify the examples project.
👍 2
A
adys10:19
Ok, downloaded libbitcion-system repo, version3 branch. opened solution, restore nugets, rebuild. libbitcoin project is compiling Ok. Test and examples project are not - again missing bitcoin.hpp - that now exist in the include folder. Anyway to fix that without adding path manually to the projects?
A
adys10:27
Also libbitcoin-network... c:\sources\crypto\libbitcoin\libbitcoin-network\include\bitcoin\network\protocols\protocol_address_31402.hpp(23): fatal error C1083: Cannot open include file: 'bitcoin/bitcoin.hpp
evoskuil10:30
Nothing is required for trstband example except to download the system repo, set up NuGet and build the solution.
(edited)
@pmienk can you please take a look, I’m on the road.
evoskuil10:53
*test and example
A
adys12:31
I will write the steps here to see if I did everything right: C:\Sources\Crypto\libbitcoin_local>git clone -b version3 https://github.com/libbitcoin/libbitcoin-system.git open this solution in vc2017 enterprise edition: c:\Sources\Crypto\libbitcoin_local\libbitcoin-system\builds\msvc\vs2017\libbitcoin.sln rebuild ( all nugets ok) libbitcoin passing, the 2 other libs are failing. 2>c:\sources\crypto\libbitcoin_local\libbitcoin-system\examples\main.cpp(21): fatal error C1083: Cannot open include file: 'bitcoin/bitcoin.hpp': No such file or directory 2>Done building project "libbitcoin-examples.vcxproj" -- FAILED. 3>block.cpp 3>Unknown compiler version - please run the configure tests and report the results 3>c:\sources\crypto\libbitcoin_local\libbitcoin-system\test\chain\block.cpp(20): fatal error C1083: Cannot open include file: 'bitcoin/bitcoin.hpp': No such file or directory 3>Done building project "libbitcoin-test.vcxproj" -- FAILED. ========== Build: 1 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========
libbitcoin-examples was missing in its prop file under section <ClCompile>: <AdditionalIncludeDirectories>$(RepoRoot)include\;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
same for tests
neillm12:35
@adys I don't use the windows builds, but @pmienk should be able to help there. In the meantime, can you be sure of a proper checkout by pasting what you see for git reflog?
A
adys12:37
Yes, I know I avoid windows when I can 🙂 but this time I need to, and I also want others to be able to run the examples
(edited)
git reflog 159783c8 (HEAD -> version3, origin/version3) HEAD@{0}: clone: from https://github.com/libbitcoin/libbitcoin-system.git
neillm12:38
Ok, thanks, that looks correct. Had to be sure since the failure to open bitcoin.hpp is something that could easily happen in master, but should not in version3.
A
adys12:39
now its compiling after I change the prop files.. but I seems like all the projects suffer from this issue
also, now its can't link
2>LINK : fatal error LNK1104: cannot open file 'libbitcoin.lib'
* for both tests and examples
neillm12:42
Understood. I don't see anything obviously wrong with the .props or project files in v3, but without being able to test myself, I'm at a loss. Hopefully @pmienk chimes in soon.
(edited)
It may help to look at the last automated CI build log?
Not sure if helpful, they seem to use the vs2013 builders
evoskuil12:47
Yes, we always CI on the oldest supported platforms/dependencies
neillm12:48
👍 I was just hoping to glean some information that may be useful for @adys from the log, but having a quick look, not sure if that's a good route to go. Worth a look though.
evoskuil12:51
The builds should be the same and CI should be clean.
I’ve built v3 recently and build v4 regularly on Windows.
A
adys12:54
perhaps I need to do something to make it work?
I am not familiar with prop files
Its look like libbitcoin.import.props is not importing for both project or something...
evoskuil12:58
It’s automatically configured in generated sources.
A
adys13:12
BTW - I didn't have that with version 4
everything compiled successfuly, I had issues with the new project I created, but everything else compiled
pmienk21:13
@adys, @evoskuil I've rebuilt on windows. It works fine for version3 if you use the install script from version3. Remember that the migration between libbitcoin and libbitcoin-system was not meant to introduce alteration to version3. For that reason all props files expect the libbitcoin name for the repository instead of libbitcoin-system. If we're okay with modifying to libbitcoin-system as the canonical path now it would be relatively simple to alter the paths in all necessary props as it's already been done for master. Its just a matter of mindfully avoiding the lib/dll rename.
(edited)
if instead you clone libbitcoin-system for version3 or libbitcoin-system for master and change branches, you'll encounter breaks related to pathing through the repository name.
evoskuil21:30
We don’t want to change v3 for compatibility reasons. What script are you referring to (Windows)?
pmienk21:32
sorry, on windows i still trigger shell scripts and merely invoke developer_setup.sh (personally maintained, install.sh variant) to trigger initialization of my environment
the requirement is that initializing the environment for version3 requires git clone https://github.com/libbitcoin/libbitcoin
👍 1
modification to encode libbitcoin-system as the expected path while still producing libbitcoin.<lib/dll> should be simple, it just wasn't viewed as consist given the intent for install.sh to continue to behave as it does.
evoskuil21:46
I think a note in the v3 Windows readme should be sufficient.
evoskuil22:22
Malwarebytes Labs
Threat actors are relentlessly phishing and attacking Electrum Bitcoin wallet users, racking up millions of dollars.
💸 1👍 2

Sunday, April 21, 2019

A
adys11:16
@evoskuil @pmienk Thanks for the help, it works now. * simple renaming libbitcoin-system to libbitcoin fix the issue for now.
👍 1
Great library, I am enjoying learning it thanks to @James C. excellent examples. I will do my best to create windows solutions for the examples and hopefully I will be able to contribute some in the future.
👍 1
evoskuil11:21
👍👍

Wednesday, April 24, 2019

Friday, April 26, 2019

A
adys00:53
Hi, I am trying to direct bx to testnet, but from some reason bx is ignoring bx.cfg settings, no matter what I tired: file on this location: <prefix>/etc/libbitcoin/bx.cfg - not working file on this location: /usr/local/etc/libbitcoin/bx.cfg - not working BX_CONFIG environment variable - not working either. Ubuntu 16.04
using it with -c is working:
bx fetch-height -c /home/adys/Sources/libbitcoinbx/etc/libbitcoin/bx.cfg 1512308
neillm00:54
Hrm, I regularly use BX_CONFIG
A
adys00:54
echo $BX_CONFIG /home/adys/Sources/libbitcoinbx/etc/libbitcoin/bx.cfg
neillm00:54
And ls -al $BX_CONFIG
A
adys00:54
bx fetch-height -c $BX_CONFIG 1512308
but without -c :
bx fetch-height 573244
ls -al $BX_CONFIG -rw-r--r-- 1 adys adys 2747 אפר 22 00:00 /home/adys/Sources/libbitcoinbx/etc/libbitcoin/bx.cfg
neillm00:55
Try: BX_CONFIG=/path/to/bx.cfg bx fetch-height
A
adys00:56
Yes, thats working BX_CONFIG=/home/adys/Sources/libbitcoinbx/etc/libbitcoin/bx.cfg bx fetch-height 1512309
neillm00:57
That's how I tend to use it, personally. But it should work either way. I suspect something else is going on in your environment. Running it this way eliminates that option.
A
adys00:58
Any way to use only : bx fetch-height ?
the file also in both recommended locations...
neillm00:59
Like I said, it should work, but something I can't explain without looking around your environment appears to be going on. Start a new shell and export it again and try?
A
adys01:00
same with new shell...
neillm01:00
There are many things that can go wrong -- the bx in the path, may not be the one you're expecting it to be, for example. Like if you installed to system and also to a prefix, or exported a prefix one to a path and used a different prefix at some point. Not sure
I actually regularly test several different configs, so always specifying that way is what I do out of habit to be sure I'm testing what I want to be testing.
A
adys01:02
I am trying to use it inside jupyter notebook, so I need simple bx to work...
neillm01:03
I guess debug by running bx settings and see if you can find what it's using instead. I'll be afk a bit
e.g. change all configs to silly things and see which it picks up automatically to make sure your environment and install is sane, etc.
A
adys01:04
I see, ok I will try that. thanks!
* settings is not coming from bx.cfg cause all of the copies are testnet copies but I will check again
A
adys01:17
Ok I have only one file now on my machine; BX_CONFIG=/home/adys/Sources/code-demos/setup/bx_config_files/bx.cfg bx fetch-height -> 573247 - still mainnet BX_CONFIG=/home/adys/Sources/code-demos/setup/bx_config_files/bx.cfg bx fetch-height -> 1512312 - testnet Its ignoring and taking setting from default values and not from cfg file.
2 replies · neillm · last Apr 26, 2019
neillm02:35
Did you use export BX_CONFIG=/path/to/bx.cfg, assuming a bash or bash-like shell? If not, it doesn't have the effect you're looking for.
neillm02:36
Instead of the quick test I suggested of doing ls -al $BX_CONFIG, a better test would have been to try env | grep BX_CONFIG. If you don't export it, that will return nothing.
evoskuil01:21
I use -c to config regularly.
👍 1
A
adys08:43
I switched to my mac, works on the first try with BX_CONFIG
👍 2

Monday, April 29, 2019

P
Phil21:51
What is the sense in using something like script[2] ? And a more general question, what is the sense in the returns of the function extract_output() on payment_address? https://github.com/libbitcoin/libbitcoin-system/blob/master/src/wallet/payment_address.cpp#L341
pmienk22:05
@Phil script[i] extracts the i-th operation of the script. extract_output() returns lists of addresses from within the provided script base on pattern of the script. As for the 'sense' in it, I believe it's very readable in that it's presuming patterns in the script to expect addresses
P
Phil22:46
@pmienk thanks for the fast answer! It’s much clear now