Future-proofing a deflationary currency from future counterfeiting Say someone locks away a wallet in durable storage for 100 years and BitCoins are still actively used.

Are those BitCoins still going to be valid if they haven't been traded in/upgraded to the newer protocols?

I've seen other answers on this site that suggest either that 1) BitCoins will need to be upgraded by a certain block (at the switching of the hash function and protocol, for example, to adapt to any discovered weaknesses) OR 2) that they will forever be valid but that future equipment might be able to steal away those bitcoins (or even generate never-before-seen ones under the older protocols).

1) Would be awful, it seems to me.  What if you miss the deadline because you're in a coma and nobody knows to keep your wallet updated?

2) Seems like a danger for a deflationary currency where the older money is easier to counterfeit AND is worth more.

Perhaps I'm just confusing matters of BitCoin, Blocks, and Wallets?

As I understand it, if the first BitCoin ever made had been squirreled away and the currency takes off as a success, the novel and deflationary nature of the currency will make the exchange value of that first BitCoin very high compared to it's initial exchange value.

Over time, weaknesses in the original hash functions may be found and counterfeiting early BitCoin may become practical.  And the reward for doing so seems to me that it would be higher than counterfeiting BitCoin of the future-present!

In the physical world, finding a buried treasure of gold or a sack of US dollars has a lot of protections against counterfeiting.  I don't know how old of a design of US dollars banks would accept, but I guess that as long as you can do a convincing show of where you found it and forgery experts examine it all different ways and it checks out, they you're entitled to trade up.  Gold is pretty easy - can't fool people for too long.

Authenticity of BitCoin is all in the math, so if the technology to forge the math is practical at any point in the assumed infinite future of technological advancements then the forgery would be undetectable.

Due to inflation, an old $20 would get you a lot more than it did today.  But then again, I'm assuming that the old $20 and the new $20 are equivalent, once the old $20's authenticity is established.  And due to deflation, a BitCoin today will get you a lot less than the equivalent BitCoin in the future.

With inflation, the standard denomination of the future might be $100s or $1,000 or $10,000 ...  so a recovered or counterfeit old $20 isn't worth much, and a sack of $10,000 bills from 1960 would be hard to explain!

With deflation, the standard denominations get smaller, so a counterfeit old BitCoin would be easy to explain and forge.

So we could require that people keep their wallets updated.  You mean if I don't keep up with my BitCoin Updates every Tuesday that my bank accounts would be wiped clean?  But that seems unacceptable to me - seems that a powerful group could do a lot of damage to a person or a population by somehow disrupting or disallowing access to their wallets.  I don't know how that would play out, but it seems plausible that a scheme could be devised if money expires like that.

There are a few things one needs to consider:

Bitcoin software is bound to change. It will be adapted to new systems, hardware, and so forth. Expecting a program from now to work 100 years from now is probably not going to happen.
Bitcoin protocol probably will change, but the change will be less drastic. For example, block size might get changed. If a protocol changes, it makes software that uses old protocol not able to properly communicate with the network.
The last part that needs to be addressed, is whether or not the way bitcoins are "stored" will change. At the moment, everything is handled using secp256k1 ECDSA algorithm. In order to spend bitcoins, one needs to sign a transaction with their private key. The exact specific of what such a transaction might look like is likely to change, but the algorithm itself is very unlikely to change unless some serious threat appears for Bitcoin. At the moment, quantum computers are a thing that might or might not brake that algorithm in the future. If that was to happen, the algorithm would be changed.

In order to be able to access one's bitcoins 100 years from now, one would need to get their hands on a piece of software from that time (pretty easy), that works with the protocol at that time (very easy), and the Bitcoin protocol must still accept ECDSA signatures or at least private keys (unknown).

Provided secp256k1 is still secure in the future, your coins will be yours to claim (unless someone adds an unlikely exception of "coins older than X years cannot be spent").


How to integrate a Bitcoin payment service in my auction site So, if I wanted to have Bitcoin as a form of method where users could pay, how would I do this? Obviously, there is paypal, where the buyer sends money through pp, which disperses to the seller. So, I need to have this type of system on my site as well. Is there anything like it for Bitcoins?

Thanks!

It depends on where your head is, and what your level of skill happens to be.

You could actually run something like BitEscrow, and integrate it into your site. Or you could run a full on copy of Bitcoind, that would do the job without a payment processor. Of course, that requires thinking about things like security, which you might not want to do.

On the other hand, you have services like Coinbase and Bitpay and Coinpayments, and others, that can take some of the risk away by offering a viable third party interface, for which they, rather than you are responsible.

It also depends on the bigger question; which is, do you want to have Bitcoins or Fiat at the end of the transaction cycle? If it were me, I would want Bitcoins, because I like Bitcoins. But your needs may be different. You very well might want dollars or euros, and that's okay too.


Beginner's question: Why must proof-of-work be useless? I wonder why the proof-of-work under no circumstances may be usable. The argument I understand is: If the proof-of-work could be used, its results could be sold, and doing the proof-of-work would cost the user nothing - or even could be valuable - and so would not restrict the usage of the service (e.g. bitcoins).
But why not use ideas from captchas of which the usage can be monetarized (e.g. by improving character recognition systems)?
Is a crypto currency system unconceivable where the user must pass the results of the proof-of-work to a central instance which can use them? (Prohibiting that the user can monetarize them on his own account.)
This would make crypto currencies much more sustainable than they currently are.

In addition to the technical factors mentioned by MCCCS, it's important to consider economical factors as well.
If the problem being solved has value outside of the Bitcoin network, it allows miners to essentially "double dip" on the rewards - they earn both from the Bitcoin received as block rewards, as well as the incentive structure off chain.
For example, if the problem being solved is character recognition, it would enable a number of companies who seek good character parsing systems, such as Google, self driving car companies, etc, to double dip. These companies are then incentivized to build a a mining farm to not only train their programs, but also use that training to earn Bitcoin, subsidizing the operation they're already doing.
Being such large companies, their primary goal is likely to have a good text recognition system - the value of Bitcoin earned is secondary. This allows them to invest much more into their mining farms, potentially outstripping other miners who do not have a dual incentive. Moreover, as they get paid twice, it is in their favour to attempt to resolve minor reorgs to build on top of their blocks - they are already subsidized via the off chain incentive, so the cost of losing a block proportional to their operating cost is much lower, allowing them to take riskier routes to resolving minor forks.
This also reduces the cost of mounting attacks - if the mining power required to launch an attack is subsidized by external incentives, it is easier to pay for and acquire.
This also changes the reward structure overall - if the majority of the earnings for a miner are from an outside source, they are less concerned with the effects of bad blocks, 51% attacks, or other bitcoin issues that drop the value of bitcoin. The risk:reward calculation for attacking the chain becomes skewed, allowing for high reward attacks to have a lower cost than in a single use system.


difference between Master Public/private Key and Public/private Key? what is difference between Master Public Key (MPK) and Public Key?
what is difference between Master Private Key and Private Key?
should I use master public key (MPK) when generating address or public key?

With "Master public key" you probably refer to deterministic key derivation after bip32.

The correct term is "Master extended private key" (acronym xpriv) and "Master extended public key" (acronym xpub).

The acronyms are "xpriv" and "xpub" because the base58 check prefix results in those 4 characters for a mainnet extended pub/priv key.

The difference between a extended public key and a normal public key is that it also contains information about the bip32 chain (deterministic chain/hierarchy).

It contains:

The depth in the hierarchy (1byte 0x00 for master nodes, 0x01 for level-1 derived keys, ....)
A fingerprint (4 bytes, possible identifier)
The chaincode (32 bytes, = link used for the hierarchy)
The child index ("number" of the key at the current hierarchy level)
The private or public key (32bytes for private-, 33bytes for public-key)

A normal private- or public-key only contains the last element (32/33byte [public|private]key).

A (simplified) example how you would generate addresses:

Take the extended master private key (m/)
Derive an account extended private key (m/0')
Take this account extended private key (m/0') and derive the first extended private key on the next level (m/0'/0).
Use the extended private key of (m/0'/0) to generate the extended public key and take out the "normal public key" (33 bytes) and encode a P2PKH address (or P2WPKH, multisig, etc.) out of it.


which indicates the correct total received bitcoins, blockchan.info or bitcoind I'm trying to see how much bitcoins I've received via bitcoind's one method, getreceivedbyaddress specifying a certain address, and after knowing the amount of bitcoins, I soon realized that such as block explorer services, blockchain.info or blockcypher indicates the different amount of bitcoins.
It's interesting that when I specified another address, both bitcoind and block explorer services indicated the same amount.

Since I'm developing a crypto exchange, I need to know a user's deposited amount of bitcoins in order to calculate how much a user has bitcoins rightly, even after letting other users withdraw their bitcoins.

So which is exactly right and reliable?

In general, I would trust my own local node over a block explorer website. If you’re running an exchange you should be running a node, or more likely several nodes on isolated machines, this will allow you to interact with the network without trusting any other person or service to provide you with honest information. You will need to build a system to resolve deposits, based on the info supplied by your node(s).

Relevant point: bitcoin does not keep track of ‘account balances’, rather the system tracked ‘unspent outputs (UTXOs). To find the balance for an address, a block explorer would need to sum all current UTXOs associated with that address.

So the source of error may come from how a particular block explorer performs this operation. Blockchain.info, for example, will report the sum of all inputs that have ever paid to a certain address. So if you had 0.1 btc, and you repeatedly spent it back to the same address 30 times, blockchain.info would probably report it as 3btc received (lifetime). This may be an interesting stat, but it isn’t necessarily relevant to your issue of resolving customer deposits.


Capabilities of Bitcoins and their place in the future I`ve recently read a presentation that mentioned a couple things about how big would be the potential bandwidth if Bitcoins would handle the transaction volume of Visa:

http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011

It stated, that storing all Visa transactions would take about 1TB of storage per week. This certainly limits the feasibility of using the Bitcoin protocol as an alternative to existing payment processors. Are there any plausible concepts of what part of the economy Bitcoins might be capable of replacing entirely, and which would be harder or impossible to substitute with 'coins?

We are a long way away from VISA scale transaction volume (>4K transactions per second) however there are some methods for Bitcoin to deal with the data on that scale

Remote blockchain. In the current implementation of the mainline client, every client downloads and store a complete copy of the blockchain.  This is the best way to boostsrap the bitcoin network while transaction volume is low.  However at peak transaction volume most users will have no interest in downloading and storing terrabytes worth of data.  In the future if a client trusts an online entity they could query transactions against that entity rahter than store the block chain locally.  Obivously this requires a level of trust so it would be important to choose a trustworth "block chain provider" however it has the advantage of each client only needing to query transactions they are interested in (for example client could ask for all transactions involving a particular address (to get current balance) or number of confirms for a particular transactions (to update the confirmation status). Before someone cries "centralization" there would be no official blockchain provider but instead numerous independent entities offering this as a service (either paid or free). If someone is paranoid they could use/build a client which queries two different block chain providers to ensure they return same data.  Lastly if a person is sufficiently concerned about security they could trust no-one and compute the entire blockchain themselves.

GPU Acceleration of transaction verification.
GPU are currently used to find a hash to sign the block as this is cryptographically intensive and any performance increase pays huge dividends.  This isn't true for transaction verification as transaction volume is low.  As a result the bitcoind uses non-openCL CPU calculations to verify transactions.  If necessary an Open-CL GPU powered client would be able to verify significantly higher transaction volume.

A rough estimation of future computation power required.  The paper linked by author indicates it would take a modern CPU can only handle ~100 tps (transactions per second). For integer math (like used in cryptographic hashing) a high end GPU is (as of writing) roughly 20x as powerful as a high end CPU. That allows in the ballpark of ~2000 peak tps per GPU.  Furthermore even with say 50% annual transaction volume growth we are two decades away from VISA level transaction volume.  Moore's law would indicate that average CPU/GPU in 20 years would be roughly 1000x as powerful.  That would be on the range of 100,000 tps per CPU and 2 mil tps per GPU in 20 years. Even if growth in computational power slows as long as it isn't slower than the growth in transaction volume it will ensure that all transactions can be verified by off the shelf hardware.

Actual transaction volumes.
Bitcoin is digital cash.  Many people today chose not to use cash for online and offline transactions favoring instead indirect payment methods (check, debit card, credit card, gift card, etc).  It is probable that higher level payments systems built on top of bitcoin network will emerge.  Users of these systems should cause significantly lower transaction volume.  For an example lets look at how VISA transactions work.  An individual may have 200 VISA transactions in a month but only makes a single payment to the card issuer (a 200:1 multiplier between purchases and actual currency movement).  Likewise a company may have a thousands of VISA transactions in a day but recives that as a single currency payment (usually ACH).  Another thing to consider is "VISA level" is more an end game scenario.  A more likely interim goal (say over next 2 decades) would be a "PayPal level transaction volume" which despite being a modest 100 tps (vs VISA >4K tps) would indicate Bitcoin is a massive success.


Why is the address 1MAdS7aPszWG4EYgBpbF9mnGUi5ChbMu8d sending me Bitcoins? I'm receiving 1 satoshi today from an odd address. This account has been very consistent in creating spammy transactions that distribute 1 satoshi to a lot of account. Any one know what's going on with it?

This is spam. Point                          .


Why the system does not try to optimize and put maximum number of transactions in blocks? If the reward to add a block is the same, why the system does not try to optimize and put maximum number of transactions in it? I saw an example block where there was only one transaction in it.

Since we are getting one block roughly every 10 minutes, is this a major concern for the efficiency of the system?

There is no single 'system' that can be optimized, there are hundreds of miners running different software to mine. The bitcoin protocol have incentives in place to maximize the number of transactions per block, like the fees charged by each transaction. But they are not mandatory.

Only the miners could answer for what they did what they did. But possible reasons are:

An internet connection outage that prevent them to receive new transactions to be mined.
A bug in the mining software.
Disregard for the low value of the fees present in transactions at that moment
Use of ASIC-boost or some other optimization that favors small blocks.


Will there be a point in the future where moving bitcoins to a new address will make them safer? OP_SCHNORRCHECKSIG:
Exploring Schnorr Signatures as an
Alternative to ECDSA for Bitcoin

I've noticed (e.g., the above article) that newer forms of encryption are being researched and developed for use in bitcoin. Is it possible that moving bitcoins to a new address using new encryption will make those stored bitcoins less likely to be lost than keeping them where they currently are?

Will there be a point in the future where moving bitcoins to a new address will make them safer?

That is already the case.

Using a 2-of-2 multisig address (with keys separated) is safer against theft than a normal P2PKH.
Using a 1-of-2 multisig address (with keys separated) is safer against accidental loss than a normal P2PKH.

If native P2WSH segwit addresses get deployed in the future (with 256-bit script hashes, instead of 160-bit P2SH script hashes), we'll also get a way that is more secure against exhaustive collision searches.

  I am noticing (e.g. the above article) that newer forms of encryption are being researched and developed for use in bitcoin.

I believe the term you're looking for is digital signatures rather than encryption. While some cryptographic algorithms (notably, RSA) can be used for both encryption and digital signing, this is an exception rather than a rule. Bitcoin's authentication used in its script system is currently based on ECDSA, which cannot be used for encryption. The only places in Bitcoin where encryption is used is locally in wallets for password protection, and possibly on the P2P protocol if BIP151 gets adopted. If one of these is actually what you're asking about, I misunderstood the question.

The linked paper suggests the use of Elliptic Curve Schnorr signatures, something I've been working on myself as well. They have various advantages, one of which is a theoretical proof for its security. ECDSA does not have this, though it's not considered to be an issue in practice.

What Schnorr mostly helps with is privacy and compactness. The most interesting idea is signature aggregation, which would allow us to combine all signatures in a transaction - whether they are from multisig, multiple inputs or whatever - into just a single one.

Regardless, the answer to your question is absolutely yes. In particular, if we'd ever want Bitcoin to remain safe in the presence of sufficiently powerful general-purpose quantum computers, we'll need to switch from elliptic curve cryptography to post-quantum cryptography, which uses entirely different private keys, public keys, and signatures, and thus addresses.


Hashing Transactions for Mining After reading that Mining involves Taking a root hash of a transaction and combining that hash with a nonce it is required to find a number that is equal or below the given target, i was wondering if you have to try different orders of hashing the transactions or you just hash them all at once. For example does it make a difference if i hash a transaction A first and then transaction B or B first and then A.

Yes, the order matters. Changing the order of bytes of data being hashed will result in a different hash. Thus changing the order of transactions for the merkle root will also result in a different merkle root. There is no requirement that miners try different orders of transactions. But they may choose to do that instead of re-selecting transactions for the block. Note that transaction order does matter (coinbase must come first, parents must come before children, etc.) so a miner cannot try all possible permutations of transactions.


Mastering Bitcoin: Advanced Scripting Question At the end of Mastering Bitcoin Chapter 7. https://github.com/bitcoinbook/bitcoinbook/blob/second_edition/ch07.asciidoc#complex-script-example

They ask this question in regards to the script:

How do the partners "reset" the clock every 29 or 89 days to prevent the lawyer from accessing the funds?

Does anyone have a good explanation for this? I feel like I missed something in the timelock section that might have explained this but I'm not seeing it.

They 'reset' the clock by moving the funds to a new output before the period ends.


How to restore the original mnemonics from shares? I just read that an original mnemonic can be split into parts, I am a little confused about how the system can restore the original mnemonic from these mnemonic pieces.
example i have mnemonic
radar warm pizza grief worth attack van ribbon milk surface guitar bachelor

and then i split and get 5 shares mnemonic
1. demise reopen sort defy forward gorilla live cannon scan large thing action
2. arch peasant act box try install indicate organ tourist hungry biology thought
3. gun win grace exhaust movie sail cable news bundle glide bright minimum
4. load sunny bicycle dragon ghost sort turtle buzz orbit slender bargain photo
5. recipe snake submit gentle squirrel tattoo boy penalty sail summer tongue dove

The three 3 shares that I combined, turned out to be really the original mnemonic. but here I have a question. If I only remember 2 of the 5 mnemonic shares, can I recover my original mnemonic? if possible please show me how?
thank you

You can select what subset of the shares are enough to reconstruct the original secret. That's why it's called m of n. So set m to 2 and n to 5 and you have what you need.
If you haven't done this before splitting the secret then 2 shares will not be enough.


How to tax trading in colored coins representing fiat? Say Kraken and Bitstamp both issue colored coins for USD, called KrakenDollars and BitStampDollars. Then I find an colored coins exchange where I can trade between the two, and deposit some KrakenDollars. In the eyes of the IRS, these are still dollars I think. Then I start trading between KrakenDollars and BitStampDollars, and make a respectable profit. Then I put my KrakenDollars back into Kraken, and withdraw to my bank account. How on earth should that be taxed? I was just trading between dollars and dollars...

You trade a bunch of stuff, you wind up with more dollars than you started with, you have a taxable profit.


Bitcoin difficulty: One block with very high difficulty vs. long chain with accumulated difficulty First assume the hypothetical scenario, that someone has infinite hashing power, starts with the genesis block and mines one block, that has higher difficulty than the whole "normal" blockchain accumulated. Let's call this one-block blockchain (B) and the regular one (A). Would this be the new "real" blockchain with only 50 BTC in circulation? To extend the question, secondly assume our attacker splits their hash power to mine a whole blockchain with similar length to the current one but higher accumulated difficulty, how would we know if it's the real blockchain? All non-fake transactions are in Blockchain (A).
There is no concept of time in the blockchain, but everyone on the planet would know that (A) is the real blockchain because it had been used for so long. Is there some mechanism to prevent this, some kind of sanity check?

that has higher difficulty than the whole "normal" blockchain accumulated.

That's not possible. The difficulty of a block is solely a function of the timestamps of the blocks in its history. It does not depend on the block itself, it cannot be chosen by the miner, and isn't dependent on how low the hash is. The only thing that matters is if the hash is low enough or not to meet the difficulty target. The difficulty can go up at most 4x, and that happens only when the past 2015 blocks took less than 3.5 days.
In general, if there are two chains and both are otherwise valid, the one with the highest accumulated difficulty will win. There is nothing to protect against here, (short) reorgs are a fact of life, and long ones cannot be prevented. The economic assumptions underlying proof-of-work imply that no attacker will want to pay the cost for such a deep reorg. If that happens to be wrong, we should move to something else.


How to query sender address from copay? I have transaction ID and some other data in my disposal when I am on first screen on Copay wallet. I need to show in transaction details originating address for transfer to my wallet.

Is there some API endpoint I can hit in bitpay API ?

copay didn't provide this information for the transaction. It can be retrieved from other APIs.


Multi-signature and "pay to script hash" vs "pay to pub key hash" If I understand correctly, there are two methods to perform a multi-signature transactions in Bitcoin. One is "pay to pub key hash", which is a method commonly used to send standard single signature transactions. The other is "pay to script hash", as specified in BIP 16.

If you use "Pay to pub key hash" , any senders to the multisig address need to specify all the public keys involved in the multisig address, which can be cumbersome. If you use "pay to script hash" , the sender only needs to know the hash of the script , which is equivalent to the length of a single bitcoin address.  Obviously, "pay to script hash" fits better with the various infrastructure already setup around the standard transaction.

Are there any other advantages or disadvantages between the two methods?

Sorry, my English is poor, I'll try to explain. Feel free to comment and ask.

First, terminology. There are no "pay to pub key hash msig txs". There are

bare multisig outputs
p2sh outputs

In bare multisig output i create a list on [N] pubkeys and choose [M]. The output script will look like [push M] [push key1] [push key2]... [push keyN] [push N] [checkmultisig]

Every person can check this set. If he has [M] keys he will be able to redeem this output. If he has less than [M] keys he will be able to partially sign the redeem transaction and pass it to another person (this passing step can not be done within bitcoin network, because nodes do not relay partially signed transactions). When the transaction gains at least [M] signatures it can be mined. Have a look to https://gist.github.com/gavinandresen/3966071

p2sh gives more functionality. I can write my own redeem script and calculate its checksum. To redeem p2sh output you should know the script itself (blockchain contains only the hash of it) and you should create scriptSig for it. Usually p2sh outputs used for multisig transactions, but there are exceptions. https://bitcointalk.org/index.php?topic=293382.0

Update:
One more useful link: What are multi-signature transactions?


Are hacked bitcoins spendable? 700,000 BTC were stolen from MTGox. So are they actually spendable by the hacker or are they now just lost to the world? I can understand wallets being encrypted, but why aren't individual BTC encrypted with the owners private key so that a stolen BTC is worthless unless the owner unencrypts it first?

Your question indicates certain misconceptions about what Bitcoin is. I would advice you to take an afternoon to read the Bitcoin whitepaper, learn from other sources and understand as much as possible. It is possible to know what Bitcoins truly are without great technical knowledge. (Bitcoin transactions can only be made with the owner's private key. A "theft" usually means performing a transaction towards a thief's address, by manipulation of software or persons or obtaining other people's private keys.)

They can be spent just like any other Bitcoin. The only thing is that you can trace every Bitcoin, and therefore know it has been partially stolen Bitcoin. This is called "Taint".

A tainted Bitcoin could be considered less valuable as it would not be accepted everywhere and spending them at "legal" institutions would give a lead towards the thief. Buying stolen goods is illegal in most countries, stolen Bitcoin would count too.

If the Bitcoin community agrees on no longer accepting stolen coins they could even become practically worthless, the risk of arrest for theft and the low value or spendability of coins would be complicating.

The problem is that "theft" is a political issue, just like ownership. Some nations might not consider a hack a theft, and certain Bitcoiners definitely think so too ;). Who would be the judge in discriminating a stolen from an unstolen Bitcoin?

Then there's the fact that someone might have accepted Bitcoins not knowing they were stolen, or even whom they're really from. Or accepting them before it was decided they were stolen. Similarly to counterfeit money. This means that Bitcoins once stolen, are not per definition "stolen" or "illegally accepted" now. Certain Bitcoin laundry services are available to attempt to disturb the usual tracebility.

Overall I would say that a thief would have to be very careful not to expose him/her self. An effective laundry service could help him/her with that. But the coin is still the coin, and can still be spent.

Please let me know if this answered your question. Comment if you are unsure of something.


Is it true that a bitcoin transaction can go unverified and eventually get dropped by the system? I have attempted to transfer 0.5BTC from my personal wallet to Coinbase and it's been 5 days since I initiated the transfer. It is still pending. I started reading about this and learned that there is no guarantee in the bitcoin system to actually have any particular transaction verified. The transaction volume is high right now and transactions with higher fees get higher priority. And transactions with low fees get low priority and may not EVER get verified (or mined) before being dropped from the system. Is this true? That's a huge flaw in the system if it is. how can any kind of commerce happen with this "feature"?

Transactions with low fees get low priority and may not EVER get verified (or mined) before being dropped from the system. Is this true?

Yes.  However they can be resent, potentially with a higher fee.

  That's a huge flaw in the system if it is.

Matter of opinion.

  How can any kind of commerce happen with this "feature"?

You have to think about things a little differently.  Sending the transaction isn't the end of the story; confirmation is.  The sender has to be responsible for monitoring the progress of the transaction until it is confirmed, and to be willing to either increase the fee or eventually give up on the transaction as no longer economical.  Likewise, the recipient needs to not assume that a transaction is final as soon as it's sent; instead, they have to wait until it is confirmed before shipping goods or services.  Escrow services can help with this, playing a role similar to that of a credit card company.

I think everyone wishes the situation were simpler and that we had a system where nobody had to wait to have their transactions confirmed.  But we don't yet have such a system, and there doesn't seem to be any obvious design that would solve this problem while remaining scalable, decentralized, and reasonably easy to transition.  In the meantime, however, despite your concerns, an awful lot of commerce can and does happen with Bitcoin as it is.  People consider the limitations and adapt accordingly.

  I am beholden to some god-like entities (miners) for my transaction to be verified, then how is this better than central banks?

Miners aren't centralized.  Anyone who buys appropriate hardware can be a miner.  So there are lots of miners competing to confirm your transaction, and you can expect that it will be confirmed just as long as you offer enough of a fee.  With a central bank or credit card company, they can block your transaction for non-economic reasons: you come from a country they don't like, your credit rating isn't good enough, etc, etc.  In that case you might not be able to make a transaction at all, or you might have to pay more than other people receiving similar service.

In other words, transaction confirmation isn't necessarily designed to be cheap or fast, but it is designed to be fair.


How can I generate SegWit addresses from a mnemonic using python? So, I have written a script that generates BIP39 mnemonics. I now want to generate N native SegWit public keys from this mnemonic.
I have found this, but it generates legacy addresses. It uses the module bip32utils.
def bip39(mnemonic_words):
    mobj = mnemonic.Mnemonic("english")
    seed = mobj.to_seed(mnemonic_words)

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

    return {
        'mnemonic_words': mnemonic_words,
        'addr': bip32_child_key_obj.Address(),
        'publickey': binascii.hexlify(bip32_child_key_obj.PublicKey()).decode(),
        'privatekey': bip32_child_key_obj.WalletImportFormat(),
        'coin': 'BTC'
    }

if __name__ == '__main__':
    seed = 'input display smile visa surround learn solar hero vacuum parrot cigar devote'
    pprint.pprint(bip39(seed))

I assume I need bip44utils or something, but it doesn't exists. I have tried looking at bip-utils but I can't work out how to convert my mnemonic to an address.
Does anyone know how I can convert a mnemonic to a SegWit address (in a way that I can change the derivation path to get multiple addresses)?
EDIT (SOLVED):
I found bitcoinlib can do this.
from bitcoinlib.wallets import Wallet

passphrase = 'input display smile visa surround learn solar hero vacuum parrot cigar devote'

w = Wallet.create("Wallet1", witness_type='segwit', keys=passphrase, network='bitcoin')
WalletKeys = (w.get_keys(number_of_keys=10))

for k in WalletKeys:
    print(k.address)

And now it works just as I wanted it to.

If you just need a command line, you can try pip3 install btc-address-dump.
Here is an example:
$ btc_address_dump "olympic wine chicken argue unaware bundle tunnel grid spider slot spell need"
mnemonic = olympic wine chicken argue unaware bundle tunnel grid spider slot spell need
private key (hex) = c7ac679b56f50bfd54dd924fe45a8dca7a1c2dced254b03dac22afc03adb9127
private key (WIF) = 5KLDyKtrScLYsKMJzVCt8Mf6Nn9DEV7V3fg8njfSZnqe7ZEMqzK
private key (WIF compressed) = L3urFcPsE2yHf5zeQjVSfUB8j8FEzX5cnmhjNsJfqjKgowPP4tmg
public key (uncompressed) = 044cd0aaeca3b636078583408e75edd77307b5190ca7a48bb9fbc1f2576c17dff1087190d91e26af594e3f8ecd3f4d3596c03c45d3b235da916903c930c6593cc4
public key (compressed) = 024cd0aaeca3b636078583408e75edd77307b5190ca7a48bb9fbc1f2576c17dff1
legacy address (p2pkh uncompressed) = 1Q5RqZctfcNkTPad2tuJSREByd2gB8xs63
legacy address (p2pkh compressed) = 12W36tm2jnreFiYdrzfE6cvRaKRbicEpnA
p2sh-segwit address (p2sh p2wpkh) = 3AzXxVUqdzvzEqVmdtmeVqRwc98uqwyh76
bech32 address (p2wpkh) = bc1qzp6lz6zy9p7k68r0a7lzfpkdxvj3yapynzuatt


What is the limit on the number of "transactions" you can make inside one "sendmany" call/transaction? https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/sendmany/
What is the limit on the number of "transactions" you can make inside one "sendmany" call/transaction? 10? 50? 500? Thousands? Tens of thousands? Unlimited?
What happens if that (presumed, undocumented) limit is reached? Will the client not allow it or will it allow it and then sit there in limbo forever or for a long time?

A standard transaction may use up to 400,000 weight units (=100,000 vbytes). Every transaction must have at least one input and at least one output. It is possible to perform multiple payments in one transaction by adding several outputs that each pay one recipient. This is often referred to as payment batching. Usually, a change output is used to return the remaining funds to the sender's wallet.

Let's assume that the sender is using the most blockspace efficient output format, Pay to Witness Public Key Hash (single-sig native segwit). A P2WPKH input weighs 68 vB, and each P2WPKH output weighs 31 vB. A transaction must have a header that tracks the meta information of the transaction. For a segwit transaction, the header weighs 10.5 vB.
The maximum number of payments in one transaction can therefore be calculated with:
(limit - header_size - input_size - change_output_size) / output_size

(100,000 - 10.5 - 68 - 31) / 31 = 99,890.5 / 31 = 3,222.27

A pure P2WPKH transaction with a single input can therefore perform 3,222 payments, or 3,223 when it does not need a change output. If the transaction uses more inputs, the number of possible payments decreases accordingly.
I would expect that this limit is not usually reached in practice. I don't know for sure whether Bitcoin Core would allow you to create a non-standard transaction with sendmany, but I'd expect that it would allow it. I guess one could check in the source code if one would expect the limit actually to actually be met.


Am I getting charged extra? I bought bitcoin on coinbase. I was charged the network fee, I understand. Then I had to transfer my purchase to electrum wallet. I was charged again. Am I doing something wrong??

Transaction fee's are a requirement whenever transferring Bitcoin on-chain. This is part of the reward that keeps miners mining bitcoin (the other reward is of course solving blocks and generating new coins). It is possible to set your own transaction fee/reward but the lower the fee the lower your chances that your transfer will be verified (miner including your transaction their block) and vice versa.

Most exchanges and wallets set standard fee's which pretty much guarantee verification at a reasonable rate. You can view most of their rates in the help section. Off chain transactions occur when a specific provider (or agreement between different providers) exchange Bitcoins and keep the record of the exchange between themselves (most likely a SQL database) and off the public chain.


Send Bitcoins back where they came from How do I send Bitcoins back to the person that sent me them without asking that person for a address without querying a block explorer?

I already know that (given that the person has his own wallet and doesn't use a shared wallet service) I can look up the transaction with its txid on a block explorer and just use one of the source addresses, but can I do it without needing a block explorer, directly with bitcoind API calls?

So called "block chain based refund" is not reliable with bitcoin.

The sending wallet may be a shared web wallet (blockchain.info, MtGox, e.g. any web site) and thus you cannot guarantee that any of change addresses in the transaction are controlled by the user. Even by exploring the block chain and knowing from which address the bitcoins arrived and where unspent change went, it is not guaranteed that if you make a refund to any of these addresses the sender receives the payment.

Instead, all refunds must be handled off-band and the refund bitcoin address must be asked separately.

E.g. SatoshiDice includes the following disclaimer (players basically must use a desktop wallet where the wallet software generates a change address and the wallet is not shared with other users):

  IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from. If you're not sure, test by sending a bet for the minimum amount. If you get nothing back, then your wallet is not compatible. Note that some bets may require one confirmation before the win/loss value is sent back.

A just-dice.com FAQ regarding shared web wallet.

In the case you still want to pursuit change-address based refund you might find these links useful

https://bitcoin.stackexchange.com/a/9152/5464
https://bitcoin.stackexchange.com/a/5982/5464
https://bitcointalk.org/index.php?topic=138752.msg1481892#msg1481892

Here is some more info (I have written this down some time ago, but I have not verified whether this is still valid):

Your bitcoind must run in a special: Since bitcoind/Bitcoin-qt 0.8, no transaction index is kept anymore by default, as it is not necessary for validation in the new database model. Instead, there is only a database of unspent transaction outputs, which has enough information to (slowly) locate transactions in block files. getrawtransaction uses this, but it only works for transactions that are not yet spent in the block chain. If you want to be able to look up historical transactions, you need to set the txindex=1 configuration option (or start with the -txindex command line flag). As this setting can only be set when the database is created, you'll need to rebuild it from scratch (using -reindex).


Aborted escrow transaction I know that multisig (n of i) transactions provide a decentralised escrow mechanism. Let's say we have a 2 of 3 address. What happens if funds are sent to the multi-sig address and say the seller is hit by a bus before posting the adorable Hello Kitty™ mug that you bought?

Does the 3rd party simply sign a transaction returning the coins to the buyer?

What about the general case of an address where n == i? Are the coins lost?

What happens if funds are sent to the multi-sig address and say the seller is hit by a bus before posting the adorable Hello Kitty™ mug that you bought?
Does the 3rd party simply sign a transaction returning the coins to the buyer?

Yes, if your address has a public key for 3 users, and you have problems receiving your goods, you can ask the arbitrator to sign review the situation and maybe create a transaction which pays you the money in the address. You sign, he signs, you get a refund. It's at the whim of the arbitrator.

What about the general case of an address where n == i? Are the coins lost?

Yes, if anyone loses their key, and the address requires same number of sigs as public keys, you cannot recover the funds.


electrum windows client, standalone executable versus windows installer From the download page, http://electrum.org/download.html

What is the difference between the two windows versions? standalone executable and the windows installer version?
What are the advantages and disadvantages of each, and how should I choose which one I should use?

The Windows Installer will install the executable in "Program Files", create shortcuts and other registry entries. The Standalone Executable is exactly that, just an executable to run the Electrum program.
Benefits of Windows Installer would be ease-of-use for those most familiar with installed programs, plus it will be available to multiple users (whether that is desired or not, is another question). Benefit of Standalone is don't create registry entires (cleaner) and don't require raised privileges (as not installing globally).

In either case - user-specific data will be saved in C:\Users\USERNAME\AppData\Roaming\Electrum

There are some more details in this blog post


Same seed from Electrum but generate different Bitcoin addresses I am using Electrum 3.2.2, I have the wallet file generated from Electrum and a password to decrypt the file. There is an error whenever I am trying to send Bitcoin out of that wallet, so I decide to create a new wallet with the same seed.

But with the same seed and same Electrum client version, the Bitcoin addresses in both wallets are completely different, and there is no balance in the newly create wallet.

I have tried to directly import the private key instead of seed to a new wallet, but I am getting a different Bitcoin address as well.

In case there is a solution for the error I mentioned before, here is the message I get:

  error: {'message': 'the transaction was rejected by network
  rules.\n\n16: mandatory-script-verify-flag-failed (Script failed an
  OP_EQUALVERIFY
  operation)\n[010000000299e8fae8016f8a522bae07139c8a25e7aba82f363c3ef67481686f72f796b90d060000006a4730440220474f74cddda1f944b71f73d919ad78752176ca3335ecc5fc081ca531e5a69f9b022079efdc804841f96ccd2e80625d0c88e04ce1c4f2edf720448c0d84b4bf6a25d00121028fe4be5e66fa6ec8701a372d91d94fb5a07e133e4c91c57d1af07678dc29a228fdffffff04bd4f7d392e23482b650cf8824fa147fe0dc286177c5a2d3e1d5c32a33cfb21010000006a473044022023fcd70a5a4ee29c57a63884337ff3a5482537610d43aabf1d87093b19f7dde3022077245d5409e01eb7045e9b436c2a7455de9eed9e03296f9bea5290af85a1a8b90121028fe4be5e66fa6ec8701a372d91d94fb5a07e133e4c91c57d1af07678dc29a228fdffffff02b6040100000000001976a9140bdc1d5780d7c5544fec545a29e306f19115662588aca037a0000000000017a914882dd5029d788855b32e3656c1aa96ba4c3488e787403b0800]',
  'code': 1}

Edit: I have tried to validate the private key I get from Electrum on bitaddress.org, apparently the private key does not match my previous wallet address, there might be some issue with my old wallet file.

Edit2:

I have tried to sign message with the address, but failed to verify with the same wallet file under same Electrum client.
After exporting the seed, and using the seed on a newly created wallet, both the old wallet and new wallet show the same master public key, but with entirely different addresses list.
Moving the wallet file to another computer, using the latest Electrum and decrypt the file shows the same old addresses, but the transaction error persist.

The issue might be with the wallet file. I was using Electrum 3.1.3 to generate the wallet several months ago. I might have used an infected client to generate the wallet file.

Edit3: Forget to mention that I am using portable version of Electrum all this time, and it seems to be vulnerable to attack.

At the time of me generating the wallet, my computer is only one month old, not a laptop, and the windows os is directly downloaded from Microsoft and is still unactivated. No anti-virus installed, no suspicious programs or files ever downloaded, and has never noticed any weird activity happening in my computer. So, the chance of being infected is very low.

I believe I am using the official portable Electrum from electrum.org, the wallet file might be modified at the time I generate it.

The problem is properly that you have a different account number because you said that you are using addresses starts with 1 (standard) so Purpose path is 44 and it's Bitcoins so coin path is correct (0)

You have to check that you are using the same account index while you importing the seed.

On your seed path try to increase account number by one and import your seed until you get your coins.

m/44'/0'/0'/0
m/44'/0'/1'/0


LN Payment Channels: Can you have more than two nodes in a channel? I can't seem to find an answer to this but apologies if this exists somewhere already.

From the last paragraph of section 2.0 in the lightning network paper version 0.5.9.2, "Micropayment channels create a relationship between two parties".

However the staked coins for the channel are held in a multisig address, and those addresses can have more than 2 signatures, max 20 signatures I believe, so can a lightning channel be set up that would be able to resemble more of a traffic circle than a 2 lane highway?

Theoretically you are correct. However maintaining and operating the channel would become much more complex as everybody has to exchange signatures with everyone. Also the penalty case in case someone breaches the protocol is not clear. Unless we switch to eltoo channels as described in https://www.blockstream.com/eltoo.pdf I doubt that the lightning network will see multiparty channels.


How can I create a list of X richest bitcoin addresses? I have looked around, but I can't find the code related directly to my question. I want to create a list in any format that contains the all accounts with balance over 0 for example. Thanks ahead for any help.

Have an up-to-date blockchain in ~/.bitcoin
Download and compile blockparser.
Run ./parser allBalances >allBalances.txt


Unable to install MultiBit 64bit version How do I install the 64 bit version of MultiBit? I downloaded the MultiBit client that is supposed to be compatible with 32 bit & 64 bit but when I run the program it give an error message that says that the program is incompatible with the current version of Windows that it is being run under. How do I get the MultiBit client to run in 64 bit?

This can be caused by the multibit.exe executable not being able to find the 64 bit version of Java.
There is some discussion about it on the MultiBit issues database here:
https://github.com/jim618/multibit/issues/376

tl;dr If you install the 32 bit bit Oracle Java runtime MultiBit should find and use that.


How much time in average does it take for an simple PC to create block? Let's say I have simple computer (CPU- Intel i7 for example), and I start mining blocks in the bitcoin network. How much time in average does it take to create 1 block? (1 per week? 1 per month? 1 per 3 month? ....)

And if the answer is 1 per month or something like that, why not all the world participate in the mining process? it seems like an easy money to earn ...
And that's why I think that I missed something in my knowledge

Thanks in advance!

The answer is constantly changing, but this is something you can calculate yourself.

Look up the current Bitcoin difficulty value.  Right now it is 460,769,358,091.  Let's use scientific notation: 4.6e11.
The difficulty determines the average number of hashes needed to mine one block.  A minimum difficulty of 1 corresponds to 2^32 = 4.3e9 hashes, so we need an average of 4.6e11 * 4.3e9 = 2.0e21 hashes to mine a block.  (More precisely, each hash performed has a probability of 1 in 2.0e21 of successfully creating a block.)
Look up the approximate hash rate for the hardware you have in mind.  For CPUs and GPUs there is a table here; ASIC devices can be found here.  According to that table, a Core i7 2600 CPU can do 23.9 MHash per second, or 2.3e7 hashes per second.  Maybe you are starting to see the problem.
2.0e21 / 2.3e7 = 8.7e13.  That is the average number of seconds your computer will need to mine one block.  It is about 2.7 million years.

This should give you a sense as to why all Bitcoin mining is now done with specialized ASIC hardware, which is many orders of magnitude faster and more energy-efficient.


If the economy was based on bitcoin, how would someone go about getting a loan? In today's society, people often take out loans from banks. In an economy that was run on bitcoins, how would someone go about getting a loan? I do not understand how this would work with Bitcoin's deflationary model. It seems a loan would be creating a short on bitcoins which could be very harmful with the value of bitcoins increasing.

Loans are possible in a deflationary environment.  Currently bitcoins is too volatile (which has nothing to do with deflation) to make lending viable.  For the purpose of answering the question I will assume that in the future volatility is either low or easily hedges.

The interest in a loan comes from 4 components:

Opportunity Cost.  Instead of giving you a loan I could do something else productive with the money.  If I could get a 10% ROI on my money by installing a new air-conditioner that will factor into the interest I change.  It would be a loss to loan money to you at less than 10% (after adjusting for the other risks) as I would "earn" more by taking the 10% ROI.
Inflation risk.  If money is worth 5% less in one year I will want to be paid 5% more even on a no risk no profit loan.  Thus inflation contributes to the overall interest charged.  Deflation would subtract from the overall interest charged.
Default risk.  If you don't pay me I lose money.  In the long run I need to collect interest equivalent to % of amount loaned that is lost due to defaults.  If I project I will lose on average 10% of amount loaned and charge 11% interest then I would break even.  Note: real world calculations are more complex because one may collect some revenue even from loans that default and may receive collateral, or sell defaulted loan for some recovery.  Still default risk needs to be included in the price of the loan.
Delayed Consumption.  By giving you a loan (even if priced to exactly break even) I am delaying my ability to use my money today.  I can't use it until repaid thus I will charge a premium for the time I lose waiting for repayment (sometimes called time value).  Thus even if all other costs/risks are 0% there will be some interest charged otherwise I might as well just keep the money in a can.

Interest is the "cost" of money.  Of the four components that contribute to that cost only one of them is related to inflation/deflation.  If in the long term all other factor were equal (which is unlikely), the USD had 3% inflation rate, and BTC had a 2% deflation rate one would be expect interest rates in BTC to be ~5% lower.


Why do nodes trust other nodes to approve their transactions? I know that the blockchain technology works so well, because everybody has basically a copy of the last ledger.
Therefore, if a transaction happens, everybody inside the network has to "approve" the transaction to do it.
These other participants are then seen as trusted sources.
However, what makes them into trusted sources? Let's say there are only three participants, two make a transaction and one has to decide if the transaction is acceptable or not (does the clearing). What makes him a trusted source?
Are these thoughts right or where am I wrong?
I appreciate your replies!

I know that the blockchain technologie works so well, because
  everybody has basically a copy of the last ledger.

Yes, every full bitcoin node has a copy of the blockchain (aka ledger).

  Therefore, if a transaction happens, everybody inside the network has
  to "approve" the transaction to do it.

Correct, every transaction is propagated to all bitcoin nodes and it is validated by each one of them. Some of those nodes also do mining and they will include this transaction to a block. If they mine the block successfully (before any others mine their blocks successfully) they propagate their block to all the other bitcoin nodes which validate the block and all the transactions within. Thus, transactions are validated a second time.

  These other participants are then seen as trusted sources.

  However, what makes them to trusted sources. Let`s say there are only
  three participants, two make a transaction and one has to decide if
  the transaction is ok or not(does the clearing). What makes him a
  trusted source?

No one is considered a trusted source. Bitcoin enables trustless transactions. If we have 1000 bitcoin nodes in the network and user A makes a transaction that sends some coins to user B all 1000 bitcoin nodes will validate the transaction. Then, when the mined block is propagated all 1000 nodes will validate it again. Note, that users A and B may or may not run a full bitcoin node themselves.

Hopefully, that clarifies things a bit.


Error: Unknown network starting a bcoin node Getting an error Unknown Network running a bcoin node, but I'm not sure what's causing it since I'm defining the network very quickly.

Error Message:

(node:10579) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Unknown network.
(node:10579) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Here is the bcoin script

var bcoin = require('bcoin').set('testnet');

(async () => {
  var full = new bcoin.node.FullNode({
    network: bcoin.network.get().toString(),
    httpPort: 18332,
    httpHost: '127.0.0.1',
    bip37: true,
    listen: true,
    passphrase: "secret",
    logLevel: "info",
    loader: require
  });

  if (!full.config.bool('no-wallet') && !full.has('walletdb')) {
    const plugin = require('/Users/<user>/Projects/bcoin/lib/wallet/plugin');
    full.use(plugin);
  }
  await full.open();

  setUpWalletWatcher(full.pool, full.walletdb);
  await full.connect();
  await full.http.open();

  full.startSync();

})();

bcoin.network.get().toString()

returns main which is not a valid network string, it should be one of mainnet testnet simnet or regtest.


In the sourcecode, what does this line mean that recovers the key from the signature? I understand that the public key (Q) can be extracted from a signature (r,s), but I'm having trouble understanding this line:

if (!key.Recover(hash, &vchSig[1], (vchSig[0] - 27) & ~4))

The third variable is called "rec" and must 0 through 3.

What is the purpose of this parameter (3rd one)?
Why is the signature starting a byte1 and not [0]?  Perhaps I'm not properly understanding "where" r and s is located in the Bitcoin signature.

By any chance is the signature format encapsulated in any standard? PKCS..? etc.

It's a custom format that encodes both a signature, and a parameter that allows the public key to be reconstructed from it.

Given a signature (an (r,s) pair), and the message it signs, there can be up to 4 different public keys for which it is valid. To know which one, the number is encoded along the signature.

The first byte is this recovery parameter plus 27. If the corresponding public key is to be a compressed one, 4 is added. The next 32 bytes encode r. The last 32 bytes encode s.

Note that this format is only used for message signatures. The scheme used for transaction signatures is older, doesn't support recovery, and uses DER encoding.


Converting from Private Key to WIF, what am i missing? They say a image speaks louder then 1000 words so:

As you can see from the image above, this should work ?
What am i missing here?

This is my encode function,
http://cryptocoinjs.com/modules/currency/coinstring/

I can confirm the private key spitted out is in correct format for if i do a dump i get:

$ ./src/d-cli dumpprivkey WRSybD94sWugjAQ89zyvbLsnw76ovCYEGo
BxkN86fdFBN75Aat3WCDs9w6NRHCMJJvvrDgb44Vcc23f96ohFZ5

The issue as suggest by Andrew was in the encode function.
After using https://www.npmjs.com/package/wif everything worked perfectly as intended.


Create a new receiving address in the behalf of another wallet? I want to create an API service that will trigger my local wallet to generate new account with receive address and return that address to a user.

User => API => my_local_wallet => API => User

The user will have this address and will be able to transfer Bitcoins into that address.

Yes, you can use bitcoin-cli for address generation.

To learn more try:

  bitcoin-cli help getnewaddress

Also consider using some RESTful service running on your Bitcoind host.

For Node I can recommend https://www.npmjs.com/package/bitcoin-core


BIP 47: Bob's first receive address? I'm trying to create Bob's first receive (ephemeral) address according to the BIP 47 spec after the Notification Transaction has taken place, which I believe to be:

  141fi7TY3h936vRUKh1qfUZr8rSBuYbVBK

according to these test vectors. I have been unable to calculate the correct ephemeral public key (B') corresponding to this address via:

B' = B + sG

or the correct private key (b') for the ephemeral address via:

b' = b + s

The variables I have come up with so far for this first address include:

// Alice selects the 0th private key derived from her payment code:
a = 8d6a8ecd8ee5e0042ad0cb56e3a971c760b5145c3917a8e7beaf0ed92d7a520c

// Alice selects the next unused public key derived from Bob's payment code,
// starting from zero:
B = 024ce8e3b04ea205ff49f529950616c3db615b1e37753858cc60c1ce64d17e2ad8

// Alice calculates a secret point:
S = 03f5bb84706ee366052471e6139e6a9a969d586e5fe6471a9b96c3d8caefe86fef

// Alice calculates a scalar shared secret using the x value of S:
// x value = f5bb84706ee366052471e6139e6a9a969d586e5fe6471a9b96c3d8caefe86fef
// SHA256(x value)
s = d24366e662da47c0cccca4cc2d2d817af54e4d21039c0cc4fc441624efe273f7

// s multiplied by generator point
sG = 0283850c6835576554261fbab5845a099638859528b2725455e6a48e7566415c02

// Alice uses the scalar shared secret to calculate the ephemeral public key
// used to generate the P2PKH address for this transaction:
B' = 0344b4795e48df097bd87e6cf87a70e4f0c30b2d847b6e34cddde64af10296952d

// Bob's first private key
b = 04448fd1be0c9c13a5ca0b530e464b619dc091b299b98c5cab9978b32b4a1b8b

b' = d687f6b820e6e3d47296b01f3b73ccdc930eded39d559921a7dd8ed81b2c8f82

Are any of these variables incorrect, and if so, how are the correct ones obtained?

Felix Engelmann and I sat down tonight and we used bx via libbitcoin. We have been able to produce the address from the test vector and exactly your intermediate results

a='8d6a8ecd8ee5e0042ad0cb56e3a971c760b5145c3917a8e7beaf0ed92d7a520c'
B='024ce8e3b04ea205ff49f529950616c3db615b1e37753858cc60c1ce64d17e2ad8'
S=$(bx ec-multiply $B $a)
echo $S
> 03f5bb84706ee366052471e6139e6a9a969d586e5fe6471a9b96c3d8caefe86fef

s=$(bx sha256 'f5bb84706ee366052471e6139e6a9a969d586e5fe6471a9b96c3d8caefe86fef')
echo $s
> d24366e662da47c0cccca4cc2d2d817af54e4d21039c0cc4fc441624efe273f7

sG=$(bx ec-to-public $s)
echo $sG
> 0283850c6835576554261fbab5845a099638859528b2725455e6a48e7566415c02

B_prime=$(bx ec-add $B $s)
echo $B_prime
> 0344b4795e48df097bd87e6cf87a70e4f0c30b2d847b6e34cddde64af10296952d

addr=$(bx ec-to-address -v 0 $B_prime)
echo $addr
> 141fi7TY3h936vRUKh1qfUZr8rSBuYbVBK

Note that our value for B_prime was
0344b4795e48df097bd87e6cf87a70e4f0c30b2d847b6e34cddde64af10296952d as you suggested. Actually encoding it to a Bitcoin address seemed a little bit tricky as without passing -v 0 it would use a testnet address. Maybe you have a similar problem while using Bitcoin core? I don't know the API though for transforming a pub key / ec point to an Adress in Bitcoin core out of my head.

Anyway I think you did everything correctly and you just did a mistake in encoding the P2PKH address.


Difference between PoW and BFT What is the difference PoW algorithms (as used in Bitcoind) and BFT (used for instance in Libra) ?

They really don't have any similarities, so I'm not sure that there's much point in comparing them or talking about their differences. If you understand what PoW is and what it does and you understand BFT algorithms and what they do, there's no much else to know.

Both algorithms are algorithms designed to get eventual agreement on how to make forward progress in systems that can make forward progress in more than one valid way where agreement on which way to go forward is needed for the system to be useful.

PoW algorithms are slow and expensive and don't provide any actual finality but eventually provide practical finality. They're vulnerable to majority attacks and require honest participants to actually spend, on a continuous basis, to protect the network more than any attacker is willing to spend to harm it.

PoW algorithms are dangerous on blockchains that have non-native tokens. For example, Ethereum's security comes from PoW and the value of its native token, Eth. But it also has an ERC-20 ecosystem of non-native tokens. Things get scary if the value of Eth doesn't remain high enough to keep this ecosystem secure. Ethereum is a secure platform to build DeFi on so long as all these DeFi projects together don't get too valuable for Eth to secure.

BFT algorithms are fast and cheap and can provide actual finality. You get to choose who you trust, rather than having to trust whoever has money and cheap power as you have to do with PoW algorithms.

One very important thing to understand about Libra is that it cannot possibly ever be decentralized. Whatever legal entities control the assets that back Libra are parties without which the Libra currency will lose its value. That means that for any proposed hard fork, those custodians get to decide which side of the fork keeps the economic value. Because any rules change can be imposed by a hard fork, that means that the custodians get to choose the rules, period. That means no real decentralization ever, period.

Suppose, for example, that someone proposes adding respect for a government-provided censorship list to Libra. If the custodians say that they will issue and redeem on the censorship side of the hard fork, then that's it. The censorship wins, and it doesn't matter what anyone else wants or says. The censorship side of the fork will have the backing which is what gives Libra its value. By design, Libra cannot ever possibly be decentralized so long as it is backed.


Can Segregated Witness function in an Emergent Consensus environment? Same as subject. I've been finding it difficult to find any discussion on the current Emergent Consensus implementation and theory, but I have seen reservations.

Does it adversely impact the viability of the current Segregated Witness implementation?

Although I've been bombarded with polarization on these topics, I haven't concluded that they are mutually exclusive.

Technically, there is no reason why the two protocol upgrades couldn't be added to a blockchain in combination. Obviously, they would have to be amended for compatibility in their treatment of blockweight/blocksize. The perceived incompatibility mostly stems from the radically opposed visions the two developer teams appear to have regarding the scaling roadmap of Bitcoin.

SegWit was especially engineered to provide a capacity increase in a way that does not require a hard fork. Many of its proponents appear to expect a hardfork to permanently split the Bitcoin network.

The Emergent Consensus proponents on the other hand appear to take the position that hardforks are preferable to softforks or at least perceive them as much less risky.

Neither of the teams appears to perceive the other proposal as a priority for inclusion into the codebase. A bridge proposal was provided by means of the "BitcoinEC" client that patched the Emergent Consensus feature on top of Bitcoin Core 0.14 which doesn't appear to be maintained anymore though.


Given N addresses, Is there any way to know how many address are linked to a single entity? Let's assume that we have N wallet addresses - Addr1, Addr2,.... AddrN, Is there any way to know how many of these addresses are owned by a single entity on the considerations that there's no direct or Indirect transaction links between any of these accounts and all of them are making transactions independently.

There is no clear way to do this.

Chain analysis techniques exist that can attempt to identify relations between addresses based on transaction patterns. However, these are not guaranteed to work and often miss relationships or result in false positives.

This "feature" is why it is recommended to use addresses only once, since it is hard to link multiple addresses to a single owner.


How to use bitcoinj to transfer btc from p2sh-p2wpkh I wrote the code for transmitting btc from p2sh-p2wpkh based on the information I found, but when I tried to broadcast the original transaction in https://live.blockcypher.com/btc-testnet/pushtx/, an exception occurred and the exception message was :
Error validating transaction: Error running script for input 0 referencing
f6ff7b391590c3c161f012e7313c9bd7379846a209219a4722cb8864190466ae at 0: Script was NOT verified successfully..

This is my broadcast data:
01000000000101ae6604196488cb22479a2109a2469837d79b3c31e712f061c1c39015397bfff600000000160014208a8852a3cec93382c8bebbbd6c9ef4676f5120ffffffff02a08601000000000017a9141f396a0c4994cae1820224bb249a21de3ad4e73287acfd13000000000017a91466e9ecd8e67b63a4022f0420f772a070fa7d6e608702483045022100f3e5b7483760ff764b5a7620ba341499ec41c5b2fd67917bfef233b547f6e5e7022071b3f96e9c1d271b723f161a7a0aeafddef16aeb053fe2b443c0e4d31a785a7a012103ca65ac405e0ea1b514c61b797035674a27457fea63a8972cd473eef05871247400000000

I have checked a lot of information, but I can't find the problem. I hope to get help!
The test method I executed:
https://github.com/lingting/VirtualCurrency/blob/0.3.4/src/test/java/live/lingting/virtual/currency/omni/Transfer.java#L387
I signed the p2sh-p2wpkh address processing code:
https://github.com/lingting/VirtualCurrency/blob/0.3.4/src/main/java/live/lingting/virtual/currency/service/impl/BtcOmniServiceImpl.java#L414
// Custom redemption script
Script redeemScript = new ScriptBuilder().smallNum(0).data(keys.get(0).getPubKeyHash()).build();
TransactionSignature signature;
signature = tx.calculateWitnessSignature(inputIndex, key, redeemScript, txIn.getValue(), SigHash.ALL,false);
txIn.setScriptSig(redeemScript);
// p2sh-p2wpkh 设置 witness
txIn.setWitness(TransactionWitness.redeemP2WPKH(signature, keys.get(0)));

solved
Script redeemScript = ScriptBuilder.createP2WPKHOutputScript(key);

Script witnessScript = ScriptBuilder.createP2PKHOutputScript(key);

TransactionSignature signature = tx.calculateWitnessSignature(inputIndex, key, witnessScript, txIn.getValue(), SigHash.ALL,
        false);

txIn.setWitness(TransactionWitness.redeemP2WPKH(signature, key));
txIn.setScriptSig(new ScriptBuilder().data(redeemScript.getProgram()).build());


How to verify the signature of a raw transaction I know there are many tools to check an ecdsa signature of a bitcoin transaction and I understand the ecdsa algorithm. It takes three inputs, a hash of the transaction, the digital signature and the public key of the sender.

In a raw transaction such as this one:
http://blockexplorer.com/rawtx/9b4912711de5e258a74a529227f43647bc3b2304212fb508c5f8e910d5986270

I know the signature is the first line of the Scriptsig and the public key is the second and I assumed that the hash of the transaction is the first line on the page (also in the URL) but they don't validade and I've tried a handful of transactions from blockexplorer.

My question is, what do I take as the first variable to validate a transaction in that form?

See How to calculate a hash of a Tx? .  The hash that serves as the ID of the transaction is not the same hash that is used for signing.


Is price volatility necessarily a bad thing? Discussions of BitCoin as the potential basis for a future global monetary system often point to the currency's price volatility as a shortcoming. Fiat currencies, by comparison, are (mostly) a lot less volatile. My question is whether an economy that relies on a low-volatility currency is actually preferable to one that is agnostic to currency volatility. The latter strikes me as more robust.

Volatility has two sides of course, an upside (commodity or currency increasing in purchasing power) and a downside (decreasing).

When you invest in something as a store of value, you're always going to appreciate when it gains value as you hold it and dislike when it loses value.

Before you invest (EG, you have another money you're about to use to purchase it) you like when the price comes down so that you can get more of it (with the expectation of going back up again once you have it) and you dislike when the price shoots up prior to your purchase.

It is always a bad idea to price loans and contracts in a volatile currency, however. Since each party would be in a position to hope for an opposite swing direction, one party would always be inconvenienced by a change in value. Since loans and contracts are designed to offer joint utility, you don't want one party suffering or resenting the other party for their perceived unjust lucky gains: people would just avoid such contracts instead.

Today it is common to price items in USD then allow for spot payment in Bitcoin, for example, or to loan out money or establish contracts denominated in USD with sides paid by Bitcoin spot value. EG, I borrow $100usd from you today when Bitcoin is, say $100usd/BTC so you give me 1BTC. I pay you back later $110usd (principal + interest) but Bitcoin is in a dip when the contract matures so at $90usd/BTC I have to pay you back 1.222BTC.

And finally, while it is nice that Bitcoin appears to be on a long term up-trend, it's shorter-term volatility makes investments and contracts that can't hold out for the duration required to "get to the moon" much riskier and more difficult. Most Bitcoin-related business (including merchants, arbitrage, obtaining BTC and then holding to pay off payroll or suppliers and avoid paying multiple interchange fees) require maintaining balances in BTC over time and those balances may ebb or flow. Again, if you receive BTC on a rise (customer pays you; hey they get to choose the timing!) and have to pay it during a dip (regular payroll, running lower on parts than you can afford to wait for an upswing) then you are experiencing a significant capitol loss.


Are there any complete Bitcoin systems? It seems to me that to keep Bitcoin both decentralized and secure, the whole of the Bitcoin process should ultimately depend on each user, or rather, that the involvement of each user should incorporate all aspects i.e. mining, full nodes, wallets, and exchanging.  Perhaps this is too much to think about at this stage, or maybe I simply have not found this, but is there any product or community that is focused on empowering individuals with simple systems that incorporate ALL of these aspects, and may I dare say, while being itself decentralized?

No, not to my knowledge. Also, it doesn’t make sense to me to want to incorporate all these different aspects into one device.

Mining devices need to run continuously and produce a lot of noise and heat. They also need to be replaced eventually, as they get obsoleted by better technology. As such, they are most cost efficient if they just focus on the mining algorithm.

While full nodes also run continuously, they can run on fairly small machines more suited to quieter environments. They run more complicated software than the miners and need to have software updates frequently, while the hardware can last.

You don’t want wallets that store large amounts to run all the time, as that increases the exposure to potential theft. Wallets for daily spending tend to be thin wallets which will catch up with the network quickly whenever you need them to, which also is beneficial for running them on small devices that you can carry around.

Decentralized exchanges are even harder. In a way, these are covered by mobile wallets in that they allow users to meet up and trade directly. The challenge with decentralized exchange systems is the interfacing with fiat currencies. I don’t think there is a widely popular solution yet, and it doesn’t appear likely that a majority should be running any such solution.


sendrawtransaction creates hash but does not propogate to the network I'm on testnet, I've created a raw tx and I'm using bitcoind. I've confirmed that the hex is formed correctly and signrawtransaction returns complete:true.

After I've run bitcoind sendrawtransaction raw_tx I get a hash returned, however when I look at http://blockexplorer.com the hash cannot be found.

I'm definitely on testnet.

Can anyone suggest any ideas?

When using sendrawtransaction if the hash is generated but not propagated, then first I would assume that bitcoind retry mechanism will eventually send to the network.

On build 8.99 the transaction will go through, AcceptToMemoryPool. Which will validate the tx. So unless you see error TX rejected 22, which could be anything, as the validation is not yet reported. Then it's safe to assume you just need to wait.


How does difficulty impact profitability? what is the formula? I have an Antminer S9 ASIC miner , and I have visited this , but I want to know how difficulty may impact my profitability in the future. I would also like to estimate break even costs.

Source: http://bitcoin.sipa.be/speed-lin.png

The difficulty growth has been slowing down over the years, but in the last year it still has about quintupled.

Source: http://bitcoin.sipa.be/growth-10k.png

The general formula for calculating profitability is elaborated on How much Bitcoin will I mine right now with hardware X?.


Why did bech32 define a new base32 encoding scheme rather than use an existing one? There are multiple existing base32 encodings (RFC 3548/4648, z-base-32, Crockford's etc). Why did bech32 define a new one rather than use an existing one?

There are multiple aspects to the design of bech32. There is the choice of character set (i.e. which characters are included in the 32 options and which characters are excluded because they visually look like other characters e.g. 1 because it looks like l), the mapping of specific bits to this character set, the type of checksum to use and the final address structure.
BIP 173 explains the choice of character set.

The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

The mapping of bits to bech32 characters is also included in the BIP.
e.g. 11 maps to t (3 on x axis and +8 on y axis) and 30 maps to 7 (6 on x axis and +24 on y axis)

Note that although 1 is included in bech32 addresses as a separator (see here) the character 1 is not included in the permitted character set of bech32. Nothing maps to 1 in this mapping.
Pieter Wuille explained the rationale for this bit to character mapping at SF Bitcoin Devs in March 2017:

The reason for this is we were able to select our code to optimize for low bit error rates. Wouldn’t it be great if we could choose the character set in such a way that 1 bit errors are more likely than non 1 bit errors. This character set is the result of another year of CPU time to optimize for this. We found a bunch of information on tables for similarity between various characters. What you can see on this slide, the z and the 2 are considered similar in some fonts or writing. As you can see they are 8 apart. One is 2 and the other is 10 so they are 1 bit apart. And r and t are 1 bit apart. And y and v are 1 bit apart. And x and k are 1 bit apart. And e and a are 1 bit apart. And s and 5 are 1 bit apart. And 4 and h are 1 bit apart. There are way more similar errors overlaid in this data that you can look for. It’s pretty cool. We made a character set that optimizes for 1 bit errors. As a result our code is distance 6 for 1 bit errors. If you just look at these 1 bit errors we guarantee 5 errors. If you only make errors like this you can detect 5.


Power Off Dash Miners for Short Time on P2Pool I've been DASH ASIC mining (3 miners) for about 1.5 months. I have accounts with the NiceHash and SuprNova pools. I switched to the P2Pool (peer-to-peer pool) method just this evening.

I have typically powered my miners off for about 2-3 minutes per night to make recordings for another activity of mine. I am assuming that as long as I leave my P2Pool program running and simply power my miners off for a short time, I should be fine.

This got me thinking about other needs for the future. When I eventually reconfigure my setup, update my server, update it's OS, or move my mining to a new location, I am guessing that if I setup my P2Pool programs and config file the same way, and start everything back up, I should be fine.

I just want to confirm that these assumptions are correct. If not, what's the best procedure for when you do need to do the above things?

Mine as long as possible, turn off only when needed.  I haven't check Dash P2Pool, but most payouts use some form of PPLNS (Pay Per Last N Shares) payout (although some have different methods to calculate it), so the longer you're offline, the lower the payout will be if you hit a block (since your %age of the submitted shares will be lower).

This is intended to stop people "pool hopping" (when your pool hits a block or gets super lucky, you jump to a pool that is due to find one or particularly unlucky at that point in time, if you're lucky you can get both rewards.  As you're paid depending on how many shares you've submitted, then you're not going to get paid as much because your work on the new pool is low, so it disincentivises that behaviour.

It's technically fine to stop mining for a few minutes, no harm to the machines (although heating them up and cooling down too often could pose a problem with components etc, but it's unlikely to be a big issue).

If you want to regularly turn them off, or for extended periods, then I'd advise sticking with something like NiceHash, since they use PPS (Pay Per Share), so any work you do is paid (although their fees may be higher).

Someone can correct me if I'm wrong, but stopping P2Pool and starting it shouldn't be a problem, I don't know how it stores it's statistics, but if it's a local version then it doesn't matter anyway, since you're the only one on that node.


When miners are working on their block, does everybody's block have the same transactions in them? On Bitcoin-Wiki's page about Blocks, it says that "Bitcoin transactions are broadcast to the network by the sender, and all peers trying to solve blocks collect the transaction records and add them to the block they're working to solve.".

So, do all peers have the same transactions in their blocks at all times?

Miners will naturally be inclined to include those transactions in their blocks that give them high transaction fees (though exceptions exist), because apart from the block reward from coinbase transaction, those are the only incentives for miners. So, whatever transactions have reached a miner through the network, her choices will be restricted among those transactions. At a particular time instance, different miners most likely have different snapshots of transactions available to them. So, the answer is no (with very very high probability).


What stopping miner from altering value in transaction to increase transaction fee? I'm learning bitcoin through this book "Mastering Bitcoin, 2nd Edition by Andreas M. Antonopoulos". I'm at Chapter 6 "Transactions".
Here is my doubt:
Example there is node A, received transaction like this below

{
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
      "vout": 0,
      "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01500000,
      "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
    },
    {
      "value": 0.08450000,
      "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
    }
  ]
}

So here transaction fee is: 0.0005 ( 0.1(input) - 0.015(vout[0]) - 0.0845(vout[1]) ).

So what if node A that received this transaction altered the transaction like this:

{
      "version": 1,
      "locktime": 0,
      "vin": [
        {
          "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
          "vout": 0,
          "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.01500000,
          "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
        },
        {
          "value": 0.07450000,
          "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
        }
      ]
}

Now the transaction fee is: 0.0105 ( 0.1(input) - 0.015(vout[0]) - 0.0745(vout[1]) )

What If node A after altering the transaction, able to find the nonce and submit the block to the other nodes.

Other nodes trying to validate this block will checks the UTXO set and signature by the owner found it's a valid block and accepts it to the chain.

Sender can't deny because that transaction has his signature.

In the book it's mentioned that transactions can happen in unsecured network, what if someone altered the transaction values in the middle going through this unsecured network like I mentioned above, now every node gets this altered transaction.

My Question, is this possible or there any further checks happen to ensure the transaction values are the valid ones sent by owner. So far what I learned (till Chapter 6) there is no hashing of values or whole transaction just owner signature.

The signature signs the spending transaction(*). Modifying it in any way will invalidate the signatures in it.

(*) Not actually, as it's obviously impossible for the signature to sign itself. There are also means for a signature to indicate it explicitly does not sign certain parts of the transaction, permitting those to be modified after the fact.


C-lightning lightningd crashing To run a lightning node I followed the instructions here: https://medium.com/@dougvk/run-your-own-mainnet-lightning-node-2d2eab628a8b except that I downloaded and installed bitcoind and lightningd from source and not in a docker. I can fund my on-chain wallet, connect to peers but when I try to open a channel the daemon crashes, with the following message in crash.log:

+61107.734361005 lightningd(30005):BROKEN: wallet_channel_save: UPDATE channels SET  fundingkey_remote=?,  revocation_basepoint_remote=?,  payment_basepoint_remote=?,  htlc_basepoint_remote=?,  delayed_payment_basepoint_remote=?,  per_commit_remote=?,  old_per_commit_remote=?,  local_feerate_per_kw=?,  remote_feerate_per_kw=?,  channel_config_remote=? WHERE id=?: no such column: local_feerate_per_kw
+61108.166336903 lightningd(30005):BROKEN: FATAL SIGNAL 6 RECEIVED

What does local feerate per kw mean? To set the tx fee of bitcoind I followed the instruction from the blog post:
bitcoin-cli settxfee 0.0004

Thanks!

It appears that the database schema update was not successful. Meaning the database is not in a known good state. I'd suggest closing any open channels, withdrawing all funds from this node into an external wallet, moving the database (or the entire .lightning directory) and then restarting the client to create a fresh database.

This version is also really old, so the issue has most likely been addressed in the meantime.


Is it possible to derive bitcoin adress from blockchain.com id? so here is the situation: my friend lost password to his "blockchain.com" wallet. He opened it in 2015 approx. And asked me to help get access again to it. He even doesn't remember are the funds in it. He had 3 blockchain.com accounts. To one of them he collected bitcoins from faucet freebitco.in
we have email and blockchain id (which is sent to email). support does not help.
so the question is: Is it possible to derive bitcoin adress from blockchain.com id? so we could check are there bitcoins in it and know is it worth of finding password to it or just for fun to that he lost to access to n number of bitcoins)

No. The Blockchain.com ID is simply a random ID number that points to an encrypted copy of your wallet. Their support will not be able to help you find the addresses or gain access to the wallet even if they wanted to.
Unfortunately, if you've lost your password and your recovery key, and you can't find any backup copies of them, you're probably out of luck.


Is the BCH version of Schnorr signatures compatible with taproot? BCH is going to introduce support for Schnorr signatures on May 15th. One of the most anticipated features for Schnorr signatures on Bitcoin is the introduction of taproot constructions. Will it be possible to use Taproot on BCH after the upcoming fork?

No, it will not be possible to use Taproot on BCH after the hard fork. Taproot requires additional script constructions and interpretations of stack elements which the Schnorr signature algorithm by itself cannot provide. The BCH hard fork merely changes the signature algorithm for specific kinds of OP_CHECKSIG and OP_CHECKDATASIG outputs. No other changes related to scripts or the interpretation of stack elements is done.


How can I export all my private keys using bitcoind? I know that PyWallet has a -dumpwallet but without using pywallet, how can I export all the addresses and privatekeys with the stock bitcoind?

Is there an API command that lists all addresses held by the wallet?

You could send the dumpprivkey JSON-RPC call to the client.  It takes a single parameter of BitcoinAddress to reveal the private key for that specific address.

To export all private keys for all addresses, you would have to call listreceivedbyaddress to list the addresses and then call dumpprivkey for each.

See:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


What are we trying to predict in fee estimation and why? There are different estimations used in wallets, explorers and other Bitcoin projects. For example: estimatesmartfee in Bitcoin Core
This is the fee rate distribution right now according to https://btc.bitaps.com

Are different estimations misleading and affect the way fees are used in Bitcoin transactions? Will it be better if we just share mempool stats and user can decide the fee rate accordingly?
If I compare this with BTCUSD orderbook on any exchange, are we trying to estimate at what price buy order will get filled in certain time? Does that make sense?

In Bitcoin, block space is the supply, fee bidding to get the transaction included in a block is demand, miners are sellers who will fill the limit orders however they can include any transactions (not necessary it will be prioritized based on fee rate) so what exactly are we trying to estimate and why?
Market buy orders that fill the sell orders on exchanges can be compared to a transaction using fee rate 310 sat/vByte when highest bid in mempool is 300 sat/vByte. Although things are not instant in Bitcoin and there is a time gap between broadcasting with a certain fee rate and transaction being included in block. There are few other differences like if I try to buy 0.01 BTC right now on Bitfinex at 70,000 it will be executed at 53,450 and in Bitcoin there is no such thing, you can decide any fee rate and even if I use 1000 sat/vByte right now, same will be used and accepted by miners unless there is something that avoids such errors in wallet being used but overall picture looks similar and all this makes estimation even more difficult.
I consider it misleading because lot of users think a transaction with fee rate 1-5 sat/vByte will be included in 1 week or maybe a transaction with X sat/VByte will be included in Y time which is not true. User decide the fee rate and can do bidding, transaction will be included based on demand, supply and miners.
Will it be better if the wallets used this approach?

Show mempool stats
Leave the fee rate for user to decide
RBF every transaction and follow different algorithms for automated bidding

A simple algorithm for automated bidding can be:

What are we trying to predict in fee estimation and why?

Different Bitcoin projects try to predict fee rates for improving UX because its not easier for every user to understand all the technical things involved, look at different charts and decide a fee rate for the transaction.

Are different estimations misleading and affect the way fees are used in Bitcoin transactions? Will it be better if we just share mempool stats and user can decide the fee rate accordingly?

Some fee estimations maybe misleading but not everything. And they are only estimates which does not guarantee the transaction to be confirmed. Mempool stats can be shared in the wallets and most of the wallets already provide option to enter fee rate manually.

If I compare this with BTCUSD orderbook on any exchange, are we trying to estimate at what price buy order will get filled in certain time? Does that make sense?

There are few differences between BTCUSD market and Bitcoin fee market which are shared below.
Fee rates used for bitcoin transactions increase during the bull market and stay low in bear market.

BTCUSD follows cycles which are mentioned as bull and bear above.

The difference in two charts above is BTCUSD making new highs in every bull market and considered as a store of value in long term following logarithmic regression, whereas fee rates chart looks like sine wave and reset to 1 sat/vByte often.

Fee rates used in bitcoin transaction are lower during weekends because of less demand for block space however there can be exceptions and its not necessary that fee rates will always stay low during weekends. The amount of decrease in fee rates during weekends and fee market post weekend also varies. An example with weekends highlighted in last one month:

Other things that affect the fee rates used are technical:

Segwit usage: https://transactionfee.info/charts/payments-spending-segwit/
Batching: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb
UTXO Consolidation: https://bitcoinops.org/en/xapo-utxo-consolidation/
Fee estimation used in different wallets: https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72
Coin selection algorithms used in different wallets: https://iohk.io/en/blog/posts/2018/07/03/self-organisation-in-coin-selection/
Layer 2 usage: https://bitcoinkpis.com/layer2
Exchanges: https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/

Taproot will be added to this list once its activated and being used by different Bitcoin projects.

Will it be better if the wallets used this approach?

Show mempool stats
Leave the fee rate for user to decide
RBF every transaction and follow different algorithms for automated bidding
A simple algorithm for automated bidding can be: https://i.stack.imgur.com/1SlPv.png

RBF algorithms for automated fee bidding can be tried and users should also manually prefer to use RBF for most of the transactions.
ZmnSCPxj shared few exceptions on bitcoin dev mailing list which should be handled while creating such algorithms:

Again, a race condition can occur --- while the wallet is feebumping a new transaction that includes the new output, a random miner can find a new block that includes the old transaction.
Further, of course it is convenient to be able to spend money even while it is unconfirmed.

But the sender of the unconfirmed input might be using the same software as this wallet as well, meaning that the actual transaction output might change as the original spender keeps fee-bumping it over time.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018886.html
Jeremy Rubin shared few other ideas in response to my question related to fee estimates and RBF:

In the long term, this can be particularly useful since you can use a
separate fee-only wallet to arrange the bumps if your main wallet keys are
offline, and you do not disturb any of the on-chain dependants.

I'd like to share with you a draft proposal for a mechanism to replace
CPFP and RBF for
increasing fees on transactions in the mempool that should be more
robust against attacks. A reference implementation demonstrating these rules is available
here
for those who
prefer to not read specs.
https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018882.html


Can a Bitcoin address be traceable to a crypto exchange? If a Bitcoin address was created upon the opening of a Binance or Coinbase account, is there anything in the address itself, or its activity, that can give clues to whether it was in fact created on Binance or Coinbase? So that the tracer can approach that exchange and complain about that account's activity?

Possibly in it's activity, exchanges have quite unique transaction footprints and this can be used to make an inference. It's not an easy process however and there is nothing in the bitcoin address itself that indicates which exchange etc. was used to create it.


How to make a transaction start from a given address? Usually, a Bitcoin wallet includes multiple addresses, and each address has a balance of 0 or more Bitcoins. When a payment is sent out, outgoing Bitcoins are taken from one or more addresses, depending on their balance.

Is it possible to choose the transaction source address (assuming that specific address has enough balance, of course)?

I can think of two ways to manually enforce it:

Use (or create) a new wallet with a single address, send Bitcoins from your main wallet to that address, then send the payment from the new wallet.
Move all the Bitcoins in your wallet to a single address in the same wallet; then each new payment will have to be origined from that address.

Is there any simpler way to obtain this?

If this feature is not included in the reference client, does any other wallet include it?

As of version 0.9.0, the bitcoin-qt reference client includes a "coin control" feature.  When you create a transaction, it lets you explicitly select which past transactions will be used as inputs.  You can enable this feature via the Display tab in the Options dialog.

This accomplishes what you are asking for.