Maand: februari 2019

How to sign raw transaction with private key.
this is my raw transaction :

0200000001fcd54594bba82795afa84ebf500b3944546117c9371e951fc4539e7455ebafb20000000000ffffffff01b8f902000000000017a914b4e6b1471691d9e9e54cd19d39c8565bcadeb3338700000000

which is made by bitcoin-cli createrawtransaction .

That raw transaction made in server.

And I want to sign this raw transaction in my local PC.
How do I sign that with private key?

Please let me know with the sample code.
My language is java.

Very Thank you.

Suppose I have an address with a single UTXO. I want to create 100 transactions and sign/broadcast them all at once. Could I do the following:

1. Create a transaction by hand (where change funds are sent to the sender address)
2. Calculate the transaction ID
3. Use the transaction ID and change UTXO output index to create the second transaction
4. Go to step 2

Until I create 100 transactions? I suppose my question boils down to: Is it possible to calculate the TXID of a raw transaction before it is signed or broadcasted?

Thanks!

I am trying to create a new bitcoin address and store it in a shell variable $NEW_ADDRESS.

When I run this command:

$NEW_ADDRESS=$(./bitcoin-cli getnewaddress)

I get the following errors:

error: Could not connect to the server 127.0.0.1:8332
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
-bash: =: command not found

I have tried everything to fix the connection error, including typing the command:

./bitcoind -rpcport=8332

Or even, changing the bitcoin config:

nano ~/.bitcoin/bitcoin.conf

And typing these lines on the configuration:

rpcconnect=127.0.0.1
rpcport=8332;

But nothing works. Does anyone have an idea on how to troubleshoot and fix this?

Thanks in advance.

What is the query param to specify the decimal precision in Bitfinex API v2?

Seemly the default precision is ####.0, but i want a "precision more precise" than only one decimal place

I cannot find where to get the host to complete a lightning channel. I have tried searching in the command prompt but cannot find host info anywhere.

Assume you’re Satoshi Nakamoto, completely, and that you’ve forgotten your private key/s. How do you prove that this is true, using the BTC blockchain? Is there a transaction you can make, or a message you can sign? Remember, you don’t remember your private keys.

Fully synced on testnet blockchain after building Bitcoin with UI and wallet enabled on Ubuntu 18.10.

Pressing Send and Receive buttons results in no UI displayed.

Receiving addresses dialog doesn’t have New button in this version so it can’t be used.

Debug window getnewaddress worked, however, and I was able to receive some coins from coinfaucet.eu using that address.

After receiving coins Send button still doesn’t result in any UI displayed.
Receiving addresses menu/resulting dialog now shows the address that coins were received at (the one obtained via getnewaddress).

I see the same behavior of buttons when synced on the main net but couldn’t test sending or receiving the real Bitcoins.

What can I do to debug this issue without getting deep into the (quite unfamiliar at this point) source code? I compiled bitcoin with optimizations enabled.

Here is a link to the debug.log created in the following way: exited bitcoin-qt and renamed original log which was huge. Restarted bitcoin-qt with options -testnet -debug=1. Clicked on Send, Receive and Transactions buttons. Exited bitcoin-qt.

Reading Blockstream’s introduction article on Eltoo and one paragraph says:

[..] in eltoo all participants share a common set of transactions, unlike LN-penalty, which requires asymmetry in which participant has access to which transactions, in order to tailor the reaction to the misbehaving party. This change eliminates what we call toxic information in Lightning. Toxic information comes from transactions belonging to outdated states, which if leaked will result in the loss of funds. This happens not only if a party misbehaves, but also if a node forgets about an update (e.g., when being restored from a backup). With eltoo this is no longer possible because only agreed-upon states can be settled (i.e., eltoo is penalty-less).

What this seems to imply to me is that it’s not possible to broadcast an old channel state and have it accepted by the network, and this would seem to greatly simplify some design issues we’re dealing with today. I strongly feel like I’m misunderstanding something here and would love to get clarification from someone more knowledgeable. Thanks

Im trying to make Stadicus guide work for both Bitcoin Core & LND

I did download the blockchain and moved to the HDD on my Rasp3

However, when starting the bitcoind service, im having this debug.log

2019-02-23T23:47:58Z Bitcoin Core version v0.17.1 (release build)
2019-02-23T23:47:58Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-02-23T23:47:58Z Assuming ancestors of block 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 have valid signatures.
2019-02-23T23:47:58Z Setting nMinimumChainWork=0000000000000000000000000000000000000000028822fef1c230963535a90d
2019-02-23T23:47:58Z Using the 'standard' SHA256 implementation
2019-02-23T23:47:58Z Default data directory /home/bitcoin/.bitcoin
2019-02-23T23:47:58Z Using data directory /home/bitcoin/.bitcoin
2019-02-23T23:47:58Z Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2019-02-23T23:47:58Z Using at most 40 automatic connections (1024 file descriptors available)
2019-02-23T23:47:58Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-02-23T23:47:58Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-02-23T23:47:58Z Using 4 threads for script verification
2019-02-23T23:47:58Z scheduler thread start
2019-02-23T23:47:58Z HTTP: creating work queue of depth 16
2019-02-23T23:47:58Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-02-23T23:47:58Z HTTP: starting 4 worker threads
2019-02-23T23:47:58Z Using wallet directory /home/bitcoin/.bitcoin
2019-02-23T23:47:58Z init message: Verifying wallet(s)...
2019-02-23T23:47:58Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-02-23T23:47:58Z Using wallet wallet.dat
2019-02-23T23:47:58Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2019-02-23T23:47:58Z Cache configuration:
2019-02-23T23:47:58Z * Using 2.0MiB for block index database
2019-02-23T23:47:58Z * Using 8.0MiB for chain state database
2019-02-23T23:47:58Z * Using 90.0MiB for in-memory UTXO set (plus up to 47.7MiB of unused mempool space)
2019-02-23T23:47:58Z init message: Loading block index...
2019-02-23T23:47:58Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2019-02-23T23:47:58Z Opened LevelDB successfully
2019-02-23T23:47:58Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000

Same log goes on and on every minute.

Tried with bitcoind -reindex, however, all the reindex blocks goes to my /root/.bitcoin/blocks folder and gets filled in 2 hours (12gb of reindex)
I also don’t understand why the -reindex option goes towards to my /root/ folder instead of /mnt/hdd when i try to run bitcoind normally.

Anyone has any clue about this? Thanks you!

An even bigger loop log file

2019-02-24T14:19:56Z Bitcoin Core version v0.17.1 (release build)
2019-02-24T14:19:56Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-02-24T14:19:56Z Assuming ancestors of block 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 have valid signatures.
2019-02-24T14:19:56Z Setting nMinimumChainWork=0000000000000000000000000000000000000000028822fef1c230963535a90d
2019-02-24T14:19:56Z Using the 'standard' SHA256 implementation
2019-02-24T14:19:56Z Default data directory /home/bitcoin/.bitcoin
2019-02-24T14:19:56Z Using data directory /home/bitcoin/.bitcoin
2019-02-24T14:19:56Z Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2019-02-24T14:19:56Z Using at most 40 automatic connections (1024 file descriptors available)
2019-02-24T14:19:56Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-02-24T14:19:56Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-02-24T14:19:56Z Using 4 threads for script verification
2019-02-24T14:19:56Z scheduler thread start
2019-02-24T14:19:56Z HTTP: creating work queue of depth 16
2019-02-24T14:19:56Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-02-24T14:19:56Z HTTP: starting 4 worker threads
2019-02-24T14:19:56Z Using wallet directory /home/bitcoin/.bitcoin
2019-02-24T14:19:56Z init message: Verifying wallet(s)...
2019-02-24T14:19:56Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-02-24T14:19:56Z Using wallet wallet.dat
2019-02-24T14:19:56Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2019-02-24T14:19:57Z Cache configuration:
2019-02-24T14:19:57Z * Using 2.0MiB for block index database
2019-02-24T14:19:57Z * Using 8.0MiB for chain state database
2019-02-24T14:19:57Z * Using 90.0MiB for in-memory UTXO set (plus up to 47.7MiB of unused mempool space)
2019-02-24T14:19:57Z init message: Loading block index...
2019-02-24T14:19:57Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2019-02-24T14:20:00Z Opened LevelDB successfully
2019-02-24T14:20:00Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2019-02-24T14:20:22Z LoadBlockIndexDB: last block file = 1409
2019-02-24T14:20:22Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=120, size=133788575, heights=547036...547155, time=2018-10-23...2018-10-24)
2019-02-24T14:20:22Z Checking all blk files are present...
2019-02-24T14:20:22Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2019-02-24T14:20:26Z Opened LevelDB successfully
2019-02-24T14:20:26Z Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 81292deb9b99a760
2019-02-24T14:21:26Z 




2019-02-24T14:21:26Z Bitcoin Core version v0.17.1 (release build)
2019-02-24T14:21:26Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-02-24T14:21:26Z Assuming ancestors of block 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 have valid signatures.
2019-02-24T14:21:26Z Setting nMinimumChainWork=0000000000000000000000000000000000000000028822fef1c230963535a90d
2019-02-24T14:21:26Z Using the 'standard' SHA256 implementation
2019-02-24T14:21:26Z Default data directory /home/bitcoin/.bitcoin
2019-02-24T14:21:26Z Using data directory /home/bitcoin/.bitcoin
2019-02-24T14:21:26Z Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2019-02-24T14:21:26Z Using at most 40 automatic connections (1024 file descriptors available)
2019-02-24T14:21:26Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-02-24T14:21:26Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-02-24T14:21:26Z Using 4 threads for script verification
2019-02-24T14:21:26Z scheduler thread start
2019-02-24T14:21:26Z HTTP: creating work queue of depth 16
2019-02-24T14:21:26Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-02-24T14:21:26Z HTTP: starting 4 worker threads
2019-02-24T14:21:26Z Using wallet directory /home/bitcoin/.bitcoin
2019-02-24T14:21:26Z init message: Verifying wallet(s)...
2019-02-24T14:21:26Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-02-24T14:21:26Z Using wallet wallet.dat
2019-02-24T14:21:26Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2019-02-24T14:21:28Z Cache configuration:
2019-02-24T14:21:28Z * Using 2.0MiB for block index database
2019-02-24T14:21:28Z * Using 8.0MiB for chain state database
2019-02-24T14:21:28Z * Using 90.0MiB for in-memory UTXO set (plus up to 47.7MiB of unused mempool space)
2019-02-24T14:21:28Z init message: Loading block index...
2019-02-24T14:21:28Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2019-02-24T14:21:30Z Opened LevelDB successfully
2019-02-24T14:21:30Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2019-02-24T14:21:52Z LoadBlockIndexDB: last block file = 1409
2019-02-24T14:21:52Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=120, size=133788575, heights=547036...547155, time=2018-10-23...2018-10-24)
2019-02-24T14:21:52Z Checking all blk files are present...
2019-02-24T14:21:53Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2019-02-24T14:21:57Z Opened LevelDB successfully
2019-02-24T14:21:57Z Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 81292deb9b99a760
2019-02-24T14:22:57Z 




2019-02-24T14:22:57Z Bitcoin Core version v0.17.1 (release build)
2019-02-24T14:22:57Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-02-24T14:22:57Z Assuming ancestors of block 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 have valid signatures.
2019-02-24T14:22:57Z Setting nMinimumChainWork=0000000000000000000000000000000000000000028822fef1c230963535a90d
2019-02-24T14:22:57Z Using the 'standard' SHA256 implementation
2019-02-24T14:22:58Z Default data directory /home/bitcoin/.bitcoin
2019-02-24T14:22:58Z Using data directory /home/bitcoin/.bitcoin
2019-02-24T14:22:58Z Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2019-02-24T14:22:58Z Using at most 40 automatic connections (1024 file descriptors available)
2019-02-24T14:22:58Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-02-24T14:22:58Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-02-24T14:22:58Z Using 4 threads for script verification
2019-02-24T14:22:58Z scheduler thread start
2019-02-24T14:22:58Z HTTP: creating work queue of depth 16
2019-02-24T14:22:58Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-02-24T14:22:58Z HTTP: starting 4 worker threads
2019-02-24T14:22:58Z Using wallet directory /home/bitcoin/.bitcoin
2019-02-24T14:22:58Z init message: Verifying wallet(s)...
2019-02-24T14:22:58Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-02-24T14:22:58Z Using wallet wallet.dat
2019-02-24T14:22:58Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2019-02-24T14:22:58Z Cache configuration:
2019-02-24T14:22:58Z * Using 2.0MiB for block index database
2019-02-24T14:22:58Z * Using 8.0MiB for chain state database
2019-02-24T14:22:58Z * Using 90.0MiB for in-memory UTXO set (plus up to 47.7MiB of unused mempool space)
2019-02-24T14:22:58Z init message: Loading block index...
2019-02-24T14:22:58Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2019-02-24T14:23:02Z Opened LevelDB successfully
2019-02-24T14:23:02Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2019-02-24T14:23:23Z LoadBlockIndexDB: last block file = 1409
2019-02-24T14:23:23Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=120, size=133788575, heights=547036...547155, time=2018-10-23...2018-10-24)
2019-02-24T14:23:23Z Checking all blk files are present...
2019-02-24T14:23:24Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2019-02-24T14:23:27Z Opened LevelDB successfully
2019-02-24T14:23:27Z Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: 81292deb9b99a760
2019-02-24T14:24:28Z 




2019-02-24T14:24:28Z Bitcoin Core version v0.17.1 (release build)
2019-02-24T14:24:28Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2019-02-24T14:24:28Z Assuming ancestors of block 0000000000000000002e63058c023a9a1de233554f28c7b21380b6c9003f36a8 have valid signatures.
2019-02-24T14:24:28Z Setting nMinimumChainWork=0000000000000000000000000000000000000000028822fef1c230963535a90d
2019-02-24T14:24:28Z Using the 'standard' SHA256 implementation
2019-02-24T14:24:28Z Default data directory /home/bitcoin/.bitcoin
2019-02-24T14:24:28Z Using data directory /home/bitcoin/.bitcoin
2019-02-24T14:24:28Z Using config file /home/bitcoin/.bitcoin/bitcoin.conf
2019-02-24T14:24:28Z Using at most 40 automatic connections (1024 file descriptors available)
2019-02-24T14:24:28Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-02-24T14:24:28Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-02-24T14:24:28Z Using 4 threads for script verification
2019-02-24T14:24:28Z scheduler thread start
2019-02-24T14:24:28Z HTTP: creating work queue of depth 16
2019-02-24T14:24:28Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.
2019-02-24T14:24:28Z HTTP: starting 4 worker threads
2019-02-24T14:24:28Z Using wallet directory /home/bitcoin/.bitcoin
2019-02-24T14:24:28Z init message: Verifying wallet(s)...
2019-02-24T14:24:28Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-02-24T14:24:28Z Using wallet wallet.dat
2019-02-24T14:24:28Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
2019-02-24T14:24:29Z Cache configuration:
2019-02-24T14:24:29Z * Using 2.0MiB for block index database
2019-02-24T14:24:29Z * Using 8.0MiB for chain state database
2019-02-24T14:24:29Z * Using 90.0MiB for in-memory UTXO set (plus up to 47.7MiB of unused mempool space)
2019-02-24T14:24:29Z init message: Loading block index...
2019-02-24T14:24:29Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2019-02-24T14:24:33Z Opened LevelDB successfully
2019-02-24T14:24:33Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2019-02-24T14:24:55Z LoadBlockIndexDB: last block file = 1409
2019-02-24T14:24:55Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=120, size=133788575, heights=547036...547155, time=2018-10-23...2018-10-24)
2019-02-24T14:24:55Z Checking all blk files are present...
2019-02-24T14:24:56Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate

Is there a way to retrieve the Channel_ID knowing the Short_Channel_ID without using any lightning network explorer?

How is the Short_Channel_ID calculated? Is this operation reversible?