Maand: juli 2015

There are quite a lot of bitcoin faucets on the Internet. They give away bitcoin for free, but where do they come from? Won’t the faucet operator lose money?

I’m looking into the data and source of bitcore-node ( http://bitcore.io/ ), I’m a bit confused how all the information is stored in the database, probably it’s in a similar way to others block explorers, so maybe someone could help me.

In this case for example https://blockchain.info/tx/acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42

In the database I found two txo- txo-acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42-0

{"prevTxId":"8697331c3124c8a4cf2f43afb5732374ea13769e42f10aa3a98148a08989af5e","outputIndex":1,"sequenceNumber":4294967295,"script":"4730440220106c316c22d4bf8c970f8e4b1af1edd95121397cfe29ab987cb000b478ec8e4302202b77986b89d77ab716da3cf53424efacf35e9097b1c89194df220e99503b8cae01","scriptString":"71 0x30440220106c316c22d4bf8c970f8e4b1af1edd95121397cfe29ab987cb000b478ec8e4302202b77986b89d77ab716da3cf53424efacf35e9097b1c89194df220e99503b8cae01","heightConfirmed":37514}

txo-acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42-1

{"satoshis":10100000000,"script":"76a91427d25a1ff9a6da31eeb991c48bb6cd95191a6b2c88ac"}

Clearly different data, not sure why in one case we store the previous txid and in the other just the satoshis sent. It has to be obvious, but not sure what I’m missing here.

Another example https://blockchain.info/tx/00eff263871e6d44abed66d90abb10d5a211441668511dba3146e380360efe4b

txo-00eff263871e6d44abed66d90abb10d5a211441668511dba3146e380360efe4b-0 (from 0 to 5 all have similar data)

{"prevTxId":"6aebb4a764a027436f703ca9d42d0735423798f56973f9f236832a91fc2e9026","outputIndex":0,"sequenceNumber":4294967295,"script":"473044022057801e812f964bcb9e8ff17b37acef55afbb7119a66f24a148ba65e86a7aa1e3022064af657d280068b979ea17a29969976aedee8a664b3f1b575ebb88ef9275302601","scriptString":"71 0x3044022057801e812f964bcb9e8ff17b37acef55afbb7119a66f24a148ba65e86a7aa1e3022064af657d280068b979ea17a29969976aedee8a664b3f1b575ebb88ef9275302601","heightConfirmed":10712}

Also,… they are inputs, not outputs of the transaction.

I’m trying to read the code, but I can’t get to understand all the pieces.

As someone points me in reddit, it looks like it’s using txo– to store both, outputs and inputs. So I’m not sure how bitcore manages to get the inputs/outputs separately later (the API allows you to request only the inputs for example).

I try to implement the payment processing API from blockchain.info
I created a request by the example of their website, and receive a generated bitcoin adress:

See an example here: https://blockchain.info/address/1Jv2S3iMo71c1WZEuE25Gemx7qjmqcVqNX
I send 0.001 BTC to that adress. It has already 8 confirmations atm. But when are they send to my adress? How much confirmations does blockchain.info needs?

Thank you

My concern isn’t with individual bitcoin users but governments, what if a government spammed the network with say $1 Billion dollars worth of tiny dust transactions, including fees? The backlog of unconfirmed transactions would seem to effectively render the blockchain useless at that point and people would no longer have trust in or want to wait for transactions to confirm. This seems like it could be a major issue for the protocol…are their any defenses in place currently for some type of attack like this?

I’d like to know what’s the probability of a sybil attack and if there are mechanisms built in to prevent this kind of attack?

I’ve heard a couple of times “a shorter blocktime is unsafe,” (first about Litecoin and now Ethereum) but never understood why. Is it the higher probability of a fork? Why do some people consider a shorter blocktime less safe?

I am having trouble with the bitcoin-ruby gem. I get the following error when trying to send money to another address I have on the test network:

/var/lib/gems/2.2.0/gems/bitcoin-ruby-0.0.7/lib/bitcoin/protocol/txout.rb:76:in
pk_script=': undefined methodbytesize’ for nil:NilClass
(NoMethodError)

I am generating a private key with:

def new_address
 Bitcoin::generate_address
end

And getting details for the private key with:

def key_details(prikey, pubkey)
  #returns prikey, prikey_hash58, pubkey_hash58, pubkey_uncompressed, address as a hash
  my_key = Bitcoin::Key.new(prikey, pubkey)
  { prikey:prikey, 
    prikey_base58:my_key.to_base58, 
    pubkey_58:my_key.hash160, 
    pubkey: my_key.pub_uncompressed, 
    address:my_key.addr
  }
end

The code I have to send money to myself is as follows:

require 'bitcoin'
require_relative 'utilities.rb'
require 'open-uri'

Bitcoin.network = :testnet3

def build_transaction(prev_tx, prev_out_index, key, value, addr, message)
  include Bitcoin::Builder

  new_tx = build_tx do |t|
    t.input do |i|
      i.prev_out prev_tx
      i.prev_out_index prev_out_index
      i.signature_key key
    end
    t.output do |o|
      o.value value 
      o.script {|s| s.type :address; s.recipient addr }
    end
  end
end

def prev_tx(prev_hash, network)
  if network == "testnet3"
    prev_tx = Bitcoin::P::Tx.from_json(open("http://test.webbtc.com/tx/#{prev_hash}.json"))
  else
    prev_tx = Bitcoin::P::Tx.from_json(open("http://webbtc.com/tx/#{prev_hash}.json"))
  end
end

def key(publ_key, priv_key)
  key = Bitcoin::Key.new(priv_key, publ_key)
end

def bin_to_hex(s)
  s.unpack('H*').first
end

#transaction inputs
priv_key = "private_key"
publ_key = "public_key_long_format"
address = "address"
previous_tx = "previous_tx_hash"

# generate tx info off inputs
key = Bitcoin::Key.new(priv_key, publ_key)
prev_tx = prev_tx(previous_tx, "testnet3")
prev_out_index = 1
tx_value = prev_tx.outputs[prev_out_index].value

# build new tx
tx = build_transaction(prev_tx, prev_out_index, key, tx_value, address, "hello")

#
# puts tx.to_json
puts bin_to_hex(tx.to_payload)

If the bitcoin protocol were changed so that the merkle root from block N-1 were replaced in block N by the two roots of blocks N-2 and N-3, then it would become possible to mine 2 blocks at a time in parallel and increase the block frequency compared to the time each block took to propagate. Each block would still get confirmed by 6 of the following 7 blocks. The block size variance could be controlled by requiring that transactions with odd hashes go into odd-numbered blocks and vice-versa. What would be the limitations of this variant protocol compared to the existing Bitcoin protocol, assuming nobody considered one confirmation to be much better than zero?

What metrics can I use as indicators of the health of (a) a full bitcoin node I am running and (b) the bitcoin network as a whole.

Some examples I’ve considered: recency of last block I received on my node is a good indicator of (a) or (b) — if a long time passes, I have an indication that either my node or the network is not in a good state. The number of full nodes (N) participating in the network is a good measure of (b). N is difficult to measure but the folks here are taking a good run at it: https://getaddr.bitnodes.io/

What other metrics should I look at on my nodes or on broader level across the network, to gauge the health of my nodes and the network?

I want to create ECDSA signature {r,s} where r is very low (for example 1) and can be encoded in DER-format in one byte.

How to calculate k value? Seems to me that it does not depend of anything. What is the value of k which produces r=1 ?

Note: I do not worry for the safety of my private key while publishing this signature.