text:
Multi-Sig Transaction not broadcasting error - Script evaluated without error but finished with a false/empty top stack element
Trying to produce a multi-sig transaction. I have this so far.
Sent funds to : 2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp
https://mempool.space/testnet4/address/2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp
I guess firstly was that the wrong address to send to?
Here is my tx hash:
010000000196dd89c30c3f8772aae682d14c009bc5c24fd4690106b10734261c693cdc0bcc010000009100473044022004365796cf079934bc168f07e624eba6fe79dceba3d5ef583674265af9b86a8c02201f5858deec99afb9850af2c5d0db8d7da8987e1922ac98448288f5c466e97ad901473044022072ea4e179b0332349ed62fa0f071d31b6e574145629754ee1bdccba4d0fd180d02205eb0afdb3e34fd39b6d8bc11b833332a9cc8cb3da5b8ca66a8ba2def3a01419601fdffffff022602000000000000160014945a3408d2f7cd07b7d1defbda62992481601d8e389d07000000000017a914e087832bbf2a86debc46b2ffbbf73f85d197ee788700000000
I wrote this code to produce all this:
void Main()
{
    Network network = Network.TestNet4;
    byte[] key1Bytes = ("Removed").HexToByteArray();
    byte[] key2Bytes = ("Removed").HexToByteArray();
    byte[] key3Bytes = ("Removed").HexToByteArray();

    Key key1 = new Key(key1Bytes);
    Key key2 = new Key(key2Bytes);
    Key key3 = new Key(key3Bytes);

    // Create a 2-of-3 multi-sig script
    Script scriptPubKey   = PayToMultiSigTemplate.Instance.GenerateScriptPubKey(2, new[] { key1.PubKey, key2.PubKey, key3.PubKey });
    //Script redeemScript = scriptPubKey.PaymentScript;

    //Get deposit address '2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp'
    BitcoinAddress multiSigAddress = scriptPubKey.Hash.GetAddress(network);
    var sender = multiSigAddress.ToString();

    Console.WriteLine("Multi-Sig Address: " + multiSigAddress);
    //cc1e708dd199b390f5103444ff0b131bbc4294ce55cfaa3e0878e41cb21abc14
    //cc0bdc3c691c263407b1060169d44fc2c59b004cd182e6aa72873f0cc389dd96
    //vout 1

    OutPoint outPoint = new OutPoint(uint256.Parse("cc0bdc3c691c263407b1060169d44fc2c59b004cd182e6aa72873f0cc389dd96"), 1);
    Coin coin = new Coin(outPoint, new TxOut(Money.Satoshis(500_000m), scriptPubKey));
    //ScriptCoin coinToSpend = new ScriptCoin(coin, scriptPubKey);

    var txInAmount = coinToSpend.Amount;
    var minerFee = new Money(450, MoneyUnit.Satoshi);
    var sendAmount = new Money(0.00001M, MoneyUnit.BTC);
    var totalSpend = sendAmount - minerFee;

    // Destination address
    BitcoinAddress recipientAddress = BitcoinAddress.Create("tb1qj3drgzxj7lxs0d73mmaa5c5eyjqkq8vwjx7xak", network);

    // Create the transaction
    TransactionBuilder builder = network.CreateTransactionBuilder();
    TransactionBuilder builderForKey1 = network.CreateTransactionBuilder();
    TransactionBuilder builderForKey2 = network.CreateTransactionBuilder();

    NBitcoin.Transaction unsigned = builder
        .AddCoins(coin)
        .Send(recipientAddress, totalSpend)
        .SendFees(minerFee)
        .SetChange(multiSigAddress)
        .SetOptInRBF(true)
        .BuildTransaction(false);

    NBitcoin.Transaction key1Signed =
        builderForKey1
        .AddCoins(coin)
        .AddKeys(key1)
        .SignTransaction(unsigned);

    NBitcoin.Transaction key2Signed =
        builderForKey2
        .AddCoins(coin)
        .AddKeys(key2)
        .SignTransaction(key1Signed);

    NBitcoin.Transaction fullySigned =
        builder
        .AddCoins(coin)
        .CombineSignatures(key1Signed, key2Signed);

    var txVerified = builder.Verify(fullySigned);
    var result = fullySigned.Check();

    txVerified.Dump();
        result.Dump();

    var hexTx = fullySigned.ToHex();
    var hashTX = fullySigned.GetHash();
    hexTx.Dump();

    //Console.WriteLine(fullySigned);

//  var hexTx = fullySigned.ToHex();
//  var hashTX = fullySigned.GetHash();
//
//  hexTx.Dump();
    //BroadcastTransaction(fullySigned);
}
public static decimal BTCMultiplier = 100_000_000M;

void BroadcastTransaction(NBitcoin.Transaction transaction)
{
    using (var node = Node.Connect(Network.TestNet4, "Removed"))
    {
        node.VersionHandshake();
        node.SendMessage(new InvPayload(InventoryType.MSG_TX, transaction.GetHash()));
        node.SendMessage(new TxPayload(transaction));
        Thread.Sleep(500); // Wait a bit to ensure the transaction is sent
    }
}

public static class MyExtensions
{
    public static byte[] HexToByteArray(this string hex)
    {
        var bytes = Enumerable.Range(0, hex.Length / 2)
                .Select(x => Convert.ToByte(hex.Substring(x * 2, 2), 16))
                .ToArray();

        return bytes;
    }
}

I am kind of at a loss and the transaction passes both the verify and the check, but when I go to broadcast in CLI I get Script evaluated without error but finished with a false/empty top stack element)
Any help is appreciated.
Updated code to reflect the address 2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp

Ok, so for those wanting to see what I did. Here is the following code that IS working:
void Main()
{
    Network network = Network.TestNet4;
    byte[] key1Bytes = ("Removed").HexToByteArray();
    byte[] key2Bytes = ("Removed").HexToByteArray();
    byte[] key3Bytes = ("Removed").HexToByteArray();

    Key key1 = new Key(key1Bytes);
    Key key2 = new Key(key2Bytes);
    Key key3 = new Key(key3Bytes);

    // Create a 2-of-3 multi-sig script
    Script scriptPubKey   = PayToMultiSigTemplate.Instance.GenerateScriptPubKey(2, new[] { key1.PubKey, key2.PubKey, key3.PubKey });
    Script redeemScript = scriptPubKey.PaymentScript;

    BitcoinAddress multiSigAddress = scriptPubKey.Hash.GetAddress(network);
    var sender = multiSigAddress.ToString();

    Console.WriteLine("Multi-Sig Address: " + multiSigAddress);
    //cc1e708dd199b390f5103444ff0b131bbc4294ce55cfaa3e0878e41cb21abc14
    //cc0bdc3c691c263407b1060169d44fc2c59b004cd182e6aa72873f0cc389dd96
    //vout 1

    OutPoint outPoint = new OutPoint(uint256.Parse("cc0bdc3c691c263407b1060169d44fc2c59b004cd182e6aa72873f0cc389dd96"), 1);
    Coin coin = new Coin(outPoint, new TxOut(Money.Satoshis(500_000m), redeemScript));
    ScriptCoin coinToSpend = new ScriptCoin(coin, scriptPubKey);

    var txInAmount = coin.Amount;
    var minerFee = new Money(450, MoneyUnit.Satoshi);
    var sendAmount = new Money(0.00001M, MoneyUnit.BTC);
    var totalSpend = sendAmount - minerFee;

    // Destination address
    BitcoinAddress recipientAddress = BitcoinAddress.Create("tb1qj3drgzxj7lxs0d73mmaa5c5eyjqkq8vwjx7xak", network);

    // Create the transaction
    TransactionBuilder builder = network.CreateTransactionBuilder();
    TransactionBuilder builderForKey1 = network.CreateTransactionBuilder();
    TransactionBuilder builderForKey2 = network.CreateTransactionBuilder();

    NBitcoin.Transaction unsigned = builder
        .AddCoins(coinToSpend)
        .Send(recipientAddress, totalSpend)
        .SendFees(minerFee)
        .SetChange(multiSigAddress)
        .SetOptInRBF(true)
        .BuildTransaction(false);

    NBitcoin.Transaction key1Signed =
        builderForKey1
        .AddCoins(coinToSpend)
        .AddKeys(key1)
        .SignTransaction(unsigned);

    NBitcoin.Transaction key2Signed =
        builderForKey2
        .AddCoins(coinToSpend)
        .AddKeys(key2)
        .SignTransaction(key1Signed);

    NBitcoin.Transaction fullySigned =
        builder
        .AddCoins(coinToSpend)
        .CombineSignatures(key1Signed, key2Signed);

    var txVerified = builder.Verify(fullySigned);
    var result = fullySigned.Check();

    txVerified.Dump();
        result.Dump();

    var hexTx = fullySigned.ToHex();
    var hashTX = fullySigned.GetHash();
    hexTx.Dump();

    //Console.WriteLine(fullySigned);

//  var hexTx = fullySigned.ToHex();
//  var hashTX = fullySigned.GetHash();
//
//  hexTx.Dump();
    //BroadcastTransaction(fullySigned);
}
public static decimal BTCMultiplier = 100_000_000M;

void BroadcastTransaction(NBitcoin.Transaction transaction)
{
    using (var node = Node.Connect(Network.TestNet4, "BTCNodeIpGoesHere"))
    {
        node.VersionHandshake();
        node.SendMessage(new InvPayload(InventoryType.MSG_TX, transaction.GetHash()));
        node.SendMessage(new TxPayload(transaction));
        Thread.Sleep(500); // Wait a bit to ensure the transaction is sent
    }
}

public static class MyExtensions
{
    public static byte[] HexToByteArray(this string hex)
    {
        var bytes = Enumerable.Range(0, hex.Length / 2)
                .Select(x => Convert.ToByte(hex.Substring(x * 2, 2), 16))
                .ToArray();

        return bytes;
    }
}

You can see the TX worked here: https://mempool.space/testnet4/tx/800f4031f65eb141fc7083d89a29c6987da75c6d282ccb2bc72673e219d027ad
Now that I understand how to do a basic MS, I will attempt to use PSBTs for better support and cleaner code.
This was done in C# and with a modified version of NBitcoin to support Testnet4.

The correct address, derived from the redeem script in your transaction, is actually 2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp. Both of these recently received 500,000 testnet sats, you must have mixed them up.

well I wasn't sure which one was correct. so I tried with both. I will switch everything to use that and report code. Let me know if you see any issues.

I have update source code and information above. I still get the same error, so I must be constructing the TX wrong is all I can think. Any ideas?

I believe I see my errors. Thank you for assistance.

010000000196dd89c30c3f8772aae682d14c009bc5c24fd4690106b10734261c693cdc0bcc010000009100473044022004365796cf079934bc168f07e624eba6fe79dceba3d5ef583674265af9b86a8c02201f5858deec99afb9850af2c5d0db8d7da8987e1922ac98448288f5c466e97ad901473044022072ea4e179b0332349ed62fa0f071d31b6e574145629754ee1bdccba4d0fd180d02205eb0afdb3e34fd39b6d8bc11b833332a9cc8cb3da5b8ca66a8ba2def3a01419601fdffffff022602000000000000160014945a3408d2f7cd07b7d1defbda62992481601d8e389d07000000000017a914e087832bbf2a86debc46b2ffbbf73f85d197ee788700000000

Looking at this transaction data, there is no P2SH redeem script set at the last of script_sig.
You need to set the redeem script for the P2SH address 2NDiRgpVVQ3CtYMi962myja69pFW8VSJ9Yp.

Hey thank you for comment. I figured out was I was doing and posted the response below. You are correct I have  my redeem and scriptpubs mixed up and once sorted TXs were being approved and confirmed


text:
how to generate bech32/segwit address from pubkey in golang
I am trying to generate bech32/segwit address in golang with the following code:
var pubkey *btcec.PubKey
address, err := btcutil.NewAddressPubKey(pubkey.SerializeCompressed(), chainParams)
if err != nil {
    log.Fatal(err)
}
address.SetFormat(btcutil.PKFCompressed)
bech32Bytes, err := bech32.ConvertBits(address.ScriptAddress(), 8, 5, true)
if err != nil {
    log.Fatal(err)
}
segwitaddr, err := bech32.Encode("tb", bech32Bytes)
if err != nil {
    log.Fatal(err)
}

and also more simply
var e *hdkeychain.ExtendedKey
address, err := e.Address(chainParams)
bech32Bytes, err := bech32.ConvertBits(address.ScriptAddress(), 8, 5, true)
if err != nil {
    log.Fatal(err)
}
segwitaddr, err := bech32.Encode("tb", bech32Bytes)
if err != nil {
    log.Fatal(err)
}

But neither segwitaddr generated match the bip84 address I got from https://iancoleman.io/bip39/. What is wrong with the code above or how to properly get a bech32 address from a pub key?
I have looked into another post on the same question, but could not figure out how to prepare the data needed in golang. More specifically, I am confused in preparing the input []byte to call bech32.Encode() and using bech32.ConvertBits().

I have found the answer thanks to modood/btckeygen.
Here is the relevant code extracted from the repo.
witnessProg := btcutil.Hash160(pubkey.SerializeCompressed())
addressWitnessPubKeyHash, err := btcutil.NewAddressWitnessPubKeyHash(witnessProg, chainParams)
if err != nil {
    panic(err)
}
address := addressWitnessPubKeyHash.EncodeAddress()

source: Stack Exchange

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

sort: votes


text:
Compare altcoins in one chart
Is there a website where I can compare several altcoins in one chart?
In particular, I am looking for a chart where each coin, that I want to consider, starts with the same value (say a value of 100$) at a certain date. With such a chart one could compare the performance of the altcoins.

Take a look at this website, They may be what you're looking for.

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


text:
What wallets currently support RBF?
What wallets currently support RBF?
Is there some workaround if they don't?

Friends a little what you mean by support. You mean you want to create RBF transactions? Or do you mean they need to recognise incoming RBF transactions and then do something special with them (user interface warning). I've heard greenaddress supports RBF, not sure and don't know about others.

No wallet currently supports creating replaceable transactions conveniently. To work around this, you can manually create raw transactions from scratch.
The following are suggested instructions for use with bitcoin-cli.
To create a replaceable transaction. You can use "createrawtransaction" to manually add inputs and mark the "nsequence" field to a value less than 0xffffffff. If you would like to replace the first transaction created this way. You will have to dump the transaction to free the UTXOs for use again using the "abandontransaction" command.
Once you've dumped the first transaction. You should be able to repeat the process above then increment the "nsequence" field. This new transaction when broadcasted should then be accepted by any node that supports full RBF.

This answer is outdated, please consider updating it. :)

As I answered in another question, Electrum Bitcoin Wallet has the feature. I've confirmed that mac client worked. It seems that Android app has the same feature.
https://electrum.org/#download
Which clients offer a way to replace unconfirmed transactions?

As far as I know other than bitcoin core API's (as renlord suggested) the only wallet that conveniently supports the functionality is GreenAddress

Today, Bitcoin Core, Electrum, Blockstream Green, and Samourai support creating BIP125 opt-in full RBF transactions. These wallets then subsequently allow bumping the feerate of transactions signalling replaceability.
The Bitcoin Optech group tracks RBF capability of wallets and services in their compatibility matrix.

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

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


text:
Is libsecp256k1 faster than OpenSSL?
Bitcoin Core is eventually going to replace OpenSSL with libsecp256k1 for all ECDSA operations. As I understand it, this is motivated by wanting consensus-critical rules to not depend on OpenSSL.
Is libsecp256k1 signature verification also faster than OpenSSL? I've heard conflicting information about that.

Yes it's a lot faster. For example from one of the core developers:
reddit - Pieter Wuille / 2015-02-19 18:13

Just did a benchmark on libsecp256k1's current master, without GMP,
  without hand-written assembly, and it's around 3.6x faster than
  OpenSSL on my machine (64-bit code, i7 cpu). When the assembly is
  compiled in (which does not require any extra dependencies anymore),
  it's 4.9 times faster.

http://www.reddit.com/r/Bitcoin/comments/2weymr/experiment_bitcoin_core_0100_initial_sync_time/coqghm2
This talks about signature verification, which is currently the bottleneck when catching up to the blockchain.


text:
Does bitcoin.conf allow multiple zmqpubhashblock settings?
If two programs both want to use the same bitcoin core instance to get notified about new blocks, do you add zmqpubhashblock=<address> twice to bitcoin.conf with two different port numbers, one for each program?
I have some "Meta" questions about this question too:
I suppose the answer to this question already exists somewhere and I spent some time trying to find it but failed.  What keywords would you use in a search engine to find the answer if it already exists online?  Is there a site where you'd expect this question to already have an answer, and if so, how would you find it?


text:
Test environment for bitcoin transactions/wallets
I want to build a pet project which would use bitcoin for sending/receiving and see balance of wallets involved changed.
What are my options for having a local env that would allow me to perform these operations in a way similar to real environment?

Bitcoin Core and all implementations of Bitcoin should provide developers with a local regtest mode which is local only (no peers) and a mining difficulty of 0. This is the mode most tests are written in because blocks can be mined instantly.
Since you tagged nodejs you might be interested in bcoin:
https://bcoin.io
https://github.com/bcoin-org/bcoin


text:
How to recover bitcoin from a site that is no longer operating?
In 2013 I had 1.5 but coins on bitinstant. The bitcoin lost money and it was at 73$. Since it was hard to deal with I let it go. I don’t even care to get it out for less than 150$
But now it’s skyrocketed.
The site is shut down though.
Is there anything I can do to find it?

Please do not use obscenities in your posts. I've removed it for you. Note that other users may have flagged your post as "rude or abusive" leading to possible rep loss or suspension. Please read Be Nice: "Avoid vulgar terms and anything sexually suggestive"

I’m so sorry !!! I’m trying to edit the post, but I can’t seem to figure out where.

I've already proposed an edit. It is waiting for approval.

You might have made a backup of your wallet and stored that on your drive. It may contain a private key...

If you don't own the private key, you don't own the coins. As sad as this is, you will have to accept the coins are lost.  This is a very common occurrence and many of us have similar stories. Always use a offline wallet and back up your private keys!

I'm voting to close this question as its a matter between you and bitinstant (now, I believe would be a matter with the Department of Justice, USA). I'm sorry for your lost.


text:
Any documentation available that would help developing a Bitcoin Client?
I want to start developing a Bitcoin Client in a new language. For this I'm looking for references and resources that could be used to as a guide. Some kind of comprehensive guideline of what a client should include. But haven't been really successful so far. Does anybody knows about something like this?
EDIT:
I'm aiming for a full node with wallet capabilities

You may want to be specific about what type of client you want to make.  There are full nodes with and without wallet capabilities, there are SPV wallets, there are mining nodes, etc.   The features and protocols that need to be implemented will be determined by what type of node you want.

just edited the question and added it, @Jestin

If I would redesign Bitcoin Core today, I would start with a design where the wallet and the node functionality were separate (and work towards that is slowly underway in practice). By combining the two you are limiting your options. Write an SPV wallet first, and connect it to an existing full node. That way you don't risk introducing consensus bugs (which are extremely hard to find, experience has shown).

The ultimate, and authoritative, documentation is the source code of Bitcoin Core.

It would be nice if most android spv wallets gave you the option of connecting to a specific set of full nodes.

For some inspiration, do checkout go-btc. They do seperate full node logic and wallet implementation.

The bitcoin.it wiki contains a Protocol documentation section with information about network messages mostly. You can also use other pages of this wiki, but be sure to check it's up to date.
Ultimately, the documentation you are looking for, as mentionned by the commenters, is Bitcoin Core's source code (unfortunately) ; if you want to create a full node implementation, you'll have to be bug for bug compatible.
Finally, to test your progress, you can use https://github.com/TheBlueMatt/test-scripts to see how your implementation handles some edge cases, as well as run it on testnet.

I'd suggest you to start from making an offline blockchain-parser.
Use the block stored on disk and start parsing them in order to build (and update) the UTXO database.
This is the most crucial and performance critical part - if you have it working, the network part will not need much more of the resources.
Later, when you start playing with the network part, you will likely encounter problems that are much harder to analyse and fix, because to the asynchronous matter of the events.
Still having a stable (and well performing) blockchain parser will benefit you hugely at this stage.
Also I'd advise you to not implement memory pool and transaction relaying from the start - make sure that processing of new blocks is stable before adding the memory pool feature.


text:
Bitcoin testnet3: unable to push/publish raw transaction: how to verify validity of transaction?
I have created a raw transaction and am now trying to push the hex format into testnet3. I have used following two ways and both are giving me two different errors, first one:
curl -d '{"hex":"TX_HASH"}' http://tbtc.blockr.io/api/v1/tx/push

I get this error:
{"status":"fail","data":"Could not push your transaction!","code":500,"message":"Did you sign your transaction?"}

and second one using this link:
https://test.webbtc.com/relay_tx
gives me this error:
Testnet3 - Error - Request took too long.

Not sure if signature is really the problem here. I used decode api from blockr.io to check my message - it seems well formed and is 226 bytes in length. I played around with fee wondering if that was an issue, but I think i have ruled that out as well.
I have also checked the validity of signature in the code (inspired by David De Rosa's guide).
Any tips on how can I verify the validity of my transaction?
Thanks.
Edit: Now I am getting this very descriptive error message from blockr:
{"status":"error","data":"NULL","message":"It's looking like you may have taken a wrong turn. Don't worry... it happens to the best of us.","code":404}

Wish these guys didn't employ their sense of humour in error messages :(
used blockcypher api to push the raw transaction. This is the error message I get:
Error sending transaction: Error running script for input 0 referencing 87ce205d61e4bf63c0bcc42db1a58c36a2cac0048df32e470f3dc1bd39741367 at 0: Script was NOT verified successfully..

After signing the transaction, I checked for signature verification using ECDSA_verify(0,digest, sizeof(digest), sig, sig_len, key) and this function call returns 1 - So I assumed my signature is correct. Am I wrong in assuming this? Am I missing something big here?

What are you passing as digest?

Can you provide the serialized tx in order to check the correctness?

Found the error!
I am using OpenSSL library and was signing using the function: ECDSA_Sign
The parameter unsigned int *siglen passed to this function is supposed to be filled with signature length. I was using the signature(parameter sig) and the length from parameter siglen to serialize the data. Turns out, although the signature being generated was always 72 bytes, the siglen parameter was filled seemingly randomly with 70, 71 or 72. And hence the number of bytes of signature that was being copied into my txn was not correct. Interestingly, if I call ECDSA_size(key) after making call to ECDSA_Sign(), i would get correct 72 value back.
AAAAh! Has anyone experienced this issue before with ECDSA_Sign? I haven't found anything on google yet.
But successfully posted the raw signed transaction using blockcypher's web tool/api.

Can you elaborate on how you solved the issue?

authors: فادي المناصره


text:
The Bitcoin scripting system is purposefully not Turing-complete - why?
Can somebody explain to me why the Bitcoin scripting system is purposefully not Turing-complete? To make malicious programs difficult to develop (I guess)? Or because it was difficult to make it Turing-complete?

Bitcoin uses a scripting system for transactions. Forth-like, Script
  is simple, stack-based, and processed from left to right. It is
  purposefully not Turing-complete, with no loops.

Retrieved from: https://en.bitcoin.it/wiki/Script.

As others have said, there is no real need for Bitcoin scripting to be more complex than it is, as its complexity is more than enough for its intended applications; but the main reason is that not allowing some features (such as loops) in a language makes it completely deterministic: you can know for sure when and how a given program will end; you can't f.e. have infinite loops if you don't have loops in the first place, thus you don't have to worry about programs getting stuck and blocking/crashing the interpreter which is running them (in this case, the main Bitcoin software).
Not having to deal with the halting problem is definitely a plus for a tiny, embedded, purpose-specific language such as the one used for Bitcoin scripts.

It's easier to meter and restrict if it's not Turing complete, remembering that every node in the network needs to execute every script to ensure validity, we want it to be lightweight. It's not like it needs to be any more complex, nobody uses what we have to do anything interesting. Most of the opcodes are completely disabled and there's been no requests for them to be re-enabled.
There's so little use of script that I have manually inspected every single instance of a non-standandard transaction to see what they do. Other than the hash collision competitions and a lot of broken p2pool outputs, nobody to date has done anything even approaching interesting.
In other words, it's not complex because it doesn't need to be.

Question is, at which level would Turing-completeness be useful?
If a single transaction was Turing-complete, then it would have unknowable verification time and could be used as a DoS vector on nodes that would attempt to verify it.
With any single transaction having a knowable worst-case verification time, there's no problem of a transaction's validity being unknowable.
But what about transaction chains? The Bitcoin (BTC) network's ScriptVM doesn't have the primitives needed to carry the computation over to the next transaction because there's no way for a locking script to enforce constraints on the outputs (a kind of locking script known as "covenant").
If the ScriptVM would be upgraded with transaction introspection opcodes (which is feasible as a soft-fork), then a transaction chain would become Turing-complete through the use of recursive covenants. There's been some work discussing why this is so: Self-Reproducing Coins as Universal Turing Machine, A. Chepurnoy, Vasily Kharin, D. Meshkov
Note that nodes wouldn't be automatically evolving the multi-TX program. Some blockchain-external agent would have to construct the next transaction that satisfies the covenant and then broadcast it to the network. The program could code-in a reward for this and incentivize anyone to construct and post the next transaction, or external agents could do it for free. The program would halt when it runs out of money for the fees/incentives, but then again, other external agents could give it more money to continue evolving.
Introspection opcodes were proposed (Jan '21) and activated (May '22) on Bitcoin Cash (BCH), a code and blockchain fork of the first Bitcoin blockchain (blocks 0 to 478558 are the same on both blockchains).
Such opcodes were also proposed (Jun '21) as Tapscript opcodes for the Elements experimental Bitcoin sidechain.

Apart from what goatse said, and as your post comments, being not Turing complete means no loops, which could represent a problem with malformed (intentionally or not) scripts.


text:
Can I hide my IP address by blocking incoming connections in the client?
I know that it is possible to find out the IP address of a transaction by connecting the client to every node in the network. Dan Kaminsky wrote:

When you are connected to every node, the first node to inform
  you of a transaction is the source of it.

So my question is: is it possible to hide my IP address by blocking incoming connections in the client? Or are there other ways to find out the IP address of a transaction?

Couldn't you just route your traffic over Tor?

Dan Kaminsky's deanonymization works by having a lot of probes in bitcoin network that collect data about how transaction propagate and than trying to localize it's source.
When packet travels in the network (Internet), it has to have source and destination IP addresses in it's header. Therefore when your bitcoin client sends transaction it has to wrap it into IP packet with your source address and destination address of the connected peer.
For one way communication it's theoretically possible to have random IP source address in a broadcasted transaction, but it would be still possible to deanonymize by knowing location of closest peers.
It would be easy to avoid deanonymization by using any kind of IP proxy, see this question.
P.S. The answer has some speculations because Dan Kaminsky didn't release the software yet.

You can block incomming connections and that would make your client "invisible" on the Bitcoin network however when you would also never receive any transactions related to your wallet.
Even then when you send a transaction you would make your client visible as it would have to transmit that transaction to at least one peer.
There are a couple of work arounds.
1) Use a web based wallet.  In that instance the IP address of transactions is the web based wallet provider.
2) Use a VPN proxy.  Maybe companies provide VPN encrypted proxies.  Anyone tracing your transaction would only know it originated at the VPN proxy.  They can't see beyond that back to your original transmission.  You will need to trust whoever is providing the proxy to not keep logs or share data.
3) (future solution) Someday a company may provide a bitcoin anonymizing service. In essence a low cost VPN proxy for bitcoin transactions.  You would receive blockchain data from the proxy and the proxy would submit transactions to the rest of network.  Obviously in that instance you would need to trust the proxy.  This would work similar to #2 but provide two key advantages.  The cost should be lower since bitcoin doesn't use much bandwidth and since the proxy would be aggregating all transactions from all anonymous clients it would provide some safety in numbers so that even if someone knew you used this service they wouldn't be able to determine which (if any) transactions are yours.


text:
Should I leave the Bitcoin client open?
Some people recommended that I leave my Bitcoin client open because it helps the network.
Apart from the security implications, why should I do this? I thought that miners were the ones responsible for validating transactions and including them in the blockchain. What role does the Bitcoin client play in the network?

Bitcoin is a peer-to-peer network, which means that the clients not only receive the blocks from other clients, but send out the blocks to other clients. (You may notice the "connections" number in the bottom right of the original client. You can think of this as "peers" in a torrent client). So yes, by having your client open you are technically helping relay the recent blocks out across the network faster than they would get their otherwise, but there is really no reason to keep a client running all the time.
At one point, the client also doubled as a CPU miner, but we are far past the point where that is useful from a security point of view.

I accept as correct, but David Schwartz's answer is worth checking for some additional details and limitations.

@lemonginger, What do you mean by "but we are far past the point where that is useful from a security point of view"?

I would add two points to those already mentioned: First, if you cannot accept inbound connections (because you are behind NAT or have specifically disabled them) you won't really be helping the network. Second, if you are running any version earlier than 0.3.24, you could actually be harming the network, due to a bug in those versions.
For some reason that isn't well-understood, the Bitcoin peer-to-peer network is consistently short of available inbound connection slots. This makes it more difficult for newly-started clients to establish a resilient connection to the Bitcoin network. If you can accept inbound connections, leaving your client running helps reduce this problem.

Thanks.  It would help if you could also indicate the impacts of running short of available inbound slots.

If you have compiled bitcoin with UPNP support (the pre-packaged version has this) and your router supports it, you can accept inbound connections even behind NAT

UPnP was enabled by default in the pre-compiled Windows client because the problem of the lack of inbound connection capacity was so severe. Many people, including myself, consider this a questionable decision.

@DavidSchwartz.  Why is it a questionable decision.  The risk of UPnP comes from the router not the clinet.  i.e. user installs malicious software on computer and uses UPnP to modify firewall to allow attacker inbound access and then notifies attacker of vulnerable system.  However Bitcoin client creates no risk. If uPnP is turned off the feature does nothing (client can't force a uPnp connection when disabled in router).  If UPnp is enabled the system is already at risk (how much is subject to debate).  Personally I think the risk is overstated for most systems.

It's questionable because a program shouldn't assume the right to open a port in a UPnP setup. That's something a program should request permission to do. Also, there were political issues involving that decision and competing suggestions that I don't think were resolved in a good way.

@DavidSchwartz, When you mentioned "the Bitcoin peer-to-peer network is consistently short of available inbound connection slots", do you mean that this is not a problem other networks like torrents have?

Turning your client off gives it a chance to fall behind the network. The client is so bad at downloading the block chain from other clients, that if you fall more than few days behind, you'll have to download a copy of the block chain from the nightly archive in order to catch up.


text:
Why do people burn Bitcoin or other cryptocurrencies?
Burning is the process of destroying some of your tokens.
In the old days, this was done by sending them to an unexistend (or at least unclaimed, as far as known) address. Nowadays, some cryptocurrencies provide special 'burn' calls that can be used instead (and are easier for other parties to prove by that the tokens were burnt).
But wy do people burn their Bitcoin or other cryptocurrencies?

Counterparty coin is one instance I can recall that they burned 20+ bitcoins to prove they are "serious" about their project and from those burned coins they generated counterparty tokens. These tokens can be seen as proof that they are linked to burned bitcoins, but obviously doesn't give them the same bitcoin value. It's more of a: "Hey, I'm serious about my project. Here's proof that I'm going to work on my project by throwing away money, but I'll also generate new coins in its replacement".

In the past (when the value of bitcoin was much less than it is now), people would sometimes create bogus bitcoin transactions as a way of writing information to the blockchain in a bitcoin transaction.  But now, op_return can be used for that.


text:
How does lnd's autopilot feature work?
Autopilot automatically connects to peers in order to establish a p2p network. I didn't find however a complete explanation of its motivation and logic.

I suggest that you read the code (which is well commented): https://github.com/lightningnetwork/lnd/tree/master/autopilot

there is an issue out discussing the strategies for the autopilot (c.f.: https://github.com/lightningnetwork/lnd/issues/677 ) there it is stated that it currently uses a constrained barabasi albert model or preferential attachment ( https://en.wikipedia.org/wiki/Barab%C3%A1si%E2%80%93Albert_model ) this means that it will look at the topology of the network and randomly select nodes to connect to. However the probability distribution is not uniformly distributed but weighted by the node degree (meaning the numbers of channels a node has) of the nodes resulting to the fact that the autopiolot is more likely to connect to nodes which are already highly connected.
the model is constrained because currently nodes that are too big ( I think having more than 5k channels) will be excluded.

please extend post by config, see https://www.reddit.com/r/lightningnetwork/comments/gvrpvg/struggling_with_lnd_autopilot/


text:
How are scriptless scripts and taproot different?
I recently read Aaron van Wirdum's layman explanation of both scriptless scripts and taproot. I gather that both utilize the aggregation of Schnorr signatures to hide complex scripts (smart contracts) in a normal-looking transaction. What are the finer details that sets the two schemes apart?

One of the most common use of script in Bitcoin is to construct logically atomic operations, such as "Tx2 happens if and only if Tx1 happens".
Scriptless scripts tells us how to use the additive properties of schnorr-signatures to construct atomic transactions without using script. Doing so this way will make them more efficient and private.
Taproot is an idea which uses the additive property of ECC public keys to allow users to commit to a script which is only revealed if needed. If it isn't needed, it is never even revealed that a script existed at all.
This is useful because almost all sensible contract terms (both smart and otherwise) can be rewritten as a top level OR between "Everyone agrees" and the actual contract, and because (with schnorr) you can make a single signature work for the everyone agrees case.
Taproot itself doesn't depend on the specific properties of schnorr and could be implemented e.g. for ECDSA. Technically taproot works outside of the EC signature itself to allow you to spend either via a single plain signature OR some other conditions, with the existence of other conditions hidden if you spend via the signature. But with ECDSA it isn't easy to use a single public key to represent the "everyone agrees" case, so taproot would be much less useful.
So, for example, if you had an output that could be spent either by Alice or by Bob but only after a time limit then pattern would be more efficient with ECDSA taproot than without taproot: Alice's key would be used to generate the root, and bob's key and timeout would be in the hidden script.

the coolest part is that in cooperative case you’ll pay the same transaction fee no matter how large your actual script is. Free “gas” basically.

Scriptless scripts are more like the constructs used in HTLCs and Taproot is more like P2SH.
The common example used for scriptless scripts is adaptor signatures. With adaptor signatures, what one person A wants is a valid signature which person B is able to provide but only if they receive payment. This scriptless script allows person A to give person B money, and when person B takes the money, they automatically will reveal to person A the complete signature that person A wanted. This process is done without any scripting, just changing signature values and the transactions all appear as normal transactions.
However, what Taproot does is very different. Taproot hides a script inside of a signature. In Taproot, you have a tree of possible conditions. At the top level, you have a n-of-n multisignature of all parties involved, or some script that allows some parties to spend. If all n parties agree, then the multisig is used and the transaction appears like a normal transaction.
But if not all parties agree, then the script must be executed. Once this happens, the spending transaction will no longer look like a normal transaction. It will be very obviously spending a Taproot output. The script will be revealed and the conditions of that script will need to be checked.

I don’t fully understand the taproot collaborative branch. So an off-chain protocol must allow participants to individually execute/verify the spending script of one of the complex branches, then settle via collaborative branch if verified. So script branch verification only amongst signers, not on-chain? Why do non spending signers have incentive to collaborate?

No, the script is only for non-collaborative case. There is no script execution that happens off chain; nothing happens off chain. The theory is that for every case involving multiple people, there is implicitly a case where all of them agree.

So the collaborative spend always implies one script branch has its spending conditions fulfilled, right? The unlocking data is not broadcast though, instead the musig branch is spent. How do they agree that spending conditions of the script branch have been met without executing it? If no execution, why even commit these script ops to the root?

The top level of taproot doesn't need to be N of N, it could be some other admissible set of authorizers, it's just that N of N is almost always sufficient. E.g. if your policy is (A&&B) || (A && timelock) || (B && 2-of-3(C,D,E))  An A+B toplevel  isn't everyone, but it's sufficient. Likewise  2of3 B+C,B+D,B+E could be a taproot top level and would also be acceptable-- you'd prefer to use whichever of these is a more likely outcome.

James C. if they don't cooperate the transaction will have higher fees and be less private. They don't have to, but they can. If this is a concern for some protocol you can have parties prepay additional fees, then refund them in the cooperatives case, but keep them if they don't cooperate.

I see, thank you @G.Maxwell. So we could use the taproot top level  branch to settle the contract, and because authorisers were collaborative, return their prepaid fees via script-less scripts? :)


text:
Are there any services that group multiple transactions together?
I discovered an interesting block that contains 10 inputs and nearly 200 outputs. Does this indicate the operation of a specific service, or is it simply a case of someone executing a large-scale distribution?
https://www.blockchain.com/ru/explorer/transactions/btc/8ecdbb5f430892606e00af76c9357389df0b3cd0bef72a45ad4c6ab7b93e170c

As an example, exchanges and other custodial account providers typically batch together large numbers of transactions where their account holders are transferring money to recipients who are not account holders at the exchange.
Inferring specific organisations and processes is inexact and requires significant and extensive analysis work.


text:
Could miners possibly steal SegWit transactions on The Real Bitcoin?
Going to be lolz epic when all the SegWit transactions are double-spent, i.e. stolen by miners on The Real Bitcoin (the legacy Satoshi blockchain).
Can anyone offer any refutation, confirmation, or more thorough explanation of this?
EDIT Sept, 26, 2019: the attack is being promised by Craig Wright at the May 2020 halving. This Q&A is archived at archive.is and archive.org. Bakkt and other exchanges hodling their BTC in SegWit “anyone can spend” addresses have been officially warned.

Go ahead and continue voting to close and censor this question. It will not change the embarrassment that you will have when it comes true and all the losses that people sustain because you blocked timely disclosure. Your censorship only further lowers your future reputation. This page has been archived.

Looks like the gatekeepers over on this site are going to vote to close this question, as there are 4 close votes and only 1 more needed. I have blogged about this. I think it is travesty that this site is supposed to be about Bitcoin, but you are going to make fools out of yourselves by closing this VERY IMPORTANT question.

Go ahead and continue voting to close and censor this question. If you insist. This page has been archived. Archived? Oh no!

Nick, are you seriously pretending that you’re Coretards were not going to vote to close regardless of what I wrote in the comment section about the rapid assent of close votes. Btw, I upvoted @Andrew Chow’s answer because I appreciate participation, regardless of his affiliation.

I get that you were going for a reverse psychology thing. My general rule of thumb is that if someone asks to be banned, I oblige them.

Then why the fork did this circlejerk site unban me after I had asked to remain banned forever in 2013/4?

Dunno, must've been a paperwork mixup.

I pose that this thesis is wrong, since this never happened with P2SH. No supporting evidence, spamming FUD. https://bitcoin.stackexchange.com/questions/9678/what-is-script-hash-address-exactly-and-how-does-it-work/40730?noredirect=1

@karimkorun, unless you’re a poser (which seems likely), the correct word is ‘posit’ not ‘pose’. It is technically possible. I have provided considerable evidence that it is plausible at my blog which I linked to. The DAO attacker is the one who is promising that all the SegWit will eventually be stolen. That is cred.

If segwit activates, any attempt to steal anyone's Bitcoin by stealing segwit outputs will be considered invalid and any blocks that contain said transactions will be invalid and thus will be a hard fork. With a hard fork, anything goes. Anyone can make a hard fork and confiscate anyone's coins on that fork, it is, after all, a change in consensus rules where you can make the consensus rules whatever you want. "The Real Bitcoin" is no different. In fact several forks have been made from Bitcoin which no one really cares about, and "The Real Bitcoin" will just be another one of those. If there is no economic activity and no users actually use a coin, it is worthless and no one will care about it. Currently ALL miners are signaling for segwit per the BIP 91 rules. No miners are using "The Real Bitcoin" and no major businesses, exchanges, or users are using it. In fact, the vast majority of users (including businesses and exchanges) and miners are supporting segwit.
So sure, you could hard fork and steal coins spent in Segwit transactions, but no one would care because it would be a hard fork and it would just become another altcoin that no one ever thinks about.
Also, you could just steal all P2SH coins now. P2SH was released after "The Real Bitcoin" made their fork. And it would get you more coins much sooner. But no one would care if you did.
Miners are also incentivized to not hard fork and steal coins. Besides the fact that stealing coins means that they will be damaging the value of the chain they forked from, miners are also then taking the risk that the fork that they switched to will be completely worthless. It is far more profitable to continue to mine the chain which the majority of the community backs and will be using than it is to mine some fork which will likely be worthless with no users on that fork. There will be more transactions on that chain and more value with it as people are actually using it. Furthermore, any miner who did choose steal anyone's coins would come under significant criticism from everyone in the community and that would be terrible for their reputation.

This is a good answer that provides some interesting points about which I have some comments to make. Firstly, no one can plausibly steal P2SH as of right now, because afaik there is no one mining “The Real Bitcoin” (TRB) now. TRB nodes are following the Core chain so far. I explained that in more detail in one of the comment posts I linked to in my question.

You don't have to be mining "The Real Bitcoin" to steal P2SH outputs. I can make a hard fork which steals anyone's coins regardless right now, but no one would care, and likewise, any fork that steals P2SH coins or Segwit coins would be irrelevant. As you said, no one is mining "The Real Bitcoin" now, so what makes you think they will in the future? If all miners are mining segwit, they won't be mining "The Real Bitcoin" and stealing anyone's coins.

In order to plausibly steal P2SH, you need to get your transaction into a block which other miners mine on top of. Since that is implausible right as of now, then it is implausible that anyone (other than a powerful miner) can steal P2SH as of right now. You could mine your own fork of TRB now, but it would have no value whatsoever and would be ignored in the future if ever miners with significant hashrate start mining TRB in order to spend all the historic SegWit transactions to themselves. At that future time, there could hypothetically be a real blockchain that potentially has value.

Transactions that “steal” P2SH (SegWit) UTXO are invalid only on the “fake” Bitcoin Core. They’re valid on the legacy Satoshi Real Bitcoin before Gavin et al started implementing BIPs. After Aug. 23, there may be significant SegWit transactions that have the potential to incentivize powerful miners to switch to mining TRB in order to double-spend those SegWit transactions to themselves on Satoshi’s original Bitcoin (aka TRB). My opinion & game theory explanation why TRB ultimately wins the fork war.

IMO, you irrationally characterize Satoshi’s Bitcoin as a hard fork of Core (which is the reverse of the truth), but chronological order dictates that Core is the hard fork when it starts issuing SegWit transactions which allow anyone to spend them on Satoshi’s protocol rules. Who gave Core the right to unilaterally change Satoshi’s protocol rules? Hashrate stays with Core until the carrot of moving back to Satoshi’s protocol rules is too valuable to not steal. Millions of BTC have pledged to sell Core and buy TRB at the coming juncture sometime after Aug. 23 (perhaps month(s) after).


text:
Lightning close-channel transaction example?
From this article, I can understand that a punishment-based bidirectional payment channel (the type used by Lightning) would contain roughly this bitcoin script as one of the outputs:
OP_IF
“+7 days” OP_CHECKSEQUENCEVERIFY OP_DROP
<Bob pubkey> OP_CHECKSIG
OP_ELSE
OP_SHA256 <sha256(Bob secret)> OP_EQUALVERIFY
<Alice pubkey> OP_CHECKSIG
OP_ENDIF

I guess there are some block explorers that let you visualize the real script being used in a transaction, so can anyone point me to a real LN transaction (in mainnet) that follows the template above?
Thanks

The actual script implemented on Lightning Network is a little bit different from what you quoted. This is the script below and the specification is here
OP_IF
    # Penalty transaction
    <revocationpubkey>
OP_ELSE
    `to_self_delay`
    OP_CSV
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

I've created that transaction on Testnet as the following,
Txid:
4f8d776c85b1fc15c1125e7043a9aee70e33f0793b472823e3946a8de075bec4
Rawdata:
6321026644cb387614f66421d14da3596c21cffa239011416c9adf3f351ee8551a9fc767029000b27521029654f80732769d7c435a184a3559f12178315526c53bbf003349390811c7590a68ac

Decoded by here
{
    "result": {
        "asm": "OP_IF 026644cb387614f66421d14da3596c21cffa239011416c9adf3f351ee8551a9fc7 OP_ELSE 144 OP_CHECKSEQUENCEVERIFY OP_DROP 029654f80732769d7c435a184a3559f12178315526c53bbf003349390811c7590a OP_ENDIF OP_CHECKSIG",
        "type": "nonstandard",
        "p2sh": "35M7MGVGd3ajyiTMvriUiyUM3H2cT5sgb4"
    },
    "error": null,
    "id": null
}

blockchain.com has a "show scripts" link.
Here's a mainnet LN transaction:
https://www.blockchain.com/btc/tx/2facfe9147121b64761bef31c3808f43f92311349dbba01217bb666f0bd9b83c?show_adv=true
From this channel:
https://1ml.com/channel/586011110465142785

mmm but those scripts don't match the template I posted in my question

Note that the revocationpubkey is derived https://github.com/lightning/bolts/blob/master/03-transactions.md#revocationpubkey-derivation


text:
Litecoin explorer that accepts M-prefixed segwit addresses?
Just realized that the litecoin explorer I was using (blockcypher) doesn't allow me to input M-prefixed segwit addresses (more info).
Any other litecoin explorer that can do this?

Seems this explorer works fine:
https://chainz.cryptoid.info/ltc


text:
How can the number of peers from the same IP address be counted?
A Bitcoin client connects to peers and can accept connections from peers.  Is it possible to learn how many nodes exist from a specific IP address?
Specifically, the monitoring service from RowIT ( http://bitcoinstatus.rowit.co.uk ) gives a metric "Total Hosts", but I suspect that if there was more than one host from an IP address, the second and successive hosts would not be counted in the total.

That monitoring page states that it counts hosts from 'addr' messages seen on the bitcoin network.
An 'addr' message contains the IP number & port number of a bitcoin client. Since all bitcoin clients use the same listening port number the IP number is the only information to count by.
When a bitcoin client connects to a peer it does send out an extra number to identify it by. However there is no friendly way to force all clients behind an IP number to connect to you so you cannot capture that number for all those clients.


text:
Are there Bitcoin password crackers I can use to recover forgotten passwords?
I've lost the password to one of my wallets (it's a small one, don't worry). I was sure I remembered the password ... but evidently I don't.
Is there a program that I can use to brute-force my password, given hints?
Meaning, suppose that I remember that my password was "abc", but in fact maybe it's "Abc" or "Abc0". I would give the cracker program the string "abc" as a hint, and it would try a lot of permutations on it until it finds the real password.
Does such a cracker program currently exist? (Reliable sources please, hopefully open source)

To clarify, are you asking about the Satoshi client?  I have a 'mywallet' that I instantly forgot the password to, but I believe it's empty.

@ChrisMoore - yeah, Satoshi/standard client.

If you don't want the password to exist anywhere outside your brain, you should use a spaced repetition software to memorize it. (Ideally the software should be able to check your input against a stored hash, and used on a computer permanently disconnected from the internet)

@MeniRosenfeld and what does this have to do with this question?

@Lohoris: That it proposes alternative solutions to its premise. I am under the impression that this is acceptable use for comments.

I had to google "spaced repetition".  Found http://en.wikipedia.org/wiki/Spaced_repetition and thought a link here might be useful.

@Meni: At this point, the password does not exist anywhere outside his brain (and possibly no longer inside, either) :-)

@Thilo: Yes, but this circumstance can be prevented for the future, in theory at least.

FYI - luckily enough, the password was indeed stored on my Keepass. I just named the entry "wallet" and not "bitcoin", so when I searched for it it didn't come up. But the question is still relevant.

Yeah!
+1 for KeePass!

Yup, question is still relevant.  Here's another unfortunate story: http://www.reddit.com/r/Bitcoin/comments/rqymz/forgot_my_walletdat_password_how_to_fix

Revalin made available a sript that you can try running:

http://bitcointalk.org/index.php?topic=85495.msg942171#msg942171

There may not yet be anything else, but you'ld probably find someone willing to write one if you offered to send your wallet along with what you think the pass phrase might be and ask only for a fraction of the wallet's bitcoins back once cracked.

Make sure that the "someone" is trustworthy - at least if you want to get your coins back.

Depending on how wallet encryption works, you don't need to actually send the wallet itself, but only the header.

Much better to ask that person to write a script for him, in exchange for a fixed amount.

Another alternative is btcrecover, available on GitHub here. From the Tutorial:

btcrecover is a free and open source multithreaded wallet password recovery tool with support for Armory, Bitcoin Core (a.k.a. Bitcoin-Qt), MultiBit (Classic and HD), Electrum (1.x and 2.x), mSIGNA (CoinVault), Hive for OS X, Blockchain.info (v1 and v2 wallet formats, both main and second passwords), Bither, and Bitcoin & KNC Wallets for Android. It is designed for the case where you already know most of your password, but need assistance in trying different possible combinations.

It also supports seed recovery for deterministic wallets:

seedrecover.py is a Bitcoin seed recovery tool which can take a seed with one or more mistakes in it, and recover the correct seed if not too many mistakes have been made.

Full disclosure: I am the developer of btcrecover.

You should try walletrecoveryservices.com since that appears to do just what you want. (brute forces bitcoin wallet recovery if you forget your password, without being able to steal your bitcoins)

For a free badge, read the "About" page near the search bar. Thanks and Welcome to StackExchange!

You might want to add some links to testimonials to this answer. I have heard good things about this service but it's a good idea to be sure about it before handing over your wallet.


text:
How can I combine all the tiny amounts I've received to minimise transaction fees, and do I need to?
Important parts in bold, for those who don't want to read the detail!
I've received lots of tiny transactions, in amounts sometimes as low as 0.000003BTC.
Even though I've also received (relatively) larger amounts, I'm worried that when I want to spend my bitcoins the transaction fees may be very high thanks to the large number of "input" transactions needed to make up the output transaction.
As I understand it, the network has an algorithm for determining minimum transaction fees, and the relationship between number of inputs and required transaction fee is non-linear. This means there is likely some optimum way to combine my inputs. This has already been discussed here and here, but neither question asks how it can be done, and how bad the consequences can be.
It might be best to somehow include as many tiny inputs with a larger input each time I spend a moderate amount, or perhaps it would be better to somehow combine all the tiny inputs in individual batches of some optimum size and send them to myself to prevent future problems.
If I were to combine the tiny amounts, I'd be happy to wait for the newly combined bitcoins to age, so additional fees which would be required by spending young bitcoins won't be a problem.
In most, but not all, cases, my tiny amounts have been received to a dedicated tony-amount address.
For the sake of the question, let's assume I've received 1000 tiny transactions of 0.001BTC each, and another 100 transactions of 0.1BTC each, all in the same wallet. This would give a total balance of 11BTC. Assume all amounts were received 6 months ago.
If I wanted to spend the entire 11BTC at once (with 1100 transaction inputs), how high might the fee be?
If I only spent 1BTC at a time, how high might the fee be?
How can I actually combine the tiny amounts without affecting the larger ones?
I'm running the standard (Satoshi) client, but other clients could be an option.

I have not actually done this, but here is how I understand it. With many tiny amounts, you probably want to consolidate them because the fees for transactions with lots of inputs will be high. Now you ask, by consolidating, won't I just be paying the fees in advance? The answer is that by planning ahead and consolidating them, you can use the low-fee mining pool Eligius to do it.
To estimate the cost of the transaction, I'm going to use only the transaction size (for large transactions, the fee is dominated by or entirely consists of the cost per KB). This is based on the number of inputs and outputs. If all your balances are the same (0.01 BTC), then it doesn't matter how much you spend at at a time, the fee grows linearly with the total BTC amount.
Assuming 180 bytes per input, 1000 inputs comes to 175KB, which I'm going to round up to 200KB for a safety margin. With the official client, at the default 0.01 BTC / KB fee [1], that would cost 2 BTC.
Eligius will mine transactions for a fee of 0.2 TBC (0.00008192 BTC) per KB [2]. So Eligius's fee would be 0.016384 BTC. Might as well round that up to 0.02 BTC or higher just to be sure.
If your coins are old enough (say, 3 months for 10 BTC and a 200KB transaction size) [3], then the official client might not enforce the minimum fee on your transaction. Otherwise you may need to use a modified client that doesn't enforce a minimum fee.
In any case you will need to point your client to Lightfoot Hosting's free transaction relay, which will relay any transaction to the network [2], so it can be picked up by Eligius.
It may take longer than usual, but Eligius should eventually mine it.
As for combining the "dust" while leaving larger balances alone -- you would have to find a client that allows you to choose the inputs to your transaction. I don't know which clients can do that.
[1] https://en.bitcoin.it/wiki/Transaction_fees (The fee calculations on this page are as of client 0.3, so they may be outdated.)
[2] https://en.bitcoin.it/wiki/Free_transaction_relay_policy
[3] Wiki link [1] above says that transactions with priority over 57,600,000 aren't subject to the minimum fee calculation. If this is true, then 10 BTC with an average age of 3 months in a 200KB transaction would have a priority of (1000000000 * 144 * 90) / (200 * 1024) = 63,281,250

Thanks for your answer! Especially for the mention of the waiver for the min transaction fee; I didn't know that

You may update your answer with the fact that a fork of the original client done by cozz (https://github.com/cozz/bitcoin) does allow to pick specific inputs.

Not sure why this old question popped up on the rss stream but might as well add the tidbit that bitcoin-qt these days also allows you to pick inputs manually. It has for a while actually.

I am in this same basic boat except that 100% of my transactions (around 200) are tiny like this, from a mining pool.  I want to transfer everything over to an exchange (Kraken) but the fees will be greater than 50% of the total!  Best case if I opt for the slowest confirmation is about 1/3 of the total in fees.  I really don't understand this answer enough to know what to do with it, I'm on Mac but don't know if there is actually an easy way to solve this issue.  Does this warrant a new question?  Concerned it would just get closed as a dupe.

I haven't kept up to date on all these details. Since this information is nearing 5 years old, I would suggest asking a new question. It looks like Eligius is still around and mining low-fee transactions. But a lot of things could have changed that I'm not aware of.

It is not directly answer for what the question asked but I wanted to give a tip for reducing bitcoin sending fees.
Electrum allows to send bitcoin by selecting the inputs separately.
Edit:
Electrum offers "Coins" tab which list all the inputs and their amounts separately.
So, when I will send bitcoin, I try to select and spend minimum number of inputs for the transaction.

This is a late answer but with still current value, if you will please elaborate on how this can help reducing the fees. As it is now, the answer is nearly useless.

Electrum offers "Coins" tab which list all the inputs and their amounts separately.
So, when I will send bitcoin, I try to select minimum number of inputs for the transaction.
As you know, if input count increased in a transaction also the fees.

authors: محمد اليماني


text:
How do I see the IP address of a bitcoin transaction?
How do I see the IP address that someone used to send or receive bitcoins with? Is it stored in the blockchain?

No, IP addresses are not stored in the blockchain.
But Gavin Andreson indeed notes that

Unless you are very careful in the way you use Bitcoin (and you have
  the technical know-how to use it with other anonymizing technologies
  like Tor or i2p), you should assume that a persistent, motivated
  attacker will be able to associate your IP address with your bitcoin
  transactions.

One way to do this is to simply run bitcoin peer-to-peer clients that connect to a large fraction of the active nodes.  It's not as hard as you might think.  See Dan Kaminsky's Black Hat 2011 talk, starting at slide 21, for more.  (Thanks to kirian for reminding me of the link).  Then see An Analysis of Anonymity in the Bitcoin System 2011-07-22 by Fergal Reid, Martin Harrigan for how to link together the various bitcoin addresses that each user uses.
Some related background is outlined by Craig Reading:
Bitcoin Theft – The Top Ten Threats | Genesys Guru Blog

Also see this presentation by Dan Kaminsky at the Black Hat USA 2011 conference for more details about associating IP addresses with bitcoin transactions.

How connecting to all nodes will help you to obtain IP of a client who sent the transaction? You will only get IP of a node.

The blockchain doesn't store IP addresses.  In order to obtain the IP address of someone sending or receiving bitcoins, you would have either observe the activity of the network very carefully, or track them down by some other means.  Keep in mind that, for example, someone could receive bitcoins without ever being connected to the internet.

If the transaction was made through a third party website (such as en e-wallet or an exchange), you could try to contact the website owner and ask for the logs, if there are any.
The Bitcoin protocol does not record this information by itself.

This seems to be a huge concern when it comes to preserving anonymity. Is there a way to find out whether someone is using an e-wallet or exchange (and which one)? Do coin laundering services have the same vulnerability (i.e. a hack or subpoena could potentially make transactions public)?

if a mixing service was logging ips, that would be something only they know.   no way to find out if they are doing it.   just use tor.

The IP information you can obtain monitoring the network traffic.  Block-chain doesn't contain any useful information to garner IP addresses, but if the user isn't careful with their activities or using a bitcoin mixer, tracking their block-chain info to ascertain habits won't be challenging, and you can use that to confirm an IP.
Now, onto bitcoin mixers.  If you use a clearnet mixer, those sites are subject to governmental regulation (which varies by government) and can be required to give up their records.  Darknet mixers on I2P and Tor are not subject to the same controls and don't typically record any information about their users.  Since there's no user data to surrender and the hash data from the block-chain is all scrambled, it's useless to LEOs.


text:
What is the "silk road" and what does it have to do with bitcoin?
I have read a lot about the silk road and I am still unsure what it is. I went to http://silkroadmarket.org but it just says that the site is down.

This site is about Bitcoin and other Crypto currencies. It cannot possibly become about any business that happens to accept bitcoins unless the primary focus of the question is the bitcoin technology or similar issues.

@Robert - Asking about "businesses" that are primarily Bitcoin, especially enabled by Bitcoin is on topic IMO. Voting to reopen.

Silkroad is an anonymous online marketplace inside the Tor network which became famous for selling illegal drugs.
They don't have anything to do with the Bitcoin project, except for the fact that they accept bitcoins as a payment method.

It also sells books. Got a few good books on there.

Silkroad is a Tor Hidden Service enabling supply and demand of/for (mostly illegal) goods & services to meet. Its onion address is http://silkroadvb5piz3r.onion/
Silkroad does not itself engage in selling goods or services, but merely offers a marketplace for doing this. Neither does it engage in handling payment or delivery.
A reputation system is in place to weed out the bad suppliers.
To be able to visit Silkroad you must make use of the Tor Network and Onion Name Resolution. There are many HowTos on this, here is one.


text:
How to generate mycelium addresses from the 12 words in python
I am trying to re-generate the receiving addresses (and change addresses, for that matter) my mycelium wallet has generated.
So far I've used trezor's implementation of BIP39 to generate the entropy from the 12 words, and a BIP32 implementation I have used previously (successfully, to generate the same addresses as bitcoin core, which uses a different subkeys scheme but from a tpub, not from entropy), to produce the keys from the entropy.
Here's the code:
from bip32utils import BIP32Key
from bip32utils import BIP32_HARDEN
import bip39

wallet_generator = bip39.Mnemonic('english')
entropy = wallet_generator.to_entropy('12 words here')
key = BIP32Key.fromEntropy(entropy)
account_number = 0
i = 0
print key.ChildKey(44 + BIP32_HARDEN) \
         .ChildKey(0 + BIP32_HARDEN) \
         .ChildKey(account_number + BIP32_HARDEN) \
         .ChildKey(0) \
         .ChildKey(i) \
         .Address()

I am trying to follow BIP44's scheme as described here.
I am getting a key, but not the one that appear in my first mycelium transaction. I've tried to search the first 100 i with account_number 0 to 9, to no avail. Using bip32gen from the command line does not produce the correct key either:
echo YOUR_ENTROPY_IN_HEX_HERE | \
    bip32gen -v \
    -i entropy -f - -x \
    -o addr -F - -X \
    m/44h/0h/0h/0/0

With entropy converted to hex with print ''.join('{:02X}'.format(x) for x in entropy)
What am I missing? Is the entropy with BIP39 part wrong? Is that BIP32 library yielding erroneous addresses? What alternatives are there?
UPDATE:
Thanks to this site, I've seen that the xprv generated from the 12 words is incorrect. So either the bip39 is faulty, or the way I'm using it is.

Try with the second to last part of the derivation path being hardened. Right now you have m/44'/0'/0'/0/i, try m/44'/0'/0'/0'/i.

@AndrewChow still nothing.

not sure what exactly shall be achieved, but I know that every wallet has different type of implementations, as outlined here in a post: https://bitcoin.stackexchange.com/questions/60690/how-to-convert-electrum-12-words-seed-to-private-key/60905?noredirect=1#comment69615_60905 - maybe this helps...

The difficulty is with the poorly named BIP32Key.fromEntropy.
Typically to create a new wallet, you:

Get some entropy from a cryptographically secure random source, at least 128 bits and must be a multiple of 32 bits.
Convert the entropy to a mnemonic (this conversion is not a one-way function, it's bijective).
Convert the mnemonic to a 512-bit seed (this conversion is one way).
Convert the seed to an extended private key (also one way).
Do the BIP-32 derivation and all the rest....

BIP32Key.fromEntropy really should have been named BIP32Key.fromSeed.
Here's an example:
from bip32utils import BIP32Key
from bip32utils import BIP32_HARDEN
import os, bip39

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

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

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


text:
How harder is it on average to find a block with one more zero in its hash?
If

the size of the block hash, the one that has to be below a certain value, is fixed (256b, right?), and
finding a hash with one more bit set to zero is, I suspect, twice as hard, and
Moore's law (doubling of cpu power every 18 months. I know, that's not Moore's law, he meant storage in a given space) persists for long enough, and
the total hashing power follows Moore's law (bitcoin does not take over and remains somewhat underground)

then we can calculate when the protocol will have to change.
As far as I've seen on recent bloks, 17 hex characters are already zero in the hash, meaning 188 bits are left with a value. This means that in 188*1.5 years, we'll collectively be able to calculate an all-zero hash in less than 10 minutes.
So what did I miss ? Is my assumption about hash calculation difficulty correct ?

From Applied Cryptography, by Bruce Schneider (pp. 157-158):

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10^-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10^-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×10^41 ergs. This is enough to power about 2.7×10^56 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
But that's just one star, and a measly one at that. A typical supernova releases something like 10^51 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Essentially, the laws of physics prevent the existence of classical computers which can count to 2^256, let alone break 256-bit encryption. Moore's law alone won't ever stop Bitcoin's proof of work from working.
There are two ways around this, however. The first is a break in SHA-256. This is quite unlikely, as Bitcoin uses twice as many rounds of SHA-256 as the usual implementation, as block headers are actually hashed twice. If SHA-256
is ever broken, Bitcoin will actually probably be one of the last programs to suffer from the break, and will have ample time to switch algorithms.
The second way to get around the aforementioned laws of physics is with a computer not made of bits; a quantum computer. Any function can have its domain searched in O[N^(1/2)] on a quantum computer by Grover's algorithm. For SHA-256, with a domain and codomain size of N = 2^256, a string of zero bits twice as long as that of a classical computer running at the same speed can be found in the same time. This would still not be enough to exhaust the remaining bits, and in any case, an attacker with a quantum computer would make much more money by cracking Bitcoin public keys and stealing their balance.
EDIT: Fixed exponents getting mangled in the copy-pasting from PDF.

So it IS twice as hard... ?

So what did I miss ?

Conservation of energy

Please elaborate, I'm still missing it.

I think you can expand this answer and make it much, much better.  You're not wrong, but you need to lead readers to the conclusion.

OK, take one more link: https://en.wikipedia.org/wiki/Landauer's_principle

I do not want to answer this question, but give you useful links for studying yourself

Then maybe you should have commented instead of answering it :)

So you think there's an upper limit to computational power so that calculating an all-zero hash in less than 10 minutes is impossible ? Yeah, and 640k should be enough for everyone.

@Gabriel, amaclin's answer is correct...but doesn't do a great job of explaining why.  You should check out the other answer.

@Jestin, I did, and I'm baffled (:

@Gabriel, basically our primitive little computers, despite Moore's law, are no match for the vastness of the 256-bit space.  It's not just the Moore's law trend line that shows this, but the physical limitations of the universe we live in.  Cryptography is really about the closest thing we have to magic :)


text:
cannot get bitcoind working on ubuntu 12.04
i was previously using ubuntu 10.04 and i tried to install bitcoind. this failed and i upgraded to ubuntu 12.04. when i run bitcoind it still doesn't work:
$ bitcoind
************************
EXCEPTION: 11DbException
Db::open: Invalid argument
bitcoin in AppInit()

terminate called after throwing an instance of 'DbException'
  what():  Db::open: Invalid argument
Aborted (core dumped)

also trying to install again does not work:
$ sudo apt-get install bitcoind
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  bitcoind
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 981 kB of archives.
After this operation, 2,873 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/ precise/main bitcoind amd64 0.8.5-precise1 [981 kB]
Fetched 981 kB in 7s (130 kB/s)
(Reading database ... 222704 files and directories currently installed.)
Unpacking bitcoind (from .../bitcoind_0.8.5-precise1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/bitcoind_0.8.5-precise1_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/bitcoind', which is also in package bitcoin 0.3.24-ppa2~lucid
No apport report written because MaxReports is reached already
                                                              dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/bitcoind_0.8.5-precise1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

how can i get bitcoind working? i don't mind uninstalling and reinstalling if that is what it takes...
update 1
i just tried removing the package and installing again, but still no luck:
$ sudo apt-get remove --purge bitcoind
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package bitcoind is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

$ sudo apt-get install bitcoind
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  bitcoind
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 981 kB of archives.
After this operation, 2,873 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/ precise/main bitcoind amd64 0.8.5-precise1 [981 kB]
Fetched 981 kB in 7s (136 kB/s)
(Reading database ... 222704 files and directories currently installed.)
Unpacking bitcoind (from .../bitcoind_0.8.5-precise1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/bitcoind_0.8.5-precise1_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/bitcoind', which is also in package bitcoin 0.3.24-ppa2~lucid
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/bitcoind_0.8.5-precise1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Try to overwrite the existing version:
sudo dpkg -i --force-overwrite /var/cache/apt/archives/bitcoind_0.8.5-precise1_amd64.deb

perfect. that was all it took!


text:
Blockchain Explorer for local full node
I would like to build my own blockchain explorer because I have found that using the API's of 3rd party blockchain explorers only gives me around 2 or 3 requests per second.
Does an open source project already exists which will let me explorer my local copy of the bitcoin-core blockchain?
Ideally, I would like to:

Index all transactions into a local database such as MySQL to make searches faster,
Be able to search by tx, address, public key, block number etc,
Would be nice if it can interface with NBitcoin so I can code with C#.

Any recommendations will be highly appreciated.

You could check https://github.com/Blockstream/esplora
I think it ticks all of the boxes, I am not sure about the NBitcoin though.

This looks good.  Any idea if they have some good documentation and example usage which is better than the few lines written on their github page.

You can use my blockchain parser (python script) that converts the local copy of blockchain (blkXXXXX.dat files) to human readable text view -> my parser
Bases on this parser you can do anything you want with that data.


text:
What does it mean that fork is required?
In bitcoin related discussions people often say that something may require a "hard fork".
What do they mean? What is a fork?

Fork means in this context that devs are about to change some fundamental hardcoded rule. This may mean that the part of network which didn't upgraded client to new version will run on one set of rules and another upgraded part of network will run on other set of rules. In general, network fork means inconsistency of whole network.


text:
How many sigops are in the invalid block 783426?
On April 1st 2023 F2Pool mined block 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 (full block) which my node failed with bad-blk-sigops.
Bitcoin Core stops counting as soon as it reaches the 80,000 limit.
I had a hard time counting this, but how many sigops did this block contain?

The correct, but non gratifying, answer is 80,003.
I found it by changing MAX_BLOCK_SIGOPS_COST, recompiling and the using the invalidateblock and reconsiderblock RPC to recheck it.
The block fails validation with the sigops limit set to 80,002 as passes validation when it's set to 80,003.

Was this an april fools joke by them? Is there any context as to why this occurred?

They probably miscounted the sigops on bare multisig transactions.

@Poseidon that would be a $150K prank, and they already had a different April Fools joke on social media. So I think it was an accident. I suspect they use custom software to compose the block, not Bitcoin Core's getblocktemplate. See also: https://twitter.com/provoost/status/1642182022176161795

The answer is 80,003. I arrived at the same number as Sjors by writing a script that goes through every transaction in a block and counts the sigops.
Here is a detailed breakdown:

Bare multisig outputs: 71,200. There are 890 and each contributes 80 sigops.
P2PKH outputs: 3320. There are 830 and each contributes 4 sigops.
P2WPKH-in-P2SH inputs: 2219. Each contributes a single sigop.
P2WPKH inputs: 1751. Each contributes a single sigop.
P2WSH inputs: 1160.

28 inputs contribute a single sigop.
363 inputs contribute 2 sigops.
128 inputs contribute 3 sigops.
2 inputs contribute 4 sigops.
2 inputs contribute 7 sigops.

P2WSH-in-P2SH inputs: 193.

12 inputs contribute a single sigop.
29 inputs contribute 2 sigops.
33 inputs contribute 3 sigops.
6 inputs contribute 4 sigops.

P2SH inputs: 160.

1 input contributes 4 sigops.
13 inputs contribute 12 sigops.

Can you share the script? Either in your answer or via a Github gist?

It's a "script" in a sense that it's a JavaScript (actually TypeScript) file sitting in a larger project of mine using some of its internals as dependencies. If you'd like I can produce a minimal standalone repo.

Even without the dependencies it could be useful to see the script and the queries it makes, so I can compare with what I was doing.

Here you go: https://gist.github.com/vostrnad/ce761880282d881dacb5337af7d73e35

I was able to do a partial count, but I'm having a hard time counting it for P2SH and SegWit transactions.
Parse the block and store result:
bitcoin-cli getblock 00000000000000000002ec935e245f8ae70fc68cc828f05bf4cfa002668599e4 2 > block.json

This lists transactions like so:
    {
      "txid": "914b24cf50f4bc930c3a11123411031010f010563ed293f65f1ef8cb9bc1e950",
      ...
      "vin": [
        {
          "txid": "cf3349976fedfe34502333310f753d91c16dccb3220d37d5f4c1a11b70eceda2",
          "vout": 1,
          "scriptSig": {
            "asm": "30440220253e9a3fc9cbae7833abc38ea29ae4f7672cb33591c227446c71b26a8199760a022071042cde824b3cfddc51888d49ac8f85062921e1430ee85885252e1a6758fc17[ALL] 02b704c5bac9ed2e23193f28f0a9e1108ff6164e713552fca936c9447566df1d66",
            "hex": "..."
          },
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.00071520,
          "n": 1,
          "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 8342c5f824ae0806236e746b951e68192c1b124f OP_EQUALVERIFY OP_CHECKSIG",

            "address": "1Cy3Wd2pArq359z9d3VYMUoBQBM1kkANCn",
            "type": "pubkeyhash"
          }
        }
      ]

I can use jq, grep, sed, awkandwc -l` to count various stuff.
Legacy OP_CHECKSIG:
cat block.json | jq -r '.tx[].vout[].scriptPubKey.asm' | grep OP_CHECKSIG | wc -l
830

Each OP_CHECKSIG used to count as 1 sigop before SegWit, and now counts as 4.
This yields 830 * 4 = 3,320 sigops
Bare multisig:
cat block.json | jq -r '.tx[].vout[].scriptPubKey.asm' | grep OP_CHECKMULTISIG | wc -l
890

Each OP_CHECKMULTISIG counted as 20 sigops before SegWit, regardless of the number of public keys.
This yields 890 * 20 * 4 = 71,200 sigops.
P2SH:
Now it gets a bit more complicated. Because the P2SH script is only revealed when you spend it, we have to look at scriptSig on the inputs. Specifically we're looking for a scriptSig that's not one of these:

A regular OP_CHECKSIG spend, which always starts with a DER encoded signature (^304.*\[.*) and ends with a pubkey (0.*$).
P2SH wrapped v0 SegWit: ^0014.*

We also assume it contains at least one signature, which we recognise by the presence of a sighash marker like [ALL]. The script itself is the last thing pushed on the stack, which is what the awk command gives us. We then pipe that into decodescript.
cat block.json | jq -r '.tx[].vin[].scriptSig.asm'| grep . | grep -v "^304.*\[.* 0.*$" | grep -v "^0014.*" | grep "\[" | awk 'NF>1{print $NF}' | xargs -i -n 1 bitcoin-cli decodescript {} | jq '.asm'

The result is a very short list consisting of 13 2-of-3 multisig transactions and 1 OP_CHECKSIG.
So that yields (13 * 3 + 1) * 4 = 160 sigops
Pay to witness public key hash:
For this we look at the txinwitness field. Specifically we check if the last stack entry is a public key.
cat block.json | jq -r '.tx[].vin[].txinwitness[-1]' | grep . | grep -v null | grep "^0..*" | wc -l
3981

This yields 3,981 sigops. Update: Vojtěch found 2219 + 1751 = 3,970 in his answer
Pay to witness script hash:
We again look at the last item on the witness stack, which we assume to be the script. We do the opposite of P2WPK and drop all matches with a public key. We also drop (taproot) Schnorr signatures which are 64 bytes plus optionally 1 for the SIGHASH. We also drop entries that start with 33 bytes (I think these are Tapleaf script hashes).
cat block.json | jq -r '.tx[].vin[].txinwitness[-1]' | grep . | grep -v null | grep -v "^0..*" | sed -r '/^.{128,130}$/d' | sed -r '/^.{66}$/d' | xargs -i -n 1 bitcoin-cli decodescript {} | jq '.asm' | grep -o "OP_CHECKSIG" | wc -l
231

This yields 231 sigops.
We count multisig in a similar way. First we sort them by N and not which N's are used:
| jq -r '.tx[].vin[].txinwitness[-1]' | grep . | grep -v null | grep -v "^03.*" | sed -r '/^.{128,130}$/d' | sed -r '/^.{66}$/d' | xargs -i -n 1 bitcoin-cli decodescript {} | jq '.asm' | grep "OP_CHECKMULTISIG" | rev | sort | rev

Then count the number of occurrences:

2 times m-of-7: 2 * 7 = 14 sigops
1 time m-of-4: 4 sigops
102 times m-of-3: 306 sigops
385 times m-of-2: 770 sigops
List item
27 times 1-of-1: 27 sigops

So that yields 1,159 sigops.
Total
3320 + 71200 + 160 + 3981 + 231 + 1159 = 80,051


text:
How safe it is that a single San Francisco company controls the canonical location of Bitcoin code?
The single most-trusted canonical source of Bitcoin client is https://github.com/bitcoin/bitcoin
This URL is controlled by a single US company GitHub Inc., headquartered in San Francisco, United States. The US government (nor any other government) is probably not a friend of Bitcoin, and they could theoretically threat the CEOs of GitHub Inc. with an arrest, unless they implement some kind of backdoor into the Bitcoin code, which could be downloaded by a large number of people before it would get noticed.
If and how is the Bitcoin network protected from being poisoned and destroyed this way?

You should learn more about the way the git scm system works. First, it is distributed so that everyone has a complete copy of the entire codebase; second, every commit is checksummed, so that if github wanted to (or was forced to) underhandedly change code, it would be detected by everyone.

It's just not a plausible threat model. First, all changes are publicly audited by hundreds of people. Second, releases are signed by the developers.
Third, it wouldn't even do any real damage. Bitcoin once had an overflow bug that did about as much damage as any intentional defect possibly could. The network easily recovered as people identified the bug, distributed fixed clients, and rejected the invalid transactions.
If you're really worried about this, just don't upgrade to any new version until it's been out for at least a week. By that time, any subterfuge would have been discovered by dozens of people and widely reported around the world.

If you follow the advice on this question, you can download the client and verify it's been signed by Jeff Garzik, free from any possible tampering by middle men.
Future client versions are planned to be distributed via other, more p2p-friendly means (the name of the distribution project has slipped my mind right now)

It does not matter where code is situated. Github may be used just for first time.
Your question is about developers. Anybody who can commit to master branch, can inject malicious code. It will be a little mistake in math, parser, network stack.
It also may be a group of coders, they will try to hide this injection with mass commit to code, with preposition to improve bad places, e.g. improve db size( v0.7 -> v0.8 ).
Behind them may stay a great government's structure, like NSA or FBI, CIA.
Such injection was in OpenBSD project early. One of the developers collaborated with FBI.
Only God know what kind of mistakes(backdoors) contain mass commit by Microsoft to Linux kernel(v3.0).
My 10 cents of paranoia.

I say that Microsoft commit "Microsoft's code" to Linux kernel. And only God know how many backdoors will be founded in "Microsoft's code" in the future.

You say: " My 10 cents of paranoia. " I'd say this is more than just paranoia. This is bordering on insanity.


text:
What is the Elliptic Curve algorithm used in Ripple to generate public / private key pairs?
The algorithm used by bitcoin to generate keys is secp256k1, is it the same for ripple?

Yes in ripple-lib the default elliptic curve is set in sjcl-custom/sjcl-secp256k1.js
// Overwrite NIST-P256 with secp256k1 so we're on even footing
sjcl.ecc.curves.c256 = new sjcl.ecc.curve(...)

Then in keypair.js when a new key pair is instantiated its _curve attribute is set to secp256k1.
function KeyPair() {
  this._curve  = sjcl.ecc.curves['c256'];
  this._secret = null;
  this._pubkey = null;
};


text:
Coinbase lost my transaction from Bitstamp
I'm moving my coins out of Bitstamp I was looking for another exchange. I have sent 0.00007 BTC to just test the transaction. I got the address where I want to send coins to from coinbase.com/myAccountName. Apperently this address changes after a while.
I got a mail from Bitstamp to verify my transaction, what I accepted.

You requested to withdraw 0.00007000 bitcoins to address
  1Kr8jaHPqEfwd1ZXMh6PHg2fhM5vqCYAQH.

A few minutes after my transaction it was finished on Bitstamp. I copied the address to the blockchain and I saw it was confirmed and verified my the network.
Then I went back to coinbase.com/myAccountName and I saw the address was changed...
I never got a mail or a conformation the funds have been transferred on my coinbase account.
I thought Coinbase was doing a lot of effort to make this dummy proof?
What did I do wrong? Isn't coinbase.com/myAccountName made to do an easy transfer?
I'm using Bitfinex now, worked great. Very happy with the exchange!

https://coinbase.com/addresses has a list of addresses you can receive. Does the address appear there?

It only has one address what is different than the address I use to transfer the money... I gave the link of this topic to the support of coinbase, lets way for the result. It would be a shame if a new person to Bitcoin lost a lot of money by this bug. It loses trust in Bitcoin...


text:
Can I change the bitcoin block-data directory from /home/user/.bitcoin/blocks to something else?
I have two users on my Linux system, daemonuser, which runs bitcoind and abeuser, which runs Abe.
Whenever I start Abe, I am told:

Skipping datadir /home/daemonuser/.bitcoin/blocks: [Errno 13]
  Permission denied: '/home/daemonuser/.bitcoin/blocks/blk0001.dat'

Even after adding abeuser as a readable user on the /home/daemonuser/.bitcoin/blocks/ directory.
Would it be easier to keep bitcoin's blockdata in a public folder and read it from there for Abe's purposes?

That's for windows :S And bitcoinqt. Does the same work on bitcoind on linux? If so, awesome!

Bitcoind is exactly the same codebase as Bitcoin-Qt, only compiled without GUI. There's very little difference between the versions for different OS'es too. One notable exception is the location of the standard datadir.

Asking about how to change the default storage location has been posted many, many times. The future canonical question is probably Bitcoin-Qt setup: Change block-chain file location, settings? documentation?. Possible duplicate of Bitcoin-Qt setup: Change block-chain file location, settings? documentation?.

Did you make the files in the .bitcoin/blocks/ directory readable for Abe? You can test this by logging in as Abe (sudo su abeuser should suffice) and typing strings ~daemonuser/.bitcoin/blocks/any.file.


text:
Why is BIP-147 (Dealing with dummy stack element malleability, part of segwit) necessary?
Given BIP-11 (M-of-N Standard Transactions) it's not clear why BIP-147 (Dealing with dummy stack element malleability) is necessary.
BIP-11 states:

OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig:
OP_0 ...signatures...

(OP_0 is required because of a bug in OP_CHECKMULTISIG; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).

Yet BIP-147 claims:

A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY causes them to consume an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. ... [my emphasis]

This statement appears to contradict BIP-11, which clearly requires OP_0 as the first validation script element.
I can think of two reasons for BIP-147:

BIP-11 doesn't explicitly require the stack to be checked but just that a multisignature validation script begins with OP_0;
BIP-11 doesn't apply at all to OP_CHECKMULTISIGVERIFY.

Are these indeed motivations for BIP-147, and are there others?

BIP 11 is not a consensus rule, but a recommendation on how to use multisig on the network.
BIP 147 is correct in describing the existing network consensus rules: OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY pop one element more off the stack then needed, and ignore that element. BIP 147 changes the rule to make these opcodes not ignore the element, but require it to be a 0. To be compliant with BIP 11, transactions already had to put a 0 zero there, and in practice everyone always has. But there was no requirement that transactions follow BIP11 - it was just a recommendation for better interoperability. With BIP147 it becomes required to have a 0 there for every transaction to be valid.
The reason for changing this is malleability: currently, anyone can take a valid transaction that uses any of these opcodes, and take the 0 and replace it with anything else, without invalidating the transaction.
Ideally, we would want to fix the bug entirely, and make OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY  not pop off an unneeded stack element. However, that would be backward incompatible, and thus only apply to new transactions if we don't want to break existing software. The approach in BIP147 applies to all multisig transactions.

Is the extra-element bug addressed any differently in SegWit transactions? I'm looking at a SegWit multisig redeeming input and I think I see an "empty" stack item followed by 2 signatures, then followed by the P2SH redeem script. Is that first empty stack item "" the dummy element for CHECKMULTISIG?

@pinhead Yes and no. 0 is encoded as "" on the script execution stack, so OP_0 really just pushes an empty stack element, and BIP147 doesn't actually require OP_0 - it just requires an empty stack element. In SegWit, the input stack is encoded directly rather than as a sequence of opcodes (as is the case in scriptSig). As a result, the dummy CMS argument in the witness stack is indeed just "".