text:
How to recover corrupted Bitcoin-Core blockchain?
I recently experienced a I/O error resulting in data block corruption or index corruption cause bitcoin-qt wasn't quitting so I forced bitcoin core to shutdown without killin it properly. I checked the harddisk..
when I restarted Bitcoin-qt it asked me a question:

Error opening block database. Do you want to rebuild the block
  database now?

Answered yes but when Bitcoin core came up I realized that I was 4 years back to synchronize with the blockchain. So I immediately stopped it again to look for more information before proceeding for safety
I found the relevant command in bitcoin-core options to rebuild chain state:
bitcoin-qt -reindex
bitcoin-qt -reindex-chainstate

Edit : This useful answer from user Pieter Wuille here: When should I use -reindex-chainstate and when -reindex answers my second question.

-reindex:

wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index

-reindex-chainstate:

wipes the chainstate
rebuilds the chainstate using the blocks in the index you had before

Found this bitcoin.se answer Bitcoind --reindex vs starting allover again but made me a bit uncertain on what to do next in order to retrieve my database without downloading the whole blockchain from the start

What would be the proper and fastest possible ways to rebuild/recheck my blockchain from Bitcoin-qt?

What is the difference of use between of bitcoin-qt -reindex vs bitcoin-qt -reindex-chainstate?

From: When should I use -reindex-chainstate and when -reindex

-reindex:
wipes the chainstate (the UTXO set) wipes the block index (the
database with information about which block is where on disk) rebuilds
the block index (by going over all blk*.dat files, and finding things
in it that look like blocks) rebuilds the chainstate (redoing all
validation for blocks) based on the blocks now in the index
-reindex-chainstate:
wipes the chainstate rebuilds the chainstate using the blocks in the
index you had before The latter should be strictly faster, as it does
not need to rebuild the block index first. Perhaps the progress bar
during reindex confuses you: that progress is only for the rebuilding
of the index. The recreation of the chainstate happens after that
rebuild is completed.
You should use -reindex only when you were running in pruning mode, or
if you suspect the blocks on disk are actually corrupted. Otherwise,
when you only suspect corruption of the chainstate (which is far more
likely), use -reindex-chainstate.

With -reindex I was able to restore my corrupted data

Did it recovered without redownloading all, when in prunned mode?


text:
How are transactions in discarded forks merged back into the blockchain?
It sounds like transactions in discarded blocks are propagated back to the network to be included in the next block to be generated, is that the case?  If so, is that triggered in the client when it discards a fork and accepts the longer chain?
I see some info and discussion on this in the protocol and forums, but it's not entirely clear, and sounds like the heuristic is somewhat complex and non-deterministic (eg, some transactions can just be lost).

The client will import all the lost transactions into its pool of transactions it's trying to commit. Miners will include those transactions into blocks mined for the new chain, if they're not already in it.
Since a miner won't keep a conflicting transaction in memory anyway, it's not possible for the client to cause a conflict by accepting the transactions in the blocks that are undone. Miners should immediately accept all transactions that meet its transaction fee policy and fit as many of them as they can, in priority/dependency order, into blocks they mine.
Of course, coinbase transactions (the payment for mining a block) are forever lost. This is the primary reason that many more confirmations are typically required before coins from these transactions can be spent.

Does this mean that after the March 2013 fork was resolved, 31 blocks of orphaned transactions got sucked over into the newly validated highest chain? Is there a block that contains some huge number of transactions that got swept up from the orphaned chain?

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Costing arbitrage between exchanges
I'm currently writing something to script arbitrage between two exchanges to test the concept.
I know I can determine the difference in prices by using
(ExhangeA_sell - ExchangeB_buy) <- this will give me the price difference. i.e. gross profit (before fee's)
My question, how do I take the fee's into account when calculating net profit?
Currently my thinking is that I add the commission % to the buy price on ExchangeA and subtract the commission % from the sell price on ExchangeB.
Any ideas on this?
Thanks.

Hi Conor, just wanted to explain the close votes that are starting to pop up on this question.  It's a perfectly valid question, but because it's not specifically unique to Bitcoin, it may be better suited to a site like http://money.stackexchange.com/ or http://math.stackexchange.com/ so don't be surprised if it gets moved there.

nmat: i think you got the signs wrong in there somewhere. the fees will /decrease/ your effective selling price, and /increase/ your effective purchase price. so it should in fact be:
ExchangeA_sell * (1 - ExchangeA_fee) - ExchangeB_buy * (1 + ExchangeB_fee)

and also, you should take into account any deposit/withdrawal fees (E.g., when you withdraw via LR from mtgox, that's a 2% hit, when you use dwolla, that's 0.25USD fee, etc) that you'd incur when moving money between the exchanges.

It's pretty simple. Like you said, you only have to add the fees to the selling price and subtract them from the buying price. Considering that the fee is a number between 0 and 1 that represents the percentage, here is an example:
ExchangeB_bidPrice * (1 - ExchangeB_fee) - ExchangeA_askPrice * (1 + ExchangeA_fee)

This will give you the profit per coin for buying at ExchangeA and selling at ExchangeB.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How can I get the key of blockindex
According to this post: What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?
One type of the keys in leveldb of bitcoin is formed in the following way

'b' + 32-byte block hash

I wrote the following code in go but I got "not found".
genesisBlockHash := "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"
hashBytes, _ := hex.DecodeString(genesisBlockHash)
keyBytes := append([]byte("b"), hashBytes...)
data, err := db.Get(keyBytes, nil)

Where did I do wrong? How can I add 'b' to the hash?

Tried a simple case:

'R' -> 1-byte boolean ('1' if true): whether we're in the process of reindexing.

Go code
data, err := db.Get([]byte("R"), nil)

But I still got "not found". Why...

Tried file.

'f' + 4-byte file number -> file information record.

I could get some data. I think the following code should retrieve the "blk00000.dat" block file information, right?
readFile(db, []byte{0, 0, 0, 0})

func readFile(db *leveldb.DB, file []byte) {
    data, err := db.Get(append([]byte("f"), file...), nil)
    if err != nil {
        log.Println(err)
        os.Exit(1)
    }
    // read data
}

Where did I do wrong? How can I add 'b' to the hash?

The block hashes need to be byteswapped. Instead of 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, you should have 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000.

But I still got "not found". Why...

This key-value pair is not always present.

I could get some data. I think the following code should retrieve the "blk00000.dat" block file information, right?

Yes.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to generate public and private key pairs from the 12 seed words in python
I basically followed the instructions here How to generate mycelium addresses from the 12 words in python
So my code is similar:
from bip32utils import BIP32Key
from bip32utils import BIP32_HARDEN
from bip32utils import Base58
import os, bip39

strength_bits = 128
entropy = os.urandom(strength_bits // 8)
wallet_generator = bip39.Mnemonic('english')
mnemonic = wallet_generator.to_mnemonic(entropy)
assert wallet_generator.to_entropy(mnemonic) == entropy  # see, bijective!

# Or specify the mnemonic directly if you prefer:
mnemonic = 'aware report movie exile buyer drum poverty supreme gym oppose float elegant'
passphrase = 'test'

seed = bip39.Mnemonic.to_seed(mnemonic, passphrase=passphrase)
key = BIP32Key.fromEntropy(seed)
account_number = 0
i = 0
print "Address: " + key.ChildKey(44 + BIP32_HARDEN) \
         .ChildKey(0 + BIP32_HARDEN) \
         .ChildKey(account_number + BIP32_HARDEN) \
         .ChildKey(0) \
         .ChildKey(i) \
         .Address()

And I verified it using https://iancoleman.io/bip39/#english that the generated address is indeed the first address that this webpage generated as well. However, I also want to get the public and private key pairs using this same library. I originally tried:
print "Public Key: " + Base58.check_encode(key.ChildKey(44 + BIP32_HARDEN) \
         .ChildKey(0 + BIP32_HARDEN) \
         .ChildKey(account_number + BIP32_HARDEN) \
         .ChildKey(0) \
         .ChildKey(i) \
         .PublicKey())

print "Private Key: " + Base58.check_encode(key.ChildKey(44 + BIP32_HARDEN) \
         .ChildKey(0 + BIP32_HARDEN) \
         .ChildKey(account_number + BIP32_HARDEN) \
         .ChildKey(0) \
         .ChildKey(i) \
         .PrivateKey())

However, the output of these two calls are not the same as the ones provided by the website above for the same address.
So my question is: what's the proper way for me to generate the public and private key pairs?
Edit: To clarify, for the exact mnemonic and passphrase above, the website I'm using for reference tells me the first address and keypair should be:

While the output of the above python code is:
Address: 1K6WQtD7bLQ5nQ14GyBV33mBWSbkiRKhQs
Public Key: 62Yi9HBYYagf8CY1Ve2fquHKjBqAA7GFjGUUtkUHbkP5PHzv3W
Private Key: EGHMsAp7nY7Jo9F589zCU227KBLTDhiwRq5vYVvRVZxJNPJn4

So the address matches, but not the keypair.

take a look at this: https://bitcointalk.org/index.php?topic=1060451.0

Are you sure it's not matching? I see you are using PublicKey() vsAddress(), did you want the public key or the address?

I want the public key and the private key. The address is already correct. I've edited the question to add the sample output of both the reference webpage and the python script for reference

Please try the following demo, and the result is same with https://iancoleman.io/bip39/.
$ python3.6 test.py
{'addr': '1A9vZ4oPLb29szfRWVFe1VoEe7a2qEMjvJ',
 'coin': 'BTC',
 'mnemonic_words': 'aware report movie exile buyer drum poverty supreme gym oppose float elegant',
 'privatekey': 'L3g3hhYabnBFbGqd7qReebwCrRkGhAzaX4cBpYSv5S667sWJAn5A',
 'publickey': '029dc2912196f2ad7a830747c2490287e4ff3ea52c417598681a955dcdf473b6c0'}

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import pprint
import binascii
import mnemonic
import bip32utils

def bip39(mnemonic_words):
    mobj = mnemonic.Mnemonic("english")
    seed = mobj.to_seed(mnemonic_words)

    bip32_root_key_obj = bip32utils.BIP32Key.fromEntropy(seed)
    bip32_child_key_obj = bip32_root_key_obj.ChildKey(
        44 + bip32utils.BIP32_HARDEN
    ).ChildKey(
        0 + bip32utils.BIP32_HARDEN
    ).ChildKey(
        0 + bip32utils.BIP32_HARDEN
    ).ChildKey(0).ChildKey(0)

    # return {
    #     'mnemonic_words': mnemonic_words,
    #     'bip32_root_key': bip32_root_key_obj.ExtendedKey(),
    #     'bip32_extended_private_key': bip32_child_key_obj.ExtendedKey(),
    #     'bip32_derivation_path': "m/44'/0'/0'/0",
    #     'bip32_derivation_addr': bip32_child_key_obj.Address(),
    #     'coin': 'BTC'
    # }

    return {
        'mnemonic_words': mnemonic_words,
        # 'bip32_root_key': bip32_root_key_obj.ExtendedKey(),
        # 'bip32_extended_private_key': bip32_child_key_obj.ExtendedKey(),
        # 'path': "m/44'/0'/0'/0",
        'addr': bip32_child_key_obj.Address(),
        'publickey': binascii.hexlify(bip32_child_key_obj.PublicKey()).decode(),
        'privatekey': bip32_child_key_obj.WalletImportFormat(),
        'coin': 'BTC'
    }

if __name__ == '__main__':
    mnemonic_words = "aware report movie exile buyer drum poverty supreme gym oppose float elegant"
    pprint.pprint(bip39(mnemonic_words))

How do you write the result in a txt file? python 3

@debug what if I want to do this for ether rather than Bitcoin? what aspects of the code I should change to do this?

The public key should be in hex as @MohamedLEGH pointed out above. Regarding the private key you have to append the network code to it first. See step 2 here.

I found the problem I think.
You should not do the Base58.check_encode
To print the PublicKey, use the .hex() method.
Also, https://iancoleman.io/bip39/#english print Private key in the WIF form so you should do .WalletImportFormat() instead of .PrivateKey() if you want do have the same output as iancoleman.io . This time, no need to use .hex()
(again no need to encode in base58)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to properly terminate a bitcoin-qt process?
I run my bitcoin-qt on headless raspberrypi where it runs pretty smoothly.
The Issue starts when Marco gui crashes via vnc so the Bitcoin-qt GUI is hanging although that deamon is still running as a process when i check with
ps -ax | grep bitcoin
In short I can't access the gui and close it normaly
the only way to still access is through ssh and I tried
bitcoin-qt stop
bitcoin-qt: cannot connect to xserver
What is the proper way to terminate/stop safely my bitcoin-qt process?

My answer is no different to the answer by Jannes, just with more explanation.
If you key: kill PID then if no signal specified in the kill command, signal # 15 (SIGTERM), is sent by default. This is the same as kill -15 PID and is considered safe, so you can specify SIGTERM manually if you like. If this cannot close your process without corruption then it was probably inevitable.
Note that upon closing, bitcoin-qt opens a new GUI window for the close process, with the do not shut down your computer message.
It may be a better solution to try and revive your GUI session before you exit bitcoin-qt.
Note that if you starte bitcoin-qt with the correctly configured -server option you can use bitcoin-cli stop to close bitcoin-qt.
rel:
nixCraft - Kill Process in Linux or Terminate a Process in UNIX / Linux Systems - https://www.cyberciti.biz/faq/kill-process-in-linux-or-terminate-a-process-in-unix-or-linux-systems/

There is no reason why the "do not shut down" window couldn't be created, given that there already is an existing window.

@PieterWuille I was looking at the OP error: bitcoin-qt: cannot connect to xserver

Yes, that's expected. He can't run bitcoin-qt from an environment without xserver. But the existing bitcoin-qt process clearly does have an environment with an xserver, and will open windows there.

@PieterWuille is receiving another SIGTERM handled if bitcoin-qt is already on the shutting down process window?

kill <PID> should just work fine.

Not the answer I look for cause I already used that one.
My blockchain got corrupted.

That's a bit weird. Are you sure it does not get corrupted when you normally close it? https://superuser.com/questions/406920/linux-close-a-program-with-command-line-not-kill-it

@Denja How long did you wait? Bitcoin Core may take seconds or even minutes to flush all its caches at shutdown time. If you can't see the UI it may be best to watch debug.log file to see when it is safely shut down.


text:
As a solo miner how can I prioritize my own unconfirmed transactions?
Is it possible to prioritize my own unconfirmed transaction through my mining machines without being in a pool? And if its possible how can I do that?

How much hashrate do you have access to?

"without being in a pool", do you mean you are solo mining?

@PieterWuille Correction to my comment I sure mean solo mining.
I have access to 160GH/s

If you are the pool itself, or are solo mining you can use the prioritisetransaction command to add weight to your own transaction, if you are a client of a pool you do not have any control over what you are mining.

If I understand Prioritisetransaction is a client side thing that is configured on bitcoin core software mining node, and it's only possible if i'm a pool myself (solo miner) with how much hashrate would that be possible?

With 150GH/s, at the time of writing, you would find one block every 1500 years.
That means if you were solo mining, you'd be able to control the contents of a block once every 1500 years.
Or in other words: not at all.


text:
Bitcoin full node installation on Raspberry Pi3 not working
I'm trying to setup a Bitcoin full node including GUI & wallet based on guide on raspnode.com but I got stuck at the this point:
'i@raspnode~/bin/bitcoin$ make -j2'
having this error:
Making all in src
make[1]: Entering directory '/home/pi/bin/bitcoin/src'
make[2]: Entering directory '/home/pi/bin/bitcoin/src'
  CXX      bitcoind-bitcoind.o
make[3]: Entering directory '/home/pi/bin/bitcoin/src/secp256k1'
make[3]: Leaving directory '/home/pi/bin/bitcoin/src/secp256k1'
  CXX      libbitcoin_server_a-chain.o
  CXX      libbitcoin_server_a-checkpoints.o
In file included from /usr/include/boost/thread.hpp:24:0,
             from scheduler.h:15,
             from bitcoind.cpp:15:
/usr/include/boost/thread/future.hpp:3188:0: error: unterminated #if
 #if ! defined BOOST_NO_CXX11_RVALUE_REFERENCES
 ^
/usr/include/boost/thread/future.hpp:3164:0: error: unterminated #if
 #if defined BOOST_THREAD_PROVIDES_FUTURE_CTOR_ALLOCATORS
 ^
In file included from /usr/include/boost/thread.hpp:24:0,
             from scheduler.h:15,
             from bitcoind.cpp:15:
/usr/include/boost/thread/future.hpp:16:0: error: unterminated #ifndef
 #ifndef BOOST_NO_EXCEPTIONS
 ^
/usr/include/boost/thread/future.hpp:8:0: error: unterminated #ifndef
 #ifndef BOOST_THREAD_FUTURE_HPP
 ^
In file included from util.h:18:0,
             from bitcoind.cpp:16:
tinyformat.h:104:1: error: expected unqualified-id before ‘namespace’
 namespace tinyformat {}
 ^
tinyformat.h:109:1: error: expected unqualified-id before ‘namespace’
 namespace tfm = tinyformat;
 ^
In file included from util.h:18:0,
             from bitcoind.cpp:16:
tinyformat.h:150:1: error: expected unqualified-id before ‘namespace’
 namespace tinyformat {
 ^
bitcoind.cpp:191:1: error: expected ‘}’ at end of input
 }
 ^
In file included from bitcoind.cpp:15:0:
scheduler.h:80:87: error: expected unqualified-id at end of input
     bool shouldStop() { return stopRequested || (stopWhenEmpty && taskQueue.empty()); }
                                                                                ^
scheduler.h:80:87: error: expected ‘}’ at end of input
Makefile:7351: recipe for target 'bitcoind-bitcoind.o' failed
make[2]: *** [bitcoind-bitcoind.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/pi/bin/bitcoin/src'
Makefile:8357: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/pi/bin/bitcoin/src'
Makefile:668: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

PLEASE HELP!

Looks like libboost is not installed?
Try:
apt install libboost-all-dev -y
Then rebuild:
./autogen.sh; ./configure; make

What Config option are you using? I'm assuming you're using this guide from the mentioned domain. If so you've three options for the ./configure stage of install because you've mentioned full and GUI I've pulled the needed Config line out
 ./configure CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" --enable-upnp-default --with-gui

Note those file paths may need adjusted of you've installed dependencies elsewhere.
If you're still having errors it would be helpful to know what commands you've entered leading up to the posted build errors.
edits and updates
Looking real close at the error logs posted there seems to be an ' or " or similar that didn't get closed it starts showing up at a if statements not being terminated correctly near the top of the log. Additionally if your copy/pasting commands from a web page into your terminal the quotation and other special characters maybe not interpreted correctly. Definitely start the guide from the top by manually typing in commands if that sounds correct because those errors are usually caused by something being misstyped or misinterpreted.

Building with -j4 will certainly cause an out of memory. An RPi3 doesn't nearly have enough memory to run 4 gcc's in parallel.

Ah go call, last I'd built my node was on similarly limited hardware but I've yet to have the drive space to try again on the RPi without bootstrapping. I'll remove the bad suggestion, thank you Pieter.

authors: ประวิทย์ จันทร์โอโซน


text:
Basic bittrex api question
I read the api documentation but I could not find anythin related to market buy and sell commands. Where do I find this information?
Moreover, I read the following from the api site
https://bittrex.com/api/v1.1/market/selllimit?apikey=API_KEY&market=BTC-LTC&quantity=1.2&rate=1.3
My understand of this statement is that I use my 1.2 Bitcoin to buy 1.3X1.2 Litecoin. Is this correct?
If I want to use my Litecoin to buy Bitcoin, do I need to change the market from BTC-LTC to LTC-BTC??

I see someone has voted to close this using the "customer relationship" reason. Note that this should be a publicly answerable question about a public API and should not be closed for that reason. C.f. https://bitcoin.meta.stackexchange.com/questions/871/usage-of-the-off-topic-reason-customer-relationship

If anyone know about how to use the conditional buy in api, that would help too.

My understand of this statement is that I use my 1.2 Bitcoin to buy
  1.3X1.2 Litecoin. Is this correct?

The quantity parameter refers to how many of the coin you want to buy, and the rate parameter as to the limit price you want to buy/sell those coins at.
Example, buy 100 dogecoin at 0.00000400 BTC each.
https://bittrex.com/api/v1.1/market/buylimit?apikey=api_key&market=BTC-DOGE&quantity=100&rate=0.000004&nonce=nonce

If I want to use my Litecoin to buy Bitcoin, do I need to change the
  market from BTC-LTC to LTC-BTC??

No, the market stays the same, just change part of the URI from /buylimit? to /selllimit? or vice-versa. Selling your litecoin for bitcion is the same as buying bitcoin with litecoin.
You can make it act like a market order by checking the current bid/ask and making your rate equal to the side your trading. For example if you want to market buy you can query the best ask price and then make that the rate.
function fetchPairPrice($pair){
    $pair = strtoupper($pair);
    $uri = "https://bittrex.com/api/v1.1/public/getticker?market=BTC-".$pair;
    $ch = curl_init($uri);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $execResult = curl_exec($ch);
    $obj = json_decode($execResult, true);
    return $obj;
}

function bittrexbuy($apikey, $apisecret, $symbol, $quant, $rate){
    $nonce=time();
    $uri='https://bittrex.com/api/v1.1/market/buylimit?apikey='.$apikey.'&market=BTC-'.$symbol.'&quantity='.$quant.'&rate='.$rate.'&nonce='.$nonce;
    $sign=hash_hmac('sha512',$uri,$apisecret);
    $ch = curl_init($uri);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('apisign:'.$sign));
    $execResult = curl_exec($ch);
    $obj = json_decode($execResult, true);
    return $obj;
}

    $symbolRate = fetchPairPrice("DOGE");
    $fetchPrice = $symbolRate["result"]["Ask"];
    $amountToBuy = 100;
    bittrexbuy($apikey, $apisecret, $symbol, $amountToBuy, $fetchPrice);

    //response
    //{"success":true,"message":"","result":{"uuid":"b5f891ab-a7b4-44aa-9488-94986d1d9551"}}


text:
Manually extracting ledger nano s wallet public / private keys using "Mnemonic Code Converter" from ledger
I have the following example seed:

morning twist board pelican denial retire middle inherit evil
  ritual omit fade general toddler grace evoke recipe
  sad minor destroy public dawn scissors cube

I'm trying to generate the same addresses on the ledger site which is showing up on my device: https://www.ledgerwallet.com/support/bip39-standalone.html
My intial pin was 5555 and my first bitcoin address is: 12mCn27...
I also set a "passphrase" of just the letter "a" which generates btc address: 1NSXBid...
I then did an attach to pin with the pin: 4555 which generates btc: 17Dn62...
I then added a passphrase to the 4555 pin with just the letter "b" and I get the following btc address: 1HBPpj...

When setting up ledger nano s initially is the address randomized? And what deviration path does it start from?
I tried pasting the example seed into https://www.ledgerwallet.com/support/bip39-standalone.html and I can't find the initial pin 5555 setup of address: 12mCn27
If I'm able to set different pins, where do I type this pin on the Mnemonic Code Converter page? It's not the passphrase field thats for sure.
If I wanted to recover all those private keys with the above scenarios with different pins  and passphrases. How can I?

It looks like the PIN doesnt matter. The passphrase "b" I used with 4555 pin also generates the same exact address if my pin is 5555 with passphrase "b" aswell. Looks like the PIN is used only to physically access the device itself and doesn't communicate at all with the connected computer or it being used for address generation.

I also just tried restoring this seed on another ledger and I'm getting a totally different bitcoin address. why is that?

Right. PIN just protect the configuration. It is not an input in the calculation.

The first normal address should be m/44'/0'/0'/0/0, the first *change address should be m/44'/0'/0'/1/0.

If you use segwit-p2sh m/49'/0'/0'/0/0 and m/49'/0'/0'/1/0. Native segwit: m/84'/0'/0'/0/0 and m/84'/0'/0'/1/0. And so on

Use the command line utils in pycoin. Pretty up-to-date. You have to somehow start from the seed though. They don't support BIP39.

EDIT: The Master Public given by ledger wallet is already derived so: to obtain the first 10 addresses with ku (pycoin) this work for me (segwit):

ku -j -s0/0-9 xpubYourMasterPublicKeyHere |jq '.p2sh_segwit'

If you don't use segwit it's much easier:

ku -s0/0-9 -a xpubYourMasterPublicKeyHere

DISCLAIMER: Don't send money on a derivation you have obtained like this unless you know exactly what you're doing!
Check that the addresses produced are the same AND you have to use the address try first with a small amount to test and check the landing on Ledgerwallet.

m/44'/0'/0'/0/0 did not generate any of the above addresses that I have from my ledger.

maybe the master public you have used is already derived to m/44/0'/0' so you have to add only "0/0", "0/1", etc. If you have taken the master public from Ledger wallet you are in this situation.


text:
Proper getmemorypool data endianness?
As there are a couple endiannesses used by Bitcoin, what is the proper way to encode the data parameter for a getmemorypool JSON API call?

The "data" is not a number (only numbers have endian issues), but the raw byte data of a valid block. You may wish to read over BIP 22, which is the Draft-status standard detailing the getmemorypool protocol.

Do you mean the data response for a getwork call?  Because getmemorypool only returns version, previousblockhash, transactions, coinbasevalue, coinbaseflags, time, mintime, curtime, and bits.
If so, I answered that here.

No, I'm specifically referring to getmemorypool call's data field, as in a whole, solved block, rather than just a block header. Maybe I shouldn't have called it "response", but a "parameter".

In that case: it's a byte-per-byte encoding in hex of the serialized block, the same way it would be serialized on disk in blk0001.dat or on the network.


text:
I have an issue with my wallet. it is giving me fatal error
Sorry to ask it here because I can not find a better place..
This question is related to my Dogecoin wallet ...
I accumulated some dogecoin in the past, but I have not been able to recover them for weeks but finally today I managed to recover them.
However, when I closed my wallet, I was never been able to open as the wallet until now as it keeps giving me this error message
A fatal error occurred. Dogecoin can no longer continue safely and will quit.
EXCEPTION: St13runtime_error
CWalletDB::ListAccountCreditDebit(): cannot create DB cursor
D:\ML\Other Files\Altcoin Projects\Dogecoin Project\Program\Dogecoin\dogecoin-qt.exe in Runaway exception

Link to error
I don't really know what to do now. Please help me

Are you using the latest version of the dogecoin client?

authors: Ольга Басова


text:
How do I detect a double-spend in real-time, like Bitpay?
By Bitpay to pay only take 10 seconds to complete.
How do they do it?

If you want to detect a double spend, you need to listen to all transactions broadcasted to the network, and write some code to detect if the address that sent you Bitcoins also sends a transaction to another address (until 1+ confirmations).
To answer your other question, Bitpay cannot guarantee the transactions not to be double spent. In an effort to promote usage of Bitcoin as a payment solution, they take on the risk of a potential double spend, and if one happens, they eat the balance (no risk to the merchant). This is a vanishingly small occurrence in practice, so any fees (or venture capital) paid to them more than cover that possibility.


text:
Does Bitcoin mining benefit at all from having more video memory?
Example: I am mining on a Windows computer with guiminer on an onboard gpu. Will assigning more memory to the IGP improve its performance while mining?

It seems unlikely. SHA-256 uses very little memory, so while I don't know a lot about GPU mining code, I would doubt that additional GPU memory would be used at all - I can't think what it would be used for.
But if you want to know for sure - since this is a simple BIOS option, why not just try it both ways and see?

GPU Mining is dead. It's been overtaken by ASICs which are many orders of magnitude more efficient. There is no point in even trying.

Thanks, but I already know that and it doesn't answer my question.


text:
Bread Wallet on OS X
How can I use my Bitcoin ID created in Bread Wallet on a OSX Desktop app. MultibitHD requires an Date stamp to "recover" passphrase. Is there a Mac app that works with Bread Wallet?
TIA,
Dave


text:
Would it be profitable to manufacture and sell my new mining hardware?
I am bit new with bitcoin. I run a electronics/software company in China and Australia. I would like to create new bitcoin mining hardware. The specs are as follows:
The miner is PCI-E installed, runs in a normal PC case or rack sized server around 200w, latest 28nm chip, around 200GHash/s, selling $99 (USD).
I will buy the chip from existing supplier. The design and manufacturing will be done myself.
Given I have a hardware team that have done many ARM Soc applications, and a reasonable experienced software people with Linux and software.
My question is it worthwhile the effort to do it? Is it profitable and what if any are the perceptive pitfalls?

In regard to the reopen votes: The question doesn't seem to provide enough information to answer the core topic, i.e. it's missing information e.g. about when the product would become available. Also, any other answer than "who knows?" would require making guesses about the future development of the mining market and Bitcoin's progress. I'm not sure that the question is a good fit for our site. However, I will abstain from voting, because I don't feel strongly about this. If you feel that this question can get better answers, please feel free to vote to reopen.

Depends on whether you can bring something to market that's better than what's already out there. I'm not sure how quickly you can set up something like that, but 200GH/s for $99 right now would probably sell decently. 12 months from now, probably not so much.
This is really an economics question you have to answer, and we'd need a lot more information about your costs and market in order to assess the opportunity properly.

No way. 200GH/s @ 200W for $99 was obsolete a year ago! Absolutely no way. I just got a 60GH/s at 50W (notice similar Hash/Watt which is the only thing that counts) for FREE from someone because it's been obsolete for more than a year.


text:
Normal hashrate but no accepted shares in
For the moment I'm trying to mine altcoins using an AMD HD6850.
The version of cgminer is 3.7.2. The pool I'm using is prohashing.com.
It's a scrypt-mining pool which mines the most profitable coins at the moment. When I'm connecting to the pool, I get decent hashrates for my GPU (200Mh/s), but I get no accepted shares... When I look on the prohashing profile page I see that next to my worker there's following message:
"This miner is not responding to work restart testing, so a suboptimal default value was chosen. Use the r= password argument to manually set a default value."
My main screen is looking like this:

My configuration file is as following:
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe -o stratum+tcp://prohashing.com:3333 -u CoinHunter -p "" -I 13 -w 256 --thread-concurrency 6144

Changing the difficulty or mining a specific coin didn't do the job...
Someone who has an idea?

200Mh/s is impossibly high for an HD6850 mining scrypt. My bet is that you're mining SHA256d, not scrypt. I don't see a -scrypt in your configuration file.


text:
Recovery of a corrupted wallet
I have a very old wallet.dat that I've put into my .bitcoin folder. When trying to run bitcoind, the service stops giving the following error
2019-06-11T18:14:02Z Using wallet directory /home/nom/.bitcoin
2019-06-11T18:14:02Z init message: Verifying wallet(s)...
2019-06-11T18:14:02Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-06-11T18:14:02Z Using wallet wallet.dat
2019-06-11T18:14:02Z BerkeleyEnvironment::Open: LogDir=/home/nom/.bitcoin/database ErrorFile=/home/nom/.bitcoin/db.log
2019-06-11T18:14:02Z Renamed wallet.dat to wallet.dat.1560276842.bak
2019-06-11T18:14:02Z BerkeleyEnvironment::Salvage: Database salvage found errors, all data may not be recoverable.
2019-06-11T18:14:02Z BerkeleyEnvironment::Salvage: WARNING: Unexpected end of file while reading salvage output.
2019-06-11T18:14:02Z Salvage(aggressive) found no records in wallet.dat.1560276842.bak.
2019-06-11T18:14:02Z Error: wallet.dat corrupt, salvage failed
Error: wallet.dat corrupt, salvage failed
2019-06-11T18:14:02Z Shutdown: In progress...

Edit. Here is the content of the DB log
file unknown has LSN 1/151495, past end of log at 1/28 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment Page 0: metadata page corrupted Page 0: could not check metadata page wallet.dat: DB_VERIFY_BAD: Database verification failed file unknown has LSN 1/151495, past end of log at 1/1080 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment wallet.dat.1560341204.bak: DB_VERIFY_BAD: Database verification failed file unknown has LSN 1/151495, past end of log at 1/2500 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment wallet.dat.1560341352.bak: DB_VERIFY_BAD: Database verification failed

Edit. Using db_dump I am able to see the content of the wallet file ( addresses, keys etc)
Is there any way I could debug this, perhaps recovering just part of the keys or any useful data from the DB itself? Any useful hints how to approach such recovery?

Using db_dump -p <wallet file>, do you see anything lines that contain ckey or key? Does the output have HEADER=END near the start of the output and DATA=END at the end?

Yes, there are plenty of lines with \0key entries and indeed, both HEADER/DATA entries appear. Also if it helps db_verify says the DB is fine. The wallet was created with a fairly old client (2010?)

It sounds like your wallet.dat file is still intact, but some of the environment data has gotten corrupted (possibly due to moving wallet files).
Try doing
db_load -r lsn wallet.dat

This will reset the LSNs in the wallet.dat file which should cause the errors in the db.log to go away. Once you do that, delete the database/ folder and start Bitcoin Core.

This seems to make the wallet load just fine, though I wonder if all keys were erased?  Is this error msg expected? 22019-06-14T16:40:30Z [default wallet] Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total. Unknown wallet records: 0 ?

That doesn't sound good. It seems like all of the keys were erased, and that's not supposed to happen. If you do db_dump on the file again, do you see what you saw earlier? Do you still see lines beginning with key?

Yes I can still see that. As a matter of fact diff seems to be saying that the two dumps are equivalent.

Don’t use -r lsn you can lose data.

did that, it worked for me, pywallet sees my addresses now and bitcoin core doesn't crash on import (still scanning, though)

where would you input the command db_load -r lsn wallet.dat?  I tried doing this in the node window console window and I got Method not found (code -32601) using v26.0.0

trying that command db_load -r lsn wallet.dat using bitcoin-cli.exe and I get an error:  error: timeout on transient error: Could not connect to the server 127.0.0.1:8332 (error code 1 - "EOF reached")
I don't know if my wallet.dat is fully corrupted or just partial.  It is just the wallet.dat and I have the encrypted password for the wallet.dat file.  I was able to use a java program and decrypt/dump some keys .  the db.log file showed similar file unknown has LSN 1/151495, past end of log at 1/28...  So I assumed i could just load wallet in and get it to work somehow.

@JonGrah db_load is an external tool, not one of Bitcoin Core's commands. It comes with BDB and you have to use the terminal or command prompt to use it.


text:
The BIP32 Extended Keys are different?
I was using the same random entrophy (d2310508c6c5313795dc80a7408b608ffda7176dbedefac00f8114c5dd89a673) to generate the BIP32 Root ExtendedKey (path: m) in the libbitcoin-explorer and web-based wallet respectively.
But I don't know why i got two different results?
In the libbitcoin-explorer, I typed the command (./bx hd-new d2310508c6c5313795dc80a7408b608ffda7176dbedefac00f8114c5dd89a673) and got:
xprv9s21ZrQH143K4bPcDZFCnACLDrv2ta2XUpPyMU2j98VEpw1XPPTt7oPiQbbXscESmatehXLGGUGLRZ5yYBiN2y2VR1q6pmH69YBuDWkqW1f
In the web based wallet I had:
 xprv9s21ZrQH143K4EQpRE59bbF9QXCW7QxJSW4LF9wWWWJCamtjVqnn5yuQGh9Y3XDAr9NSwyszLGjqXCuVc3gYMgRjy7FrW12MuaBY5jc4jVu

Because they are doing two different things.
libbitcoin is taking the entropy and directly using it as a BIP 32 seed to produce the BIP 32 master private key.
However the web based wallet is taking the entropy, producing a BIP 39 mnemonic, then using the BIP 39 mnemonic to produce the BIP 32 seed and from there the master private key. Since BIP 39 mnemonic to BIP 32 seed involves hashes and does not result in the same value used to create the mnemonic, the resulting BIP 32 seed is different from your initial entropy. Thus you are getting two different private keys.

oh, thanks for your kind explaination. That's really helpful.


text:
sendrawtransaction and txn-mempool-conflict
When i sendrawtransaction to bitcoind, i get error (exceptions) 18: txn-mempool-conflict (use Bitcoin JSON-RPC denpamusic/php-bitcoinrpc)
But the transaction is sent to the network and is subsequently confirmed.
Example one decoded transaction : https://jsfiddle.net/rn58a4j6/
then i send this transaction:
94ec12fc463230b4285a29b047608627c05572a4c6eabe6688a201ce49ae72f7

looks like you already submitted the transaction

To solve this problem, I restarted bitcoind.
I think that maybe when i was developing my project, I made a bad transaction and it saved in mempool


text:
why --user used constantly in curl examples?
curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "encryptwallet", "params": ["my pass phrase"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

https://bitcoincore.org/en/doc/0.16.0/rpc/wallet/encryptwallet/
what's it?
looks  like username:password but why then it's called 'myusername'

The RPC interface is an authenticated interface - it requires a username and password to use it. By specifying --user with the RPC username, curl will prompt you to enter the passphrase before sending the request. myusername is just a placeholder for the RPC username that you actually use.
Note that this username and passphrase is unrelated to the wallet. The wallet does not have usernames, and the passphrase is specific to the wallet and provided in the RPC, not in HTTP headers.

it constantly fails so i do not know what's it. i use http://uname:password@127.... stuff

Fails how? You could add -v to get verbose output to get more info on what is going on. The example command works for me.

authors: Алексей Неудачин


text:
Segwit & Offline Signing
Yesterday Trezor released details of a segwit-related hardware wallet vulnerability.
The writeup claims that providing full previous transactions to the hardware wallet prevents the exploit.
My question: Why can't the compromised desktop software provide fake previous transactions corresponding to the fake inputs?
Using the example in the writeup:

In "step 2", create a fake transaction containing an output spent by "input 2" with value  5.00000001 BTC and same outpoint as the 20BTC UTXO.
In "step 5", create a fake transaction containing an output spent by "input 1" with value 0.00000001 BTC and same outpoint as the 15BTC UTXO.

The offline signer couldn't know that these fake transactions aren't on the blockchain. Most hardware wallets don't show information about the UTXOs being consumed so the user couldn't catch it by inspection. Does the fix involve incompatible sighash values for the two rounds?

The attack vector seems very edge case, I'm also interested in more details regarding the proposed fix.

Answered on Twitter

The hash of the provided prevtx must match the prevtx hash given in the input. The attacker is unable to construct a fake prevtx that hashes to a predefined value. The prevtx hash in the input cannot be changed either, otherwise the network will reject the tx.

Basically, you can't create fake previous transactions because that would require producing a sha256 collision, which we assume can't happen.


text:
analyzepsbt says next role is "updater", but nothing is "missing"
I'm trying to spend a 2/2 P2WSH input.
I don't understand how the "next" field can be "updater" if the "missing" field is empty:
$ bitcoin-cli -testnet analyzepsbt cHNidP8BAH0CAAAAAXz0qBDXO+uQOsNVaUcorfJafZYydCv5kGUTLaFs/r2HAAAAAAD+////AugDAAAAAAAAFgAUlBEbC0zwnx3lVjBHQ8j/OSY8D00DggEAAAAAACIAIIwfpAXvuuV+RHcUKJQhamBeY2kX8NQjEHnXq7nAxI0kAAAAAAABASughgEAAAAAACIAIF7irfIOj9QsEsbGg+4bmfHAIfxHGagcdw2PSeqZV1i9IgICykuckuH/D6RW3lBdbEqbEqHDxjQObhF8l5eQRDa64ftIMEUCIQD81o45GQb5Sl957dP64X4xj0QXzoMA8JTSBjbFRC3nrAIgCi1Ku1pSArpmyap0ZiZmAq8LRqis+cBdVeHJE9Da7WcBIgIC/NzEeTxfWJoNRzy7vS+dJSjAlu71hTAThp31g1LONFdHMEQCIBymHkm6ugBcdmllS0XhFHlGYglnrhtJOYk6ET865tYcAiAaBi9klfVfRnTP2KmHb7ZumIWEPzYRsXv2yUWn17Z3NAEBBUdSIQL83MR5PF9Ymg1HPLu9L50lKMCW7vWFMBOGnfWDUs40VyECykuckuH/D6RW3lBdbEqbEqHDxjQObhF8l5eQRDa64ftSriIGAspLnJLh/w+kVt5QXWxKmxKhw8Y0Dm4RfJeXkEQ2uuH7GGuz1AMsAACAAQAAgAAAAIAAAAAAAAAAACIGAvzcxHk8X1iaDUc8u70vnSUowJbu9YUwE4ad9YNSzjRXGHd0/yAsAACAAQAAgAAAAIAAAAAAAAAAAAAAAQFHUiEDLB2e+6+bTRK5ciRgj64xzggam4YgzswByu9oxg3wZ3UhA/jRhjYGYlDGSAoiCvs6tlL6CEU/gcH8yAq4NOqm8SEXUq4iAgMsHZ77r5tNErlyJGCPrjHOCBqbhiDOzAHK72jGDfBndRh3dP8gLAAAgAEAAIAAAACAAAAAAAIAAAAiAgP40YY2BmJQxkgKIgr7OrZS+ghFP4HB/MgKuDTqpvEhFxhrs9QDLAAAgAEAAIAAAACAAAAAAAIAAAAA
{
  "inputs": [
    {
      "has_utxo": true,
      "is_final": false,
      "missing": {
      },
      "next": "updater"
    }
  ],
  "estimated_vsize": 181,
  "estimated_feerate": 0.00001000,
  "fee": 0.00000181,
  "next": "updater"
}

I've used HWI to add partial_signatures for each of the 2 pubkeys specified in the inputs[0]['bip32_derivs'] field.
$ bitcoin-cli -testnet decodepsbt cHNidP8BAH0CAAAAAXz0qBDXO+uQOsNVaUcorfJafZYydCv5kGUTLaFs/r2HAAAAAAD+////AugDAAAAAAAAFgAUlBEbC0zwnx3lVjBHQ8j/OSY8D00DggEAAAAAACIAIIwfpAXvuuV+RHcUKJQhamBeY2kX8NQjEHnXq7nAxI0kAAAAAAABASughgEAAAAAACIAIF7irfIOj9QsEsbGg+4bmfHAIfxHGagcdw2PSeqZV1i9IgICykuckuH/D6RW3lBdbEqbEqHDxjQObhF8l5eQRDa64ftIMEUCIQD81o45GQb5Sl957dP64X4xj0QXzoMA8JTSBjbFRC3nrAIgCi1Ku1pSArpmyap0ZiZmAq8LRqis+cBdVeHJE9Da7WcBIgIC/NzEeTxfWJoNRzy7vS+dJSjAlu71hTAThp31g1LONFdHMEQCIBymHkm6ugBcdmllS0XhFHlGYglnrhtJOYk6ET865tYcAiAaBi9klfVfRnTP2KmHb7ZumIWEPzYRsXv2yUWn17Z3NAEBBUdSIQL83MR5PF9Ymg1HPLu9L50lKMCW7vWFMBOGnfWDUs40VyECykuckuH/D6RW3lBdbEqbEqHDxjQObhF8l5eQRDa64ftSriIGAspLnJLh/w+kVt5QXWxKmxKhw8Y0Dm4RfJeXkEQ2uuH7GGuz1AMsAACAAQAAgAAAAIAAAAAAAAAAACIGAvzcxHk8X1iaDUc8u70vnSUowJbu9YUwE4ad9YNSzjRXGHd0/yAsAACAAQAAgAAAAIAAAAAAAAAAAAAAAQFHUiEDLB2e+6+bTRK5ciRgj64xzggam4YgzswByu9oxg3wZ3UhA/jRhjYGYlDGSAoiCvs6tlL6CEU/gcH8yAq4NOqm8SEXUq4iAgMsHZ77r5tNErlyJGCPrjHOCBqbhiDOzAHK72jGDfBndRh3dP8gLAAAgAEAAIAAAACAAAAAAAIAAAAiAgP40YY2BmJQxkgKIgr7OrZS+ghFP4HB/MgKuDTqpvEhFxhrs9QDLAAAgAEAAIAAAACAAAAAAAIAAAAA
{
  "tx": {
    "txid": "65cf8989e70e1112e8022043bd3a91a7f1d4074d9d7b004f0be05b327f819ff8",
    "hash": "65cf8989e70e1112e8022043bd3a91a7f1d4074d9d7b004f0be05b327f819ff8",
    "version": 2,
    "size": 125,
    "vsize": 125,
    "weight": 500,
    "locktime": 0,
    "vin": [
      {
        "txid": "87bdfe6ca12d136590f92b7432967d5af2ad28476955c33a90eb3bd710a8f47c",
        "vout": 0,
        "scriptSig": {
          "asm": "",
          "hex": ""
        },
        "sequence": 4294967294
      }
    ],
    "vout": [
      {
        "value": 0.00001000,
        "n": 0,
        "scriptPubKey": {
          "asm": "0 94111b0b4cf09f1de556304743c8ff39263c0f4d",
          "hex": "001494111b0b4cf09f1de556304743c8ff39263c0f4d",
          "reqSigs": 1,
          "type": "witness_v0_keyhash",
          "addresses": [
            "tb1qjsg3kz6v7z03me2kxpr58j8l8ynrcr6d6qvfsu"
          ]
        }
      },
      {
        "value": 0.00098819,
        "n": 1,
        "scriptPubKey": {
          "asm": "0 8c1fa405efbae57e4477142894216a605e636917f0d4231079d7abb9c0c48d24",
          "hex": "00208c1fa405efbae57e4477142894216a605e636917f0d4231079d7abb9c0c48d24",
          "reqSigs": 1,
          "type": "witness_v0_scripthash",
          "addresses": [
            "tb1q3s06gp00htjhu3rhzs5fggt2vp0xx6gh7r2zxyre674mnsxy35jq4s8uxx"
          ]
        }
      }
    ]
  },
  "unknown": {
  },
  "inputs": [
    {
      "witness_utxo": {
        "amount": 0.00100000,
        "scriptPubKey": {
          "asm": "0 5ee2adf20e8fd42c12c6c683ee1b99f1c021fc4719a81c770d8f49ea995758bd",
          "hex": "00205ee2adf20e8fd42c12c6c683ee1b99f1c021fc4719a81c770d8f49ea995758bd",
          "type": "witness_v0_scripthash",
          "address": "tb1qtm32musw3l2zcykxc6p7uxue78qzrlz8rx5pcacd3ay74x2htz7s89n5j4"
        }
      },
      "partial_signatures": {
        "02ca4b9c92e1ff0fa456de505d6c4a9b12a1c3c6340e6e117c9797904436bae1fb": "3045022100fcd68e391906f94a5f79edd3fae17e318f4417ce8300f094d20636c5442de7ac02200a2d4abb5a5202ba66c9aa7466266602af0b46a8acf9c05d55e1c913d0daed6701",
        "02fcdcc4793c5f589a0d473cbbbd2f9d2528c096eef5853013869df58352ce3457": "304402201ca61e49baba005c7669654b45e1147946620967ae1b4939893a113f3ae6d61c02201a062f6495f55f4674cfd8a9876fb66e9885843f3611b17bf6c945a7d7b6773401"
      },
      "witness_script": {
        "asm": "2 02fcdcc4793c5f589a0d473cbbbd2f9d2528c096eef5853013869df58352ce3457 02ca4b9c92e1ff0fa456de505d6c4a9b12a1c3c6340e6e117c9797904436bae1fb 2 OP_CHECKMULTISIG",
        "hex": "522102fcdcc4793c5f589a0d473cbbbd2f9d2528c096eef5853013869df58352ce34572102ca4b9c92e1ff0fa456de505d6c4a9b12a1c3c6340e6e117c9797904436bae1fb52ae",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "02ca4b9c92e1ff0fa456de505d6c4a9b12a1c3c6340e6e117c9797904436bae1fb",
          "master_fingerprint": "6bb3d403",
          "path": "m/44'/1'/0'/0/0"
        },
        {
          "pubkey": "02fcdcc4793c5f589a0d473cbbbd2f9d2528c096eef5853013869df58352ce3457",
          "master_fingerprint": "7774ff20",
          "path": "m/44'/1'/0'/0/0"
        }
      ]
    }
  ],
  "outputs": [
    {
    },
    {
      "witness_script": {
        "asm": "2 032c1d9efbaf9b4d12b97224608fae31ce081a9b8620cecc01caef68c60df06775 03f8d18636066250c6480a220afb3ab652fa08453f81c1fcc80ab834eaa6f12117 2 OP_CHECKMULTISIG",
        "hex": "5221032c1d9efbaf9b4d12b97224608fae31ce081a9b8620cecc01caef68c60df067752103f8d18636066250c6480a220afb3ab652fa08453f81c1fcc80ab834eaa6f1211752ae",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "032c1d9efbaf9b4d12b97224608fae31ce081a9b8620cecc01caef68c60df06775",
          "master_fingerprint": "7774ff20",
          "path": "m/44'/1'/0'/0/2"
        },
        {
          "pubkey": "03f8d18636066250c6480a220afb3ab652fa08453f81c1fcc80ab834eaa6f12117",
          "master_fingerprint": "6bb3d403",
          "path": "m/44'/1'/0'/0/2"
        }
      ]
    }
  ],
  "fee": 0.00000181
}

I dug around in psbt.cpp for a while but still can't figure out what's missing ...

Are you able to finalize the psbt using finalizepsbt? AFAICT, the only thing that can cause this is an invalid signature.

finalizepsbt returns { "psbt": <unchanged>, "complete": false }. Is there any straightforward way to check the signatures in a PSBT? And I got the signatures straight from HWI so could be a bug over there ...

What hardware wallet did you use? Some don't entirely support multisig (or previous versions of firmware didn't) but will still give a signature which is invalid.

Bitbox 7.0.0 & Ledger 1.5.5 (up-to-date according to their GUI apps). I also have a trezor and coldcard. Guess I'll try those, too.

can you open an issue in the HWI repo and we can continue there? Also, it would be good if you could share the PSBT you gave to HWI to be signed.

I noticed this with ColdCard simulator too, single signature, without HWI, while working on: https://github.com/bitcoin/bitcoin/pull/17509
finalizepsbt was happy though and I could broadcast the testnet transaction. I assumed did something wrong. Will file a Github issue if I see it again.


text:
Import multisig change addresses into Bitcoin Core using "importmulti" + descriptor
I'm trying to fill my wallet's internal/change address keypool by passing a multisig descriptor to importmulti, but the wallet's internal keypool is 0 before and after running the following shell script:
keypoolinitial=$(bitcoin-cli -testnet getwalletinfo | jq -r '.keypoolsize_hd_internal')
echo "internal keypool initial: $keypoolinitial"

rawdescriptor="wsh(multi(2,tpubD6NzVbkrYhZ4YgUWMmeBh1b7hrYyHwXowUrMn3mQ6QRxJNaLiVEA3jGLJDdaSpzEMTCgNF2JRukSqUxEkgX3J8Mf8tMParwTWABsjFzTsUA/*,tpubD6NzVbkrYhZ4XaWhpCwqSPgdnmqHxjPksHjdt6sgsBmQ37ohNNUFnyykgstn1UTKz21SzdKM6C3V7qEiXHkeEKWRALWMb1am8voLW72ZXDr/*,tpubD6NzVbkrYhZ4X3DR4FgNdjBjmdxvnX2TjmbkoNWquXaXQz6uMfF7kUF6rsXA26vRMzW3WP4iQgP1A8gJCSYD47qAQbsCCtnvhtRiD57jAEw/*))"

descriptor=$(bitcoin-cli -testnet getdescriptorinfo $rawdescriptor | jq -r '.descriptor')

bitcoin-cli -testnet importmulti '[{"desc": "'$descriptor'", "timestamp": "now", "range": [0, 10], "watchonly": true, "keypool": true, "internal": true}]' >> /dev/null

keypoolfinal=$(bitcoin-cli -testnet getwalletinfo | jq -r '.keypoolsize_hd_internal')
echo "internal keypool final: $keypoolfinal"

Running it gives me:
internal keypool initial: 0
internal keypool final: 0

But the same script works if I change the rawdescriptor line to use a simple P2PKH descriptor such as:
rawdescriptor="pkh(tpubD6NzVbkrYhZ4YgUWMmeBh1b7hrYyHwXowUrMn3mQ6QRxJNaLiVEA3jGLJDdaSpzEMTCgNF2JRukSqUxEkgX3J8Mf8tMParwTWABsjFzTsUA/*)"

Then it outputs:
internal keypool initial: 0
internal keypool final: 11

The keypool (currently) is not an address pool, it does not hold individual addresses, it holds keys. Those keys are then converted to addresses when you want them. Because of this, you cannot import P2SH or P2WSH addresses into the keypool as you are trying to do.


text:
How can I run Bitcoin Core with the -zapwallettxes option in Windows OS
I have been trying to run Bitcoin Core with -zapwallettxes option by starting the command line prompt, and typing (cmd.exe) Start bitcoin-qt with --zapwallettxes=1 but it keeps saying Windows cannot find bitcoin-qt. I am trying to remove a stuck transaction and have the bitcoins back in my wallet. Any help would be much appreciated.
James

First always backup your wallet.dat prior to actions then
Try running
"C:\Program Files (x86)\Bitcoin\bitcoin-qt" --zapwallettxes=1

or
"C:\Program Files\Bitcoin\bitcoin-qt" --zapwallettxes=1


text:
SatoshiLabs 2021 Signing Key" [unknown] gpg: WARNING: This key is not certified with a trusted signature!
These are the steps I took:

open https://suite.trezor.io/

download the 3 files: Desktop app, signature and signing key

follow the instructions https://wiki.trezor.io/Apps:Trezor_Suite#How_to_run, How to verify the binaries,2 terminal commands.

/Downloads$ gpg --import satoshilabs-2021-signing-key.asc
gpg: key E21B6950A2ECB65C: 1 signature not checked due to a missing key
gpg: key E21B6950A2ECB65C: "SatoshiLabs 2021 Signing Key" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

~/Downloads$ gpg --verify Trezor-Suite-21.12.2-linux-x86_64.AppImage.asc
gpg: assuming signed data in 'Trezor-Suite-21.12.2-linux-x86_64.AppImage'
gpg: Signature made Wed 08 Dec 2021 10:45:00 AM MST
gpg:                using RSA key EB483B26B078A4AA1B6F425EE21B6950A2ECB65C
gpg: Good signature from "SatoshiLabs 2021 Signing Key" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB48 3B26 B078 A4AA 1B6F  425E E21B 6950 A2EC B65C

Question: Can I still trust the Suite?
Thanks

Question: Can I still trust the Suite?

Yes. GPG indicates that there is a valid signature for SatoshiLab's signing key.
GPG has a thing called the "trust database" (trustdb). This is a local database of keys that you have told GPG that you trust, with trust meaning that you have verified that the owner of that key is who the key says it belongs to. By default, keys are not trusted or have an unknown trust value as you have to verify the identity externally, and then inform GPG.
So the warning that you see is simply GPG telling you that this particular key does not have a trusted value in the trustdb. You have not told GPG that you trust this key, and it is merely reminding you of this fact.

Thank you for the answer.
I'd recommend Satoshi Labs to include this information in their instructions so newbies don't panic :)


text:
Error in configuring Qt with Bitcoin Core on Windows
I was following this (https://github.com/bitcoin/bitcoin/blob/master/build_msvc/README.md) documentation to install Bitcoin core on Windows 10.
I have successfully configured Bitcoin core with Microsoft Visual Studio 2019 without the involvement of Qt.
Now, I want to configure Bitcoin core with Qt for the graphical interface. I followed these steps to install Qt as given in the documentation.
cd C:\dev\qt-source

mkdir build

cd build

..\configure -release -silent -opensource -confirm-license -opengl desktop -static -static-runtime -mp -qt-zlib -qt-pcre -qt-libpng -nomake examples -nomake tests -nomake tools -no-angle -no-dbus -no-gif -no-gtk -no-ico -no-icu -no-libjpeg -no-libudev -no-sql-sqlite -no-sql-odbc -no-sqlite -no-vulkan -skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdeclarative -skip doc -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip qtimageformats -skip qtlocation -skip qtlottie -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip qtpurchasing -skip qtquick3d -skip qtquickcontrols -skip qtquickcontrols2 -skip qtquicktimeline -skip qtremoteobjects -skip qtscript -skip qtscxml -skip qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip qtsvg -skip qtvirtualkeyboard -skip qtwayland -skip qtwebchannel -skip qtwebengine -skip qtwebglplugin -skip qtwebsockets -skip qtwebview -skip qtx11extras -skip qtxmlpatterns -no-openssl -no-feature-bearermanagement -no-feature-printdialog -no-feature-printer -no-feature-printpreviewdialog -no-feature-printpreviewwidget -no-feature-sql -no-feature-sqlmodel -no-feature-textbrowser -no-feature-textmarkdownwriter -no-feature-textodfwriter -no-feature-xml -prefix C:\Qt_static

After this step, it gave the following message :
Qt is now configured for building. Just run 'nmake'.
Once everything is built, you must run 'nmake install'.
Qt will be installed into 'C:\Qt_static'.

After that, when I run nmake, I get this error :
NMAKE : fatal error U1095: expanded command line 'echo moc C:\qt-everywhere-src-5.15.2\qt-everywhere-src-5.15.2\qtbase\src\opengl\gl2paintengineex\qglengineshadermanager_p.h && C:\qt-everywhere-src-5.15.2\qt-everywhere-src-5.15.2\build\qtbase\bin\moc.exe -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_OPENGL_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_DEPRECATED_WARNINGS_SINCE=0x060000 -DNDEBUG -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB --compiler-flavor=msvc --include C:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/src/opengl/.moc/release/moc_predefs.h -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/mkspecs/win32-msvc -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/src/opengl -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtOpenGL -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtOpenGL -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtOpenGL/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtOpenGL/5.15.2/QtOpenGL -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/src/opengl/tmp -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/src/opengl/.tracegen/release -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtWidgets/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtWidgets/5.15.2/QtWidgets -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtWidgets/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtWidgets/5.15.2/QtWidgets -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtGui/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtGui/5.15.2/QtGui -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtGui/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtGui/5.15.2/QtGui -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtCore/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtCore/5.15.2/QtCore -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtCore/5.15.2 -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtCore/5.15.2/QtCore -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtWidgets -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtWidgets -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtGui -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtGui -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/qtbase/include/QtCore -IC:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/include/QtCore -I. -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\ATLMFC\include" -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include" -I"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt" C:\qt-everywhere-src-5.15.2\qt-everywhere-src-5.15.2\qtbase\src\opengl\gl2paintengineex\qglengineshadermanager_p.h -o .moc\release\moc_qglengineshadermanager_p.cpp' too long
Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.

NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

Can someone please help me with this?
Thanks in advance

`NMAKE : fatal error U1095: expanded command line [...] too long

The problem reported is that the command line is too long. This is because of the location of your resources.
Shorter path
One thing you perhaps could try is to move them all to a shorter path.
Drive letter
Maybe even to a virtual drive letter so that each long path C:/qt-everywhere-src-5.15.2/qt-everywhere-src-5.15.2/build/qtbase/src/opengl/.moc/release/ becomes a short path S: say.
Symbolic link
You might just be able to add symbolic links that allow a shorter command line to be constructed.
Better shell
Alternatively find a Windows command shell or "make" that can handle long lines -- assuming one exists.


text:
bitcoin listunspent showing an address which does not belong to my wallet
I use bitcoin listunspent to list unspent UTXO, but found one that doesn't match my addresses, so what's that address and where is it from ?
bitcoin-cli listunspent
[
  {
    "txid": "edc69b3fb53bd221129c4e0f115bdaa5227d01173a23aac2064fc29a78006714",
    "vout": 1,
    "address": "2MtkQ9MeXv9vKeFLuTPeEPfj5DQfWnL1jbw",
    "redeemScript": "0014e329000822d1b101d7940800ff2983aa54b33374",
    "scriptPubKey": "a914107caab5b5a035de348d22aa865d20db3fb1907987",
    "amount": 0.54856181,
    "confirmations": 92,
    "spendable": true,
    "solvable": true,
    "safe": true
  }
]

It is a P2SH, so it's likely a segwit or multisig address. Does dumpprivkey 2MtkQ9MeXv9vKeFLuTPeEPfj5DQfWnL1jbw give you a private key?

If you have sent and received Bitcoin before, then this output is likely a change output.


text:
Why do people mine crypto currencies?
I have read many articles and watched videos but I still can't fully understand Bitcoin, mining and blockchains. I understand a block in a blockchain contains data and its resulting hash. I also understand a miner attempts to generate a new hash by hashing the previous hash in the chain with a nonce. A miner will keep trying until they create a hash with required difficulty level.

I think I understand what happens during mining by I don't
understand why we mine? i.e. Yeah I found a block so what? (of
course miners are rewarded but why?)
How would people use this found block in a real life scenario?
Is the data in a block a real life scenario data.

A real life example will be appreciated.
If people are going to down vote please let me know why so I understand?

I think I understand what happens during mining by I don't understand why we mine? i.e. Yeah I found a block so what? (of course miners are rewarded but why?)

Miners are rewarded for mining via the block subsidy and the transaction fees (transaction fees are paid to miners). They mine in order to earn that reward; the reward has value and therefore miners will want to get it by mining.

How would people use this found block in a real life scenario?

Blocks are not just arbitrary data, they are part of the Bitcoin blockchain and used to store transactions that are considered permanent. They don't have any other use. The point of blocks is to have a permanent transaction history that is guaranteed by the work that miners must do to create the block.
There is no other "real life scenario" or "real life example" to give here for blocks; that's just not how they work.

If it needs to be real life data then what data is being stored in bitcoin hashing because there is no "real" usage of bitcoin currently?

Once the last block of bitcoin is mined, will it mean there are no more blocks left to store more transactions hence bitcoin blockchain will only contain transactions that are stored until the last block is mined?

What do you mean there is no "real" usage of Bitcoin currently? There are Bitcoin transactions, people are sending Bitcoin to each other. There will always be Bitcoin transactions; that is "real" usage of Bitcoin. That is the data that is stored in blocks. There is also no "last block of Bitcoin"; once the last Bitcoin has been mined, blocks will still be mined because there will still be Bitcoin transactions that need to be processed, thus there will still be blocks.

Please find the answers below:
1). Miners are nothing but transaction processors, which share the resources/processing power in a blockchain network to verify all the blocks and try to confirm the transaction and make an entry in the public ledger (Place where all the confirmed transaction goes, which will be periodically gets distributed across all the nodes in the blockchain network). Whoever in the blockchain network wins this race will be given some incentive. This incentive will vary based on how important and critical the transaction is. I would say it is a transaction fee instead of incentive because we are paying for electricity, internet, hardware etc to be part of the network and help blockchain transaction processing.
2 & 3) Yes, it should be real life scenario data otherwise there is no point of that data to be in blockchain but the technology doesn't care what data you are trying to store  Examples: Signing a contract, purchasing a property, buying groceries from a merchant, Investing in a particular company etc. Once this data is made to blockchain with the help of miners then it will be there forever, unchangeable and unstealable.

I think I understand what happens during mining by I don't understand why we mine? i.e. Yeah I found a block so what? (of course miners are rewarded but why?)

Miners are like transaction proccessors, the more miners, the more secure the network

How would people use this found block in a real life scenario?

Blocks store transactions.

It's quite profitable. I'm also new in mining but try to follow the latest news. I also read where to sell bitcoin in canada in one article by ICO Pulse. Canada is one of the most crypto-friendly countries in the world and it's probably the simplest way to get fiat money for crypto. Want to try cryptoexchange exchanges too.


text:
How can I find the sender's address from the transaction hash?

Possible Duplicate:
How to findout the sender of a transaction

I am trying to use blockchain.info API to receive a payment and store the sender's address. However, the API only indicates the transaction hash, not the sender's address. Perhaps this is simply ignorance about the BTC Protocol, but how can I find the sender's address from any given transaction hash?
The two API's I am using:

https://blockchain.info/api/api_receive
https://blockchain.info/api/blockchain_api

You can for example check the Block Explorer's info about a given transaction. For example, given transaction 1c480aad976c61b51ae47401a554b09f65efe6f95f644041f838d9129e09167c, you can see that the only input was associated with address 1HnjAo2nbHGFDto86smcFiF3uUwfvNJ4cS.
However, generally you should avoid using transaction inputs for basically any purpose - they do not uniquely identify a user, sending Bitcoins back to the user might be problematic with just this information and so forth.

OK... Thanks for answering. Where Can I found that here? Is it the "hash" of "prevout"?
https://blockchain.info/api/blockchain_api

@flaab You'd have to parse the website, not the raw Tx, as a Bitcoin transaction does not encode the previous transaction. If you want to use raw Tx, you would need to take the prev_out hash and n, go to the transaction of that hash and check the out with an index n.


text:
Is the blockchain ever-increasing? (forever)

Possible Duplicate:
Are there any studies into the size of the blockchain scaling over time?

Hi folks, I have a theoretical question. Since the blockchain stores all bitcoin transactions, does this mean that it is ever-increasing and will never, ever stop gobbling up disk space?
Cheers!

Yes, the blockchain itself will keep increasing forever. On the other hand, one does not need to store the entire blockchain to use Bitcoin. It is possible that later version of Bitcoin will start pruning old, spent transactions to keep local disc storage smaller.

No. If a car is heading North on a highway that ends in five miles, will it run off the end of the road? Of course not.
A car going North on a highway now will not go North on a highway forever. The driver will turn the steering wheel before it runs off the end.
To get a "yes" answer, you have to assume the car has no driver. But then you're asking a question about an absurd hypothetical where a car speeds down a highway with no driver.

Zen answer is best answer.

And this is the same answer whenever someone talks about something being "unsustainable". Most of the time, they mean you can't go on forever in a straight line when you aren't going in a straight line anyway.

In your metaphor, what is the blockchain equivalent of 'turning the steering wheel'?

@shanusmagnus: It's awfully hard to predict the future. One change could be using a distributed storage scheme to store the block chain so that fewer copies are needed. It could mean a pruning/compression scheme. It could mean such a fundamental change to the Bitcoin protocol that prior blocks are no longer needed.

I think maybe the OP has the same struggle that I do, which is understanding which problems (like the blockchain scaling problem) are already addressed in the current protocol, and which problems can potentially be addressed, but will require protocol modifications, and community action to 'bless' those protocol modifications.  It sounds like you're saying this problem is one of the latter type?

@shanusmagnus: Not necessarily. A distributed storage scheme could be implemented completely independently.

The short answer is that old, spent transactions can be pruned, meaning the part of the blockchain that has to be stored to run a node doesn't have to grow forever.


text:
How malleable is the Bitcoin protocol?

Possible Duplicate:
How could the bitcoin protocol be changed? Has this ever occurred?

Given Bitcoin is a system based on consensus, is it possible and under what situations would the Bitcoin community consider changing some of it's underlying 'hard-coded' laws. Things such as the number of Bitcoins in circulation the rate of Bitcoin production or the number of confirmations before a transaction is confirmed?

The number of Bitcoins in circulation

That would be almost impossible to change and would drastically undermine confidence in the Bitcoin system. I think we're stuck with this forever, or until Bitcoin becomes obsolete.

The rate of Bitcoin production

Again, almost impossible to change.

Or the number of confirmations before a transaction is confirmed?

Anyone is welcome to consider a transaction confirmed after as many or as few confirmations as they like. There is no reason this requires any kind of agreement.

Yup.
The rules are changeable if supported by the economic majority.  http://en.bitcoin.it/wiki/Economic_majority
Any change that decreases the value of previously acquired coins is not likely to be supported.

@David, Is there any way Bitcoin can have faster than 10 minute confirmation time in future updates? E.g. as fast as LTC/FTC/worldcoin/fastcoin

@Pacerier There's no advantage. Faster confirmations just means weaker confirmations. It still takes the same amount of time to reach the same level of confidence.

@DavidSchwartz, There's an advantage when we are looking at small numbers. If a coin confirms in 3 seconds, after 3 seconds we would have 1 confirmation (non-zero confidence). Contrast this with a coin that confirms in 10 minutes. Before the first confirmation, we have zero confidence. Further elaborated by DeathAndTaxes on https://bitcointalk.org/index.php?topic=98841.0#subject_1081896 . Don't you agree that faster confirmation can be extremely useful for merchants and payment processors?

@Pacerier We can have a lot more than zero confidence before the first confirmation. I'm not convinced that faster confirmation times provide any speed benefit that outweighs their costs. (They do increase the maximum possible transaction rate for a given maximum block size.)

The easiest way to introduce changes to Bitcoin is almost certainly through creation of an alternative currency with a new name. This has been done already quite a number of times, such as with:

Litecoin, probably the most successful alternative, which uses a CPU friendly mining algorithm instead of a GPU friendly one. Unfortunately this property allows botnets to mine coins more easily.
SolidCoin, which when I last read about it was partially centalised and closed source.
Ixcoin
I0coin
Geist geld
PPCoin
Freicoin

Litecoin seems reasonably mature and is still growing (at least, in hash rate). PPCoin is very new, and I don't understand its mechanism. I'm not sure what's happening with Freicoin. All the others listed above are essentially dead or dying as I understand it.
There is also NameCoin which is designed to provide a decentralised domain registration system.
It historically hasn't taken long for exchanges to become available for new cryptocurrencies, which allows for easy conversion from Bitcoin to the new currency. Other supporting tools like automatic payment systems tend to be developed later.
However, so far nothing has even come close to Bitcoin's popularity. If there was some amazing new feature provided by a new alt-coin that Bitcoin couldn't provide, I could imagine the switchover from Bitcoin being quite rapid. It's just that nothing has provided an adequate point of difference yet.

Last I heard SolidCoin was a scam...

@Lohoris, I didn't follow it in detail. I'm pretty sure Ixcoin, and I0coin were essentially scams too, though in those cases I think the code was at least open source.


text:
How to 'pick' transactions to include when attempting to add a new block?
I saw this question about finding new transactions.
But how do you pick which transactions to include in the block you're trying to add? Should it be in a certain order, or random? How many transactions should you include? Looking at the blockchain I've seen anywhere from just a few, to hundreds. Is the number of transactions something you'd vary when pool-mining to combat exhausting all possible nonces if up-to-date with the timestamp header? (Loosely related to my other recent questions).

Basically, you can include whichever transactions you'd like.
Currently most miners simply include all valid transactions they know of. It is cheap to do so.
There is currently a limit of 1 MB per block, so as transaction volume reaches these levels, miners will typically want to include transactions that have the best ratio of fee / data size.
As a more mature transaction fee framework evolves, miners will choose transactions to optimize for it.
Playing with transactions included is not needed to extend your work scope, as you can extend it indefinitely by changing the extraNonce.


text:
Can a new wallet receive money that was sent to it before the wallet was created?

Possible Duplicate:
What would happen if two public keys had the same Base58 hash?

A follow up from What happens if I mistype the address when making a payment?
Suppose I accidentally (or intentionally)send some money to a valid wallet address that no one owns currently. Now, at a later point in time, when someone creates an account which happen to have the same address to which I sent, will the wallet get those coins?

See this answer to understand the likelihood of this actually happening: http://bitcoin.stackexchange.com/a/3205/516

No, that's not the spirit of this question. I was wondering how the "balance" is computed. For instance, suppose I send a few bitcoins to every valid key I generate. Then after a billion years, when the wallet is actually created, will the owner be able to spend those coins?

Could someone tell why the negative votes?

Though I didn't downvote it myself, it's probably because it's very similar to several other questions considering the implications of a hash collision.

Yes, it will.
To "receive" money one should have a private key corresponding to bitcoin address, nothing more. The keys do not bear any information related to their creation date.
Intrinsically, bitcoin protocol does not have such thing as "balance". Blockchain contains only the list of transactions. If you have correct keypair (with public key hashing to destination address) and the transaction output has not already been spent, then you can send this money somewhere. Your "balance" is just a sum of all transaction outputs you can spend. When importing new private key in original bitcoin client, it performs blockchain rescan to find out whether this new address has received any coins previously.

Is that scalable? Following from my comment in the question, in a more reasonable timeframe, say I send coins now and the address is created after billions of blocks. Will the entire blockchain be scanned?

@SparrowG By default it will (in importprivkey RPC there is a switch to disable scanning, since currently it takes ~2 minutes). Also, there is "ultraprune" version of client, which stores not entire blockchain but only the list of unspent tranaction outputs, which makes such scanning pretty fast.


text:
How do I reverse a transaction?
Ok here is the thing I lost coins on this computer trying to send them to my laptop this is what it said
Status: 0/unconfirmed
Date: 2/6/2013 14:53
To: 1PrM4QW3UtkGhi1uXFjvtDhn3h3x3pMipn
Debit: -3.98
Net amount: -3.98

How do I reverse it or stop it its been over a month and I cant seem to find how to do it.

Here's what I think you're really asking: "I sent bitcoins to an address, but those bitcoins never showed up on the other end. How do I fix this?" Am I correct?

You didn't lose them, they were successfully sent. You can see the confirmed transaction here, included in block 219,976.
In fact, the recipient spent them (sending them to 1ESTZpJUkqSQDkjyQHYAFecasEykhFWmMj) about 9 hours later.


text:
What was the vulnerability in v0.3.4 that allowed an attacker to steal coins?
Reference: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141
What was the specific exploit in the Tx script evaluation process?

Explanation by Mike Hearn:
https://bitcointalk.org/index.php?topic=152470.msg1620493#msg1620493

When Bitcoin was first released, it contained two completely fatal
  bugs that made the entire system worthless. Fortunately, they were
  found and fixed before Bitcoin  actually had any serious value.
The first bug was that scripts were concatenated before being run
  instead of just using a shared stack. This meant that anyone could
  write a scriptSig that always evaluated to true and claim anyone elses
  coins. Fixed here in v0.3.2:
https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0

...

Needless to say, if somebody when this version was first released
  actually wrote such a scriptSig and stole some coins, that would have
  caused a chain split between old and new versions. Nobody did because,
  why bother? I'm not even sure Mt Gox existed back then, iirc that came
  some months later. Many script opcodes were disabled around this time
  (which is also a hard-forking change).

So like the scriptsig "1 1 OP_EQUALVERIFY" could sign and obtain a Tx output?

I'm a little unclear on how this could lead to someone stealing coins. Could you give an example scriptSig?

@NickODell you could do things like push 0x{size of scriptPubKey} and then the execution would basically just involve pushing the serialized scriptPubKey on the stack, which would evaluate to true. Alternatively, a scriptSig of OP_TRUE OP_RETURN used to be able to spend any coins, before op return was changed to mean automatic failure.


text:
Wouldn't compromised crypto require entire block chain to be recomputed?
If one of the cryptographic building blocks of Bitcoin were to be broken, couldn't that result in the entire block chain needing to be recomputed? And how would that work, given the computational expense involved?

Please define "broken" and "building blocks"  The word "block" has a specific meaning in bitcoin.

I know it's on another stack exchange (and closed) but there is a solid explanation of how this scenario could be resolved at http://stackoverflow.com/questions/5605571/is-bitcoin-protocol-future-proof

@Ben: I meant the crypto primitives, of course. By "broken" I mean any occurence where one of these primitives were proven not to be up to specs and would become unreliable, possibly making the whole block chain to that date unreliable.

Related: http://bitcoin.stackexchange.com/q/8702/153

If one of the cryptographic building blocks of Bitcoin were to be broken

This is a difficult question to answer because Bitcoin uses so many.
SHA256d
This is Bitcoin's main hashing algorithm. It uses it for proof-of-work, building merkle trees, and lots of other stuff.
Collision resistance
If broken, you could create two blocks that hashed to the same thing. This would be bad because you could give both out, and nodes would think that they agreed, but they were actually talking about different blocks.
Preimage resistance
If broken, you'd have essentially infinite hashpower, and you could do the previous attack on blocks that had already been mined.
Mining faster than brute force
Currently, the fastest known way to get a hash that starts with lots of zeros is to just run through that hash lots of times. However, if you could figure out at the start that certain ranges of nonces weren't going to result in a block, you'd have a significant advantage over ASIC miners, who wouldn't be able to change the way they mined.
HASH160
Collision resistance
Irrelevant.
Preimage resistance
If broken, you could steal bitcoins.
ECDSA
If broken, you could steal bitcoins.
Final remarks
It's unlikely that every crypto primitive that bitcoin relies on would be broken. If they were, there are usually better primitives that could replace them.

So if SHA-256 was broken in some significant way and needed replacement, wouldn’t that involve recomputing the entire block chain with a different hash function? And if so, would that be feasible or would the whole system collapse?

@George Actually, you could use the existing checkpoint system, but use a different hash, like SHA3. You'd want to switch to SHA3 for the new blocks though, which would require a mutually-exclusive hard fork.

Considering the NSA uses SHA256 hashes in their suite B protocols, I doubt that one could deduce nonce results.


text:
Bitcoin Price Fluctuations
Does anyone have any hard data on bitcoin price fluctuations in relation to time of day and/or week?

Hi Connor, and welcome to BSE! I removed the part about casual opinion because it was likely to cause discussion.

Possibly the hardest data you can get is the details about every individual trade on MtGox. Using the API you can get the trades and then build any derived information you'd need. The data is complete except for the depth information which would be of little use compared to the sheer size.
Mt.Gox currently dictates the price, being the biggest market, but you could certainly splice in additional information from other markets as well.

This is probably the best source:
http://bitcoincharts.com/markets
http://bitcoincharts.com/charts


text:
I am unable to figure the getwork api
I called bitcoind getwork slightly earlier in the day and this is what I got:
{
    "midstate" : "6d8b2d759123e7311c552f0c99f6d520378062ac7a14fb11f6d433779d282faf",
    "data" : "00000002c2bf65e9637a1c11955c2ba1c45c9bffad322d4fa0d9529e0000014300000000e9587c30863f5f410ea9d0611d3da6b7d0afd390b4b8e33cd71297c9d20dc74651ad7ea71a01616400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
    "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
    "target" : "0000000000000000000000000000000000000000000000646101000000000000"
}

So for the time being lets throw away the midstate which I will not be using since I am only trying to understand.
So now doing the 32 bit byteswap on the data I get this:
Data
02000000 e965bfc2111c7a63a12b5c95ff9b5cc4 4f2d32ad9e52d9a04301000000000000 307c58e9415f3f8661d0a90eb7a63d1d90d3afd03ce3b8b4c99712d746c70dd2 a77ead51 6461011a 00000000

Now I am unable to figure out how to actually read this information. According to the wiki, the first 4 bytes are version. Here the first 4 bytes are version.
Version:
02000000

Isnt it supposed to be 2. The above is a really large number in big endian.
Now the previuos hash block:
Hash:
e965bfc2111c7a63a12b5c95ff9b5cc44f2d32ad9e52d9a04301000000000000

I am unable to find this hash anywhere on blockexplorer or block chain info? I tried to change the endianess once again but to no avail.
Finally I left the merkle root out and tried to confirm with the utc time:
Time:
a77ead51

Which corresponds to the year 2081. What exactly am I doing wrong here?

getwork has been pretty much deprecated, you should use getblocktemplate instead.

Isnt it supposed to be 2. The above is a really large number in big endian.

It's a small number in big endian. Think about it; big digits at the end.

Now the previuos hash block

I don't know why Bitcoin does this, but block hashes are stored in normal order internally, then byte-reversed before displaying them.
>>> s="e965bfc2111c7a63a12b5c95ff9b5cc44f2d32ad9e52d9a04301000000000000"
>>> import binascii
>>> s=binascii.unhexlify(s)
>>> s=s[::-1]
>>> s=binascii.hexlify(s)
>>> s

'0000000000000143a0d9529ead322d4fc45c9bff955c2ba1637a1c11c2bf65e9'

Time:
  a77ead51

Use big endian. I got 1370324647 using this tool, then converted to 04 Jun 2013 with this tool.

I didnt know I have to do that extra step to get the data. Anyway I think I understand now. Thanks a lot. Just out of curiosity, how did you know this?

@Enthusiast Reading wiki articles, bitcoin source code, pyminer source code. Also, I started writing a mining client, but I lost interest.


text:
Do transactions get slower over time?
The number of blocks formed is 1 every 10 minutes. As the number of transactions increase, wouldn't the time taken for a transaction to confirm become slower?
I am asking this because this the number of people transacting increases but how fast blocks get generated is constant. Or am I going about it all wrong?
From what I read, I understand that a block is generated whenever a proof of work is submitted by a miner; this happens when the miner processes a transaction. So in addition to the transaction, he also gets some bitcoins which are once again added to the block chain.

I understand that a block is generated whenever a proof of work is
  submitted by a miner; this happens when the miner processes a
  transaction

That's not correct. The miners doesn't submit a found block (proof-of-work) when he processes a transaction. He does when he found a block hash that was valid.
That can take a long time and in the time he looks for a good block, he will receive probably thousands of transactions.
He will verify those as they come in and put them in the block he is currently working on, all of them, one by one (until the limit is reached). When he then finds a valid block hash, he will submit the entire block consisting of all, or most of, the transactions he received.
So, to answer your questions, transactions do not necessarily get slower over time, on the condition that the upper limit of transactions in a block is high enough. If the limit is too low, there can arise a bottleneck for transactions trying to be verified.
FYI: You can see that all miners have all those transactions in their working block, but only one of them can submit the block. To prevent transactions from occurring twice, once a miner receives a new valid block from a fellow miner, he checks what transactions in his pool are also in that block. He will remove them from his pool and continues mining for the next block with the transactions from his pool that were not in the block of the fellow miner.

@Steven, Isn't it possible that in the near future we would have so much transactions that it takes over an hour merely to process the transactions?

Well, hopefully, when the amount of transaction grows, the processing performance of the mining servers will as well. But you are right that Bitcoin is not very much made to scale to very large transaction sizes. Ripple does a much better job at that.

Miners don't process transactions one at a time, they process blocks which contain many transactions. Currently each block can contain about 2000 transactions, if needed this figure might be increased.

How long does it take to process 2000 transactions?

@Pacerier: The main work required per transaction is verifying the ECDSA signatures. I don't know the exact number but verifying 2,000 transactions should take a few seconds on a decent computer.

Hmm, this means that verifying transactions could be a bottleneck when bitcoin is broadly adopted in the future right?

@Pacerier: It would be something to consider. But I'm not really worried about Bitcoin's scalability, as I explained in http://bitcoin.stackexchange.com/a/2800/575 (though that answer focused on data storage).

I consider that answer as irrelevant (despite its upvotes) because it focused on data storage which is a red herring. Scalability has much much more to do with "time" than "storage".

@Pacerier: That's silly. Take every mention of "storage" and replace it with "ECDSA verification", the points will still be relevant (except for #2).

The answer as it is now made no mention of "ECDSA verification" but only talks about storage.

@Pacerier: Why do I have to repeat myself? Replace "storage" with "ECDSA verification" and you're done. "The answer as it is now" is not what matters, what matters are the arguments within. The arguments apply equally well to ECDSA verification (1. Full nodes will have better hardware than consumer PCs. 3. Off-chain payments. 4. The amortized total cost per tx is low. 5. Hardware will improve with Moore's law.) I could have repeated the arguments here, but why should I when they're all already written?

You are missing the point. The question in that thread is "Are there any studies into the size of the blockchain scaling over time?". Your answer in that thread as it is made no mention of "ECDSA verification" but only talks about storage. Perhaps you expect the reader to mind-replace "storage" with "ECDSA verification" while reading your answer. That's fine, except, your answer in that thread as it is made no mention of "ECDSA verification" but only talks about storage.

@Pacerier: Which reader? The linked question was about storage, so my answer to that question was about storage. In the discussion here with you, I said there are multiple factors that will prevent the cost of ECDSA verification from becoming unbearable, and that these are the same factors as those mentioned in the linked answer, so I linked it instead of repeating the arguments. The only person I asked to make the leap from "storage" to "ECDSA verification" is you, and you repeatedly refused to do so. I have no idea what it is that we are arguing about, so it's probably best if we stop here.

@Pacerier: Perhaps the point you're missing is that the linked question was, in fact, about storage? If you read the question you'll notice this point.

I see we have talked past each other. I am in fact referring to the linked post, not this one. "readers" of course would mean the readers of the thread http://bitcoin.stackexchange.com/q/2798/1475 . Do read the question again carefully. It is clear that it is asking about the scalability of the size of the blockchain, misassuming that storage is the only factor. But data storage is a red herring as the scalability of the size of the blockchain has much much more to do with "time" than "storage".

@Pacerier: Maybe. I think that question was specific enough to warrant an answer to the question itself (which did make multiple references to storage), rather than speculating about different potential challenges for scalability.

authors: Станислав Спижевой


text:
Having trouble getting poclbm to work on linux, Segmentation fault
I am a linux noob, so please take that in to account.  I believe i have compile poclbm and all it's dependencies correctly however when I try and run it
python poclbm.py http://xxxx@xxxxx@pit.deepbit.net:8332 -d 0

I get the following error
21/02/2014 15:45:26, Setting server (xxxx@xxxxx @ pit.deepbit.net:8332)
pit.deepbit.net:8332 21/02/2014 15:45:26, checking for stratum...
Segmentation fault

Does anyone have an idea of why this might be happening?  Changing my logging a bit I can see it's a 3044 Segmentation fault.
Thank you

This turned out to be a problem with installing two different versions of the nvidia driver on *nix


text:
What is the default relaying policy for RBF double spend transactions?
Let's say I broadcast a transation tx0 signaling RBF replaceability. Later on, I realize it has a small amount of fees, so I send another transaction tx1 that spends the same inputs than tx0, but this time with higher fees.
Which is the default bitcoind/bitcoin-qt behaviour regarding the relaying of tx1? Would all nodes broadcast the new version of the transaction or does the relay policy depend on the mempoolreplacement parameter? Do any special rules apply to the relaying of the replacement transaction?
I have seen that Peter Todd's RBF proposal included a NODE_REPLACE_BY_FEE service bit. Is anything like this included in the current version?

Nodes will only relay if mempoolreplacement hasn't set to false (most nodes probably do relay because the default is true).

There are several rules for accepting a replacement after BIP125 (check the BIP for more details). In general: The replacement must pay greater fees than the transactions it replaces.—Otherwise the bandwidth used by those conflicting transactions would not be paid for.

The mempool rules are relevant since nodes only relay transactions after accepting them to their mempool.