Maand: november 2018

anyone ever had a similar issue where the directory exists but bitcoin-cli isn’t recognizing it? Perhaps this is related to me setting the folder up as a symlink to my external HDD?

Thank you!
aaronson

-Mac-mini:~ $ bitcoin-cli -regtest generate 1
Error reading configuration file: specified data directory "/Users/---/Library/Application\ Support/Bitcoin" does not exist.
-Mac-mini:~ $ cd /Users/---/Library/Application\ Support/Bitcoin
-Mac-mini:Bitcoin $ ls
banlist.dat bitcoind.pid    chainstate  db.log      peers.dat
bitcoin.conf    blocks      database    debug.log   wallet.dat

I am creating the web wallet for the bitcoin , I want to allow web wallet users to set the transactions fee .

Is their is any rpc call available for setting the transactions fee (for setting transactions priority) ?

What is the counter measure against dust attack, in case somebody tries to deanonymize me?

1. Is there a possibility how to prevent somebody to send you intentional small dust, so that he can track your UTXOs?

2. I think there is no counter measure to 1. So if 1 already happens, how to deal with this in the most possible clean way and with as little leaked information as possible?

New lnd version came out recently, but I’m not sure which version I’m running. How can you check?

I compiled bitcoind using the same steps as last year. In particular I set DB_CONFIG:

set_lg_dir database
set_lk_max_locks 537000

Unfortunately once I hit block 364,670 (2015-07-10) I’m treated with:

EXCEPTION: 11DbException
Db::put: Cannot allocate memory
bitcoin in ProcessMessage()

I tried raising set_lk_max_locks to 1000000 but that didn’t help. This happens immediately when restarting the node, so it doensn’t seem to be a RAM issue.

The ~/.bitcoin/database looks rather large, assuming this is the equivalent of todays ~/.bitcoin/chainstate and “~/.bitcoin/blocks/index`.

$ du -s ~/.bitcoin
92047404 # 88 GB
$ du -s ~/.bitcoin/database
42169668 # 41 GB

How can I get the synchronization to continue?

// Note that of those which support the service bits prefix, most only support a subset of
// possible options.
// This is fine at runtime as we'll fall back to using them as a oneshot if they don't support the
// service bits we want, but we should get them updated to support all service bits wanted by any
// release ASAP to avoid it where possible.

Reference: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L116

I’m running a private regtest network on GCP. I generated a list of 2000 vanity testnet addresses ordered sequentially from prefixes mooo1 to n2ooo with their respective pub/priv key pairs, and to prevent complications, I want to only have one private key for each node (change in outgoing transactions are sent to the original address). Because there’s no security concern in my setting (it’s just a performance test, no money or attacker is involved), I want to make each bitcoind instance only use a single private key for all transactions, and not generate new addresses through an HD wallet. This is because viewing transactions is much more streamlined. I can tell which node is sending bitcoins to which other node, and diagnose issues more easily. Is there an option in bitcoind to only use a single private key?

TL;DR: Where in this code does the SV client figure out that it’s not processing an ABC blockchain?

This image prompted my question.

There are a couple different mutually incompatible (I am assuming anyway) implementations of the Bitcoin Cash cryptocurrency client software…

1. Bitcoin Cash ABC
2. Bitcon Cash SV

My question assumes that each implementation processes their respective transactions using similar but mutually-incompatible blockchain processing rules.

Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa? How, then, does one implementation know that the network it is running in, is (in)compatible with its particular processing rules?

Ones tokens are issued by smart contracts on a existing blockchain, for example Bitcoin and distributed to the community, who and in wich currency the transaction fees will be realized ?

In this question What are the advantages of Schnorr vs ECDSA? I see in the Pieter Wuille’s answer the following comment about Schnorr signature batch validation: "Improving verification speed, by supporting batch validation of all signatures in a block at once (for a fraction of the speed of validating them individually)."

However, looking at the chart in the BIP here it seems that savings are actually closer to a factor of log(n). In other words, for about 10,000 signatures the time savings are about 2.5X. I know that technically that is a fraction, but it seemed that the implication was that the improvement was more dramatic.
Is there something I am missing? Also, what is the actual time in clock cycles that was a starting point for one Schnorr signature verification?
Thank you.