text:
funding and spending a "no-multisig/no segwit" P2SH tx
I got inspired by this thread:
Single signature P2SH redeem script
Assume I want to "hide" my address as long as can be. So I want a P2SH tx, which only shows a redeemscript (hash of my pubkey) on the blockchain until spent. I try to go analog to a multisig, but use just the pubkey as redeemscript. The funding tx would hash160 the public key, and use it as redeem script. This would be a payment to a "type 3 address", with this code in the "tx_out pkscript".
A9: OP_HASH160
14: OP_Data14 (= decimal 20 and the redeem hash)
87: OP_EQUAL

Would the spending tx have this in it's scriptsig?
<sig><pubkey><OP_CHECKSIG>

(instead of the way it is done in multisigs:
<sig><pubkey 1-n><OP_CHECKMULTISIG>)
Looking what happens on the stack:
sig
pubkey
<OP_CHECKSIG>

<OP_HASH160>
redeem hash
<OP_Equal>

For this to work, the <OP_HASH160> opcode would have to know, that the pubkey and the <OP_CHECKSIG> would need to be hashed together (to be compared to the redeemscript hash which follows for <OP_Equal>) ...
I think the same question applies to multisig. There is just two or more pubkeys followed by <OP_CHECKMULTISIG> (instead of <OP_CHECKSIG>).

Now I understand, why there was no answer - it gets really long :-)
So I answer it by myself. I am with bitcoin core (getinfo) version 150100, on OpenBSD (ksh) and OSX (bash v3):
I solved it on testnet, and got the tx to go through. Some information from @nick here:
Does OP_HASH160 consume the top stack element?
I was wondering, if this holds true:

For this to work, the <OP_HASH160> opcode would have to know, that the
  pubkey and the <OP_CHECKSIG> would need to be hashed together

Obviously it does. Here is the whole cycle... First I try to have a look at the stack with input and output scripts (as per link above):
sigscript:     <sig> <redeem script>
pubkey script: OP_HASH160 <RedeemScriptHash> OP_EQUAL

Based on the link above and looking at the stack, it would run through these steps:

Input SigScript (push data on stack)  STACK:
Execute pubkey script  a. this would first push first OPCODE of pubkey script on stack and execute  STACK:
  OP_HASH160
b. this command consumes top stack element, and replaces with hash
  STACK:
c. the next elements of the pubkey script is pushed to stack  STACK:
     OP_EQUAL
OP_Equal verifies top two stack elements, if untrue --> invalid
If true, script ends with "true" on top of stack  STACK:
verify if script is P2SH (... ok, it is P2SH ...)
clean the stack, and run sigscript again  STACK:
pop top stack element, and run it as script  a. the top element of the redeem script is OP_CHECKSIG   STACK:   OP_CHECKSIG
b. CHECKSIG would verify pubkey and sig, and return true ...

To see if this is correct, assemble a funding tx on testnet/regtest. When using coinbase tx (mined block), need >100 confirmations! Start with creation of a redeemscript and address for this tx:
NEWADDRESS=$( bitcoin-cli -regtest getnewaddress )
echo $NEWADDRESS
PUBKEY=$( bitcoin-cli -regtest validateaddress $NEWADDRESS | awk -F '\"' '/pubkey/ { print $4 }' )
REDEEMSCRIPT=$( printf "21%sac" $PUBKEY )
# creating the hash of the REDEEMSCRIPT
printf $( echo $REDEEMSCRIPT | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_fn.hex
openssl dgst -sha256 -binary <tmp_fn.hex >tmp_sha256.hex
REDEEMSCRIPTHASH=$( openssl dgst -ripemd160 <tmp_sha256.hex | cut -d " " -f2 )
# convert redeemscripthash to bitcoin address (testnet!), with "C4" Prefix
PRFX_REDEEMSCRIPT=$( printf "c4%s" $REDEEMSCRIPTHASH )
# double sha256 the hex value
printf $( echo $PRFX_REDEEMSCRIPT | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_fn.hex
openssl dgst -sha256 -binary <tmp_fn.hex >tmp_sha256.hex
openssl dgst -sha256 <tmp_sha256.hex | cut -d " " -f2 >tmp_dsha256.txt
# checksum and append
result=$( cat tmp_dsha256.txt | cut -b 1-8 )
result=$( printf "%s%s" $PRFX_REDEEMSCRIPT $result | tr "[:lower:]" "[:upper:]" )
# and base58
base58str="123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
REDEEMSCRIPTADDR=$( dc -e "16i $result [3A ~r d0<x]dsxx +f" | while read -r n; do
    j=$(( n + 1 ))
    echo $base58str | cut -b $j
  done | tr -d '\n' )
bitcoin-cli -regtest importaddress "$REDEEMSCRIPTADDR" p2sh
bitcoin-cli -regtest importaddress "$REDEEMSCRIPTADDR" rescan
bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR"
bitcoin-cli -regtest listunspent

The redeemscript's address would start with a "2" on testnet. Now create the funding tx. Search for an UTXO, that we can use, and note down tx and vout.
UTXO_TXID=d260e120647360dcfc8606e242c6389acece3ee585d5e0d76a26b87b08b322e0
UTXO_VOUT=0
VALUE=49.9997
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$REDEEMSCRIPTADDR'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX | awk -F '\"' '{ print $4 }' )
bitcoin-cli -regtest decoderawtransaction $SIGNED_TX
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

# verify new address has funds:
bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR"
bitcoin-cli -regtest getreceivedbyaddress "$REDEEMSCRIPTADDR"

At this point, the funding transaction is sent. Now the spending tx, we need a new address to receive the funds from the P2SH address:
RCVADDRESS=$( bitcoin-cli -regtest getnewaddress )
echo $RCVADDRESS

# verify that tx from $REDEEMSCRIPTADDR has funds
RAW_TX=$( bitcoin-cli -regtest getrawtransaction $UTXO_TXID )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
# to send funds from $REDEEMSCRIPTADDR to a new address, need the privkey:
NEWADDRESS_PRIVKEY=$( bitcoin-cli -regtest dumpprivkey $NEWADDRESS )

create the raw tx, sign it, and send it (maybe the amount needs to be updated):
UTXO_VOUT=0
UTXO_OUTPUT_SCRIPT=$( bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR" | awk -F '\"' '/scriptPubKey/ { print $4 }' )
VALUE=7.7699
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$RCVADDRESS'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX '''[{"txid": "'$UTXO_TXID'","vout": '$UTXO_VOUT',"scriptPubKey": "'$UTXO_OUTPUT_SCRIPT'","redeemScript": "'$REDEEMSCRIPT'"}]''' '''["'$NEWADDRESS_PRIVKEY'"]''' | awk -F '\"' '{ print $4 }' )
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

At this point I could see, that my newly generated RCVADDRESS contained the value (bitcoin-cli -regtest listunspent | grep -A5 -B5 $RCVADDRESS):
... "amount": 7.76990000
I had one smaller observation, which is not yet fully clear to me: the scriptsig was changed in the final tx. It had the signature, and behind should follow the redeemscript. This redeemscript was "extended" in this way:

23210355ef94c6e097752f303d685e4011b9dba8c1cd1382f8fa68bf2de0d523f18fffac

The 23 at the beginning would be the length indicator for the following pubkey, but this would include "ac"... Not sure, why bitcoin core extends it this way.
Now that I got it to work with simple P2SH, I can try SegWit-P2SH :-)

take my email: alistermaclin@mail.ru and ask anything :)


text:
coin seems to have gone to a duplicate address
in attempting to answer Bitcoin-qt multiple wallets and transferring between?, and teach myself in the process, I created a new wallet.dat file and saved it to group_wallet.dat after generating an address. I then restored my_wallet.dat to be wallet.dat, and sent an AmericanCoin to that address. almost a full day later, the funds don't show up. the transaction is in the blockchain, but they never made it to the wallet. I've switched wallets back and forth a few times since then; the one from which I sent the money is fine, and shows the -1.0 transaction.
jcomeau@aspire:~/.americancoin$ americancoind getaddressesbyaccount ''
[
    "AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U",
    "Argr7YW2enzC7TkFp4cJiVDJ1wSYPkh5ox"
]
jcomeau@aspire:~/.americancoin$ americancoind getreceivedbyaddress AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U
0.00000000
jcomeau@aspire:~/.americancoin$ americancoind decoderawtransaction $(americancoind getrawtransaction 9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473)
{
    "txid" : "9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "45614d6a67973f9d4728a2724547f3b7e9274218df28599d63f50f112cfa1d8b",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "304602210088aacfccfe71532a5bbfc3145bbff8c1f3470e228b35e879146b30ec4b3526b8022100f566b0aa825ee6786af3619f1e73d89d2b3902468c4a15082af0e15324fc37c201 02047541ccbfea550183dcd9cc21b11af6975339f61c5908f13b8f8d6d2c42fbdb",
                "hex" : "49304602210088aacfccfe71532a5bbfc3145bbff8c1f3470e228b35e879146b30ec4b3526b8022100f566b0aa825ee6786af3619f1e73d89d2b3902468c4a15082af0e15324fc37c2012102047541ccbfea550183dcd9cc21b11af6975339f61c5908f13b8f8d6d2c42fbdb"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 25.74101000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 a1ddfc061b9f000cb647f3cd1c08e6fdeacf72ec OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914a1ddfc061b9f000cb647f3cd1c08e6fdeacf72ec88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AusMMF3ETMkzvhfTUp61NoWBcCDoHcn9rQ"
                ]
            }
        },
        {
            "value" : 1.00000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 d840edbda2020b44b9fa4ad8ff912e79eb3cc000 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914d840edbda2020b44b9fa4ad8ff912e79eb3cc00088ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "AzpvNNAUFYjW79uCS1Q9ALNSVhABqrUC1U"
                ]
            }
        }
    ]
}

there may be multiple ways to find out what block it's in, but I stumbled upon one yesterday by attempting to resend the raw transaction:
jcomeau@aspire:~/.americancoin$ americancoind sendrawtransaction $(americancoind getrawtransaction 9982de4dc77eab126d2ad4837db477577bbeee733ef381c1889576cfbd328473)
error: {"code":-5,"message":"transaction already in block 29ddf391af012069f02a6e120348d5206548d50f818cad4d5182f28540d842fd"}
jcomeau@aspire:~/.americancoin$ americancoind getblock 29ddf391af012069f02a6e120348d5206548d50f818cad4d5182f28540d842fd | grep confirm
    "confirmations" : 167,

I'm well aware that one needs to get 120 confirmations on a block to get the block reward, but transactions, as I understand, are considered valid after 6. but this has surpassed even the 120. so where is the coin? I'm assuming someone else generated the same address with a different private key. if they instead stole my wallet (by cracking my netbook) it should still show up in the transaction list.
but is that the most likely possibility? there almost has to be something I'm overlooking.

bitcoind (and hence presumably also americancoind) keeps a separate database of "relevant" transactions so that it does not have to search the entire blockchain all the time.  Since you added a new address by copying wallet.dat, the daemon may never have figured out that transactions involving that address are relevant.
Try rebuilding this database with americancoind -rescan.  You can also try americancoind -reindex to rebuild all databases (this may take a long time depending on the size of the blockchain).
It's extremely unlikely that someone else managed to generate a private key with the same address.  If this were at all feasible, the currency would be useless.  Moreover, even if this had happened, what you should see would be your transaction sending one coin to Azpv... and then another transaction created by the attacker, sending the coin to an address controlled by him.

okay thanks! yes that makes sense. I'll delete my bad answer on the other question then!

source: Stack Exchange

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

sort: votes


text:
Is Mt.Gox currently accepting Dwolla deposits or withdrawals?
I know that Dwolla stopped depositing/withdrawing funds in Mt.Gox due to a court order, but does anyone know if this is still in place?
Related
Why can't Dwolla send to Mt Gox?

As of this writing, Dwolla is not sending money to MtGox
This is verified by accessing their deposit link here

That link doesn't say mtgox is not accepting money from Dwolla; it says Dwolla is not sending money to mtgox.

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


text:
How can I tell if my Bitcoin-Qt wallet is protected with encryption?
I am a new adopter of Bitcoins, forgive the ignorance. (note these are test transactions)
I am using the Bitcoin qt client and I am very confused and think I have done something wrong.

I have two computers A and B both with Bitcoin qt client on. I have made wallets on both computers.
After launching Bitcoin qt client for the first time on computer A I created two addresses using the 'new address' button. I then clicked 'Encrypt Wallet' and entered a passcode. Note I only did this process once, even though I created two addresses.
I then transfered two test transactions to the wallet on computer A from Bitstamp. These came through as:
https://i.sstatic.net/2ziI6.jpg

(don't know if anything looks wrong in that picture?)

I then tried my first ever test transaction and sent it to the address I created on computer B (I have never encrypted this wallet).
To my surprise this sent, even though I didn't have to enter any kind of passcode on computer A? Plus my address on computer B isn't even encrypted?
Does that mean anyone can use the funds I have in my wallet on computer A, without my passcode?
The status of the transaction on computer B is also,  8 confirmations? Is this a sign of a mistake. Also the 'from' is marked as unknown - is this important?
There is also no lock icon on my QT client, which I have been told there should be if the wallet has been encrypted?

I'm confused, please advise. Sorry for my ignorance, I am not a technically minded person but trying to adopt bit coins.

"(don't know if anything looks wrong in that picture?)" the "number of transactions: 1" is weird, when you clear have 2 transactions

On computer A, is 'encrypt wallet' still available in the menus?  It shouldn't be if the wallet is encrypted.

Incidentally, there was a forum thread opened for this as well: http://bitcointalk.org/index.php?topic=149057.0

You only need to encrypt each wallet once, no matter how many new addresses you make.
It sounds like the wallet encryption didn't happen.  Did you maybe not type the same passphrase twice or something?
People can only spend your funds if they have a copy of your wallet.  So even if you didn't manage to encrypt the wallet on computer A successfully yet, your funds are still safe as long as nobody gains access to your files.
The "8 confirmations" simply means that the transaction is buried 8 blocks deep in the blockchain, and so is very unlikely to ever be reversed.  The number of confirmations will go up by 1 every time a new block is added to the blockchain by a miner.
The 'from' field is always 'unknown' in my experience.  I don't even know what it's for.
My lock icon is in the bottom right corner of the client.  There are 3 icons, and the lock is the leftmost of them.  Try encrypting your wallet again and pay attention to what it says.  I suspect you didn't type the passphrase the same twice when you tried to encrypt your wallet, so it didn't do it.

If you encrypt your wallet, it will also be encrypted for all addresses your ever create.
Bitcoin qt will ask you for every transaction you made for the password.

Does that mean anyone can use the funds I have in my wallet on computer A, without my passcode?

At this moment yes, try to encrypt it again, maybe you made a misstake?

The status of the transaction on computer B is also, 8 confirmations? Is this a sign of a mistake. Also the 'from' is marked as unknown - is this important?

A confirmation means, that you transaction was successful added to a block and is processed.
Some markets or platforms need a certain number of confirmations.
Your payment is normal confirmed after 1 confirmation.

There is also no lock icon on my QT client, which I have been told there should be if the wallet has been encrypted?

Yes, there should be a "lock" icon on the right bottom. Try to encrypt your wallet again is it possible.


text:
Do I have access to the private key for an Instawallet?
It is just numbers and letters? I have transferred my bitcoin address and want to use the key so I can move my coins from this wallet to another? As you may be aware there site is down but can I set this up on another wallet so I can still get my coins?

You are misunderstanding something somewhere.  Instawallet never reveals the private key for the Bitcoin address tied to your Instawallet.

Isn't the No's/letters on the end of the URL the private key?

No, Instawallet is a hosted (shared) EWallet.
They do not provide to you the private key for the deposit addresses associated with your Instawallet.
When you request a withdrawal, Instawallet processes that request and makes the transaction.  There is no way for you to create a withdrawal transaction yourself for any funds in an Instawallet.

Thank you for the comment..Doesn't the URL they provided have the private key on the end of it? All my families ones do? I thought this was the private key as they said you should not lose it otherwise you cant access your coins?

The URL may be some hash or calculation of the private address, but even if so, it would be essentially impossible to reverse it into revealing the true private key.

ok..dam..I was thinking those No's/letters were the key.


text:
With Ripple, can I send IOU without setting a trust?
I have a simple question. User A wants to send to user B some IOU. There is no trust between A and B. There is no possible risk for user B. Can this be done without establishing a trust line? If no, why this is not allowed?

To pay someone, say, $10, you must deliver to them an asset that they have decided is worth $10. A person can never be made to hold an asset they did not agree to hold. These are core Ripple design rules that apply to all IOUs. The main reason for not allowing the "harmless" payment is that it might not be clear to the recipient that the payment is one he is free to ignore and this can create complexity for the recipient who may be legally obligated, for example, to refund it.
This was a close call though. We could have allowed this kind of payment with a special flag and designed the client to show those payments in a special way, and we could have added an account flag to indicate that you refuse these kinds of payments The added complexity and risk of confusion didn't seem to be justified by any significant benefit.

User A can only send IOUs that user B trusts.
Trust does not have to exist between A and B.
So if user B only trusts bitstamp for 100 USD and has 50 USD already in that wallet :-
User A can send up to 50 USD to User B as long as the issuer was bitstamp
The protocol will only allow IOUs to be sent to an address (from another address) which has a trust for them and then only up to that amount of trust.
The reason is to stop an address receiving IOUs it does not want.
User B might have a bitstamp account and knows how to redeem them. They do not want User A snapswap USD IOUs which you need a snapswap account to redeem to fiat.
There could of course be a path which exchanges snapswap and bitstamp USDs and so to User A it looks like they are sending their own USD but User B actually receives bitstamp USD.

In ripple, both parties need to share a trust link in order to send IOUs between themselves. It doesn't need to be direct, but there needs to be a link. Most commonly it will be a trust to a Gateway. Alternatively, users can send themselves ripples without trusting any party (or one can say that they need to trust the Ripple system in that case, but that would be just semantics), but that wouldn't be an IOU.


text:
Are Bitcoin ASICs Optimized for Fixed Length Messages?
Bitcoin block headers are 80 bytes.
int32_t nVersion;       // 4 bytes
uint256 hashPrevBlock;  // 32 bytes
uint256 hashMerkleRoot; // 32 bytes
uint32_t nTime;         // 4 bytes
uint32_t nBits;         // 4 bytes
uint32_t nNonce;        // 4 bytes
                        // total: 80 bytes

A SHA256 ASIC is specifically designed to (double) hash theses fields over and over until the resulting value is below the difficulty level, which is encoded by nBits.
Since it is a double hash, the ASIC has to be able to hash initial messages of length 80 and 32. After the padding required for SHA256, the byte strings that will be hashed have lengths 128 and 64, respectively. So, bitcoin ASICs obviously have to able to hash messages of length 128 and 64.
But say I have a file on my computer that is considerably longer (10,000x longer). Could I hash it with a SHA256 bitcoin ASIC?
Does it vary from SHA256-ASIC to SHA256-ASIC depending on how they are made?

Are Bitcoin ASICs Optimized for Fixed Length Messages?

It would really surprise me if they weren't. If you can make your cores 10% smaller by reducing the amount of memory available, then it's a no-brainer.

But say I have a file on my computer that is considerably longer (10,000x longer). Could I hash it with a SHA256 bitcoin ASIC?

In theory, it might be possible, but there's no point to it. Before the ASIC can hash your 800 KB file, it needs to be transferred to the ASIC. That's not so bad if the ASIC has a USB or Ethernet driver, but many don't; it's cheaper to use serial and buy a serial-to-USB converter from FTDI. These interfaces generally top out at 192 kilobaud, so it would take about 33 seconds to transfer the file.
However, most ASICs support a "midstate," which represents the internal state of the hash function partway through the input. The practical upshot of this is that you could hash the first 800 KB of the file with your CPU, then use your ASIC to vary the last 4 bytes of the file to search for a nonce below the target.
Lastly, I want to note that none of these ASICs are calculating SHA256. They're calculating SHA256d.

That's a good point about the midstate, so bitcoin ASICs might be optimized only for using an arbitrary midstate and only messages of 64 bytes. In that case, though, that means they can hash arbitrarily long messages as long as there is a feed supplying the data to be hashed.


text:
Multiple Addresses in one UTXO
The 'decoderawtransaction' RPC method of the Bitcoin-QT client gives a JSON object with an array of addresses in each UTXO. For example, when I run:
decoderawtransaction "01000000010fb72b5d299f095c3d3abc2130f20ce59d0ed08d56b3f247d6ae554f200eb561010000006a473044022073717edfcde0200f8aca33b6ff4f60a4aa84c6692cd1713876d94f3f19013f6d022057610074eef8285082cb9943913040031869cc98bc71642a3dc5e085a19a1805012103f071bc0f54b95e9049ba515f19cbfb647605a9f1d2f002b4e70ec548af5fbf5bffffffff02b02bc37d010000001976a9148037b2fd4114347070236b37f792966ade2bc4a688acd0ce4101000000001976a914336e5078d05a350fb5e6cdf8fc15d826e625423888ac00000000"

I get back the following JSON:
{
  ...
  "vout":[
    {
      "value":64.04910000,
      "n":0,
      "scriptPubKey":{
        "asm":"OP_DUP OP_HASH160 8037b2fd4114347070236b37f792966ade2bc4a6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex":"76a9148037b2fd4114347070236b37f792966ade2bc4a688ac",
        "reqSigs":1,
        "type":"pubkeyhash",
        "addresses":[
          "1CgxDbrb9d18DFvQn6DW8ij3c6ARpipehU"
        ]
      }
    }
  ]
  ...
}

You can see here that "addresses" is an array. Why is this an array? Can one UTXO send to multiple addresses? I know P2SH addresses can pay to an address that can be redeemed by the use of multiple addresses, but I'm wondering about sending to multiple addresses without the use of P2SH addressses. What would be the format of the scriptSig/scriptPubKey for doing so?
Also, if you only have the P2SH address, then can you determine what the requirements for redeeming from that address are?
Thanks!

An address is a shortened notation for a particular script. As a transaction output contains exactly one script, it has at most one address (it is possible that the script does not correspond to a particular address, though).
Due to historic reasons, a (normal pay-to-pubkey-hash) address is however also used to refer to keys (by giving the address that would correspond to a script paying to the hash of that key). The array that decoderawtransaction and gettransaction return as 'addresses' is an example of this. For a (non-P2SH) multisig address, if it is a m-of-n multisig script, it will decode the script, and give the keys it pays to (in address notation).

Interesting, thank you Pieter. So, this list seems to be just a list of all the addresses that were used in the 'scriptPubKey', right?. And if there is only one address used then the coins can be thought of as crediting the balance of that address. But if more than one address used in the script (like in a raw multisig transaction without P2SH), then the script does not correspond to a particular address and cannot be thought of as crediting the balance of any of the included addresses. Does this all sound right?

Crediting the balance of (some aggregate of the included keys). The 'addresses' listed are not really addresses - just keys formatted as the address it would be if that were the only key.

Thank you, Pieter. Do you know of any examples of a transaction that would have multiple addresses (keys) returned in the "addresses" JSON array? I'm looking for a link to a transaction in a block explorer that uses raw multisig like this, but can't find one.

I found one here. But when I decode this transaction using my own QT wallet (debug console), the scriptPubKey "type" is just non-standard, and there isn't an addresses array. Will it ever be the case that there is more than one address in the "addresses" array? I can't find a case with more than one. Outputs that pay to P2SH addresses also just have a single address in the "addresses" array.

I just found this transaction, which illuminates things for me. If it's an n of m raw multisig address, all m addresses are given in the scriptPubKey array.

Can one UTXO send to multiple addresses?

No. UTXO is a destination/address/output/scriptPubKey/...

I know P2SH addresses can pay to multiple address

Wrong. P2SH outputs can be redeemed by holders of several (even none) private keys. P2SH-output is not splitting funds.

P2SH address, then can you determine what the requirements for redeeming from that address are?

Ususaly, no. Sometimes google and other search engines can help. P2SH-address is a hash of unknown script. It is not possible to construct script back from its hash.

Thank you, Amaclin. About the multisig addresses, I worded that incorrectly. I meant to say that multisig addresses involve many addresses in the spending from those addresses. Meaning, the reward is given to one address, and multiple private keys are required to formulate a script that can spend the money awarded to that multisig address. Correct?
It is good to know that each UTXO rewards exactly one address. Is there any edge case, however, where a custom script could award two addresses in a script.


text:
What purpose does XRP serve in the ripple protocol?
I have been reading over this document that Ripple Labs put out. The document says that:

XRP is there to provide two key functions: to prevent abuse of the system and to act as a bridge currency for market makers providing liquidity within the network. Thus, users can hold balances in one currency and transact in another currency without converting to XRPs in the process.

And later

In theory, users of the Ripple Network could exchange anything of value.

Bitcoin already has spam prevention, and a much larger trading volume than Ripple, though. It's not clear to me why everything that Ripple Labs is doing couldn't have just been done with BTC.
I really like what most of what Ripple is doing (trying to integrate with the existing financial system, for example), it's just hard to trust it knowing that the developers own so much XRP, combined with believing that it could have just been done with BTC. So, essentially, I'm looking to be convinced that the creation of their own token was, in fact, necessary.
Is it just to fund Ripple Labs? I don't mean that in a negative way, I actually think that funding the development of decentralized applications is a difficult problem. Decentralization inherently allows users to participate in the system without consent from an authority, and without needing to pay any single entity. But then what incentive does that developing entity have to create the system? I think this is why so many decentralized projects are opensourced projects, rather than proprietary solutions. And the ones that are proprietary solutions (like Ripple), usually create their own token.

I don't think Ripple is proprietary - the development and operation of the verification servers is definitely highly centralized, but the roles they take could be done by someone else if everyone at Ripple HQ was hit by a bus.

Maybe proprietary isn't the right word, but I think making a profit is at least one of the goals of the projects, in addition to it just creating a great technology that will streamline banking technology.

It's not clear how you're imagining doing what Ripple does with Bitcoins, so it's hard to say whether you're correct or not.
If you mean with the Bitcoins still being transferred on the blockchain and being used directly to pay transaction fees for Ripple transactions, that wouldn't work. Bitcoin transactions take time to confirm, and slowing Ripple down to Bitcoin's speed wouldn't make sense.
If you mean with the Bitcoins being virtualized somehow onto Ripple's ledger, it's hard to see how you can do that reliably without a central authority. Also, what do you do with the Bitcoins that pay transaction fees? Destroy them?
You haven't really set out your proposed alternative in much detail. It's possible that you do have some good way to do it. But I don't know of one.
One of the main points of Ripple is to solve the double spend problem without relying on proof of work and without being vulnerable to 51% attacks that have no clear solution. Building on top of Bitcoin would make a system that was at best no stronger.
There are significant benefits to having a native currency on the same ledger.

I guess I'm a little unclear about how the ripple blockchain works differently than bitcoin, and how XRP are used to conduct transactions within the system. Are the transactions for other currencies encoded into the same ripple blockchain? If so, I could definitely see why having a native asset on a blockchain that works very differently (allowing the record keeping of multiple units of value), would be very useful. Am I way off base here?

I wasn't really trying to make a proposal so much as I was just trying to understand what properties tokens on the ripple blockchain have that tokens on the bitcoin block don't. I definitely don't understand all the ins-and-outs of how Ripple works, so this may seem like an illogical question, but I suspect it's one that others have had.

Ripple uses a ledger rather than a blockchain. But the basic function is the same. XRP is used to pay transaction fees, and you pretty much have to have a native asset to do that. (You could use proof of work, but that has severe disadvantages.) The basic difference is that Ripple was designed from the ground up to support arbitrary assets and atomic, cross-asset payments.

Does the Ripple ledger allow for atomic trustless trades of currency by both parties consuming inputs and receiving outputs within the same transaction? And thanks for your explanations. The take-away I am seeing is that it's because Ripple needed a blockchain/ledger with native support for trading in any currency, and transaction fees are paid in XRP. If you modify your answer to note that the fact that the native tokens and the records of other currency being on the same ledger is important, I'll mark it.

The Ripple ledger allows for atomic transactions with complex payment paths, so a payment can draw from multiple order books (either in parallel, in series, or in combinations). Each payment transaction has a single sender and receiver though.


text:
How did Bitcoinica get its prices?
I'm interested in building a Bitcoinica replacement and wondered how did they get their pricing information.
Was it from Mt.Gox and was it verifiable, I mean could you have gone to a web site and seen a history of prices and therefore know why your position may have been liquidated ?

As far as I know:

Yes, Bitcoinica's prices were based on MtGox ticker
Using the MtGox price, they had an algorithm to build their spread (you will always buy on bitcoinica at a higher price and sell at a lower price than the reference mtgox price, thats where a broker like bitcoinica makes profits).
Yes, Bitcoinica had some charts, where you could see the reference price, and the spread (the graph was called "daily quotes"), so yes you were able to check the price and spread and understand why you had been liquidated.

No guarantee on these answers, I'm not in the Bitcoinica code, this is just how I understand this.

Do you mean to say that Bitcoinica doesn't actually have it's own market?


text:
P2SH that pays out only to a certain Bitcoin address?
Is it possible to create a type of redemption script that when the correct number of signatures are collected pays out to a pre-defined address ?

And who would be able to sign? If anyone can sign, this is trivial to game. Otherwise it is multisig?

Yes it would be multi sig. Basically a multi sig address that only pays out to a pre-determined bitcoin address.
This would be useful as a secure bitcoin vault. Even if the key holders collude. The destination can't be changed. You could then create a hierarchy of wallets with different approval levels.

Ah, sorry, I had overread the "pre-defined address" part. Carry on. :)

I believe this is possible, but with a subtle difference to how OP suggests.
OP seems to want: funds are first signed off by the multisig address, then a transaction is broadcast moving the funds to [destination].
It's not possible for a destination script to stipulate where the funds can end up. A new opcode could introduce that feature, but we can do this a different way.
I would argue this no weaker than having a transaction between the two destinations (as OP envisioned). In either case the multisig participants could hold the funds to ransom before the end user can move them.
Multisig: 2 [pubkey1] [pubkey2] 3 CHECKMULTISIG
Destination: DUP HASH160 [hash] EQUALVERIFY CHECKSIG

Since we cannot lock funds so they are released to a certain destination, we just merge the two scripts, allowing predefined party to take control only when the multisig is solved. He would propose a spend to the others, they sign, then he signs (it can be done in any order)
The scriptPubKey (or P2SH script) would then look like this:
 2 [pubkey1] [pubkey2] 3 CHECKSIG DUP HASH160 [hash] EQUALVERIFY CHECKSIG

And the scriptSig:
 [sig1] [sig2] [sigA] [pubkeyA]

Re ransom/theft: In the predetermined address case, they would refuse to sign release unless they are paid 1BTC. In my case, they would only sign a transaction if x% goes to their address.


text:
Will the block reward continue halving beyond 1 satoshi if bitcoin precision goes beyond 8 decimal places?
If bitcoin precision is increased beyond 8 decimals, will the block reward continue halving forever instead of eventually going from 1 satoshi to 0 satoshi?

Where'd you get the idea that having 8 decimals was temporary?

The "8 decimals limit" is not that, but rather bitcoins are a human readable representation for 100,000,000 satoshi: The software natively computes in satoshi.
What happens under the hood is that the limit of satoshi that a miner may claim by creating a block halves. Obviously, only whole satoshi can be claimed, (as currently they are indivisible), so after block 6,930,000 when the reward limit drops from 1.164… satoshi to 0.582… satoshi per block, one cannot claim a whole satoshi anymore, as it would be greater than the limit.
If a new smallest unit of Bitcoin would have been introduced by then, we could continue to claim parts of a satoshi until the reward limit drops below that new unit.
In fact, we will be losing out on part of a satoshi in every block starting with block 2,310,001 when the reward drops from 9,765,625 satoshi to 4,882,812.5 satoshi in approximately 2049.

There are several places where the 8 decimals property is listed as something that can change over time. This is true, but not in any meaningful way.
Of course Bitcoin can change. It's a piece of software that people run. If all those people agree to suddenly start using changed software, anything is possible.
Changing the number of decimals is not technically difficult. It would just require an extreme degree of consensus and coordination to make it happen. So unless not changing this is seen as a clear and inevitable danger to the Bitcoin ecosystem, it is very unlikely to ever happen (nor do I think it is necessary, but who knows what the future brings).
Once we decide to change the number of decimals, anything can be changed. Including, how the mining subsidy changes in the long term.
So, the answer to your question is: whatever the future Bitcoin ecosystem agrees upon.

I'm not sure that changing the number of decimals is on par with "anything could be changed": Increasing divisibility would of course require a lot of changes to the protocol and programming, but conceptually is it a very small change, and not one that significantly changes how Bitcoin works: The total amount of money in the system wouldn't change (well, by a few satoshi that could additionally be mined), and most importantly, it could be done without redistributing any holdings. I get why it would still be hard, but isn't it magnitudes easier than e.g. changing the reward schedule?

That's all true, but it doesn't change the fact that whatever "everyone" agrees upon, can change. Obviously not everything is equally likely to be agreed upon :)


text:
How to get sender address from transaction with JSON RPC?
I'm using JSON-RPC call to connect to local bitcoin node on my clouding server.
I could get all transactions with wallet name by using gettransactions.
Now I need to get sender's address for each transaction but result contains only receivers' address.
Following is response of gettransactions request.
{
    "result": [
        {
            "address": "bc1qd9mgd4ynryaw2kp0pzfjdxguhz9dzvs5vh0nfn",
            "category": "receive",
            "amount": 0.001,
            "label": "",
            "vout": 27,
            "confirmations": 1322,
            "blockhash": "000000000000000000074551080f954e790edfe6ad810ecebf4691e881175eaf",
            "blockheight": 660029,
            "blockindex": 106,
            "blocktime": 1607147554,
            "txid": "07ab59c8d3a204172887085258460d0058c20a9acdb451daa5ad4290cbd461b0",
            "walletconflicts": [],
            "time": 1607147511,
            "timereceived": 1607147511,
            "bip125-replaceable": "no"
        },
        {
            "address": "bc1q6dh3h5e3qgku8u9s8y664844fj4fkm08n7cnwt",
            "category": "receive",
            "amount": 0.0011,
            "label": "",
            "vout": 9,
            "confirmations": 1313,
            "blockhash": "00000000000000000000960f4476a8552cac203eec6e0f826886b41fae402bec",
            "blockheight": 660038,
            "blockindex": 393,
            "blocktime": 1607153799,
            "txid": "af0885e4c1d10e935de525680c6c33d221ab506742b08e34a0322bba90b56fb0",
            "walletconflicts": [],
            "time": 1607152236,
            "timereceived": 1607152236,
            "bip125-replaceable": "no"
        },
        {
            "address": "1L8ZNCibVVpPjJ8VJ1ALLuTjtctA4mzGPw",
            "category": "send",
            "amount": -0.001,
            "vout": 0,
            "fee": -0.00008536,
            "confirmations": 706,
            "blockhash": "0000000000000000000c3230522e267980bb990883cc0b36460ad3efc1f8fed4",
            "blockheight": 660645,
            "blockindex": 1049,
            "blocktime": 1607529332,
            "txid": "a2056e7a49bc608435713519bc038ed7da2e65f588495f36c6628f5ca6fe2d7d",
            "walletconflicts": [],
            "time": 1607528963,
            "timereceived": 1607528963,
            "bip125-replaceable": "no",
            "comment": " ",
            "to": "seans outpost",
            "abandoned": false
        },
        {
            "address": "1L8ZNCibVVpPjJ8VJ1ALLuTjtctA4mzGPw",
            "category": "send",
            "amount": -0.0005,
            "vout": 1,
            "fee": -0.00008536,
            "confirmations": 705,
            "blockhash": "0000000000000000000994e21412109847caffa2bd990884f49461d53c047055",
            "blockheight": 660646,
            "blockindex": 844,
            "blocktime": 1607529675,
            "txid": "ddbe1dce4537926b6cf5bc1e222e5cd32de224cf346ca89251c127ce32226f30",
            "walletconflicts": [],
            "time": 1607529401,
            "timereceived": 1607529401,
            "bip125-replaceable": "no",
            "comment": " ",
            "to": "seans outpost",
            "abandoned": false
        }
    ],
    "error": null,
    "id": "curltest"
}

How can I get sender's address?

What do you need the sender address for? Bitcoin doesn't really have such a concept. There are approximations but they're often wrong. If the goal is distinguishing multiple payments to determine who paid, the best practice is giving a different receiving address to for every payment.

@PieterWuille Certain regulatory reporting schemes require a list of the sending addresses. The sending addresses can definitely be discovered for a given txid and would be considered pertinent information as shown by every blockchain explorer.

What if the transaction is a payjoin/coinjoin? The "apparent" sending addresses would belong to a multitude of unrelated people. If funds are withdrawn from an exchange, the apparent sending address may belong to a different exchange customer. Just because data is visible does not mean it is meaningul.

@PieterWuille I agree with your statement that "visible does not mean it is meaningful", but that is irrelevant to the original question about how to achieve this in a technical manner (not what the significance of the result is). It seems you agree that the concept exists by having a conversation about its meaningfulness or usability. If the transaction is coinjoin then the sending addresses can still be enumerated in the same way. The connections between inputs and outputs in coinjoin transactions may still be inferred through certain heuristics.

Despite how it looks on most block explorers, Bitcoin doesn't really have a concept of a "sender address", at least not on the raw transaction level. What a transaction has is inputs and what block explorers do is go look up those inputs and guess the address that was used to create those UTXOs.
You might find these related questions useful (just search this site for "sender address"):
How to findout the sender of a transaction
Sender address from DecodeRawTransaction (C#)

To get the sender address from Bitcoin Core, you will have to track additional information about the blockchain by setting txindex=1 in the configuration file. This is because the sending address of the transaction in question is only associated with the previous transaction. Setting txindex=1 configures Bitcoin Core to maintain the entire transaction index, beyond what pertains to your wallet or read-only addresses, allowing you to call getrawtransaction on any txid.
Once you have properly configured and synced Bitcoin Core, you can retrieve the sending address(es) of a transaction by looking through each input tx using decoderawtransaction(getrawtransaction(txid)) (code pulled from this answer):
txid = <relevant transaction id>
addresses = []
raw_tx = decoderawtransaction(getrawtransaction(txid))
for(input in raw_tx['vin']) {
  input_raw_tx = decoderawtransaction(getrawtransaction(input['txid']))
  addresses.push(input_raw_tx['vout'][input['vout']]['scriptPubKey']['addresses'][0])
}

Many blockchain explorers have free low-volume API access and you can just query their data instead of maintaining a full txindex node. Two that come to mind are Blockchair and BlockCypher (BlockCypher even includes all the sender addresses in their tx endpoint so you can retrieve these with a single API call instead of querying each input tx from Blockchair like you would need to with Bitcoin Core).

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


text:
Locking litecoin wallet with JSON-RPC
There is this very helpful post detailing how to lock and unlock your bitcoin wallet using walletlock and walletpassphrase api calls. Unfortunately the litecoin api does not boast these features.
I was wondering if there is a similar strategy in place for securing a litecoin wallet perhaps using the lockunspent command?

Actually, Litecoin-Qt/litecoind v0.8.5.2 and probably several v0.8 releases before do support these api calls.
The --help doesn't seem to have any entries on these commands but this is true of Bitcoin-Qt/bitcoind as well so if you want to submit a bug report or code it and submit a pull request, please do so at https://github.com/bitcoin/bitcoin.


text:
Key Pools and best practices
I'm wondering about what the best practices are around generating and maintaining key pools for a wallet.

What is the maximum number of keys/addresses that can be created for a single wallet? Phrased another way, what is the largest value one can safely put for the keypool option in bitcoin.conf?

If I generate some keys with bitcoind keypoolrefill then generate some new addresses and then call keypoolrefill again, will the original addresses still work, and will my private key now work for all addresses I've ever created?

Is there some way to determine how many keys are left in the current key pool?

The Bitcoin documentation says that this feature is actively being phased out. When will this happen and what will the new system be?

This wallet type is being actively phased out and discouraged from being used due to the backup hassle.

Answers to any of these questions is greatly appreciated.

Gavin Andresen (Bitcoin's Chief Scientist) has to say on the topic:

Backup every 30 sendtoaddress or generatenewaddress and you'll be fine-- you should always have at least 3 backup copies of all your keys.
If you're running a very busy service so backing up every 30 is too often, then run with -keypool=1000 and backup at least every 300 sends/generates.

The new system is Hierarchical Deterministic Wallets, BIP 32.

What is the maximum number of keys/addresses that can be created for a single wallet? Phrased another way, what is the largest value one can safely put for the keypool option in bitcoin.conf?

The type of that parameter is int64_t so the maximum value is 2^(64-1)-1. In practice, you can put any number you want and it should not make the software break. However having a lot of keys (hundreds of thousands) will result in a very large wallet and potentially slow down the wallet loading phase.

If I generate some keys with bitcoind keypoolrefill then generate some new addresses and then call keypoolrefill again, will the original addresses still work,

Yes. Everything is stored in the wallet and keys are never deleted.

and will my private key now work for all addresses I've ever created?

That's not how private keys work. Each address has a private key, so if you have one private key, it corresponds to one address. Each address that is generated in the keypool will have its own private key which is stored in the wallet file.

Is there some way to determine how many keys are left in the current key pool?

bitcoin-cli getwalletinfo will tell you how many keys are left in the keypool. The keypool is automatically refilled when your wallet is unlocked.

The Bitcoin documentation says that this feature is actively being phased out. When will this happen and what will the new system be?

This system with the keypool is still in use and making periodic backups is still recommended as the wallet contains transaction data that is not backed up by deterministic wallets. The "new system" is to use BIP 32 Hierarchical Deterministic key derivation instead of randomly generated private keys. A seed is first randomly generated and then all private keys are derived from that seed. This means that only one backup is necessary in order to backup all of your private keys, but periodic backups are still recommended as stated above.
This feature was added to Bitcoin Core in Bitcoin Core 0.13.0. Most other modern wallets use BIP 32 HD wallets.


text:
Is it possible to reject a bitcoin payment?
Say someone sends bitcoin to an address. It is later determined that those incoming funds are tainted and the recipient wants no association. What is their recourse?

You should be aware that the concept of "tainted" coins is at best very controversial and at worst damaging to the Bitcoin ecosystem. It implies that Bitcoin lacks fungibility which is a crucial component of a useful currency.

The protocol doesn't include a way to reject transactions, for a variety of reasons (the protocol doesn't know which output is real and which is change; blocks can't be changed after being mined; etc) but it is possible to do something similar.

Accept payment, then return it
Pick one of the funding addresses at random, then send the coins back to that address.
Accept payment, then destroy it
Send the coins to an address that doesn't have a private key associated with it, like 1BitcoinEaterAddressDontSendf59kuE.

Implementations
To my knowledge, no client implements an easy way to do either of these things. The best way would be use coin control to select the offending output, then make a transaction that returned/destroyed it.

Note that in general it's a very bad idea to send coins back to one of the sender addresses without contacting and agreeing with the sender first. You can't assume the sender (still) has control over that address, so the coins might go to the wrong person or be lost completely.

A third choice you have is to spend the coins as miner fees. That way you help secure the network a little instead of actually destroying the coins for eternity.

@Jannes That's technically true, but 95% of the time, people who have control over an address have control over it 24 hours later. There are exceptions (shared send) but they're exceptions, not the rule.

@NickODell Your 95% estimate seems dangerously high IMO.... if sent from an exchange or a web wallet, it's often the case that the payer does not control the private keys which sign the tx.

@NickODell Apart from being an dangerous estimate, even if it's 1 in a million: it will end up destroying money. So you have to assume the worst. That means only in the case where you actually want to destroy money, could you use that method. But if you want to actually destroy the money, the it's better to use option 2 (or 3).

@Jannes if it's 1 in a million: it will end up destroying money So? 1 in a million is a perfectly acceptable rate to lose money, especially when it's not yours. But if you want to actually destroy the money, the it's better to use option 2 (or 3) Sending the money to someone else is not really the same thing as destroying it. I mean, as long as we're sending the money to someone else, why not donate it to charity, instead of a random miner?

Personally I would make a new wallet, then delete it. Mostly because I don't know how to spend it as a miner fee.

You seem to be getting the order of that wrong. When somebody sends you an unwanted payment, how does creating a new wallet provide any recourse?

Would you like to learn how? https://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr/12452#12452 is a good deep dive. Or much simpler, just send some tiny amount to yourself and make the rest the fee. How to do this depends on what wallet client you're using.

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


text:
Exception in Boost library when running bitcoind.exe
I've built Bitcoin 0.8.6 on Windows 32bit using mingw32 and now trying to execute bitcoind.exe in the prompt using the following command:
bitcoind.exe -datadir="e:/BitcoinDataTest"
I'm getting the exception "N5boost10filesystem16filesystem_errorE" related to Boost. Can anybody help me to solve this issue? Thanks.
Output:
Bitcoin version v0.8.6.0-g03a7d67-beta (Thu, 5 Dec 2013 13:11:26 +0100)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Default data directory C:\Documents and Settings\Admin\AppData\Bitcoin
Using data directory e:\bitcoindatatest
Using at most 125 connections (2048 file descriptors available)
Using 2 threads for script verification
init message: Verifying wallet...
dbenv.open LogDir=e:\bitcoindatatest\database ErrorFile=e:\bitcoindatatest\db.lo
g
************************
EXCEPTION: N5boost10filesystem16filesystem_errorE
boost::filesystem::status: The operation was concluded with success: "e:\bitcoindatatst\wallet.dat" C:\mybitcoin\bitcoind.exe in AppInit()

************************
EXCEPTION: N5boost10filesystem16filesystem_errorE
boost::filesystem::status: The operation was concluded with success: "e:\bitcoindatatst\wallet.dat" C:\mybitcoin\bitcoind.exe in AppInit()

Shutdown : In progress...
Flush(false)
DBFlush(false) ended               0ms
StopNode()
Flushed 0 addresses to peers.dat  0ms
Flush(true)
DBFlush(true) ended               0ms
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::remove: The operation was concluded with success: "e:\bitcoindatatest\bitcoind.pid"

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

Does the available Windows binary have the same problem, or is this something specific to your build?

The official binary client works fine on my Windows. I think the problem is related to my build only. It's fun because it shows an exception but at the same time it shows a successful message.

This question appears to be off-topic because it is about an individual programming problem.


text:
Cryptocurrency compile error
I'm compiling a SmallChange clone on Mac OS using the .osx makefile, and I get this error. What should I do?
'boost/assign/list_of.hpp' file not found

Install boost.
See the instructions if you have additional problems.

Can I get db48 set up with homebrew instead of macports?  I get the error: fatal error: 'db_cxx.h' file not found

I think I fixed the above error. Getting now: unsigned char *SHA256(const unsigned char *d, size_t n,unsigned char *md) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;

@meecoder That's outside of the scope of this question. However, I made a new question. http://bitcoin.stackexchange.com/questions/30502/deprecation-error-on-mac


text:
What level of mathematical understanding do I need in order to contribute or to understand the crypto behind bitcoin?
My mathematical knowledge is up to CALC II (college level.) Is this enough mathematical maturity in order to understand the crypto in bitcoin or do I need more knowledge? If I do indeed need more knowledge than please point me to good books/resources to learn them. Thanks!

I'm no expert, but hopefully this answer helps a bit. In my opinion you only need about year 11 calculus and algebra to understand the basics of elliptic curves and modular arithmetic. You can learn everything you need to know by googling and watching youtube videos. Here are some resources:

a layman's guide to elliptic curves
a visual guide to secp256k1 i started (incomplete but still useful)
an introduction to modular math by the khan academy

and if you are familiar with python or keen to learn then pybitcointools has a native implementation of all elliptic curve functions used by bitcoin. once you are familiar with the math then this code will be very useful for verifying your results.

somewhat working mirror of the layman's guide: https://web.archive.org/web/20141114045348/http://www.royalforkblog.com/2014/09/04/ecc/


text:
Copying my Blockchain account to Multibit
Please can you tell me if it is possible to transfer my Blockchain account to Mulitibit.I want to keep my bitcoin address but back it up on Multibit.

You are looking for the export section on blockchain.info. This will provide you with your private key(s) so you can then import them on Multibit.
If you go to the "import/export" tab there will be an option to export your private-keys for every address in your wallet. There is also an import function that allows you to import a private-key into your blockchain.info wallet. You can click on export unencrypted and it will display your public and private-keys in a JSON output. The long string of what seems to be random characters after the "priv" is actually your private-key. The string of characters after the "addr" is your address. As you can see in my example there is more than one key exported. If you wanted to you could copy the private-key and then import it into another wallet program. This would allow you to access this address from more than one wallet service.

Never show anyone your private-keys.
I am only showing these keys for demonstration purposes.

How do you then transfer it to Multi bit as there does not seem to be an option to import private keys on that

There is an import private key with multibit classic, so I assume you are using the new hierarchical deterministic multibit (Multibit HD)? These are two different types of key management methods. With multibit HD it uses seeds which then creates new addresses based on that seed. Whereas blockchain.info and multibit classic uses single address management.  So in otherwords, you won't be able to use multibit HD to back up blockchain.info, single addresses. You'll need to use electrum or switch to multibit classic.


text:
Creating your own Bitcoin price ticker
Say that you wanted to build your own Bitcoin price ticker from scratch, and not rely on other tickers; how would you go about that?
What variables would come in to play? How would you gauge the price of the coin? Would you add multiple tickers together to get an average, or would it be standalone?
I was always interested in this but could never get my head around how websites do their own price tickers.

There are two possible actors that may build a ticker: exchanges and observers.
Exchanges actually perform trades on their platform so they'll likely be using the last price a trade was performed as the current price.
Observers do not trade themselves and will have to rely on exchanges to get the raw data on trades. They'd then pick the last trade price for each exchange and combine them into a single value. A wide range of schemes is available to merge the values. CoinDesk for example uses an average weighted by an exchanges daily volume.


text:
Can an SHA256 hash be used as an ECDSA private key?
Is it possible to map a pass-phrase directly to a Bitcoin private key by using its SHA256 hash? I remember reading somewhere that not all 256 bit values are valid ECDSA private keys. If so, how can I make sure that the resulting hash is valid, or is there some other canonical way of mapping a pass-phrase to a private key?

While the question isn't an exact duplicate, the answer essentially is, so I'm going to quote this answer by Pieter Wuille:

As is normal when doing Elliptic Curve encryption, a private key is
  simply a random number. In the case of secp256k1, the elliptic curve
  used by Bitcoin, it has to be a number between 1 and
  115792089210356248762697446949407573529996955224135760342422259061068512044368
  (or in hexadecimal, between 1 and
  FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551.
This private key is converted to a public key by performing an EC
  point multiplication with the curve's base point. The result is an
  (x,y) coordinate pair, which constitutes the public key.
Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of
  those coordinates, is computed, and encoded in base58, together with a
  checksum. This becomes the address.

So the short answer is yes, as long as the resulting hash is less than or equal to FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 any SHA256 hash is an acceptable privkey.
As for a canonical method of mapping a passphrase to a privkey, I don't believe there is one - after all, this functionality isn't built into the Satoshi client (at least not yet) so there cannot, by definition, be a canonical method. The closest thing I can think of would be the mini private key format used by Casascius physical bitcoins, which could easily be used with a passphrase instead. Indeed Casascius' Bitcoin Address Utility is often the app of choice for those wishing to make "mental wallets" from memorized passphrases rather than random inputs.

Thank you very much for your answer! AFAICS, Casascius doesn't seem to care at all about the fact that the result of SHA256 might not result in a valid private key. I understand now that this is a very rare corner case (about 2*10^-10), but still. Maybe hashing a second time in case the first result is larger would be a sensible behavior?

@Noah If Casascius would not obtain a valid private key, how do you think he would be able to obtain the public key from it? Without a valid private key you can't have any Bitcoin Address to put the coins to, and as far as I know, every Physical Bitcoin clearly shows what address is stored in it.

You're right of course, but since my question was specifically aiming at these corner cases, I think pointing out that they are simply not handled at all in the "app of choice" for brain wallets is justified. Besides, there might be automated implementations of such a mapping which cannot afford to just ignore these cases. Anyway, criticizing the Bitcoin Address Utility was in no way my intention, but obviously it does not cover the case I was asking for.

I can't say without looking over the code whether this corner case is handled at all, letalone how it is handled, but I would assume that in the extremely unlikely event of sha256(passcode) producing an invalid privkey the BouncyCastle crypto library would throw an error rather than generating an invalid keypair.

The most common way it's handled is to reduce modulo the generator. I believe the OpenSSL libraries do this automatically. (The consensus among the security community is that reducing modulo the generator has no significant effect on the security properties and there's no benefit to using more sophisticated methods.)


text:
Is there a Bitcoin exchange which has bank accounts in South Korea?
Is there any exchange, or a website selling Bitcoin, which has a bank account in South Korea?

CryptoXChange.com will let you withdraw KRW directly to your bank account in South Korea. They just opened about a week ago.


text:
Upgrading Multibit (without losing wallet)
I am using Multibit 0.4.23 but would like to install Multibit 0.5.9.  How would I move my coins from my current wallet? Is this done automatically?

Pretty much every single program allows you to upgrade it without losing data, and Multibit almost certainly isn't exception.
Just upgrade it.
In case you're worried, backup your wallet first.


text:
Using Ripple for assets accounting, loans, deposits, stock exchange, etc
If Ripple can handle money as exchanger, is it possible to use it for other financial operations like assets accounting, loans, deposits, stock exchange etc.?

Ripple has a contract system under development. This will allow people to bind Ripple assets or accounts to a set of rules. This should be usable for most of the things mentioned in your question.
Loans, ideally, would be done just as negative balances on a pathway.


text:
What is the refresh interval of MtGox ticker API?
I'm using the MtGox ticker API (from MtGox API V2) and I want to know the update interval. I think it is less than 3 minutes, but is it possible to know exactly? It is important to me because I'm developing an Android app that shows the current price to the user in notification bar.

I made now some tests and it seems to be less than one minute, but it variable. I don't know how they cache this value.

if you want fast http ticker use the new fast_ticker :
http://www.reddit.com/r/Bitcoin/comments/1c9npl/mtgox_fast_ticker_last_only_no_rate_limit_1second/
http://data.mtgox.com/api/2/BTCUSD/money/ticker_fast
and you will get 1 second only cached minimalist ticker ( last )
if you need more ( low, high, volume ) you have the normal ticker, most probably cached 30 seconds :
http://data.mtgox.com/api/1/BTCUSD/ticker
the new data.mtgox.com is behind cloudflare now and the only ratelimits you will hit will now be cloudflare anti dos limits
old api urls not using data.mtgox are now deprecated and not guaranteed to work

Perfect answer! BTW, I'll use this fast ticker in the next version of Bitcoin Paranoid: 1.5

To get the update interval for Mt.Gox HTTP v2 API endpoints, use the Cache-Control and Date/Expires HTTP headers.
I see a lot of misinformed information going around that the ticker_fast has a 1s cache time. I did some testing (with ticker and ticker_fast) and both the ticker and ticker_fast APIs won't update until their cache time has expired. This is a stateless API so everyone receives the same cache headers. The actual cache time varies somewhere between 20-30 seconds (at the time of writing this post), this might adjusts on-the-fly depending on how much server load they are receiving.
Try it yourself:
https://data.mtgox.com/api/2/BTCUSD/money/ticker_fast
https://data.mtgox.com/api/2/BTCUSD/money/ticker


text:
Setting up a coinbase like service in India , need suggestions
I have read and researched extensively on bitcoin, but I haven't found any service like coinbase that allows a user to buy or sell bitcoins online without having a US bank account. So how can one start an exchange like coinbase for India ? What are the legal obligations and initial startup cost ? Any advise would be welcome.

You should visit http://rbitco.in It serves all your purpose.

Nilam, that may be true, but it's not really answering his question.

Yes, Nick, you are right. But the only option available for trading is localbitcoins.com. rbitco.in is also coming up with solutions for individuals. I just came to know about it and hence replied.

You should first consult a lawyer in your country and discuss such topics as:

Money laundering laws
Whether Bitcoins are considered a currency, commodity or none of the above
Regulations considering money exchanges

In relationship to the law in your country. It would also be good to asking a legal representative of the government for an official statement in writing on trading Bitcoin and their legal status. This way you would be able to refer back to that decision in case any legal doubts come your way.
Having done that, the procedure would probably be similar to starting any business in India, with a possible addition of any special laws that you'd have to abide by when running an online money exchange.
I should state however, that I am not a legal expert nor do I have any experience with running a business in India. As stated above, consult a lawyer before taking actions.

If you're a developer you could start with some open source exchange software. Bitcoin Central provided this: https://github.com/davout/bitcoin-central. It might be a bit out of date now, but should be enough to get you or another developer off the ground.
Alternatively, you could just set up a website that reads the latest BTC/INR price from, say, Coin Mill and then provide a business account that allows people to deposit sums. You'd need to ensure that their deposit contained a reference number and was tied to their originating bank. After the deposit clears (so is irreversible) you can release the bitcoins you had on hold for them.
I'm not a lawyer, nor familiar with the legal situation for money handling in India. You will need a local lawyer to advise you with taking business payments through a bank. However, most countries require you to keep Know Your Customer (KYC) records of anyone who you deal with in fiat currency (like INR). This is for Anti-Money Laundering (AML) treaties that many countries have signed up for.
India would greatly benefit from having low-cost/friction access to Bitcoin so you might be able to approach the Bitcoin Foundation for assistance.


text:
Finding "lost" bitcoins
Bitcoins sent from Mt. Gox, but never have appeared in my account. I have the block # of the transfer.
How can I trace the deposit or find them within my account?

Could you clarify?  Did Mt. Gox send you some bitcoins to your wallet?  Have you looked on blockexplorer.com for the particular block number?  If so, you should be able to see the recorded transaction from Mt. Gox to your wallet.

To look up the transaction go to blockchain.info or blockexplorer.com and type the transaction number in the search box. You will see the sender address, the destination address, the block number where the transaction was included, among other info.
Please confirm that your bitcoin client has downloaded all the blocks. You can see a number in the bottom right corner, which should match the most recent block (the current number is 153881, you can find this information in the websites I mentioned). See this question for more information.

If you have the block number, they appeared in your account. If your client doesn't show it, it's most likely because your client doesn't have that block yet.


text:
Where is the bitcoin wedding transaction?
There has been some buzz in the news about a wedding that put a statement in the blockchain declaring their message. Here is one source that reported on the news.
Can anyone provide a link to the actual transaction in a block explorer such as blockchain.info?
I'm looking for a link to an actual transaction in a block chain explorer that has the ASCII text in it that was described in the article, or an explanation of why one doesn't exist.

Somebody also did that a while ago using Datacoin (though I don't know whether there is currently an active Datacoin explorer where you can see it).

This is the press release, but I can't find it either.

Considering adding a bounty to this question, really think this information should be available. It seems that it was done with BitNation, a counterparty application, but nowhere links to the actual transaction.

I think I found it, although it doesn't have the text as advertised.

History was made today when David Mondrus and Joyce Bayo tied the knot on the blockchain. The transaction took place through Eric Grill’s CoinOutlet ATM at Disney World. The couple ‘burned’ 0.1 Bitcoin, committing their marriage to the network. Jeffrey Tucker officiated the wedding with one of the most moving speeches you’ll ever hear.
Here is the historic transaction ID: https://blockchain.info/tx/ad2e849f1de6d48dce1b671fe9b4ef6aee9c50710daccce3c0195087233ef2f6

Looking at the transaction history, it appears that they repeatedly made transactions until they spent 0.1 BTC. Ick.

Good find, but why doesn't the transaction have the text in it that they said it would? Seems strange that they had to do so many transactions, too.


text:
How can counterparty tokens be distributed?
When a new counterparty token is created, are they all created at once? Or can there be a custom distribution schedule? Basically, I'm wondering if all counterparty tokens are centrally distributed or if there can be a way to distribute them in a decentralized way.
Another way of asking this:
In Bitcoin, mining serves two purposes:

To secure the blockchain and make it hard to overpower
To distribute coins in a decentralized way

Is there a way to use counterparty for (1) but still do mining for (2)?

1) Yes, as of now (v9.55.1) it's all at once. BUT, you can increase the issuance by issuing more later unless you "lock" the issuance.
2) So yes, there can be a custom distribution schedule. Example: start with 100, run a "stakeholder" vote via Counterparty broadcast or other method or decide by yourself as the issuer, then increase issuance to say 200. But, if you lock issuance, then it's impossible to issue additional quantity of tokens.
Another way of answering your rephrased questions:
1) Counterparty relies on the bitcoin blockchain (and the miners) and it doesn't have its own miners. The native currency (XCP) was created by proof-of-(bitcoin)-burn. Tokens/assets are created by burning a small amount of XCP
2) Coins (tokens/assets) can be distributed in any way you want, it's independent of pretty much anything - for example you could simply ask people to provide their verified address (which they could do in any number of ways that bitcoin supports, for example by signing a message) and send them some tokens. There's a faucet (google it) that works similar to bitcoin testnet faucets and you could use that as well.


text:
How can services that use the bitcoin blockchain help secure it?
There are many projects being worked on that involve using the bitcoin blockchain for its public verifiability and immutability. A few examples would be Counterparty, Medici, Factom, etc. But each use case for the bitcoin blockchain also adds an incentive to attack it.
For example, say some sort of a stock chain/ledger is secured by the bitcoin blockchain, and the total value of all stocks secured is more than 1 trillion USD. Then, even though the total market cap of the native currency to the ledger is only ~3.5 billion USD, there may be an incentive to reverse/modify the bitcoin blockchain in order to modify the stock market's chain of transactions. Miners do the necessary work to secure these types of services, but their fee does not correlate with the real-world value of the data they are securing.
Obviously, services that use the block chain like this can't be prevented, as it is a completely open peer-to-peer system.

How can external services that add incentives to attack the network also add incentives for miners to secure it?

Notes:
Merged mining with Namecoin, a decentralized service that uses the bitcoin blockchain for security, adds to the security of the bitcoin blockchain by awarding Namecoins. Centralized services, like a stock exchange, do have an incentive to keep the chain secure, because if the bitcoin block chain is attacked, then very few people will use their service. And they may be able to add to the mining incentive in a way that encourages people to try their service, similar to a marketing fee.
One upside is that just the existence of such services may bring utility to and encourage confidence in bitcoin, raising bitcoin's price and, hence, raising the reward for mining.
I am looking for descriptions of technical solutions for a standard process by which services can do their part to keep the blockchain secure, while maintaining the decentralization of the network.

The Bitcoin network is fairly simple in terms of its core security, so technically there are three things these companies/projects can do to contribute:

Run and/or encourage development of the bitcoind codebase (including code reviews)
Run and/or encourage a higher number of solo miners
Run and/or encourage a higher number of full nodes

Point 3 is especially important and a no-brainer for any project that depends on the blockchain. Running your own full node(s) is a must, so that you don't have to trust a third party node. The tragedy of the commons does not apply to this point.
Each full node adds a layer of security to the network by verifying all transactions and blocks, reducing the chance for foul play, even from "malicious" miners.

Interesting viewpoint. For (1), I think this is a good idea, as it finds security fixes. For (2), the services themselves running miners means that other miners' profit margins will decrease and miners will drop of. There needs to be more incentives to mine to support more miners, adding more miners without more incentives just displaces other miners. This is really the heart of the question, how can other services that add incentives to attack the network also add incentives to secure it. For (3), Having more full nodes just increases the number of onlookers in a 51% attack.

@StephenM347, full nodes do alot more than that. They form the backbone of the Bitcoin network and filter every transaction, verifying each one against the Bitcoin consensus rules. In a sense they protect the network even from malicious miners. They may not prevent a 51% attack but by enforcing all the rules they even limit the damage in such an event.

I know what full nodes are and why they are critical. In this specific attack we are talking about defending against (51% attack), though, they do not help.

You never mentioned 51% attack in your question.

So how can they be involved in securing the chain?

They cannot. Everyone wants to earn funds, not to help others to earn.
https://en.wikipedia.org/wiki/Tragedy_of_the_commons

That doesn't mean they, 'cannot', technically they can. They may try to get away with not doing it, but that's a risk for them too, not just for bitcoin. So there is an incentive to help secure the bitcoin blockchain.

Technically they can send you to the Moon. But they never will do it. Trust me.

It's their own "1 trillion USD" market that is at stake, so they damn well better make sure they provide some security (through Bitcoin or other means). If they don't then the people that put in that "1 trillion USD" are morons that shouldn't be investing in such an altcoin at all and deserve to lose it all. (ah yeah, I see the flaw in my reasoning there... people would blindly invest... sigh). Anyway, the original question was "how can", so your answer is not correct.

@amaclin, While you bring up a good point with the tragedy of the commons, I think we can get a bit more creative ;-)


text:
Best practices for service/merchant handling bitcoins

Possible Duplicate:
Best way to safely host a high volume online transactional wallet?

There have been numerous incidents where bitcoin services have been hacked and large amounts of bitcoins have been stolen. There was even an exchange that accidentally deleted its only copy of its bitcoin wallet.
Which best practices should a service or merchant follow when handling bitcoins?

This is probably best conveyed using the wiki:

http://en.bitcoin.it/wiki/Securing_online_services


text:
Unconfirmed Transaction - Paid Fees
wondering if anyone can help me.  I moved funds from one wallet to another with transaction 582386d5b5480804535cf382727ab72b9a09dd1435b3444f18c20617d3198a65.  Fees were dutifully paid by my wallet.  I've never had a transaction take more than an hour or two to confirm if fees are paid.  Says it spent unconfirmed inputs?  Anyone know what it is, and how to get my money back if it does not confirm?
Thanks much!

blockchain.info now says "Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned from our database."

Perhaps this is due to the "malleability attack" that was going on; it can be that the transaction has gone through with a different transaction ID.  It would be easier if you disclose the input and/or output address.


text:
additional document for BIP32
I am reading through BIP32's documentation and its implementation in Java on GitHub in the file supernode/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java.
Luckily, I was able to follow the code, but there are areas I am not sure about.
I have 2 questions:

I know it is in BIP32.json file, but why are we doing if ((sequence & 0x8000000)==0)?  It is a condition for master public key to child public key or master private key to child private key... but what sequence does for? if ( (sequence & 0x80000000) == 0 )
My second one is why we add 4 bytes.   Is there any detail document source I can find?
        extended = new byte[pub.length + 4];
        System.arraycopy (pub, 0, extended, 0, pub.length);
        extended[pub.length] = (byte) ((sequence >>> 24) & 0xff);
        extended[pub.length + 1] = (byte) ((sequence >>> 16) & 0xff);
        extended[pub.length + 2] = (byte) ((sequence >>> 8) & 0xff);
        extended[pub.length + 3] = (byte) (sequence & 0xff);
    }
    else
    {
        byte[] priv = master.getPrivate ();
        extended = new byte[priv.length + 5];
        System.arraycopy (priv, 0, extended, 1, priv.length);
        extended[priv.length + 1] = (byte) ((sequence >>> 24) & 0xff);
        extended[priv.length + 2] = (byte) ((sequence >>> 16) & 0xff);
        extended[priv.length + 3] = (byte) ((sequence >>> 8) & 0xff);
        extended[priv.length + 4] = (byte) (sequence & 0xff);
    }

Many thanks in advance.

Welcome to Bitcoin.SE! You can help the site by marking answers as accepted if they are correct and address your question so that the question does not remain as "unanswered".

Check https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format
((sequence & 0x80000000)==0) means it's not a hardened key. The key is hardened (public key derivation not possible) for child keys with index higher then 0x80000000 (== 2147483648 == 2^31).
From the BIP
4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)
32 bytes: the chain code
33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

very cool... got it confused with serialize method below.  I thought something different.


text:
Bitcoin QT using the terminal
I am trying to compile bitcoin qt and I am getting these errors:
No targets specified and no makefile found.Stop.

user@localhost:~/bitcoin/src$ ./configure --with-qt
bash: ./configure: No such file or directory

user@localhost:~/bitcoin/src$ make -j8
make: *** No targets specified and no makefile found. Stop.

I'm using Mint, not sure if there are different commands specifically for Mint.

Did you run ./autogen.sh first? Also, you are in the wrong directory. You should be in ~/bitcoin

I am following this instructions

If you are not already doing so, I think should carefully read the file ~/bitcoin/doc/build-unix.md which explains how to install the required dependencies as well as the build process itself.

Thanks Sven, Yes the install has work, though not sure how lol.  But it looks very different from the old version.  I was just going through the folders and cant find the wallet dat,   Any help here would be very much appreciated.   Its pretty cool only 217 weeks to go.

Hi Nick, no i did not, the installation work with just this commonds:  ~/bitcoin/qmake-qt4 -makefile -Wall USE_QRCODE=1
make.

My other problem now is that i cant find the wallet dat.  I know that its a hidden file and I have checked in all folder, cant see it, has it changed name?

@Rosanna your wallet.dat file is located in the ~/.bitcoin directory. Other files of interest in this directory are debug.log and bitcoin.conf

Hi Sven, ok, i have, home, bitcoin, when i double click on bitcoin i dont see the wallet file even when i click show hidden file.   I previously remove bitcoin wallet  as i was changing into mint, i took a back up of the old wallet dat. file.   I notice that even though i had remove the bitcoin wallet, now that it is open and doing that sync thing, it is showing my old transactions.   I think that reason why i dont see the wallet is because i had deleted it,  Does this mean that, i can just put the back up wallet dat. if so, do i need to wait until its finish the sync thing.  many thanks

@Rosanna The .bitcoin directory is not the same as the bitcoin directory. It is a hidden directory. From your mention of 'double click' it seems that you are accessing your file system via some GUI (as opposed to command lines on a terminal window). Look in the menu somewhere, there should be an option 'Show Hidden Files'.

Hi Sven, yes i found it, but my problem now is that hard drive is too small lol, so needing to upgrade hard before i can do anymore with the bitcoin wallet.

Type cd .. and try again.

The correct configure command is ./configure --with-gui=qt5 or --with-gui=qt4 or --with-gui=auto if you're not sure.
You can always see what configure flags are supported with ./configure --help.


text:
Is anyone taking advantage of different prices across exchanges?
Say I have funds on two exchanges. Whenever the price of bitcoin is higher on the first one, I sell on that one and buy on the other one.
Is anyone doing this or has a program that does this? Is it even possible?

It's called arbitrage, https://en.wikipedia.org/wiki/Arbitrage from the moment there was more than a single place to buy sell bitcoins there was arbitrage.

This is possible and many people do it, but the loop can be significantly delayed by the time it takes to transfer fiat between exchanges. There may be automation software out there, but it is likely closely guarded by those who employ it. There is still the manual step of coordinating fiat movement.

There are in fact a considerable number of people/institutions doing this already, and the proprietary software is getting smarter and significantly outperforms the opensource projects. It should come as no suprise that existing currency arbitrage software has been adapted to this task by trading companies very successfully, so if you are thinking of getting into it, you are about 2 years too late, the pickings are too slim for individuals to be worthwhile. (WALLSTREET WINS AGAIN!)

Yes, there are tons of opportunities, especially when you do tri-currency arbitrage, for example check out the Bitdango arbitrage reports. These break down the buying of bitcoin on one market and selling on another. The hard part is moving the fiat money back to your source bank account. That is very hard because you need to have local currency bank accounts in different countries, etc - so that's the nut to crack.

Yes. But over time third-party arbitrage tends to be pushed out by arbitrage performed by the exchanges themselves.
Essentially the arbitrage margin goes down as the exchanges buy and sell between each other. If a third-party bought and sold enough coins for decent arbitrage profit margins - it becomes an exchange by virtue of sheer volume.
This price convergence will be faster for Bitcoins than for physical commodities, as transport of the "commodity" is trivial and no tariffs or trade barriers exist on the flow of Bitcoins. Indeed, most currency arbitrage relies on extremely large volumes, extremely fast market transactions; and slight congestion/friction in the global market.

I have been performing arbitrage via a PHP bot between bitfinex, btce, kraken, and poloniex for about 3 months. I have a total pool of about 1.5 btc that I am working with. My experience has been that the arbitrage opportunities on the books only last for a few sec. before the very competitive market recognizes the opportunity. I have an algorithm to identify book opportunities, and another to place offers on spreads, after commissions . Bottom line is that I can't make more than small change daily however, due to the very competitive markets. With a large pool of funds the opportunities do increase. I found a fund that seems to consistently deliver close to 1% return on business days, you might check out their blog - results page https://bitcoin-trader.biz/?ref=arbitrage


text:
blockchain.info: "No operations allowed after connection closed."
It's not allowing me to see any TX's or addresses. It just says "No operations allowed after connection closed. Connection closed after inability to pick valid new connection during fail-over."

While the way this is worded looks too localised, it actually might be easily converted to a more general useful question.

A few minutes ago they restarted the servers, and they won't allow you to make transactions while they're not connected to the network. Since a restart implies a temporary disconnect, you just have to wait a few minutes.


text:
Do unconfirmed transactions expire?
Do they just sit there unconfirmed (e.g. when you be evil and don't pay a tx fee) forever? Or do they get deleted after a few days?

Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed anyway.
But to answer your actual question: yes, transactions (sort of) expire. When you send a transaction, it sends a tx frame to all connected peers. These peers store the transaction in their memory pools and tell all their connections that they have a new transaction. When those connections don't have it yet, they ask for it, and that's how a transaction spreads over the network.
At some point every node in the network will have the transaction in their memory pool, and at that point it will no longer be sent over the network. Now when a user restarts their client, the memory pool is wiped, and the transaction is deleted from that computer. (Plus a few other ways to delete transactions from the pool)
Because of that it's very unlikely for the transaction to be gone from the entire network, but in case it does happen: the reference client will automatically re-send the transaction every x hours(/minutes?) when it's still not confirmed.
Oh, and I forgot the most important part: transactions on Bitcoin (tx frames in the protocol) don't have a 'time' field, which means that transaction expiration can't be a feature of Bitcoin.
To summarize: yes, the transaction can expire, but that is really unlikely.

Thanks! If enough clients/miners remove a transaction from their memory pool, is it possible to make a transaction that over-writes that one (uses the same inputs) which will then get into a block? Then the first transaction would be deleted, right?

A new transaction will only be accepted into the pool if the previous one is no longer in that pool and not in a block either. As soon as it gets into a block, the entire pool is checked for conflicts again, and in that case the old transaction would be deleted. So yes, if enough nodes restart to clear a path for the new transaction, and a miner accepts the new transaction instead of the old one, the old transaction could be deleted.

Doesn't a transaction basically "expire" by becoming invalid (e.g., when its UTXO(s) are spent)?

What about locktime? Isn't locktime like an expiry date for transactions?

I recently sent 0.03 BTC to Satoshi Dice without a tx fee from a blockchain.info wallet. It stayed for about 3 days without being confirmed and it finally expired. At some moments while the tx was unconfirmed the network propagation was dropping to 2 nodes and then going back up to about 50 nodes. After it expired the sum of the transaction was added back to my balance. Any details of the transaction disappeared from my wallet and from the block explorer... Several hours after the expiry a new transaction has been issued automatically with the same amount to the same Satoshi Dice address.

Regarding "a new transaction has been issued automatically with the same amount to the same Satoshi Dice address".. is this only happening for blockchain.info wallets?


text:
Data for market depth over time?
I'd like to create a 3d representation of the market depth graph (of BTC/USD) over time. (the graph here https://www.bitstamp.net/market/order_book/) I think it would provide a nice representation of buy/sell walls and price (the trough in the middle) over time. Where can I download this data? A list of all trades won't work, but open orders over time would.

I found someone who created a visualization in shades of gray: http://www.reddit.com/r/BitcoinMarkets/comments/1murxd/behold_market_depth_over_time_ultrabeta/ , but I would like to create a rotatable model.

Why is this getting downvoted?

Who knows, I dont see a problem with it. I really wish SO forced you to leave a comment when down voting.

You can't, but you could do something similar.
To start off with there isnt a single set of order books for BTC/USD, because there are dozens of exchanges each with their own set of books. Aggregating all of data from all the exchanges in to a single order book isnt going to work due to the pricing differentials (arbitrage opportunities) across the exchanges.
If you wanted to do this for a single exchange (such as BitStamp) you'd need to write script (or program) to download all of this data from their API (or scrape it from the HTML), and insert it in to a database. However this would only give you data from the present forward. If you wanted historical data, you'd have to find someone who is actively running a bot, and try to purchase the data from them. Try asking around on BitCoinTalk.org, or you could ask the exchanges themselves if they'd be willing to sell you this data.
Also something you should be aware of, in my experience writing my own trading bot, i've noticed that some open orders exist for a very short amount of time (< 1 second). So if you're going to write your own bot, keep this in mind. Also keep in mind that most exchanges use CDNs to prevent DDoS attacks, and will actively throttle your bot if you send too many requests per second. If you're clever you can evade the CDN throttling, and send enough requests per second to observe those short lived orders.
And how to create this in to a moving 3D graph? I have no idea. You could always write your own program, but for something like this i'm sure there is already a product out there than can do it.


text:
How do I configure Bitcoin Core to connect always to a particular node?
By reading https://bitcoin.org/en/full-node I've decided that I want to run a FULL node (let's call it 'X'), to contribute to the P2P network.
So, I'll leave its ports open, or have a DMZ zone with a public IP address in it.
But this comes with security risks, so I will not have any funds in this instance of the Bitcoin Core QT client.
Then, I will keep my BTC funds in a different computer (let's call it 'Y') that will not be a full node (but still use bitcoin-core QT main client).
However, how can I configure 'Y' to always connect (in order to broadcast my transactions) to my server 'X' and not a different one?
Thanks

Depends on what software you are using for Y.

same, bitcoin-core, I'll edit the question

Bitcoin Core is always a full node in the sense that it has to download and verify the entire block chain. But if you only want it to talk to the one other node, see the --connect option.

Well, if you place it in a private IP it is not a full node. Thanks for the hint about --connect, I'll test it.

@knocte No, 'full node' means something else: https://en.bitcoin.it/wiki/Full_node

Your private node would still be a fully validating node (i.e. full node). That's a good thing.
As for having the private node connect to your public node, you have two choices:

-addnode=<ip> Add a node to connect to and attempt to keep the connection open
-connect=<ip> Connect only to the specified node(s)

What you were asking for is nr 2, but you might want to consider nr 1 instead because that gives your private node a bit more redundancy in case there's a problem with your public node (hardware problem, disk full, router misconfiguration...). But it will make a few outgoing connections to random internet nodes (slight security problem if you don't trust the bitcoin p2p protocol and it will cause a bit more bandwidth usage).
You might also consider these options:

-listen=0  Don't accept connections from outside (implied by -connect). (although if you don't port forward in your firewall, it doesn't matter.)
-whitebind=<addr>
   Bind to given address and whitelist peers connecting to it. Use
   [host]:port notation for IPv6
-whitelist=<netmask>
   Whitelist peers connecting from the given netmask or IP address. Can be
   specified multiple times. Whitelisted peers cannot be DoS banned and
   their transactions are always relayed, even if they are already in the
   mempool, useful e.g. for a gateway
upnp=0 to disable UPnP. If you're capable of doing your own firewall configuration, you don't want this increased attack surface. (This has/will become the default in recent versions.)

The whitelisting (4 and 5) will prevent your private node from accidentally banning your public node if something weird happens.
Public node configuration
You probably also want to have e.g. -whitelist=192.168.1.0/24 on your public node as well to never ban your private node.
If it's not running a wallet, use the option -disablewallet [Do not load the wallet and disable wallet RPC calls]. Saves some resources and lowers the attack surface.

Does this method implies that the private node has to download the whole blockchain?

Yes, it must be dowload all blk and create a db information when you run bitcoind