What should a stratum server do with "mining.submit"? I write some stratum server, for mining in the pool. The answer goes from the client to my server:

  {"method": "mining.submit", "params": ["g", "06a8", "01", "1d025f83",
  "c03f38ac"], "id":4}

What should I do with this in my stratum server? What next do I need to do with this data?
(I write in Plain C)

Read the documentation please: https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.submit

A quote from it:

  mining.submit

  mining.submit("username", "job id", "ExtraNonce2", "nTime", "nOnce")

  Miners submit shares using the method "mining.submit". Client submissions contain:

  Worker Name.
  Job ID.
  ExtraNonce2.
  nTime.
  nOnce.

  Server response is result: true for accepted, false for rejected (or you may get an error with more details).

You write:

  What next do I need to do with this data?

You could check the poolserver for example code: https://github.com/GOSTSec/poolserver/blob/master/src/server/poolserver/Stratum/Client.h#L82


Transactions without signatures? Do all transactions require a siganture to be broadcasted and signed or is it possible to have a unsigned transaction be mined?

Could you not just use op codes to allow a transaction to be validated without a signature?

Such as making the scriptsig OP_true?

Do all transactions require a siganture to be broadcasted

No. Bitcoin does not require that valid transaction must have signature verification.


How does the thunder network work? And how does it keep things decentralized? How does the new thunder network work? How does it keep things decentralized?

The Thunder Network is just an implementation of the Lightning Network, so it follows the same methods as LN. The summary paper provides a good overview of how it keeps things decentralised.


Is Bitcoin still an experiment? Definition of the word Experiment:

  A scientific procedure undertaken to make a discovery, test a
  hypothesis, or demonstrate a known fact.

If Bitcoin was/is an experiment, I don't think it's trying to make a discovery, it certainly isn't demonstrating a known fact.

It might be more closer to testing an hypothesis like "A digital decentralized form of money is viable". But what exactly is the hypothesis? Where does the test end? Who declares the end of the experiment? The bitcoin foundation? The governments? Forum folk?

As we're nearing the end of 2014 and getting closer to the fifth birthday of Bitcoin, is it still an experiment?

I know that this is a very broad and open ended question. And yet, the argument is popularly used by prominent people from the community. Like Gavin Andresen. Everytime he faces a tough question, this is his response. If we don't know where the experiment began and where it ended or where it will end, then maybe we should not use this as a wildcard answer.

Is Bitcoin still an experiment?

I don't think so. There's no control, and nobody's made one of those three panel boards.

In all seriousness, though, I think Satoshi probably wrote and published Bitcoin because he found it interesting. He may also have done so because it aligned with his political views. Of course, we're speculating on the motives of a guy that nobody's met.

I also speculate that the current Bitcoin developers are part of the project for much the same reason.

  When does the test end? Who declares the end of the experiment?

Anybody could declare it, I suppose. It would be a bit like Emperor Norton ordering the US Army to arrest the United Nations, but they could still declare it.

  As we're nearing the end of 2014 and getting closer to the fifth birthday of Bitcoin, is it still an experiment?

I think the essence of your question is, "Is Bitcoin ready for mainstream adoption?" I don't think so. There's aren't mature payment solutions for physical stores. There are problems with Bitcoin that haven't been sufficiently solved to my mind (primarily detecting double spending).


Bitcoin Core on a Linux partition on MacBook... Lost bitcoin due to insufficient disk space to update blocks As the title says, I have an interesting difficulty and have no idea how to resolve it.
I installed bitcoin core on the linux partition of my macbook, but was not aware that it needed as much disk space as it did to update the blocks. It says it is "4 years and 40 weeks behind", and will only run for a short time before giving me the error that there is insufficient space on the disk.

This is a problem as I have already initiated a transfer of bitcoin from coinbase to the address provided to me by bitcoin core.

It says that recent transactions may not be visible until my wallet has finished synchronizing with the network, but I don't have sufficient space to do so.

I tried to use GParted to resize the partition, but it would not allow me to.

Any ideas??? It was quite a bit of money I have lost.

You can set Bitcoin Core to run in "pruning mode" which will then keep only the last few blocks instead of the whole blockchain.

To enable pruning, you add the line

prune=<n>

to your configuration file whereby you replace <n> with the number of megabytes of blockchain data you want to keep. The minimum is 550.

The configuration file can be found in the Bitcoin data directory by default it's found at ~/.bitcoin on Linux. The configuration file is called bitcoin.conf. If the file doesn't exist yet, you can just create a text file by that name.

Also see:

How can I run bitcoind in pruning mode?
Where is the data folder for Bitcoin-Qt?
Jameson Lopp's Bitcoin Core Config File Generator


How can a currency be added to Ripple? I would like to add New Israeli Shekels (ILS) into Ripple.

How do I go about doing that?

To clarify, when I try to enter ILS in the Trust page, it doesn't recognize it.

I see that I can still add it, and in fact add arbitrary currencies such as XYZ (Ripple shorterns whatever I enter in the currency box to three letters if it doesn't recognize it).

Why doesn't ILS appear in the autocomplete box?
What does it mean that I trust someone with 1 XYZ or ZYX?

Probably the reason why it is not added is because it wasn't considered "one of the main ones" whatever that means. You can write ILS yourself though: you can use whatever three letter code you like.

Alice trusts Bob for 10 XYZ.

Alice and Bob know what XYZ represent. If you and your friends (ripple neighbors) use ILS, you know it represents New Israeli Shekels, the system only needs to know that it is the same currency so that it can apply a 1:1 exchange rate.
For more information on this, read this issue and this forum post:

https://github.com/rippleFoundation/ripple-client/issues/77

https://ripple.com/forum/viewtopic.php?f=1&t=7

EDIT: To trade ILS, manually edit the text within the selector for the currency pair. For example, substitute "XRP/BTC" for "BTC/ILS" and that's it. Of course you need to specify the issuer for ILS and BTC as always.

EDIT2: Now currencies will be ordered upon usage. The more you use a currency, the higher it will appear on the selector's list.
https://github.com/rippleFoundation/ripple-client/commit/1a44e94844d6948d103e31c6121dcb71d5b65ef1


Is it possible to calculate the difficulty purely by the number of blocks generated in e.g. 3 month and the staring difficulty? The background of this question is wether the distribution of the block generation does matter? Lets say we have a period of 12 weeks. If the number of blocks created in this time is 6*2016 then the difficulty should not change. If the number of blocks is (6*2016)*1,1 (10% more) the difficulty what have risen 6 times by 10%. This both statements should be true if the generation of the blocks is (more or less) equally distributed over the time.

I wonder now if this is true for different distributions.

I know there are this limits in difficulty adjustment (4 and 1/4) but if they are not reached it should be possible?

You should know the current difficulty to adjust the next value.
It can not be found only by number of blocks for past 3 monthes


Share difficulty and hashrate Can anybody explain relations and formulas between mining share difficulty, target and hashrate?

Thank you.

Difficulty is a measure of how difficult it is to find a hash below a given target.

Target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network.

Target = current difficulty = output by Bitcoin's getDifficulty RPC call
(Difficulty is basically a different representation of the target to make it easier for normal humans to understand it.)

Hashrate is computed hashes per second.

difficulty = hashrate / (2^256 / max_target / intended_time_per_block)
             = hashrate / (2^256 / (2^208*65535) / 600)
             = hashrate / (2^48 / 65535 / 600)
             = hashrate / 7158388.055

Sources:Relationship between Hash-Rate and Difficulty && https://en.bitcoin.it/wiki/Difficulty


Authentificate myself as the sender of a bitcoin transaction How can I prove my ownership of a tx's sending address to the receiver, assu?

I can not answer This question, but to help anyone out, reading this:

Since localbitcoin's signature verification is broken, I've put together my own solution.

www.coinig.com

Some deep, technical bitcoin magic?
Would you care to elaborate on this more?

The problem is that to prove you are the owner of the originating bitcoin address, you need to sign something using the private key from that address. That's the only true bitcoin-like solution, as this key is the very thing that allows you to make transactions is your only technical proof of ownership.

Unfortunately, the way said key is stored is by being in your wallet (be it the wallet file of your bitcoin client or your brain wallet or whatever else you use). If you do not have this, then you lost that address, and with it access to any remaining bitcoins in that address, and the only purely technical way of authenticating yourself as the owner.

There may yet be a non-technical solution: Find someone whom the beneficiary of your transaction mishap trusts and who can vouch for the address being your address. Maybe someone has transferred bitcoin to that very address of yours and can assure the beneficiary that it is indeed yours?

Note that all this leaves another question: Does the beneficiary know what address he has been paid from? I may be wrong, but I suspect that each block in the blockchain describes only lumped inputs and lumped outputs, so the source(s) could(?) be any combination of the input addresses. So if I was the beneficiary, then without further educating myself about the technicalities of bitcoin transactions, I wouldn't be quite sure from which bitcoin address I'd need authentification from.


What is a Mining Pool, what is it good for? What advantages / disadvantages does it offer over solo mining?

A Mining Pool is a protocol for a group of miners to work together, in order to smooth out their mined coins. A miner working alone would generate a block (= 50 Bitcoin) whenever he is the first to find a correct hash. In practice, this happens quite rarely for a single miner.

When several miners are working together in a pool, their earnings are split among all miners (with the pool usually taking some commission). This guarantees an even spread of earnings over time instead of "all or nothing" in solo mining.

One disadvantage of a mining pool is its centralicity - most pools today have central nodes that can be DDOSed, and if not configured accordingly when a DDOS happens the miner will just sit idly instead of reverting to a different pool or to solo mining.


Does an exchange of only virtual currencies fall under FinCEN regulations? If a business only exchanges between say bitcoin, litecoin and namecoin. No fiat currencies. Does it still fall under finCEN's regulations?

Your guess is as good as anybody else's.   FinCEN's guidelines read:

  The term "money transmission services" means "the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means."

That's as broad as you can get.  Bottles of Tide detergent apparently serve as a form of value that substitutes for currency, so going by that FinCEN could go after your corner market for not registering as a money transmitter for delivering tide to your door without verifying that you were the person who paid for the order (and keeping records for five years, and ... etc., etc., etc.).  Now I know they probably wouldn't stoop to doing that ... just like how the IRS wouldn't treat non-profits differently based on the political aims of the non-profit.

That's called totalitarianism.  The laws get interpreted such that the government gets total control over everyone and everything.


k selection for Schnorr signatures So i was reading the BIP for Schnorr signatures and I couldn't find any explanation on why the simple RFC6979 Variant wasn't chosen for their nonce generation. Instead, they decided to go with their own implementation. Why is this?

EDIT: to clarify I'm not refering to normal RFC6979.

I'm not sure what simplified variant you're referring to, but this is a great question.

There are a number of reasons.

First, RFC6979 is not cheap and fairly complex. Computing a single candidate nonce costs 22 invocations of the SHA256 compression function. Hashes are fast, but this actually corresponds to hashing 1400 bytes which isn't trivial anymore compared to the time of signing. It serves a purpose - it's instantiating a well-knowing PRNG to generate the candidate nonces - but this is overkill for us. secp256k1 has the interesting property that its group order is negligibly close to 2256. So instead no PRNG is needed at all - a single hash suffices, which is lower complexity, and obviously constant time as well.

A simpler alternative is the one used by Ed25519, where a single SHA512 invocation generates a 512-bit number that is reduced modulo the curve order. Our construction is different, but is inspired by this. There are some changes though:

We don't need a 512-bit hash and a modulo reduction, again because the curve order is close to 2256, so we can use a 256-bit hash directly without reduction instead.
We're concerned about implementations where the public key of the signer is taken from untrusted input (something most signing APIs don't seem to protect against, as it's a performance penalty to recreate the public key from the private key instead). Greg Maxwell started a discussion on this cryptography mailing list about this problem: https://moderncrypto.org/mail-archive/curves/2020/001012.html, which received comments from DJB and others. We address this issue by including the public key into the nonce generation.
We're trying to protect against fault attacks and differential power analysis attacks by encouraging synthetic nonces (which incorporate actual randomness when it is available). RFC6979 also has a variant that supports this, but it appears that due to our use of linearly derived private keys (through BIP32, and through Taproot), DPA attacks are much harder to protect against, and standard solutions may not apply. See the bitcoin-dev mailinglist discussion here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017711.html (where I agreed with OP that some of our design choices are not well explained in the BIP yet)


What does the MiniWallet class currently do and need to do in the Bitcoin Core functional test framework? I tried to run the Taproot functional tests after building Bitcoin Core with the wallet disabled (as I knew there was no Taproot code in the Core wallet at the time of writing, December 2020).
However, they were skipped because a number of the functional tests currently rely on the Core wallet to create and sign transactions. (Thanks to Marco Falke for pointing this out on IRC.)
The introduction of MiniWallet though raises the prospect of being able to update these non-wallet functional tests so they no longer rely on the Core wallet.
There is a good first issue open on the Bitcoin Core repo to do this for all non-wallet tests. As Marco states in that issue:

This is an open-ended issue. You can find candidate tests via
git grep self.skip_if_no_wallet(). Exclude the tests that start with wallet_, as those are tests that are meant to test the Bitcoin Core wallet.

So what does the MiniWallet class currently do (and perhaps need to do) so that all non-wallet functional tests can be rewritten to no longer rely on the Core wallet?

At the moment, MiniWallet doesn't do any signing. It generates an address and sends an effective regtest coinbase to it. It then constructs an OP_TRUE transaction that spends to yourself with a fee.
I'm not sure at this stage if this is enough to replace the reliance on the Core wallet for all non-wallet functional tests but I will look into it more.
MiniWallet is not a wallet handled by the node, it is an "external" wallet coded in Python for testing. gettransaction only works for those wallets handled by the node, that's why the error says: non-wallet transaction id


Blockchain vs. Banks: which one has more affordable transaction fees? Maybe one of the issues researchers are trying to solve in blockchain protocols like Bitcoin or Ethereum is removing / decreasing "transaction fees". However, if we compare blockchain transaction fee with traditional centralized bank protocols (Visa or MasterCard) which one has more affordable transaction fee? (Or which one is more expensive? blockchain (bitcoin/Ethereum)? or Visa/MasterCard?)

Bitcoin's blockchain transaction fees are market-based, so they fluctuate based on what fees miners are willing to mine:

Currently, they are around $0.75.

First of all, one major difference is that Bitcoin's fees are flat (not based on the transaction amount) and Visa or Mastercard's interchange fees are percentage-based. This means that the fee for larger transactions on the Bitcoin network are the same for very small transactions. You can find Visa's fees, for example on their website: Visa Interchange Rates, which depend on the type of transaction, but they generally are over 1%. Based on that, any transaction above $75 will be cheaper on the Bitcoin blockchain.

Now, there is a secondary layer network on Bitcoin called the Lightning Network, where you can do microtransactions, which are not all immediately posted to the blockchain, but can have drastically lower fees because nodes have to compete to route payment channels, see Bitcoin Lightning Network Creators: Fees Will Be Effectively Zero. The only time you pay the blockchain tx fee is when the channel is created or closed.


What is the coin selection algorithm? When creating a transaction in the standard client, what is the algorithm used to determine which unspent outputs will be used as inputs?

Has this changed since the first version? What different algorithms are used by alternative clients?

Does the client make any attempt to optimize which 'coins' are used based on minimizing the transaction size, the resulting fragmentation, or the 'age' of the coins (value/transactions) used as the source?

I couldn't find the results of the Coin Selection written out anywhere, and just finished piecing it together from the code. It works as David mentioned, but here are more details.

The Coin Selection Algorithm logic to transfer Target amount

If any of your UTXO² matches the Target¹ it will be used.
If the "sum of all your UTXO smaller than the Target" happens to match the Target, they will be used. (This is the case if you sweep a complete wallet.)
If the "sum of all your UTXO smaller than the Target" doesn't surpass the target, the smallest UTXO greater than your Target will be used.
Else Bitcoin Core does 1000 rounds of randomly combining unspent transaction outputs until their sum is greater than or equal to the Target. If it happens to find an exact match, it stops early and uses that.
Otherwise it finally settles for the minimum of

the smallest UTXO greater than the Target
the smallest combination of UTXO it discovered in Step 4.

As David mentioned, the subset problem will first restrict to UTXO that have at least one confirmation if sent by yourself, or six confirmations if received from another wallet, then later relaxes these requirements in two further passes if no suitable set of UTXO could be discovered.

Some examples

Alice has four UTXO:
• UTXO_A 0.1BTC
• UTXO_B 0.3BTC
• UTXO_C 0.5BTC
• UTXO_D 1BTC

I will be ignoring transaction fees for simplicity's sake.

Example 1:

Alice wants to send 0.3BTC.
Bitcoin Core discovers that UTXO_B matches the Target, and it only uses UTXO_B as input.

Example 2:

Alice wants to send 0.4BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) matches the Target here. Both UTXO_A and UTXO_B are used as inputs.

Example 3:

Alice wants to send 0.45BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not surpass the Target. UTXO_C is used as the sole input, being the next smallest input greater than the Target.

Example 4:

Alice wants to send 0.35BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not match the Target. It adds up randomly selected UTXO 1000 times until they surpass the Target, remembering the smallest sufficient combination. The smallest sufficient combination is then compared with the smallest single input greater than the target. Assuming that it does find the best combination here which would be UTXO_A + UTXO_B, it finds that Target < UTXO_A + UTXO_B < UTXO_C and uses UTXO_A and UTXO_B as inputs.

Example 5:

Alice wants to send 0.6BTC.
Bitcoin Core finds that UTXO_D is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B + UTXO_C = 0.1 + 0.3 + 0.5 = 0.9) does not match the Target. It starts trying random combinations as before, and in this situation would probably discover that UTXO_A + UTXO_C = Target. As it finds a combination that matches the Target, it breaks and immediately goes with that combination. UTXO_A and UTXO_C are used as inputs.

¹"Target" is used here for the amount to be spent.
²UTXO = Unspent Transaction Output


Blocks from before the genesis block How do we know that there are no blocks that predate the genesis block? A block that could potentially contain any number of coins. If somebody already created such a block from before the genesis but never published it could it (technically) stil be merged with the chain?

The design of the blockchain is such that such a scenario is not possible. By definition, the genesis block does not have an ancestor block. While it has a field for the previous block hash, this field is set to all 0's to indicate it is null and has no value set. This means that there are no blocks that come before the genesis block.
Additionally the genesis block is special in that it is both treated specially and hard coded into software. Nodes do not download the genesis block - they have the block in its entirety written into the software itself. This gives the genesis block special treatment, with one such special treatment being that the view of the blockchain is instantiated with the genesis block as the very first block.

While it is most certainly possible (and probable) that blocks were created before the genesis block, these blocks would have been ones that Satoshi created during testing and belong to a different blockchain. Those would not be valid on the Bitcoin blockchain because they refer to their own genesis block, or are their own genesis block. The actual time they were created does not matter, only whether they refer to blocks which eventually refer to Bitcoin's genesis block.


Will Bitcoin Cash (BCC) be mined like BTC? Will the new bitcoin-cash be available for mining and if yes, is it mined on new fork that will be submitted or on the previous code?

Will the new bitcoin-cash be available for mining and if yes, is it
  mined on new fork that will be submitted or on the previous code?

Yes, it will be available for mining, and you mine it the same way you mine BTC, all you need to do is direct your hash power to the pool which will be mining BCC after the split.

ViaBTC provide such a pool for BCC mining and it is available now, https://pool.viabtc.com/pool/bcc/home/


How does Ethereum domain registration works? I am wondering how does the Ethereum domain registration works? From what I can see in the whitepaper, I know there is account-specific data storage, but I don't know if that would be the ideal way to register domains. Generally, one would need some shared data storage between all accounts to have globally unique domains.

How does data registration in Ethereum work?

So the whole point of a name reg contract is not to send transactions, rather its sole purpose is to build up a database which other nodes can then query.

Ethereum smart contracts have immutable storage. This means that you can prove your primacy to a specific name, and other people can then reference that as part of a database.

What it comes down to is the credence other entities hold towards a specific name reg Dapp (Network effect, utility, what service it is registering names for etc). In some situations people would want a name reg for a specific purpose, say a list of Escrow contracts for one company, this could then be used internally, or shared. In others as you mention in your question, people would rather look towards a singular name reg which controls a DNS service.

You can have a look at an example name registration smart contract here: https://github.com/ethereum/dapp-bin/blob/master/namereg/namereg.html

Hope you find this useful!


Better Crypto Currency for trading Can anyone suggest me which crypto currency is better for trading? Is it Bitcoin or Ethereum?

Prices in USD as of 21/08/2017 and time 18:03 (UTC+05:30):

Bitcoin = $4041.53 or
Ethereum = $325.76

Volatility is higher in Bitcoin right now. But ETH rose recently as well. It depends on how you define better for your purposes and how the markets will behave which is always difficult to predict.


What previously existing technologies made Bitcoin possible? When watching a tutorial, they mentioned that Bitcoin is based off 4 or 5 technologies that existed for at least a decade before Bitcoin. Satoshi Nakamoto was the first person to combine them all into a digital currency.
I'm aware of at least some of them - SHA-256, ECDSA, peer-to-peer distributed ledger - but want to try and understand all of them.
What other technologies underpin Bitcoin?

Arvind Narayanan and Jeremy Clark wrote an excellent paper about that: Bitcoin's Academic Pedigree. I recommend reading the paper in full, but the following briefly summarizes the paper's content.
Linked timestamping/verifiable logs
Bitcoin borrows the blockchain data structure from Bayer, Haber, and Stornetta which described a very similar data structure in context of a timestamping service in the 1990s. The original also makes use of Merkle trees already. The authors suggested regularly publishing the "blockheaders" in a newspaper.
Byzantine fault tolerance
Byzantine Fault Tolerance (BFT) describes a distributed network to converge on a shared state even when their are malicious or unstable actors. While the whitepaper doesn't cite a specific source, Nakamoto described Bitcoin as a practical solution to the Byzantine Generals' Problem (a challenge that requires BFT), thus indirectly referencing an enormous body of scientific work done in the 1980s through 2000s. While not mentioned, peer-to-peer networks like BitTorrent (2001) must have served as an inspiration.
Proof of work
Originally proposed as a means to deter spam, sybil attacks, and denial of service attacks, PoW failed adoption in those applications due to the stark difference of computing power in various devices.
Digital cash
Digital Cash refers to a form of money that can be electronically transferred but exhibits characteristics of cash: final settlement, peer-to-peer transferability, resistance to forging, and transactional privacy. HashCash, b-money, and bit gold discussed ideas of using puzzle solutions as cash. None of these earlier projects had a solution for the doublespending problem, though. DigiCash solved the doublespending problem but required a central operator to issue new tokens.
Public keys as identies
While public-key cryptography was discovered in the 70s, the use of public keys as pseudonymous identities was first described by David Chaum in 1981. Since anyone can generate their own key pair, public-key cryptography lends itself to self-certified authentication.
Secret sauce: Putting it all together
Prior solutions for Byzantine Fault Tolerance required some level of honest behavior from which Nakamoto sidestepped partially by introducing economic incentives and assuming self-interest. Instead of publishing their chain in the newspaper as Bayer, Haber, and Stornetta floated, Nakamoto uses a peer-to-peer network and proof of work to decentrally author the timestamping data structure. The resulting shared groundtruth solves the doublespending problem that remained unsolved for HashCash, b-money, and bit gold.
The rewards for block authors incentivize collaborative convergent participation, ensuring both BFT but also distributing initial funds to the network. As the network identities derive from self-generated private keys, the peer-to-peer network can be open and permissionless—sidestepping the single points of failure of trusted third parties that caused issues for many previous digital cash projects.


Can I explicitly specify a path for Lightning payment? From what I understand, in the current Lightning implementations payments work as follows:

calculate best N paths according to some metric (like, total fees);
try to perform the payment through the best path;
if it fails, try the next one, until one succeeds.

Is there a way, using standard APIs and implementations, to specify the path for the payment explicitly? For example, how can I find the best 10 paths and then try to execute the payment through path number 4?

In clightning there exist the sendpay command. From the manpage:

sendpay route payment_hash [label] [msatoshi] [bolt11]
  Send along {route} in return for preimage of {payment_hash}

If you look at my (work in progress) code for JIT routing you can see how I create paths and onions myself just with standard api calls to rebalance my channels :

https://github.com/renepickhardt/c-lightning-plugin-collection/blob/master/rebalance-jit-routing/rebalance.py


P2SH non-segwit and no multi-sig I have a P2SH no segwit address (regtest) I create the redeem script with SHA256 and RIPEMD160 of my public key and prepend 0x0014

 ---------- Redeem Script ---------
001407b01acbc2869d92912d50de6c7a6b9cb31487f0

 ---------- scriptPubKey ---------
36e74f3c86af031ee34a4552c0d935d180db0a26

 ---------- ADDRESS P2SH ---------
2MxFXaJvTozTJNZmd6E53wwFX7RnbDkGsGe

After that I want to create a transaction manually. I put redeem_script in scriptSig place holder and sign the transaction data.

After that I create the transaction with my signature and add even the redeem_script in scriptSig (like P2SH multi sig)

my final transaction data is:

0200000001f1838b3d294b74a1869140f538ba895b7aef81eab5e87206725ef1f868598a01000000005F47304402204a181d59fd36fb921d68596a4ae89ee6aef6980ab4a2f433ff28be4760744b76022027752d2a405c20aeda51038a8dccc3f2c0df1088fdebaee5f1eed9fad6ae086b0116001407b01acbc2869d92912d50de6c7a6b9cb31487f0ffffffff016036f829010000001976a9143dc3d9dc346b539125506ca681442d89c336813688ac00000000

I get this error:
mandatory-script-verify-flag-failed (Opcode missing or not understood) (code 16)

Your redeemScript is incorrect. You need to push the public key to the stack by prepending it with its length. Otherwise the script interpreter will try to interpret the pubkey as opcodes, which is incorrect. Just putting the pubkey there does not work because the script interpreter does not know that those bytes are for a public key.


what's the principle of sending money and receiving money? who do the work to put money into account？ If i want to send money, Who gives the payment address. You know, it is said there are no center.
Another question is that if someone send money to me, who help me  put the money into my account?

An individual or merchant requesting payment will generally want to obtain a bitcoin address specific for that transaction.  When done manually, this is obtained from the Bitcoin-Qt client by clicking "Receive".  A merchant would have software that would query the Bitcoin.org client to obtain the address. An EWallet provider will provide for you this address.

The concept you possibly are misunderstanding is like how with a bank account, the account is assigned to an individual or organization before payment is transferred.

With Bitcoin, the client uses math to create the private key (and from that determine the Bitcoin address).  So there doesn't need to be some master registry where Bitcoin addresses are stored.  The person's client simply holds the keys necessary to spend any funds received by an address.

So that answers your second question -- bitcoin never really exist "in your account" but instead if you have the private key for an address, you can spend any funds received by that address.  Every node performs verification of your transaction and won't accept a transaction in which you try to spend funds that aren't yours.   Nodes that are mining will make these transactions permanent by including them in a sequence of data blocks -- which is named the blockchain.

So there are no people doing work, and instead there is simply an electronic communications protocol that is being employed.


Owner of Blockchain Technology Is Blockchain an open source technology or is it owned by a company?

I didn't see it spelled out but Blockchain.com website appears to belong to a company.

There also seems to be different implementations of blockchain databases/ledgers.

Blockchain is some concept. There are different implementations of blockchain. Most of them open source. The most notable one is the cryptocurrency Bitcoin with their reference implementation -Bitcoin Core.

Blockchain.com is just the company with the website which provides some services related to the bitcoin cryptocurrency and owns very attractive web address.


Could not sign Transaction with SignRawTransactionWithKey through the RPC (RegTest) I am able to sign following transaction with Complete=true result, but when trying to decode signed transaction, it returns error "TX decode failed" both from DecodeRawTransaction and SendRawTransaction RPC calls.

signed_Tx = "020000000103d3049e968d8b3e3e967aa90b45d3f64b5e2117ee9610b0c9d5a96081a24e3e000000004847304402201921a1acf601acb0f9e6297a55eeb853c2dd6cd246ea05f060eaa4d327d4124a02206e08e2c90b92113a64d6de1447f81bf19703f88bffeacc6d2cc4bf0e21ed8ac501ffffffff0200e1f5050000000017a9140796253e13d88cda530bf88b07eb1672952a3a7887608a0e24010000001976a914957b73da3bf34440ab2f78937a7a420835255a0988ac00000000"

[TestMethod()]
public async Task CreateRawTxTest()
{
    Dictionary<string, object> prevTx = new Dictionary<string, object>() {
                    { "txid","3e4ea28160a9d5c9b01096ee17215e4bf6d3450ba97a963e3e8b8d969e04d303"} ,
                    { "scriptPubKey", "21033ff1181726af279fb2328e9ae041d71f323a91483f76841fe23aa03f87ecf3d3ac" },
                    { "vout", 0} };

    List<object> txIn = new List<object>()
            {
                new Dictionary<string, object>() {
                    { "txid","3e4ea28160a9d5c9b01096ee17215e4bf6d3450ba97a963e3e8b8d969e04d303"},
                    { "vout", 0} }
            };

    List<object> txOut = new List<object>()
            {
                new Dictionary<string, float>
                {
                    { TestNet_ReceiverAddress, 1.0f}
                },
                new Dictionary<string, float>
                {
                    { "TestNet_SenderAddress", 48.99900f }
                },
            };

    RPCResultPrime<string> rawResult = await disp.CreateRawTransactionAsync(txIn, txOut);

    if (rawResult.Error == null)
    {
        string TxRaw = rawResult.Result;

        Dictionary<string, object> param = new Dictionary<string, object>()
                {
                    {"hexstring", TxRaw },
                    {"privkeys", new string[] { PrivateKey }},
                    {"prevtxs", new List<object>(){ prevTx } }
                    {"sighashtype", "ALL" }
                };

        string signedTx = await disp.SignTransactionAsync(param);

        //at this point transaction signed successfully but could not be Decoded in the next step

        string decode = await disp.DecodeRawTransactionAsync(signedTx);

        string jsonSend = await disp.SendRawTransactionAsync(signedTx);

        Debugger.Break();
    }

}

You are passing the parameter with signedTx incorrectly. A JSON-RPC param key must have a value that is either an array or an object. You are passing in a string. Instead you should pass in the parameter similarly to how you did for the signrawtransactionwithkey call.

You should have something like this:

     Dictionary<string, object> param = new Dictionary<string, object>()
            {
                {"hexstring", signedTx }
            };

    string decode = await disp.DecodeRawTransactionAsync(param);

The same should be done for sendrawtransaction.


Is there a fallback plan if bitcoin's underlying cryptography is cracked? Lets say someone started making real viable quantum computers that were affordable enough that large companies could buy one. And lets say a quantum algorithm was devised to crack the private keys of bitcoin public keys in days rather than years.

Is there a plan for that possibility? What would happen? Would there be a smooth migration to another system? Would bitcoin be able to update somehow to protect itself from such a breach?

No, there is no explicit, publicly-disclosed plan for this situation.

However, there is an implicit plan: when it becomes know that practical quantum computers are on the near-term horizion, the programmers responsible for maintaining Bitcoin at that point will create a hard fork or soft fork to introduce a new signature type, likely something based on Lamport signatures or Merkle signatures.

Users will upgrade their wallets to wallets which support the new signature type and spend their bitcoins from their old private keys to their new private keys.  This is pretty much identical to what Android users had to do for the SecureRandom bug.

This is all very easy if done in non-rushed manner, and fast quantum computing is still a ways off, which is one reason nobody is working on this now.  The other reason is that the proposed new signature types are all much larger than the secp256k1 ECDSA signatures we use now, so using them would increase block chain bloat.

Note: the question mentions the cracking of private keys from public keys, which could be done on a fast quantum computer using Shor's algorithm.  However, in the comments, the OP (B.T.) focuses on cracking SHA256 (which would likely be done using a different algorithm; I don't know which).

The answer above focuses on the private key problem, but the solution for the proof of work problem is the same: a hard fork or soft fork to change the hashing algorithm to make its most difficult value even more difficult.  Again, as long as we have months or years to make the change, this is an easy upgrade, so there's no sense in performing it prematurely.


How many bitcoins have been sent to Base58-invalid addresses? Some bitcoins have been permanently lost when they are sent the the following addresses.  The explanation I've found is that they contain characters that are invalid in Base58

1BitcoinEaterAddressDontSendf59kuE
1Boxo846yTDLHgKM94aYseHBnCjJ4eYbzb

Specifically, base58 only allows the following characters  (excluding 0oiL)

static const char* pszBase58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz";

What is the current running total of "lost" bitcoins, or lacking that, what is the general process needed to figure this out?

(What API methods would you call to get the data to determine this?)

The characters excluded in Base58 are 0OIl. oiL are allowed, making these two valid addresses.

It is impossible to send to an invalid address, as Bitcoin transaction scripts actually include raw 160-bit hashes (which by definition have a one-to-one correspondence with valid addresses), not addresses. Bitcoin clients will simply refuse to do anything if an invalid address is given.

There is probably no problem with 1Boxo846yTDLHgKM94aYseHBnCjJ4eYbzb. The problem with 1BitcoinEaterAddressDontSendf59kuE is that, given an English dictionary, it has very low Kolmogorov complexity, making it extremely unlikely that anyone has a private key (or even a public key) for it.

Likewise, 1111111111111111111114oLvT2 is known to correspond to the public key hash 0, which is so simple it is again extremely unlikely anyone has the keys for it.


Conditional scripting: how does OP_NOTIF (and OP_IF) operation(s) affect the stack? I'm trying to write a scriptPubKey for a transaction which checks that the hash of the top value in the scriptSig is equal to either one of two fixed values and if so will do the normal transaction signature checks to allow the owner of a specific bitcoin address to spend them; if the scriptSig value is not equal to either one of the fixed values then the spending transaction should be marked as invalid.

I'm trying to keep the scriptPubKey as small as possible, i.e. avoiding hard-coded duplications of pubKeyHash and/or duplications of large chunks of scripting.

Here's what I've got so far...

scriptPubKey:

OP_HASH160 OP_DUP <B> OP_EQUAL OP_DUP
OP_NOTIF OP_DROP OP_DUP <C> OP_EQUAL OP_ENDIF
OP_VERIFY OP_DROP
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The scriptSig would look like this...

scriptSig:

<sig> <pubKey> <A>

The intention is that the transaction would pay out if ( HASH160(A)=B or HASH160(A)=C ) and sig, pubKey and pubKeyHash were all valid in the normal way.

My worry arises from OP_NOTIF; the scripting section of the Bitcoin wiki says that OP_NOTIF removes the top stack value...I assume that it is removed as the OP_NOTIF evaluates it and it is removed regardless of whether it is TRUE or FALSE. Is that correct?

The latter assumption is why I've duplicated the result of the first OP_EQUAL so that I can OP_VERIFY it after the conditional line (assuming that it was TRUE and hasn't otherwise been OP_DROPped by the conditional line).

Would my proposed scriptPubKey have the desired result (without nasty side effects) or is there something smaller/simpler (e.g. using OP_IFDUP instead of an OP_DUP and a conditional OP_DROP) or, if my script is plain wrong, what would a workable script look like?

I should say that the point of this transaction is not to effect a multi-signature transaction; it's to effect a kind of single-signature plus 1-of-2 'passwords' transaction.

So your inputs are:

<sig> <pubkey> <a>

And you want to verify that Hash160(a) == Hash1 or Hash2, and that sig is a valid signature by pubkey? Based on your original script, it looks like you also want to verify that pubkey matches a hash in the script.

So, the best way to do this is like this:

OP_HASH160 OP_DUP <Hash1> OP_EQUAL
// stack now has <sig> <pubkey> <Hash160(a)> <Hash160(a)==Hash1>
OP_SWAP
// stack now has <sig> <pubkey> <Hash160(a)==Hash1> <Hash160(a)>
<Hash2> OP_EQUAL
// stack now has <sig> <pubkey> <Hash160(a)==Hash1> <Hash160(a)==Hash2>
OP_BOOLOR
// stack now has <sig> <pubkey> <Hash160(a)==Hash1 OR Hash160(a)==Hash2>
OP_VERIFY
// stack now contains <sig> <pubkey>, and if <a> didn't pass the test the transaction has already failed
// now just do a norma pay-to-pubkey-hash for the rest of it
OP_DUP OP_HASH160 <Hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIGVERIFY

(I realize this is an old question, but I didn't see that until I'd already written up the script for it, so I'm posting anyway...)


Can Bitcoin full nodes pinpoint the true source of a transaction which they've relayed? Assume I'm running a full node and that I've relayed some transactions. As a full node owner, can I pinpoint the true source of the transactions I've relayed?

In the bitcoin data directory there is a file called debug.log.
This file as noted in the bitcoin documentation:

  May contain IP addresses and transaction ID's.

This does not indicate that a transaction originated from a specific IP address but it does indicate that your node received a transaction from that IP address.  If someone were to have a wide enough view of the network and controlled enough nodes then it could be inferred that the creator of a specific transaction was using a specific IP at the time.  This is not always considered conclusive evidence at this time.


Using paper based public/private keys in bitcoin-qt If I only have a public key string and a private key string written on a sheet of paper.  How do I use those in bitcoin-qt?

If this can be added to bitcoin-qt, will it eventually show me how much funds that private/public key has when the block chain is synchronized on my computer?

I understand this action will cause the cold private key to become a hot private key.

I  haven't tested this myself yet but I understand that you can use the info from a paper wallet and generate a transaction using http://brainwallet.org, that said brainwallet.org make some rather nice paper wallets much more info included the the blockchain.info paper wallet.  Let me know if you send a Transaction using this would be interested to know if it works and how simple it was....


Is it possible to know if the result of 2 point subtraction is before or after G I am trying to see if there is a way to see if subtraction of 2 points on the elliptical curve resulted in a point before or after G?. Let me explain what I mean by it.
Let's take a point GP. Using the Bitcoin curve equation, for a value of P=10 I get below X and Y
G10 =(72488970228380509287422715226575535698893157273063074627791787432852706183111,62070622898698443831883535403436258712770888294397026493185421712108624767191)
Let's take another point GQ for subtraction with GP. for Q=20 I get,
G*20 = 34773495056115281091786765947597603724784643419904767525769502836017890139287,8470533044743364938367028725608288731153024648869546164814808839694950063162)
Now subtract GP - GQ, In normal math, it is 10-20= -10, but with EC math I get a point  (72488970228380509287422715226575535698893157273063074627791787432852706183111,53721466338617751591687449605251649140499096371243537546272162295800209904472)
which has the same X value as 10 but Y is different.  If I add G to the result the point is 9G but with a different value.
I am not sure how it is called (Y inverse ?) but I see it's like a point before G and if I add G it comes closer to G. 9G,8G,7G.... 1G
Another way of seeing this is that Y can have 2 possible values (below is the python code which I used to calculate)
One valve is used for 10 and the other for a point which is a result of subtraction.
p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
x = 72488970228380509287422715226575535698893157273063074627791787432852706183111
ysquared = ((xxx+7) % p)
y = pow(ysquared, (p+1)/4, p)
print "y1 = %s " % y
print "y2 = %s " % (y * -1 % p)
So that question can also be, How to know which Y value to use if a value of X is given,

There is no such thing as negative numbers on the elliptic curve used by Bitcoin because it is an elliptic curve over a finite field. It is a cyclic group of points composed of positive-integers. You might want to learn about modulo arithmetic and cyclic groups


Has the Bitcoin network surpassed the total computing capacity of all the general purpose computers in the world? I would estimate there are roughly 2 billion computers in the world, with an average hashrate of 10 MegaHash. That equals to 20,000 TerraHash or about 20 PetaHash. The Bitcoin network is around 20 PetaHash now. Does this mean that the network cannot be attacked using regular computers anymore?

The comparison doesn't make sense. You can't use Bitcoin ASICs to do general computation, and using CPUs to mine Bitcoin is incredibly inefficient.

It also isn't meaningful in terms of security: no one would try to attack Bitcoin by taking over all of the CPUs in the world. Instead, they would fabricate or buy mining ASICs. (Or, more likely, try to hack into the pool servers that miners get their work from.)


How to get passphrase from a private key? I have private key. How can I get passphrase for my bitcoin address.

Assuming you have a symmetrically encrypted copy of your private key, where the encryption key was derived from a passphrase, you would be trying to perform a known-plaintext attack. However, it should not be possible in polynomial time for a proper AES implementation, so I'm afraid you're out of luck.


Is Bitcoin core V.0.9 not updated on PPA ppa:bitcoin/bitcoin? Version 0.9 of Bitcoin-Qt just came out. When will ppa:bitcoin/bitcoin be updated? In the meanwhile, any steps showing how to upgrade are welcome!

The PPA is on 0.8.6, which is very recent (just missing 0.9, but I'm gonna hopefully upload that today). What you're referring to is the Ubuntu package distribution, which is very, very, very out of date (to the point of it being largely non-functional).


What is a stealth address? Stealth addresses are mentioned in the context of privacy of bitcoin transactions. What are they and how would they work?

Can they provide 100% anonymity?

As I understand it, the "stealth address" is intended to address a very specific problem.  If you wish to solicit payments from the public, say by posting a donation address on your website, then everyone can see on the block chain that all those payments went to you, and perhaps try to track how you spend them.

With a stealth address, you ask payers to generate a unique address in such a way that you (using some additional data which is attached to the transaction) can deduce the corresponding private key.  So although you publish a single "stealth address" on your website, the block chain sees all your incoming payments as going to separate addresses and has no way to correlate them.  (Of course, any individual payer knows their payment went to you, and can trace how you spend it, but they don't learn anything about other people's payments to you.)

But you can get the same effect another way: just give each payer a unique address.  Rather than posting a single public donation address on your website, have a button that generates a new unique address and saves the private key, or selects the next address from a long list of pre-generated addresses (whose private keys you hold somewhere safe).  Just as before, the payments all go to separate addresses and there is no way to correlate them, nor for one payer to see that other payments went to you.

So the only difference with stealth addresses is essentially to move the chore of producing a unique address from the server to the client.  Indeed, in some ways stealth addresses may be worse, since very few people use them, and if you are known to be one of them, it will be easier to connect stealth transactions with you.

It doesn't provide "100% anonymity".  The fundamental anonymity weakness of Bitcoin remains - that everyone can follow the chain of payments, and if you know something about one transaction or the parties to it, you can deduce something about where those coins came from or where they went.


Why Bitcoinchain.info Ticker API is not stable? I am trying to use Blockchain.info Ticker API (https://blockchain.info/ticker) to get current BTC price in USD.

The interesting thing is that script not every time returns the same value. When you visit this page directly, none of the values never changes (well just every 15mins) https://blockchain.info/ticker, but on the script it changes on every nth refresh of the page.

Something similar happens if you go to blockchain.info/ticker? with at least a question mark added. Just refresh it a lot and you will see.

Why this is happening and how to get a stable price every 15mins as their API should provide it?

The script I use:

$api = "https://blockchain.info/ticker";
$json = file_get_contents($api);
$data = json_decode($json, TRUE);
$rate = $data["USD"]["sell"];
echo $rate;

There's nothing wrong with your PHP syntax or blockchain.info. The Bitcoin value is always changing. It is traded 365 days a year, 24 hours a day on a multiple exchanges around the globe.


Creating a new electrum 3 wallet file with an imported segwit private key I have a segwit private key that I generated from another app. How can I create a new electrum wallet file with just this private key in there?

I tried creating a new electrum 3 wallet with this command: electrum create --segwit

Then I tried to do an importpirvkey but it says that type of wallet doesnt support importing of addresses. How can I import my bc1 address into electrum as my only address?

Use this python script:

from electrum import bitcoin

format,privkey,compressed=bitcoin.deserialize_privkey("<yourprivatekeyhere>")
print( bitcoin.serialize_privkey( privkey, compressed, "p2wpkh") )

Run the above in python 3 and then import the priv key it outputs into electrum as per this guide.

The reason you have to do this is because Electrum went its own way with the private key format. See the release notes for 3.0.


Pushing tx to the network via AJAX, without installing bitcoin Is there any web service anywhere that allows me to push raw transactions to the network via an ajax call? Blockchain's pushtx only works if you copy/paste so I can't build around it.

Looks like the premise of this question was wrong. Blockchain.info DOES support raw transactions via ajax however you have to include ?cors=true to the end.

Note they also require application/x-www-form-urlencoded data. Here's what my request looked like in angular

$http({
    method: 'POST'
    ,url: 'https://blockchain.info/pushtx?cors=true'
    ,data: $.param({tx:txHex})
    ,headers:{
        "Content-Type":"application/x-www-form-urlencoded"
    }
})


Wallet to wallet in congested periods I have waited for nearly 24 hours for my BTC transfer to my new wallet.

Does the amount I sent fluctuate with the markets?

For example, If I send .01 BTC and while the transfer is in progress, the value of BTC goes up, will I still receive the profit when it arrives to me?

You sent X BTC, and you will eventually receive X BTC.

There is no profit or market condition involved here. You hold the same amount of BTC before and after.

You can of course choose to sell those BTC, and if the market value goes up, then yes you can sell at a higher price when expressed in another currency. But this is entirely independent from you transferring coins.


Import private key to coinbase? Is there a way to import a private key that I have been using in bitcoin-qt to my coinbase wallet?

Coinbase no longer supports any sort of wallet import (wonder why?). To quote Coinbase (June 2016 on https://support.coinbase.com/customer/en/portal/articles/2285419-how-do-i-import-an-existing-wallet-)

  Coinbase wallets currently do not support a wallet import feature. If you have paper wallets, private keys, wallet.dat files, or brain wallets, they can be imported into another wallet (Bitcoin QT, Electrum, Multibit, Armory, Blockchain.info, etc) before being sent to your Coinbase wallet.
  After you have imported your wallet, you can keep your bitcoin there, or send it to one of your Coinbase wallet addresses.


How do bitcoin exchanges commit the limit/market orders? I'm trying to understand the topic of blockchain and bitcoins as well. So, the only one question I want to get answer for: how do exchanges commit orders?
I mean, how the transaction could be started by exchange? As I understand, only the owner of wallet (with the pair of pub/private key) can start transaction for transferring some amount of btc. So, I can't find the information about "remote control" of wallet. Maybe I am wrong, please correct me.
And excuse me for my English. It's not my native language.

In general, if an exchange wants to execute a buy or sell order without asking you, the relevant Bitcoins need to be held by an address that the exchange controls. When an order executes, and Bitcoins change hands, nothing changes on the blockchain. The only thing that changes is a record internal to the exchange. It's only when you withdraw the money from the exchange that anything changes on the blockchain.


Bitcoin core verification keeps reseting I'm trying to run Bitcoin Core service with full node verification on Ubuntu on testnet and it keeps resetting. The verification increases to 0.3, then resets to 0, for 2 days already. Debug.log records look like there was a process crash, but no reason mentioned:

The server is Digital Ocean's droplet, I've already tried to increase the server CPU/RAM, no luck. Want to find the reason of what is going on here, what exactly causes such behavior.

As 0x49D1 reported: reducing the Bitcoin Core database cache helped to reduce memory usage, which caused the crashes while syncing.

In bitcoin.config dbcache=<n> or as command-line argument -dbcache=<n> where n is the database cache size in megabytes (default: 300)

Source


How do i differentiate between a scam and a real bitcoin miner? Someone offered to trade for me through bitcoin. He said i should send a bitcoin to crytomine company then he is going to claim it from the company so that he trades it with a commission of 10% of profit within 48 hours.

Bitcoin mining involves setting up and running highly specialized computer machinery called ASICs (application specific integrated circuits). If you are being told you will be 'mining', but are not setting up and running these machines yourself, then chances are you are being scammed. Pretty much every instance of 'cloud mining' through some website service is a scam.

Consider: you have an ASIC machine, that profitably prints money for you. Do you:

a) use that machine to make money? OR

b) rent the use of the machine to someone else?

If you chose b), then you must expect to make more money than a) by doing so. This extra money must come from the user that is renting the machine, which means the user renting the machine is going to lose money, net.

The reality is, mining seems complicated to new users, so scammers often pretend to run 'mining operations' when they are trying to scam people. Being a 'miner' makes the scammer seem knowledgeable and wealthy, so that new users will be lured in.

  Someone offered to trade for me through bitcoin... with a commission of 10% of profit within 48 hours.

This is the second massive red flag. No legitimate broker would promise a commission of 10% within 48 hours. Professionally managed wealth funds aim for a smaller return than that, annually!

If that sort of profit was guaranteed, the broker would quickly become the wealthiest person on earth. With $1000 invested, after 1 year of 10% returns every two days, the broker would have ~$34,156,133,221. Obviously, this is completely absurd.


What is the reasoning for Grin's high inflation rate? According to an interview with Yeastplume on What Bitcoin Did, Grin is going to have a flat reward schedule of 60 grin per block at one minute blocks. This translates to an annual inflation of 100% in the second year, 50% in the third year, 33% in the fourth year and so forth.
For comparison, many countries target around 2% inflation, which Grin will only achieve in its 51st year of operation. Even given that actual inflation of fiat currencies may be higher, Grin's high inflation seems to make it unattractive to store value in Grin for many years to come.

Has the Grin team elaborated their reasoning for choosing a reward schedule with such a high inflation?

See this page of the wiki for a brief set of reasons:
https://github.com/mimblewimble/docs/wiki/Monetary-Policy


Why is wif prefix 0x80 more than pubKeyHash prefix I forked a coin and found that whatever I put in pubKeyHash prefix, I need to add 0x80 to it, to calculate wif prefix and hence generate an address keypair, i.e address and private key corresponding to that address. If I add anything apart from 0x80, to calculate wif prefix,the private key generated doesn't correspond to that address.
Would anyone tell me the reason for the same.

0x80 is the version number for private keys. It allows a decoder to know what to do with the data it received and to check that you have entered the correct thing. Like many magic numbers in Bitcoin, it was arbitrarily chosen by Satoshi Pieter Wuille.


Block Chain length/size may one day get unwieldy to compute Is it possible that the length of the existing block chain will one day become unwieldy to compute? Would it make more sense that the chain would somehow be rolled up like normal bank ledgers do with opening balance for every account every year?

Is it possible that the length of the existing block chain will one day become unwieldy to compute?

A fully validating node, on first startup, will sync to the network by downloading and verifying the entire blockchain history. Doing so means validating every block and transaction in the blockchain history (but a node does not necessarily need store the entire history, it can opt to 'prune' old transactions that are not relevant to it, once they have been validated locally).

Right now, your 'average' PC will probably take a few days to sync. As the blockchain grows, it will take more computational time to validate the entire chain. Much work is being done to optimize these validation steps, with the goal being to maintain a low barrier of entry in terms of computational power.

Many of the important properties of Bitcoin (censorship resistance, immutability, etc)  are born of it's decentralized network of nodes, so working to ensure the largest number of users are able to run a full node is very important for maintaining a healthy network. The blockchain will continue to grow in size, so balancing this against computational resources is an important part of scaling bitcoin efficiently.

  Would it make more sense that the chain would somehow be rolled up like normal bank ledgers do with opening balance for every account every year?

Bitcoin does not use 'account balances', instead it uses an 'unspent transaction output' (UTXO) system under the hood. If I understand correctly, what you are suggesting would be to implement a 'checkpoint' that new nodes can start from.

This would mean that a new node has to place trust in the checkpoint they have received, since they will not be able to verify the authenticity of the UTXOs as being 'real bitcoins' themselves. Bitcoin is designed to be a system that can be engaged with without having to trust any other user on the network, so doing so is somewhat antithetical to its design.

If you search for 'checkpoint' on this site, you'll find some answers such as this one, which contain more info.


How can I avoid the "Amount too low" message in my wallet for payout from Cloud mining service? 1) I have a Bitcoin-wallet called "Copay" on my IOS-device
2) I have joined the cloud mining-service "Genesis mining". For trying out the service I started with 50 $ from my credit card.
3) here is a list of payments I received from them and the fees which yielded always the "Amount too low" message

11th July 2017 3,243 bits   fee 0,00044277 BTC
31st July 2017  1,750 bits   fee 0.02086374 BTC
14th August 2017 1,615 bits  fee 0.00224983 BTC

There is another transaction where I went to a bitcoin shop and bought 10 Euro in Bitcoin which gets the "Amount too low" message.

As a newbie I have some questions

1) Is there a possibility to recover any of these funds without paying fees which are high (e.g. the fee from 31st July amounts to around 100 $) ?
2) Would switching to another wallet remedy the situation
3) Is this a general problem of the Bitcoin network that the fees are rising and thus it is not suitable for transactions below 20 $ ?
4) Would there be a possibility to stop "Genesis Mining" from sending me micro transactions but instead accumulating the funds until a reasonable sum is reached ?

Sorry for having so many questions, I would be grateful for any input

Regards

Use the custom miner fee setting to lower fees.  The fee categories make no sense.  If you want a payment to be received in a day or two - faster than ACH, you should set the fee to 10 satosi per byte or so.


Are there any mining pools that allow a specified amount of bitcoins to be sent to a chosen address? This would be like using a pool as a wallet service, as you could send a subset of your balance to a retailer to purchase something and avoid running the Bitcoin client app.

Most pools only pay out the complete balance to your specified address, which makes this option unavailable.

Obviously, whether or not it's a good idea depends on how trustworthy the pool operator is, and the sum of BTC at risk.

You can use an online wallet to handle all of your Bitcoins.

The reason you don't want such an option in a pool, is that in case someone steals your password, they can drain your account. This is the reason most pools have a 24h waiting period between when you change your receiving address and being able to send any Bitcoins.

In the future someone could potentially make a joined pool and wallet service that will allow you to manage your earned Bitcoins easier, but that is not yet an option (I'm slowly working on it though;) ).


BIP91 is activated, why BIP141 is still dormant? The moment is BIP91 activated non-SegWit signaling blocks will be orphaned. Since BIP91 is now activated won't that immediately boost BIP9 to 100%? Why is it not happening?

BIP9 only describes a new deployment method of softforks to the Bitcoin network. I therefore assume that you mean the deployment of BIP141 by method of BIP9.

The deployment of segwit requires 95% of the blocks of a difficulty period to signal readiness for it by setting bit1 in the version field. Since the difficulty period was already in the middle when segwit got such levels of support, it can only lock in during the next difficulty period at the earliest. The next difficulty reset will happen on the ~28th (from the top of my head, you can check on bitcoinclock.org). If it has 95% support in the difficulty period it will then lock in on the next difficulty reset ~Aug 11th, and then activate another difficulty reset later on ~Aug 24th.


How to enumerate all blocks/transactions in order with bitcoind? Is it possible to enumerate all blocks/transactions, in order, using bitcoind API? The listsinceblock call seems to return the transactions without any ordering so assuming I get a very long list, I cannot process half of it, store last processed block hash and later ask again for transaction since that block.

Yes there is a total order over all confirmed transactions, namely the order over all the blocks by blockchain height, and internally by the order in which transactions appear in the block message. This block-internal order by the way is the same order which is also used to calculate the merkle tree root.

I would suggest calling bitcoind getblockcount to get the blockchain height. Then use bitcoind getblockhash for each block from 0 to that blockcount to retrieve each block and then traverse the tx part of the result, which should give you the transactions in the order they appear in the serialized block form (which is agreed upon by all nodes). Whether you count the block before or after its transactions is a matter of taste, but I'd suggest counting it after the transactions as they had to exist before the block was found.

So if you want to stop the process somewhere, simply remember the height of the block you last processed and the number of transactions you processed for that block, and you'll be ready to continue right where you left off.

Notice that there is no way to enumerate non-confirmed transactions, and orphan blocks. This is due to the fact that there simply is no unique ordering among them, which all nodes in the network would agree upon.


can not access via RPC to litecoin node I set up a litecoin full node in AWS. I opened ports 22, 80 and 9332. Also from my laptop I cloned this project https://github.com/janoside/btc-rpc-explorer

I executed on my local but unfortunately I don't reached my litecoin node but instead if I deploy the btc-rpc-explorer in the same litecoin node it works.

The error I got when I executed in local is the following (IP have been obfuscated)

Unhandled Rejection at: Promise Promise {
  <rejected> { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
  cause:
   { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
       at Object.exports._errnoException (util.js:1018:11)
       at exports._exceptionWithHostPort (util.js:1041:20)
       at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
     code: 'ECONNREFUSED',
     errno: 'ECONNREFUSED',
     syscall: 'connect',
     address: 'XX.XXX.XXX.XXX',
     port: 9332 },
  isOperational: true,
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: 'XX.XXX.XXX.XXX',
  port: 9332 } } reason: { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
  cause:
   { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
       at Object.exports._errnoException (util.js:1018:11)
       at exports._exceptionWithHostPort (util.js:1041:20)
       at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
     code: 'ECONNREFUSED',
     errno: 'ECONNREFUSED',
     syscall: 'connect',
     address: 'XX.XXX.XXX.XXX',
     port: 9332 },
  isOperational: true,
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: 'XX.XXX.XXX.XXX',
  port: 9332 } stack: Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
Using exchange rate: 30.3812015012 USD/Litecoin starting at Sun Jan 13 2019 22:54:28 GMT+0100 (CET)

Do you know what I need to do to access the litecoin node from my local computer using this btc-rpc-explorer project? Thanks in advance

UPDATE: command netstat -tnlpu
Return this:
command netstat -tnlup
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
udp        0      0 127.0.0.53:53           0.0.0.0:*                           -
udp        0      0 172.26.6.153:68         0.0.0.0:*                           -

And in the AWS rules I have specified to let connections from ports: 22, 80, 9332. Any idea?

I finally found how access the node from my laptop I just adding the following to the litecoin.conf file

rpcallowip=0.0.0.0/0

I saw it in this Answer


How does a wallet come to know of Address just by importing Private key? I have exported my Private key to Paper Wallet. Now, when we send/receive bitcoins, we send/receive them to an "Address". So suppose I receive some bitcoins on my address. I have the private key of this address. Now I want to spend the bitcoins I received at my address. For this I need to import my private key to some wallet. Am I right?

And even though I'm importing my private key to the wallet, how will the wallet know what is my "Address"? Because I'm just importing the Private key, not address. Is address derived from private key?

I'm confused with this.

You can derive the public key from a private key
Though, you can't derive a private key from a public key
You can derive a bitcoin address from a public key
Though, You can't derive a public key from a bitcoin address

Means:

PrivateKey -> PublicKey -> Address


Bitcoin protocol and Wireshark I captured bitcoin protocol communication in real-time and it is present in fig1 and fig2.

Fig1

In red box, there are many types of command.
First Question:

  How can Wireshark detect bitcoin communication and parse them? I think
  the packet that socket sends may have something what I don't know.

In red box of fig2, you can see many properties of packet. this is definitely defined by software program, not hardware such as router. Real data that client send is really just hex data which is encoded by specific rule.

Second Question:

  How Wireshark can parse data received? Bitcoin client can parse it because they know the rule but Wireshark doesn't know anything since Wireshark is thrid-party program, which no have any relation with Bitcoin software.

Fig2

Sorry for my English.

Someone wrote a Bitcoin protocol decoder for Wireshark, several years ago. I assume it was included in the Wireshark distribution.

Wireshark simply knows about the Bitcoin protocol. There is no magic involved.


Market orders in Cryptsy and BTC-E Looking at the dynamics of the Cryptsy and BTC-E trading engines you aren't able to place market orders.  The orders just seem to be limit orders at the best market rate.  For example, I want to buy 20 bitcoins at $700 and the best offer is $700 with 15 coin volume.  The offer should get knocked out and the remainder of 5 should be subtracted from the next best offer.

My question is why this doesn't seem to be the case with BTC-E and Cryptsy?  If your order volume at market is greater than available volume at set rate it sets up a limit order until the order is filled.

Can anyone confirm this and explain why they do it?

There's nothing a market order can do that a limit order can't do. To place a market order, just place a limit order for the amount you want to buy at the worst price you are willing to pay.


Modifying data in existing blocks NOTE: I am a Bitcoin newbie. Please excuse (and correct) any wrong terminology in this post.

Can the transaction data in an earlier block be edited? Of course, it would break the verification of the Proof-of-Work because data will not match the final block digest. However, wouldn't the original data be lost, and the link to later blocks in the chain be broken? i.e. Anybody can figure out that the block has been messed with. However, how would the correct data be retrieved?

My guess is that there are multiple copies of the blockchain. Even if the data in a block in one copy of the blockchain is corrupted, other copies of the "true" blockchain will still be "out there" and will be accepted because they would be longer (have greater difficulty score) than the broken copy.

Is that correct?

Yes, your understanding is correct.  In fact, not only are there multiple copies, there are a huge number of copies: everyone who runs a full node has a complete and validated copy of the entire block chain, which they will share with anybody over the Bitcoin peer-to-peer network on request.

In fact, if your hypothetical attacker starts sending out their corrupted block, most users won't even notice: their software will validate it, notice it's incorrect, figure there is just something wrong with the attacker's data, and request it from some other node instead.


Does Lightning Network has concept of continuous stream of value? Examples:

Car insurance: $1000 per year.
Legal consultation: $500 per hour.
Visiting a website: $100 per hour.

Assuming 1 BTC = $8000

1 hour = $100 = 0.0125 BTC = 1,250,000 sat

1 second = 1,250,000 sat / 3600 = 347.22 sat

I could generate a new invoice and pay it every second.

Continous stream of value?

I was thinking about something else:

  until further notice, please charge me 3472.22 sat per second

To avoid me going offline, there could 10 second heartbeat.

Is it overcomplicated?

Because of speed of light limit and network propagation, 1s resolution is good enough, no need for a continous stream of value.

Issuing a new invoice every second is a simple workaround and no need to overcomplicate.

Or maybe it exists natively?

EDIT / UPDATE: https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#streaming-payments

Streaming payments is not part of the lightning network protocol yet.

However you can build a lightning app that simulates exactly this. There was a demo by alekos Filini on lädt years lightning residency. Check out https://youtu.be/IlSVTir_9Ns

When AMP is coming streaming payments could be stimulated with AMP by setting up more and more routes. But that would be rather fancy.

So I guess you create an app on top of lightning to solve streaming payments


Bitcoin RIPEMD160 purpose Bitcoin uses RIPEMD160 on top of SHA256. Is its sole purpose to make public key address shorter or does it strengthen security in any way?

RIPEMD160 was designed in the open academic community and not like SHA2 by a NSA competition... one may see this as security advantage.

160bit hashes do also have less space requirements (then sha256) on the blockchain as well as in indexes, etc.


can sign derived wallet transactions with master seed phrase private key? I would like to sign a transaction from a wallet which is derived from a seed, and sign it with master seed private key, can I sign any tx of any derived wallet address after the master seed wallet?

thanks a lot.

The master private key is derived from the seed and all child private keys are derived from the master private key. Knowledge of the child private keys lets you sign transaction spending coins sent to the corresponding addresses. So yes if you have the master private key you can derive the child private keys and use those to sign any transactions related to that wallet.


Varying mempool statistics across multiple sources I understand that each node is different and will have a different mempool (and size). But in looking at https://tradeblock.com/bitcoin/ it is showing a mempool size of around 20MB (http://bitcointicker.co/networkstats/ shows similar mempool size of 20MB). But https://blockchain.info/charts/mempool-size is showing a mempool of 103MB (https://jochen-hoenicke.de/queue/#24h showing similar 100+ MB size). Neither site explains how they configure their mempool. tradeblock.com and blockchain.info are referenced from many sources - do you know what can explain this big difference in how they report mempool size? thanks

Nodes have different policy about accepting transactions to mempool. Some nodes accept all transactions, others accept only transactions with a fee greater than 10 satoshi per byte for example.

Nodes have different policy about droping transaction from mempool. Some nodes drop one-day-old transactions, other nodes drop three-days-old transactions.

Nodes have different policy - this is the answer.


What will happen if i change the checkpoint data from bitcoin source code and try to synchronice with blockchain? Suppose i have fully synchronosed bitcoin node running in my local machine and i change its checkpoints data apart from its genesis block and recompile the code. Now what will happen when i try to run the daemon, having older block data residing inside .bitcoin folder.
Is this what orphan block is?

It will think that the  databases have been corrupted and so it will attempt to redownload the entire blockchain. When it does, it will find that all of the blocks are invalid (because you changed the genesis block) and then it will just do nothing as it is unable to sync what it believes to be a valid blockchain.

  Is this what orphan block is?

No. Orphan blocks are something else entirely and unrelated.


Why is there a finite amount of bitcoin addresses and how is the range of possible addresses determined My first question is what the precise logical/theoretical reason is that there are only a fixed amount of possible bitcoin addresses. Secondly, I can generate a bitcoin address by using address(sha256("Passphrase")). If it is even possible to determine, what would be the "Passphrase" in order to calculate the first and last possible address? Is for example address(sha256(0)) the first address?

I am trying to understand how the "range" of possible addresses works or how it is bounded.

My first question is what the precise logical/theoretical reason is that there are only a fixed amount of possible bitcoin addresses.

Because physics doesn't allow us to do anything that is infinite.

But even though there are a finite number of addresses, the number of possible addresses is so large that it might as well be infinite. There's no way that we could exhaust all possible addresses; there's just too many of them.

  Secondly, I can generate a bitcoin address by using address(sha256("Passphrase")). If it is even possible to determine, what would be the "Passphrase" in order to calculate the first and last possible address?

That's not how addresses work. It's not an ordered list and addresses aren't generated in any order. Addresses are not generated by hashing some password; nor would they be ordered by that password.

Addresses are generated by hashing a public key with SHA256, then that hash with RIPEMD160. The resulting hash is then encoded with Base58 Check encoding. These hash functions are irreversible so given their output, you cannot find their input. So no, it would not be possible to find out what public key an address is the hash of given just the address.

If you really wanted to order addresses, then the first address is the Base58 check encoding of 0000000000000000000000000000000000000000 and the last address is the Base58 check encoding of ffffffffffffffffffffffffffffffffffffffff. The range of possible addresses is just the range of all possible 160 bit (20 byte) values. That is because that is the range of all possible values that RIPEMD160 can output.


Copying an old private key (from 2011) into Electrum: any risks? I have an old phone, with a version of the Bitcoin wallet from 2011.  It has a few satoshis in it, which are now worth enough to be worth recovering.  However, the phone can't connect to the Internet.

This version of the wallet apparently stores the private key in an unencrypted base58 file, which I think is therefore equivalent to the Wallet Import Format.  I have root access, so I can view any file on the system, so getting it out isn't a problem.

Would there be any risks involved in simply copying the private key into Electrum 3.0 using these instructions and then sending the contents to a more modern wallet?

From my understanding, the private key gives full access to the contents of the address, but a friend told me that given the key's age, I'd need to import it into bitcoin-qt and do a full sync in order to make sure that the address works properly.

No, Bitcoin Core (formerly known as Bitcoin-QT) is not a wallet, it is a full node software + wallet, so there are better software to use as a wallet. Sure, you can use Bitcoin Core, but you'll need to keep your Bitcoin Core connected to the internet for days to synchronize.

To summarize, you should use a wallet software (sure, Electrum!) to import (or sweep the funds of) the private key.

Note: A few satoshis is worthless. The median transaction fee is currently 110,740 satoshis. according to this.


what will happen to coins on the other fork? I've received at least one notification about a company that will/will not support the hard fork. does that mean if their side of the fork falls out of favor, I will lose any coins kept with them?
if so how should I move my coins so that they won't be lost?

Move all your coins to a wallet where the private keys are under your full control.
You should not lose the legacy BTC that you have with any service now, but you may lose the new coins if they dont support the new fork.
Once you have the coins in your private wallet, you can get the software of all the new forks aopen your original "legacy" wallet with the new software and you will have the new coins.


Hex to ASCII conversion of output scripts generates unexpected characters Embedded in this transaction, there is a blockchain file upload tool written in Python.

I'm trying to convert the hex of the output scripts to ASCII, so I can assemble it all into an actual runnable Python script. However doing a direct hex to ASCII conversion generates some unexpected characters.

For example, the third output script has the following hex:

51412c756e6865786c6966790a66726f6d20646563696d616c20696d706f727420446563696d616c0a0a6966206c656e287379732e6172677629203c20353a0a20202041207072696e74285c0a2222225c0a55736167653a202573203c66696c653e203c6465737420616464723e203c6465737420616d6f756e743e207b3c6665652d706541722d6b623e7d0a0a5365742042544352504355524c3d687474703a2f2f757365723a70617373406c6f63616c686f73743a706f72746e756d22222220252073797353ae

Using a hex to ASCII converter, it becomes this Python code:

QA,unhexlify
from decimal import Decimal

if len(sys.argv) < 5:
   A print(\
"""\
Usage: %s <file> <dest addr> <dest amount> {<fee-peAr-kb>}

Set BTCRPCURL=http://user:pass@localhost:portnum""" % sysS.

Why is the character A preceding print for no reason? As well as QA and S at the beginning and ends, respectively?

From what I've seen referenced on the Web, the third output script is meant to look like this:

,unhexlify
from decimal import Decimal

if len(sys.argv) < 5:
    print(\
"""\
Usage: %s <file> <dest addr> <dest amount> {<fee-per-kb>}
Set BTCRPCURL=http://user:pass@localhost:portnum""" % sys.

What am I missing here? I'm completely new to Bitcoin, so I'm guessing it's something obvious.

Apparently, the ASCII text is split between multiple TX output scripts, and each one is actually a multisig script with the data bytes inserted in place of the public keys.

The letters actually correspond to ASCII symbols which are the opcodes forming a multi signature script, see https://blockchain.info/tx/4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17 "Output Scripts".

Only the data between the opcodes should be treated as text if you want to decode it.


What are the limits of m and n in m-of-n multisig addresses? This method describes how to create a 2-of-3 multisig.

I heard that there is an inherent limit with the number of multisig parts, limiting them to 3.

Does the standard method described above of generating and spending multisig addresses work with more than 3 parts? What is the limit? How to work around that and create/spend larger multisigs using bitcoind (practical 'how to' would be appreciated)

We need to distinguish the limitations for validity and standardness. The first is determined by the consensus rules (which cannot change without a hard fork). The second ones are determined by local relay and mining policies implemented in the reference client, and can change from version to version.

In addition, we need to distinguish raw multisig (a simple OP_CHECKMULTISIG based script), and P2SH multisig (where the OP_CHECKMULTISIG script is only revealed upon spending).

Finally, because scripts include public keys, their sizes depend on their lengths. Both compressed (33 bytes) and uncompressed (65 bytes) keys exist, depending on which version of a wallet was used to generate them.

Raw multisig

Every m-of-n combination is valid (up to n=20), but standardness rules only allow up to n=3.

This limitation is enforced when sending (i.e., sending to a 2-of-4 multisig will not be considered standard).

P2SH multisig

validity rules require that the P2SH redeem script is at most 520 bytes. As the redeem script is [m pubkey1 pubkey2 ... n OP_CHECKMULTISIG], it follows that the length of all public keys together plus the number of public keys must not be over 517.

For compressed public keys, this means up to n=15
For uncompressed ones, up to n=7.

For standardness, it depends on the version. Up to v0.9.*, the reference client required the total spending script to be at most 500 bytes.

For compressed keys, this means m*73 + n*34 <= 496 (up to 1-of-12, 2-of-10, 3-of-8 or 4-of-6).
For uncompressed keys, this means m*73 + n*66 <= 496 (up to 1-of-6, 2-of-5, 3-of-4).

In 0.10, these standardness rules will likely be relaxed, allowing to go up to the validity limits (15-of-15 for compressed keys, 7-of-7 for uncompressed keys).

Also, for P2SH, standardness and validity restrictions are only applied when spending (as the spending script is only revealed at that time). This may mean that sending your coins to a P2SH script may make them irrecoverably lost (especially when violating a validity rule).


The scriptPubKey, decoded:

02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF

The scriptSig that spends the output, decoded:

ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE

So they're combined, which results in:

ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF

It checks a signature of zero-length OP_FALSE against the pubkey 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 Obviously, that returns false. But it doesn't actually cause an error, because CHECKSIGVERIFY wasn't used. The rest of the script executes, and finally a non-zero value is left on the stack. Therefore, the transaction is valid.

Since the transaction is now in the blockchain, other clients must understand it too.

So what was this guy doing? Beats me.


help me to understand this mining code Help me to understand this code, spend all day to understand this code, and learned python from scratch, now I understand what operators do, but still some parts are complex to me.

import hashlib, struct

ver = 2
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
time_ = 0x53058b35 # 2014-02-20 04:57:25
bits = 0x19015f53

# https://en.bitcoin.it/wiki/Difficulty
exp = bits >> 24
mant = bits & 0xffffff
target_hexstr = '%064x' % (mant * (1<<(8*(exp - 3))))
target_str = target_hexstr.decode('hex')

nonce = 0
while nonce < 0x100000000:
    header = ( struct.pack("<L", ver) + prev_block.decode('hex')[::-1] +
          mrkl_root.decode('hex')[::-1] + struct.pack("<LLL", time_, bits, nonce))
    hash = hashlib.sha256(hashlib.sha256(header).digest()).digest()
    print nonce, hash[::-1].encode('hex')
    if hash[::-1] < target_str:
        print 'success'
        break
nonce += 1

In this code does the

  prev_block
  "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"

is in SHA256 and then later it's decoded in to hexadecimal by using

  prev_block.decode('hex')[::-1]

?

I just want to create a full "header" using the data I already have.

prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"

This is simply setting a variable called "prev_block" to the hexadecimal text hash of the previous block. It could have been stored as the raw byte hash, but for ease of use it is stored as hexadecimal text.

prev_block.decode('hex')[::-1]

This converts the hexadecimal text stored in prev_block into it's binary representation as a string/array of bytes.

If you simply want to create a header then this code will accomplish that as long as you provide all the variables (ver, prev_block, mrkl_root, time_, bits, and nonce):

ver = 2
prev_block = "000000000000000117c80378b8da0e33559b5997f2ad55e2f7d18ec1975b9717"
mrkl_root = "871714dcbae6c8193a2bb9b2a69fe1c0440399f38d94b3a0f1b447275a29978a"
time_ = 0x53058b35 # 2014-02-20 04:57:25
bits = 0x19015f53
nonce = 1 # make sure to change this to the correct nonce
header = ( struct.pack("<L", ver) + prev_block.decode('hex')[::-1] +
      mrkl_root.decode('hex')[::-1] + struct.pack("<LLL", time_, bits, nonce))
print header.encode('hex')

Update

The struct.pack("<L", ver) and struct.pack("<LLL", time_, bits, nonce) calls simply use the first argument (a format string) as instructions to convert the remaining arguments to little endian (also called least significant byte or LSB) unsigned long Byte arrays more details on that here. In the latter case when three "L"'s are used that's because there are 3 integer arguments provided which we want to convert into unsigned longs.

[::-1] is used to reverse the bytes of an array (this is necessary because the hashes are stored in textual hex in reverse order from how they are stored in binary which is little endian). So if for example prev_block.decode('hex') returned the Byte values 0, 1, 2, 3 then prev_block.decode('hex')[::-1] would return Byte values 3, 2, 1, 0. More about extended slicing here.


What do I do with all my old block erupters? I'm making like nothing off these guys and am looking to use them for something else.  I guess these ASICs are designed for SHA-256 hash function based cryptocurrencies.

Try to mine Terracoin?

cryptocurrency list:
http://dustcoin.com/

I use mine in "lottery mode" as I call it.

They don't really consume too much energy, so I just let them solo mine. Big chance will turn out to be nothing, but with some luck they will ever find a block and cash in 25 BTC.

How low the chance may be, it's still a lot higher than winning the ordinary lottery and way cooler :)

EDIT: A quick calculation of your odds.

The current (2014/01/24 23:07) chance of a hash to be a winning hash is 0.0000000000000000001061272725905534506860017351925762341. Then the odds of winning each day are for one block erupter USB of 330MH/s

0.0000000000000000001061272725905534506860017351925762341 * 330*10^6 * 60*60*24 = 1 / 330480.1

So one chance in 330,480 each day or one chance in 905 a year (of course, changing difficulty has to be taken into account).

Let's take the Powerball lottery as a reference as Earlz mentions, it has odds of one in 648,975.96 to win $10,000 one in 5,153,632.65 to win $1,000,000.

So, every day you have double the chance to win 25 BTC than you have to win $10k, which is less and costs you probably a dollar or two to enter.


Taking out bitcoin from offline wallet Ok, let's say I have an offline wallet for storing my bitcoin, now I have got a good amount of bitcoin, but i don't want to take out everything from the wallet, I only want to take out a small amount, is that possible?

Yes, bitcoin is divisible to the 0.00000001 bitcoin, we call this small amount the "Satoshi" for example so even if you got less than 1 bitcoin you have a pretty wide margin on what amount you want to transfer it could be 200.0099 or 0.0005123 be careful of the fees though

For the transfer part I suggest you to use electrum

You will find more useful information about the transfer from cold to online wallet there: Can I spend/transfer bitcoins directly from cold storage?


What is the difference between node, peer and mininode in the functional test framework in Bitcoin Core? I am learning about the functional test framework in Bitcoin Core. I am seeing the terms "node", "peer" and "mininode" being used. How are these defined and how are they different?

When you run P2P functional tests you are spinning up regtest nodes (running simplified Python code) that connect to your full node (running the full C++ code) to test P2P functionality.
As John Newbery outlines here:

A node is the bitcoind instance. This is the thing whose behavior
is being tested. Each bitcoind node is managed by a Python TestNode
object which is used to start/stop the node, manage the node's data
directory, read state about the node (eg process status, log file),
and interact with the node over different interfaces.
One of the interfaces that we can use to interact with the node is the
P2P interface. Each connection to a node using this interface is
managed by a Python P2PInterface or derived object (which is owned by
the TestNode object). We can open zero, one or many P2P connections to
each bitcoind node. The node sees these connections as peers.
For historic reasons, the word mininode has been used to refer to
those P2P interface objects that we use to connect to the bitcoind
node (the code was originally taken from the 'mini-node' branch of
https://github.com/jgarzik/pynode/tree/mini-node).

However, this PR 19760 (merged in August 2020) has removed all references to mininode and so no code or current docs in the Bitcoin Core repo currently refer to mininode. Obviously previous PRs and outdated documentation outside the repo will still refer to mininode.