oleganza/btcruby

Comprehensive Bitcoin and Open Assets toolkit for Ruby

btcruby's Issues

OpenSSL 1.1.0 support

/usr/local/bundle/gems/ffi-1.9.21/lib/ffi/library.rb:275:in `attach_function':
Function 'SSL_library_init' not found in [libssl.so] (FFI::NotFoundError)
  from /usr/local/bundle/gems/btcruby-1.7/lib/btcruby/openssl.rb:21:in `<module:OpenSSL>'

> openssl version
OpenSSL 1.1.0f  25 May 2017

Reproducible via ruby:2.5.0 Docker image.
Related: lian/bitcoin-ruby#205

Segmentation fault at 0x00000000000018

I was running straight-server and use straight-server-kit command to create an order, then encountered an error. Output displayed on screen is:

[seven@localhost straight-server]$ bundle exec bin/straight-server -p 9696
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/bundler/gems/straight-67b2e1679fb8/lib/straight/faraday_monkeypatch.rb:1: warning: already initialized constant Faraday::SSLOptions
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/faraday-0.9.2/lib/faraday/options.rb:205: warning: previous definition of SSLOptions was here
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/bundler/gems/straight-67b2e1679fb8/lib/straight/blockchain_adapters_dispatcher.rb:8: warning: constant ::TimeoutError is deprecated
Setting config dir to /home/seven/.straight
I, [2017-03-16T17:34:45.864982 #13255] INFO -- : starting Straight Server v 1.0.0
W, [2017-03-16T17:35:00.865987 #13255] WARN -- : Please check correctness of Insight.websocket_url in the config file.
Thread.exclusive is deprecated, use Mutex
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.6.4/lib/rack/reloader.rb:36:in call' /home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/goliath-1.0.4/lib/goliath/request.rb:166:in block in process'

I, [2017-03-16T17:35:37.251286 #13255] INFO -- : GET /gateways/1/last_keychain_id
Thread.exclusive is deprecated, use Mutex
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-1.6.4/lib/rack/reloader.rb:36:in call' /home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/goliath-1.0.4/lib/goliath/request.rb:166:in block in process'
I, [2017-03-16T17:36:35.282300 #13255] INFO -- : POST /gateways/1/orders
{"amount"=>"1.0", "callback_data"=>"1", "keychain_id"=>1}
I, [2017-03-16T17:36:35.282800 #13255] INFO -- : Creating new order with attrs: {:amount=>"1.0", :currency=>nil, :btc_denomination=>nil, :keychain_id=>1, :callback_data=>"1", :data=>nil, :description=>nil, :after_payment_redirect_to=>nil, :auto_redirect=>nil}
/home/seven/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/btcruby-1.1.1/lib/btcruby/openssl.rb:109: [BUG] Segmentation fault at 0x00000000000018

Add support for libsecp256k1

We should eventually migrate off OpenSSL to libsecp256k1. At least, start with ECDSA signing. See https://github.com/GemHQ/secp256k1-rb

TransactionBuilder InsufficientFunds error ideally should return sensible information

When using TransactionBuilder class to build from a set of utxos, it'd be very much essential to figure out sensible information out of InsufficientFunds error.

For example, information like:

1. How much fund is short
2. What is the calculated mining_fee as per rate (to see if the shortage is just the mining_fee)

straight-server build fails with "uninitialized constant BTC::ScriptChunk::OP_PUSHDATA4"

https://travis-ci.org/MyceliumGear/straight-server/builds/76432132

/home/travis/.rvm/gems/ruby-2.2.1/gems/btcruby-1.1.4/lib/btcruby/script/script_chunk.rb:150:in `with_data': uninitialized constant BTC::ScriptChunk::OP_PUSHDATA4 (NameError)
    from /home/travis/.rvm/gems/ruby-2.2.1/gems/btcruby-1.1.4/lib/btcruby/script/script.rb:31:in `initialize'
    from /home/travis/.rvm/gems/ruby-2.2.1/gems/btcruby-1.1.4/lib/btcruby/block.rb:33:in `new'
    from /home/travis/.rvm/gems/ruby-2.2.1/gems/btcruby-1.1.4/lib/btcruby/block.rb:33:in `genesis_mainnet'
    from /home/travis/.rvm/gems/ruby-2.2.1/gems/btcruby-1.1.4/lib/btcruby/network.rb:35:in `mainnet'

Is something wrong on our side?

Multisig: same order of public keys produces different address (vs coinb.in/#newMultiSig)

Not sure if this is a bug or I'm missing something.

I'm attempting to generate the same addresses as a multisig Electrum wallet using this library. When I enter the public keys into coinb.in of each address generated in Electrum, I get the same address as the one in Electrum, as long as I lexicographically order the public keys.

Using this library, I am not able to generate the same addresses. Here's the script I'm using:

require "btcruby"

# For context, not actually used in the script below.
cosigners = [
  {
    electrum_seed: "hotel congress unable service silver wool fabric ski buffalo orbit damp enjoy",
    master_public_key: "xpub661MyMwAqRbcGHY2QrfyiUyvSv93zCQN8Cv3eXFB3ivnq7SQ6TLUJueJnGZKR8r8CQ5cLsGrr9D71uwAW9RLKqFyUybARtbbqg1kiHopBsZ",
  },
  {
    electrum_seed: "trust diary skull hidden album awesome lady zoo polar gorilla alley credit",
    master_public_key: "xpub6D4K8Hb6sMZwwtbk6p94RnRewTb6PykJc1zZwB3GUozGSNXLnTdL2T8uXRehiD9d5Dis3bDpJCvR3pFZcYUu2xpPj5Z73oFNUUQKwkFTewo",
  },
]

# Copied from electrum 1-of-2 multisig wallet using the keys above. public_keys order is as shown in the address' "details" window of Electrum.
addresses = {
  0 => {
    address: "3GbE5Hn5NNfAbkk33AquoZqtoehkDDBEZn",
    public_keys: [
      "02c71e2fd1793943296f2c708ee44d0c7df113b3d9f6808180801835d510beb794",
      "036822f8013573775f7cb0c9aa1cbf7fba9b59480af59415685328a334b5f5c369",
    ],
    redeem_script: "512102c71e2fd1793943296f2c708ee44d0c7df113b3d9f6808180801835d510beb79421036822f8013573775f7cb0c9aa1cbf7fba9b59480af59415685328a334b5f5c36952ae",
  },
  4 => {
    address: "35gx2GzbtVy116Ai2kop8u95xWVHYfFPne",
    public_keys: [
      "03b064e3adf933622eff9b33e7dbc881e1bc9ec3030f96bf0ddd53cabd862adf7c",
      "0228f4d23588f5dd93ad64c1d1502f43c779e9d3811fcbe8af5f54faf585f68ece",
    ],
    redeem_script: "51210228f4d23588f5dd93ad64c1d1502f43c779e9d3811fcbe8af5f54faf585f68ece2103b064e3adf933622eff9b33e7dbc881e1bc9ec3030f96bf0ddd53cabd862adf7c52ae",
  },
  9 => {
    address: "3C1KyYDMg8woFnZZXqfmkdvUEJuLMuajCV",
    public_keys: [
      "03b84384cd966c8554ddc2303101fd416f5b4f260161c788d6c62d6c6d293b4880",
      "0336e728be1b9370565204b5de4050d418704cc9c5c2db47f13be30173f7f5bd46",
    ],
    redeem_script: "51210336e728be1b9370565204b5de4050d418704cc9c5c2db47f13be30173f7f5bd462103b84384cd966c8554ddc2303101fd416f5b4f260161c788d6c62d6c6d293b488052ae",
  },
}

addresses.each do |idx, addr_details|
  public_keys = addr_details[:public_keys].sort
  multisig_script = BTC::Script.
    multisig(public_keys: public_keys, signatures_required: 1)
  p2sh_script = multisig_script.p2sh_script
  generated_addr = p2sh_script.standard_address.to_s
  if generated_addr == addr_details[:address]
    puts "YES MATCH:"
    puts "We generated the same one for address #{idx}: #{addr_details}"
  else
    puts "NO MATCH:"
    puts " - Generated address from lexicographically ordered keys: #{generated_addr}"
    puts " - Expected address: #{addr_details[:address]}"
  end
end

puts "Done"

Links to coinbin:

• Address 0
• Address 4
• Address 9

BTC::Keychain is not generating testnet addresses

Hi,

Looks like BTC::Keychain is not taking the network config (testnet in my case) into account:

2.3.4 :021 > a = BTC::Keychain.new(seed: BTC::Data.random_data, network: BTC::Network.testnet)
 => #<BTC::Keychain:0x007fb7259b31b8 @network=#<BTC::Network:0x007fb725805190 @name="testnet3", @genesis_block=#<BTC::Block:000000000933ea01ad0ee984 ver:1 prev:000000000000000000000000 merkle_root:4a5e1e4baab89f3a timestamp:1296688602 bits:0x1d00ffff nonce:0x18aea41a txs(1): [#<BTC::Transaction:4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b v1 inputs:[#<BTC::TransactionInput prev:0000000000[4294967295] script:"">] outputs:[#<BTC::TransactionOutput value:50.00000000 script:"04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG">]>]>, @genesis_block_header=#<BTC::BlockHeader:000000000933ea01ad0ee984 ver:1 prev:000000000000000000000000 merkle_root:4a5e1e4baab89f3a timestamp:1296688602 bits:0x1d00ffff nonce:0x18aea41a>, @max_target=215676282328090475945251810757791930688087189908593312689102184775680, @testnet=true>, @public_key="\x03#u~@\xBC\xB2\x0Fl\xF5\xD7\xBA\x86\xC9\xECdbI\xEF\xD6]J6\x03\xABO\xFE\x82\a\xEDu\xEA\xD2", @depth=0, @parent_fingerprint=0, @index=0, @chain_code="P\xC9\x0F+I\n\xED\ajk\xE7vw\xC3\xC6\xF92W\x86\x88F\x7Fo\xF7\x90\xE7\x9A23\xE0\xC0\xF6", @fingerprint=nil, @private_key="\x98\x16\x19\e\x92\x1C'\xE2H\xAF\x835v\xE8x\xF2G9yx*\x19\xD4\fk\x83}\x86\xC3*\xE4\xC8">

2.3.4 :023 > a.derived_key(1).network
 => #<BTC::Network:0x007fb726908870 @name="mainnet", @genesis_block=#<BTC::Block:000000000019d6689c085ae1 ver:1 prev:000000000000000000000000 merkle_root:4a5e1e4baab89f3a timestamp:1231006505 bits:0x1d00ffff nonce:0x7c2bac1d txs(1): [#<BTC::Transaction:4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b v1 inputs:[#<BTC::TransactionInput prev:0000000000[4294967295] script:"">] outputs:[#<BTC::TransactionOutput value:50.00000000 script:"04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG">]>]>, @genesis_block_header=#<BTC::BlockHeader:000000000019d6689c085ae1 ver:1 prev:000000000000000000000000 merkle_root:4a5e1e4baab89f3a timestamp:1231006505 bits:0x1d00ffff nonce:0x7c2bac1d>, @max_target=26959535291011309493156476344723991336010898738574164086137773096960>

2.3.4 :022 > a.derived_key(1).address.to_s
 => "1Db5tEgm73mwGuKryJcSc1r2w9U57V5N8o"
# is obviously NOT a testnet address

Hope i didn't miss anything?

Edit:

Same happens also with tpub:

keychain = BTC::Keychain.new(xpub: "tpubD8v67BgSqFQzKPVxN6Bs5xUeWX9Pu4geg9KkNUQ8hPPZeaSszkdBGnDwsDWXCsxt4msPaWcHJBYuRSwjJAF2fZeh1ZcEyH5J1ccLv7KKV4z").derived_key(0).address.to_s
=> "1HVB1Qn4xmabSmJBDS3aNCV4smQzeK3x6y"

keychain = BTC::Keychain.new(xpub: "tprv8cE3xmeCgsjKRvUAUSXGgYpXwVdTjjVk6qiy5xMqH7bAp6C7NMob6Hc5h68Ld2EwiyNnJJ9BdzQ83g7t5cLEwr9RwrQPDykJzahgwWYPnxC").derived_key(0).address.to_s
 => "1HVB1Qn4xmabSmJBDS3aNCV4smQzeK3x6y"

Open asset library example?

Hello,

Do u have an example to show how to use the open asset library?

BR,
Terry

Deriving addresses for p2sh setup

I'm looking for a way, outside of Electrum, to derive addresses from a multisig setup. I'm not very familiar with this aspect of Bitcoin.

I've looked through the P2SH and Keychain documentation in this gem and I didn't see examples on how to do this, assuming it's possible with this library.

Any help is appreciated!

Support for BIP49 (segwit) address?

Hello

Is it possible to generate segwit style addresses as defined in BIP49? It should be compatible with BIP44 and only require change to derivation path, but I am not able to generate proper segwit addresses. It also seems impossible to generate addresses using custom derivation path without private key part?

k=BTC::Keychain.new :xpub => "xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz"
k.derived_key("m/49'/0'/0'/1'").address

The result is BTC::BTCError: Not possible to derive a hardened keychain without a private key (index: 49).

If I do initialize it with xprv instead, for example

k=BTC::Keychain.new :xprv => "xprv9s21ZrQH143K4KqQx9Zrf1eN8EaPQVFxM2Ast8mdHn7GKiDWzNEyNdduJhWXToy8MpkGcKjxeFWd8oBSvsz4PCYamxR7TX49pSpp3bmHVAY"
k.derived_key("m/49'/0'/0'/1'").address
# => #<BTC::PublicKeyAddress:1AgPR8sjddSPY4ZQsZet5JxjEJTLrSMqVK>

It does generate address, but not segwit style.

Can you please tell me if I am doing something wrong? Ideally I want to generate segwit style addresses with only xpub.

Release a new gem version

The last release is more than 2,5 years ago and but there is development ongoing. Could you release a new version? Mycelium Straight is based on btcruby, so careless people (like me) install a pretty old version of btcruby!!!