Why does every HTLC in a commitment transaction require its own signature? From BOLT 02 we can learn

When a node has changes for the remote commitment, it can apply them,
sign the resulting transaction (as defined in BOLT #3), and send a
commitment_signed message.
1. type: 132 (`commitment_signed`)
2. data:
   * [`channel_id`:`channel_id`]
   * [`signature`:`signature`]
   * [`u16`:`num_htlcs`]
   * [`num_htlcs*signature`:`htlc_signature`]

Why isn't the signature for the entire commitment transaction enough? I understand that every HTLC has its own htlc_pubkey and thus also htlc_secret and thus needs a signature in the HTLC success transaction but what was the rationale behind this design?

Why isn't the signature for the entire commitment transaction enough?

Because the htlc_signature field contains the signature for the HTLC transactions spending from the htlc output(s) (either received or offered) of the commitment transaction.

To expand a bit, some paths of the HTLCs scripts (timeout for an offered htlc output and success for a received HTLC output) pays to a 2of2, thus you need the right transaction which spends from this output to be signed before comiting to this (otherwise unspendable by using this script path) output.

EDIT: This question originates from this Github issue, to which Olaoluwa Osuntokun (@Roasbeef) gave today a detailed high-level explanation of why second-stage HTLCs are used in Lightning Network.

The following is the copy paste of his answer that might be of interest to anyone passing by.

Here's my attempt at a high level explanation:

We use something called two-stage HTLCs in the system. This allows us to decouple the CLTV (absolute timelock for HTLCs) from the CSV (commitment delay to allow for breach retribution). To see why this is an issue, consider if we had both of these in the top-level HTLC script. From here, one can imagine a scenario where we have an HTLC that can be timed out (absolute block height passed), but we can't spend it (timing it out) until our CSV period has also expired. Therefore, one needs to set their CSV values taking into account the absolute timelock (CLTV) value as well. Critically, before a user can cancel their incoming off-chain HTLC (timing out the outgoing on-chain), they need to wait for this CSV period. However, if the CSV is greater than the time lock delta (diff between incoming and outgoing HTLCs), they've created a race and could possibly lose money.

Without HTLCs, the dependency between the CLTV delta value and the CSV value means that if one wants to have a higher CSV value (more time to punish malicious channel peers), then they also need to have a longer CLTV delta value. As an example, a common set up with lnd is that for super higher value channels we have a CSV value of 2016 blocks (two weeks). Without second-level HTLCs, we would need to also make our CTLV delta value (40 blocks default atm), greater than 2016 blocks. This change would then propagate through the entire network, resulting in very long time lock values. The sender of an HTLC eats the full time lock delay, meaning that know their absolute worst case is much higher, trading off for better multi-hop HTLC security.

Thankfully, we figured out a solution to this: two-stage HTLCs. Note that the HTLC scripts I described above were never actually deployed. Two-stage HTLCs are actually used in the original LN white paper for a similar reason. The defective design described above was created when developers were trying to compress down the scripts and on-chain footprint a bit.

A two-stage HTLC decouples the CSV period from one's CTLV time-lock delta. To do this, we now require the party that forced closed to spend their HTLC with a special transaction. This transaction spends a CLTV clause in the script, and itself includes a nLocktime value as well. The output of this special transaction then pays to the party timing our or redeeming the HTLC, but then enforces a CSV period. We call them two stage as we enforce two states in the claim: wait for absolute timeout value, then wait for CSV value. Note that once the absolute timeout value passes, the party can spend the original HTLC output, transitioning the HTLC claim state machine to the CSV waiting period. At this point, they can safely cancel back any off-chain HTLCs, as the other party isn't able to settle it with a pre-image at this point.

The way we enforce this spend, is that we make any HTLC spends from one's commitment transaction (which you broadcast during a force close) actually be a multi-sig output. We use this output to create what's essentially an "off-chain multi-sig covenant". Since they require our signature to spend this output, we force them into a particular type of spend using pre-signed transactions. As a result, each time we want to give them a new commitment, in addition to the commitment signature (multi-sig spending teh funding output), we also send a series of signatures, one for each HTLC, that blesses their spend of the HTLC output.


If Blockchain miners weren't paid would there still be trust in all bitcoin transactions? If Blockchain miners weren't paid to mine would there still be trust in all bitcoin transactions?

Trust would remain in Bitcoin transactions only if miners continued to mine. However, without a financial incentive, there would be no reason for them to shoulder the high electricity costs of mining.


How to open a corporate account on Bitstamp? I am trying to open a corporate account on Bitstamp, but there are so many questions to answer, is there any easy way to get approved?

How are you supposed to answer: Is your business regulated for AML? If so, what is your specific policy? Specifically, how do you perform KYC for your customers?

If your (UK) business is in an area where you have specific regulations to follow for anti-money laundering, and you do, you will already know the answer. (If it is not in the UK, you may have to find out if dealing with UK-registered Bitstamp means you'll have to start complying with UK law and its requirements like KYC: Know Your Customer.) Otherwise,  the first answer is likely no and the follow-up questions are not applicable.

Commonly, KYC includes requiring a scan or photocopy of customer's photoid (passport or driving permit) and
of a proof of address (utility bill), and checking that they are not on a list of people the UK does not allow you to do business with.


How do I make my first purchase of cryptocurrency? I'd like to get started in cryptocurrency.  Be it Bitcoin, Dogecoin or something else.
I'd like to keep my own wallet and not use a Coinbase type of service.
How do I start?  Who would I send money to?  And how do I know what I get is of real value?

Download and install Bitcoin Core: https://bitcoin.org/en/bitcoin-core/
Create a wallet and receiving address there (it's better to use encryption when creating wallet).
Buy bitcoin on any available BTC exchange (Coinbase, Binance, etc.).

I'd like to keep my own wallet and not use a Coinbase type of service.

You can keep your wallet on your own, but to buy BTC, you will need to use service or find a person who wants to sell you ones.


How do I report a bug in the Bitcoin client application? I just installed the v0.4 client and have a bug to report... where can I do this?

If you could also describe how to check if the bug has been reported already, that would be great too.

You can use the issues page on github. https://github.com/bitcoin/bitcoin/issues?state=open

You can also search through the issues to see if yours is already reported.


How to get current BTC rate for BRL(real) using php cURL or javascript Is there anyway to get current rate of BRL = BTC.

I saw the blockchiain ticker. But the value for BRL currency is not updated
As listed here in preev.
I want to get the

 current 1BTC= how much BRL

Thanks in advance!

BitPay have a JSON API on https://bitpay.com/api/rates
You can get BRL value with this command and calculate, (this API update every 1 minute)

curl -ks https://bitpay.com/api/rates | python -m json.tool | grep -iA 1 'Brasilian Real' | grep -i 'rate' | cut -f2 -d ':' | tr -d ' '

You will need:
- CURL
- Python 2.7+
- grep + cut + tr


Is there a good tutorial on how to use bitcoinjs exit nodes? The documentation that I found seems to contain info about specific API calls, but no top level explaination/example.

Where can I find a practical concise example of using exit nodes?

I'd like to query transactions (say ... poll to see all latest transaction to a specific address), and submit a new transaction.

You can start with the included test package first. Then check the dependent projects.


Why do I need a private key to send some my bitcoins? Why do I need a private key to send someone my bitcoins?

A private key is the only way to assure everybody else you and only signed a specific transaction saying 'give X of my coins to Y'.

If you publish your private key, anybody can sign transactions like that and your money can be stolen. You should keep your private key private.


Bitcoin on old version of Bitcoin I have Bitcoin on an old version on the Bitcoin app; more specifically Bitcoin.org version 0.3.22. I tried to transfer the Coins to a newer wallet, but they don't go through. has anyone had or worked around this issue before? Thank you!

You can use pywallet to import the wallet.dat and export the private keys.
Then you can just sweep them into electrum or any other wallet supporting WIF.
Pywallet can be downloaded here: https://github.com/jackjack-jj/pywallet


Seed restore from one wallet to another Researching about restore walletS using seeds, I have one question:

I have 1 Jaxx wallet and the seed assigned to it.
Then, let´s say that I find another wallet that I like more, that supports the same cryptocurrencies that I had in Jaxx and also the same seed protocol (BIP39)

Can I restore my previous wallet (basically, the same cryptocurrencies, amounts, addresses...) in the new wallet, using the seed that Jaxx provided to me?

Then, there is one more question that comes to my mind...If the answer for the first question is "Yes": Can I use two wallets at the same time that use the same seed?

Provided both wallets support BIP39, you should be able to restore a seed from one into another easily.

Using the seed simultaneously on two different wallets is not a problem, since address generation is deterministic.

Note that BIP39 simply defines the seed process. BIP44 defines multiple coin types, BIP32 defines accounts. At a minimum, any seed based wallet must support these three. Most wallets these days support BIP49, BIP84, and BIP141 for segwit compatible addresses of various types. However, not all wallets support these, and even the ones that do might require you to explicitly select the correct address type and path (such as electrum). Make sure that the second wallet you use supports all the features of the first one.


How much does an online store that sells in multiple currencies need to know about exchange rates? Please take the title with a grain of salt. I couldn't make it short and also implying all that I am about to ask here.

Consider Yen devaluation. Forex traders constantly buy USD and sell JPY, or vice versa, based on news and events in politics and economy, or anticipation of the same.

Devaluation of Yen affects exporters and importers and, while it will have an effect on Japanese consumer, eventually, it is not that people in Japan today buy a sushi for 100 Yen and tomorrow for 102.1 yen, based on movements in USDJPY on Forex.

But what is an online store, that quotes goods both in Bitcoin and, say Ripple (but insert any alternative crypto currency here), to do in this situation? It has to have a fast and reliable access to some exchange current bid and ask and constantly update the prices of goods.

What are, if any, foreseeable solutions to this extra pressure on merchants who accept crypto-currencies?

How does it affect their customers who, implicitly, have to verify quotes in this or that currency in order to possibly get a better deal?

But what is an online store, that quotes goods both in Bitcoin and, say Ripple (but insert any alternative crypto currency here), to do in this situation? It has to have a fast and reliable access to some exchange current bid and ask and constantly update the prices of goods.

First off, would that really be so bad? I could write a program that polled exchanges, took the median of the exchange rates, and use that to price my goods.

Second, having prices that are slightly different because of changing exchange rates isn't necessarily a bad thing, because it can end up functioning as price discrimination. Price sensitive customers will look up the exchange rates and use the one that is less expensive. Price insensitive customers will use whatever is close at hand.

Because of this, how much you need to know about exchange rates is closely tied to how much your average customer knows.


Transparent Crypto Bitcoin 2.0 Technologies vs Anonymous Bitcoin Crypto 2.0 technologies? I'm still doing more research on Crypto 2.0 or Bitcoin 2.0 technologies and still weighing the pros and cons of each. So far we have the following technologies that are either backed by a company or a few people:

Ethereum
Counterparty
Bitshares
Ripple
Coin Prism
Sidechain

And then we have anonymous Bitcoin 2.0 crypto like NXT that took after the steps of satoshi of staying anonymous.

What I want to find out is how does being transparency play into these systems. I can understand that being transparent gives the ability to hold these companies or people accountable if anything goes wrong. But this also gives these entities the ability to be manipulated by government and laws that govern what they can and cannot do. One case is with counterparty, as they had a gambling tab within their system which they had to limit via Geo IP location due to US laws as they don't want to be labeled as a facilitator of a gambling site.

Can someone provide a list of PROS + CONS on each side of the coin for being a transparent 2.0 technology to being a anonymous 2.0 technology.

When I joined Ethereum in January 2014, one of the things that attracted me to the project was how transparently Vitalik wanted it to be run. Everyone in the team is identified publicly since day one, all the code is opensource wall to wall under MIT license, and how we intend to use the funds is completely transparent. Even our multisig account is public (https://blockchain.info/charts/balance?timespan=&daysAverageString=1&scale=0&address=36PrZ1KHYMpqSyAQXSG8VwbUiq2EogxLo2).

I personally can't imagine doing it any other way. Staying anonymous benefits who exactly? And protects the project creators from what exactly? To say it's to protect oneself from the big bad 'government' sounds far fetched at best, and a terrible excuse to operate with impunity at worst.

The 'crypto space' is currently very similar to the web circa 1993 (see: Pixelon): a miasma of a very few talented and visionary individuals, mixed with snakes, con-men, and sharks with big smiles preying on the excitement this new technology has engendered. It's very unfortunate, and certainly ironic: it is indeed the promise of the blockchain technology for operations to be executed in a 'trustless' manner, meaning without having to trust a central authority to act honestly.

TL;DR: staying anonymous only benefit the platform creators, so proceed with caution.


Proximity to exchanges and pricing I have read that numerous high frequency trading firms build datacenters near equity exchanges to minimize the milliseconds necessary to get quotes and execute trades. In the case of buying and selling Bitcoin, is my broker's proximity to an exchange relevant? Have we seen Bitcoin brokers start to advertise trade execution guarantees?

Right now, generally no. As far as I know Bitcoin exchanges dont offer peering services, and they all use CDNs (like Incapsula) to prevent DDoS attacks. So moving closer to them isnt going to help much, because you're still going to have all your traffic pass through the CDN. If you were located in China and wanted to access a US exchange, then yes it would help a some, but if you're an American trying to access an American exchange, the lower latency would be negligible.

There aren't really Bitcoin brokers as there are stock brokers. With Bitcoin you generally deal with the exchange yourself, there isnt a middle man like a brokerage. The closest thing I know of to a broker in Bitcoin is BTX Trader, which will purchase coins for you at the best price from multiple exchanges.


How many Bitcoin addresses are there? I was wondering where I could see how many unique addresses currently exist in the blockchain, and especially how many of those have a positive balance. Is that data available somewhere?

You could create an index of all addresses and their balances by going over the whole block chain, f.e. using the RPC API.

I quickly wrote this script in Python. Note that I did not verify it! I only made it to give you an idea on how you can iterate over all transactions. Also, there is probably a more time-efficient way to do it by reading the block chain files yourself.

# setup bitcoind as RPC connection to your bitcoind client using JSON-RPC
block_hash = bitcoind.getblockhash(0)
while True:
    block = bitcoind.getblock(block_hash)
    for txid in block["tx"]:
        # you will need to run bitcoind with -txindex to be able to do this
        tx = bitcoind.gettransaction(txid)
        for det in tx["details"]:
            address = det["address"]
            amount = det["amount"]
            # do something with address and amount
            #  f.e. put them in a dictionary (this will take a lot of RAM)
            #  it is more advised to setup a db on disk
    if block.has_key("nextblockhash"):
        block_hash = block["nextblockhash"]
    else:
        break


Is it "safe" to mine with your cpu on a laptop for a long time? I am currently trying to use the CPUMINER program on a Chromebook (using Linux) with its CPU for educational purposes. The Chromebook has four cpu cores.

I would like to know if it is safe for the computer to be mining Bitcoins for a long time (ex: a whole day) using all four cores. Would the CPU be damaged? Should I only use some of the four?

Unless it overheats there's no problem with nonstop mining. I'd suggest installing something like CoreTemp to view internal temperatures. You should adjust its number of cores used until all of the temperatures can be considered low enough. How low? 70°C should be fine. 100°C isn't very nice I think. There's no exact limit, but you can search online.

Overclocking? I can't comment if mining nonstop on an overclocked CPU is healthy for your computer. You might need to reduce the temperature by even more.


How do new coins come into existence in a blockchain with Proof-Of-Stake where there are no miners In Proof-of-Stake consensus there are no miners, there are validators. These validators validate the transactions in a block and charge some fee for it so when and how are new coins generated?

To understand this, you first need to understand the difference between Proof-of-Work and Proof-of-Stake.
The functionality that we want from a consensus protocol is to select a slot leader before a new block has to be generated and added to the blockchain, but we want the slot leader election procedure to be as close to random as we can have to make the system decentralized. If there is just one party, or a group of parties, that keep generating all the new blocks, then the system will no longer be decentralized.
So, what we want is to have a random process which results in a random party getting elected as the slot leader (slot leader is the party who gets to generate the new block, like the winning miner in the PoW) and this is true for both PoW and PoS.
PoW tackles this randomness requirement by presenting a puzzle of which no one knows a deterministic polynomial time solution, and the party who solves the puzzle first gets elected as the slot leader. But, PoS takes a very different approach. In PoW, the chances of you getting elected as the slot leader are quite proportional to your computing power because you will be able to check more random nonces per unit time before other parties, but in PoS the chances of you getting elected as the slot leader are proportional to your money in the system (how many PoS coins do you have). The problem that remains is that how do we enforce the randomness that we could get by putting an NP puzzle in PoW with PoS?
There are many ways this randomness can be enforced. I will talk about an approach called - Follow the Satoshi. In this approach, the online parties take part in a secure coin tossing algorithm and the result is that a random coin gets selected. This coin is completely random and the owner of this coin gets elected as the slot leader. Now, this is very intuitive to see that the person who has more coins will have a greater chance of becoming the slot leader because the odds of a random coin being in his possession are high.
This is when the new coins are generated in PoS and are awarded to the slot leader whose coin got selected.


Random election proof of stake There are currently many cryptocurrencies based on PoS (Proof of Stake). All these PoS algorithms differ from each other. Some or maybe all of them (I don't know) implement some kind of random election of nodes who participate in the "bookkeeping-process"/"block-forging-process" via having some amount of stake.

How can a random election work in an trustless decentralized environment?

The only way is to disallow membership changes in the "block-forging-process".  The DPoS used by Bitshares does this for instance, with 101 forgers, as do the PAXOS and Raft algorithms.  Otherwise it is trivially easy to Sybil attack the set of "block-forging-nodes", creating 10,000 indistinguishable, seemingly-valid chains with different forgers.  You can require work to become a member of the forging set, but then you've just reduced the whole thing back to Proof of Work.

You may be interested in my blog on the subject: What's wrong with proof of stake?


CPU bottleneck and Scrypt mining? Im planing to set up a small energy efficient mining rig, im planing to use a low power CPU/MOBO bundle, this is my favorite: Biostar A68I-350 (with 1 DIMM DDR3 4Gb)

It takes only 18W TDP and has one PCI-E 16x for a HD7950. The total Wattage is (considering the usage of a 80+ GOLD PSU) lower than 300< Watt. The KHash/s rate will be 640-650.

How much can the CPU be the cause of a BottleNeck?

The cpu is not used while mining and thus should not bottleneck your setup. The only impact that I could see would be bootup times, and it shouldn't be significant.


Would it be possible to create a blockchain that uses only X+ active blocks? Every blockchain has a beginning, the Block 0 or also known as "Genesis Block".
But wouldn't it be possible to have a blockchain or a coin, where only the last 1000 blocks are saved and 1001+ get deleted automaticly?

My question is, because it would save very much problems.

Full anonymity: Yes, you could save 1001+ blocks but if you need only 1000 blocks, you can delete the others. So at a specific point in time, you could create a real 100% anonymous cryptocurrency because the other blocks would no longer exists.
Saves disk space: It does not longer need much space to download the blockchain. Also that means, that blocksizes could be bigger.
Finally, this is one of my favorite points. When people know that they can use a blockchain where they don't need to download a blockchain for 10 hours before being able to using it, more people would and that would mean that the blockchain would be more decentralized and so it would be more secure.

Now the negative or dangerous points, that I'm not sure about. So currently, the "computer" goes through all blocks and checks if the transactions are correct and if the user x had enough coins to send to user y. That's possible through algorithms that are not reversable. I still wonder if you could hack through 1000 blocks. Next point is, that a 51% attack would be much more likely to happen. But maybe you can combine the coin with POS. And maybe you can not save only 1.000 but 50.000. But combined with ethereum and bitcoin, it would still be 10x less blocks AND the blocks will still be deleted so the disk space keeps at stable at a point. I mean, the basic problem is not the block amount, but more the danger if one person/institution/group holds the most power. And then it would no longer matter how much blocks there are, they'd be successful in any coin.

I'm interested in knowing about why that wouldn't be possible. And I really hope that that's not a basic blockchain thing and I'm embarassing myself, lol.

Full anonymity: Yes, you could save 1001+ blocks but if you need only 1000 blocks, you can delete the others. So at a specific point in time, you could create a real 100% anonymous cryptocurrency because the other blocks would no longer exists.

No, that is not true at all. Someone, somewhere will store the entire blockchain and make it publicly available. This does not guarantee anonymity, and some people, even if they don't have all of the historic data, will still store the blocks from when they came online. Nothing about deleting blocks can help anonymity unless it is somehow enforced by consensus that you can only keep X number of blocks, but even then people have backups and such which means the data is not actually gone forever. You cannot achieve anonymity by trying to delete all data.

  But wouldn't it be possible to have a blockchain or a coin, where only the last 1000 blocks are saved and 1001+ get deleted automaticly?

It is certainly possible to make it so that nodes do not have to download the entire blockchain. All a node really needs is the UTXO set, so each block can contain the hash of the UTXO set so a node can download the UTXO set from somewhere else and just start with the block that contained the hash of that UTXO set. However, this method has flaws and is vulnerable to various attacks and introduces a lot of trust into the system.

For example, an attacker could create a false UTXO set and commit it into his own short blockchain. Because you do not have the entire blockchain history, you cannot verify that the UTXO set that the attacker provided is actually correct. Furthermore, you cannot determine whether that short blockchain is even the right blockchain. The attacker could have mined it with a low difficulty and you wouldn't know that the difficulty is incorrect because you don't have the full history. This method thus introduces trust because your node has to trust that the nodes around it are giving it the correct data.


Multi-signature transactions: Address based? What is the limit? As I understand them, multisig transactions are actually transactions from multisig addresses (addresses requiring n sigs).  Is this correct?  (in other words, "multi-sig transactions" == "transactions from multisig addresses")
What is the limit on n?  Couldn't an attacker spam the blockchain by creating a giant multisig address with large n?  What are the precautions in place?

I assume im my answer that you're asking about P2SH Multisig transactions as you're mentioning multisig addresses (see What are the limits of m and n in m-of-n multisig addresses? for the 2 types of multisig schemes).

That is correct, usually what's called the multisig transaction is the one that spends from a multisig address. Note that prior to that, another transaction must have funded the multisig address.
The script length defines the limit. For each additional signature required the script will have to be longer and the limit in this case is 520 bytes. Basically, you can go up to 7-of-7 safely.


Bitcoin Testnet API that allows transaction lookup and submission of raw transactions I'm looking for a well developed, maintained and stable API allowing to access bitcoin testnet. Something like Infura for Ethereum. Googling gives many results, but can somebody point me out what is really in use?
In the moment for me BlockCypher looks the best, but can I really trust it?
It would be nice if the API was free, but it not necessarily has to be.
Cheers

Blockchain.com API  could be an option. I use it for checking incoming transactions and confirmations. It is free.


Segwit2x mining after the fork When will we be able to start mining Segwit2x?
I am currently mining with Slush's Pool. Will the entire pool switch or should I switch to a different pool?
Is there anything I should do on my side?

You can start mining on Segwit2x official pool

http://pool.b2x-segwit.io

Best regards.


How to restore Bitcoin Core HD wallet private keys by master key? Since version 0.13.0 Bitcoin Core supports HD wallets. In a .txt dump of the wallet (created by JSON-RPC dumpwallet command), one can find an "extended private masterkey" which is intended to be used for generation of rest of the private keys.
How can lost private keys be restored with the help of the mentioned masterkey in Bitcoin Core? I have not found any RPC method that would accept the masterkey to generate private keys

Unfortunately, Bitcoin Core itself does not provide methods to generate private keys from master key. However, there are libraries that can produce correct keys from xprv string (chain m/iH/0/k with hardened keys according to BIP0032) - I used https://github.com/prusnak/bip32utils for Python.


In manual raw tx creation, how do you specify the amount of the bitcoin to be sent? According to this

You can specify the amount of bitcoin with an (apparently) 16 alphanumeric hex representation.  It is stated you must specify the bitcoin you want to send in units of Satoshi.

Here is the quote:

  We then write an 8-byte field (64 bit integer) containing the amount we want to redeem from the specified output. I will set this to the total amount available in the output minus a fee of 0.001 BTC (0.999 BTC, or 99900000 Satoshis): 605af40500000000

How did they get 605af40500000000 from '99900000 Satoshis' when that hex code = 6943130077857054720?  I can find no conversion calculator online which demonstrates what they are switching it from or to.

I got the hex code from https://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html

99900000 in hex is 5F45A60. Padded out to be a 64-bit integer makes it 0000000005F45A60. But Bitcoin uses little endian for most things, so this will need to be converted to little endian by byteswapping. So the final value put into a transaction is 605AF40500000000.


Block number + bitcoin address -> Find transactions with bitcoind? If I have a block number and a bitcoin address -> Can I list all transactions for this address with an bitcoind command? Or mutliple commands?

some pseudo-code to work with the Bitcoin-Core 0.16 (if there are simpler ways pls lmk).

suppose you all have is height and addr

hash = getblockhash(height)
block = getblock(hash)

for txid in block[‘txid’]:

  tx = getrawtransaction(txid)

  for vi in tx['vin']:
    original_tx = getrawtransaction(vi['txid'])
    for vo in original_tx['vout']:
      if vo['n'] == vi['vout'] and addr in vo['scriptPubKey']['addresses']:
        print('this tx is relevant')

  for vo in tx['vout']:
    if addr in vo['scriptPubKey']['addresses']:
      print('this tx is relevant')


What happens when a hardware wallet, like Trezor, suffers a hardware damage? What happens when my hardware wallet e.g. http://trezor.io stops working?

It would be great if someone could outline the procedure. And if there are multiple ways I would like to compare by effectiveness & security.

I'm thinking about getting one, but I'm unsure about the risks having everything stored on an electronic device, rather than good ol' printed keys.

For Trezor specifically, just check their website for details.

Essentially, you need to have:

a new or wiped Trezor wallet.
your Trezor recovery card, filled out correctly.
a computer with the Trezor bridge software installed.

You plug the new Trezor into the computer, open the Bridge software, and and follow the "Trezor Recovery" instructions.  It will ask you to enter the seed recovery words from the your recovery card, which will recreate the wallet on your new Trezor device.

Other hardware wallets might have a slightly different approach; check with the prospective vendor about how to perform recovery on their device, then choose the device which suits your needs.

FYI, the recovery seed words are typically going to be compatible with any Hierarchical Deterministic (HD) wallet recovery process.  This means you could in fact recover your wallet into any HD-compatible software wallet. Pretty clearly, this means anyone with access to those seed words can recreate your wallet and steal all your funds.  Guard those recovery words with your life.


How can I send a bank wire from X to buy bitcoins? I want to have some bitcoin too, but I am currently living in Morocco, so where can I change my Dollars and Euros to bitcoins and still can use them worldwide? is there a market for that

If you can send an International (USD) bank wire then you can buy bitcoins at exchanges that accept that method.  This includes Mt. Gox, BITSPEND, Bitcoin-Central, and others.  The fees for sending International wire are generally considered too high to justify when sending smaller amounts of funds (e.g., $1K range or less).

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

If you can send a SEPA (EUR) bank transfer then you can buy bitcoins from the exchanges that accept that method instead.  SEPA transfers are generally fairly inexpensive to send.   These market exchanges include Mt. Gox, BITSPEND, Bitcoin-Central, BTC-e as well as many other fixed-rate exchanges including Bitcoins In Berlin. Bitcoin.de, Bitcoin Nordic, Instawire, and more.

If there is an exchange in your country that accepts domestic bank transfers then that may be the least expensive method of moving funds to an exchange.  For instance, Canadian users have the option of using bill payment from a bank to add funds to their exchange account at the Canadian exchange VirWoX at a low cost relative to International bank wire costs.


Transfer BTC between two wallet in two different devices? I have to format my pc, so I have downloaded a BTC wallet also on my tablet. Is there a way to send BTC without commission fees?

It might be possible to export the private keys from your PC wallet and import them into your tablet's wallet. The details and practicality of this would depend on which wallet software you are using at each end.

It would certainly be easier just to create an address on the tablet and send all the coins there. You may have to pay a transaction fee (most people don't call it "commission") but it's not likely to be more than a few pennies.


Safest way to validate typo Let's assume that I have small crypto exchange site called "MyExchangeWebsite".
It works like this: user creates ETH-BTC order, specifies his BTC address and sends ETH to my ETH address, I exchange it on Bitfinex and send resulting BTC to the specified user's address. Site is very simple and doesn't have accounts (non-custodial model).
By some reason user made a one-character typo in his BTC address for ETH-BTC order and it's impossible now to withdraw BTC, as checksum is bad. User noticed that he didn't receive BTC and contacts me to provide right address.

Am I right in my understanding that it's safe to change user's address and it's impossible to scam MyExchangeWebsite by third person who knows about typo and user's order details?
If it's not one-character, but N-characters typo. At what N it becomes unsafe to change N characters in user's address?
What is the best way to make sure that I'm in contact with the real order creator?

If user sends BTC to an address for which he does't own private keys, its not non-custodial.
Most of the websites that do such crypto-crypto exchange ask for a refund address in advance and other issues are solved depending on the case.
Best way to verify things without KYC is by asking the user to sign a message for one or more bitcoin addresses that he used earlier. Example: Someone sent me 1 BTC and I need to verify in an email communication that he is the same person, I can ask him to sign a message using bitcoin address that was used as input in the transaction.


How do I relocate my bitcoin data in bitcoin-qt to save space? I am a rather new Bitcoin user, running bitcoin-qt on Linux.  However, due to limited disk space, the application is taking up too much of my drive.  I'm guessing this is due to the ever-expanding blockchain?  So, I was wondering if there is a way to relocate the data from bitcoin-qt to elsewhere.  I have another drive connected to my computer that I could put it on, but I do not know how to safely relocate it.  Thanks for taking a look!

I recommend reading about the Bitcoin Data Directory.  You should also take a look at this answer:  How do I specify in which directory Bitcoin blocks and other data should be stored?

Basically, all your Bitcoin data is stored in ~/.bitcoin on Linux.  Not only can you specify a different location for this directory using -datadir=/some/other/directory, but you could also symlink ~/.bitcoin to some other directory on a secondary disk or network share, like this:

ln -s /some/other/directory ~/.bitcoin

However, from personal experience, I would suggest not using a network share.


Locating transactions by the relayed by IP in blockchain.info I'm working on some stats and I was wondering if the relayed by IP on Blockchain.info can be used to get an approximate (country level) origin of the transaction. Would it be reasonable to assume that this transaction has been originated somewhere in Wisconsin?

The reason I ask is that, yes, the network creates a random topology, but due to verification overhead first few relay points are bound to be within a few hops from the origin.

It is possible, but it is also quite easy to hide your activity from such inquiries. For example, lets check Address 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC:

http://blockchain.info/address-relayed-ips/15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC

We can see that most often it appears in the USA, with a dominant IP being 69.164.218.197 . If we check that IP with another tool, we can see that it was owned by Linode. And indeed, this is the address of the Bitcoin Faucet, that used to be hosted on Linode.

However, if you were to say, start your Bitcoin with -connect flag and specify an IP that you know will be running Bitcoin most of the time and not be malicious (such as a trusted pool, the Faucet, or the like), your transactions will appear to come from that IP. Switch the IPs every now and then, and you have a total control of what other people can see the origins as.

So yes, it is possible to infer some information about what IP owns which Bitcoin Address, but it is also possible to hide such data if there are any trusted nodes on the Bitcoin network.


bitcoin-cli "Could not connect to the server" Brand new Raspberry Pi mainnet node following this walkthrough:

https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1

When I run this command:

bitcoin-cli -rpcuser=username -rpcpassword=password -rpcport=8332 getblockchaininfo

I receive the error:

error: Could not connect to the server 127.0.0.1:8332

When I tail debug.log, the node appears to be fully sync'd and picking up new blocks

My bitcoin.conf file is:

#is required for Fail2Ban
logips=1

#magic RBP optimizations
maxconnections=40
maxuploadtarget=5000

upnp=1

server=1
rpcuser='username'
rpcpassword='password'
rpcport='8332'

walletrbf=1

My apologies if my formatting is bad here, couldn't figure out how to get the .conf to paste as a block of text. Thank you for any ideas on what I'm doing wrong!

I encountered this error message when I have not started bitcoind.exe.
Starting bitcoind.exe solved the problem.


How to generate the public Nextcoin key (NXT)? There doesnt seem to be an API call that returns the public key for my NXT account (with which I have not sent out any coins yet).

The NXT wallet does display the public key after I log in, but how do I calculate this public key programmatically?

There is now a getAccountPublicKey API request. But as you indicated, the public key is shown prominently in the NXT reference client (NRS version 1.3.2 currently) when an account is first opened with a secret passphrase.

This public key can be used along with the account ID (which is derived from the public key) to fund the new account from another account, thus securing the new account by adding the public key to the blockchain. If a different secret passphrase were then to be used which results in the same account ID (such a collision being a distinct possibility), it could not open the account since its corresponding public key would be different from the one already stored in the blockchain.

The public key will no longer be displayed prominently in the NXT client, but it still can be viewed by sending a transaction, then clicking on the timestamp of the transaction as displayed in the client, then clicking on "Transaction Details". The first field in the pop-up window is "Sender Public Key".

If you are interested in the algorithm for computing the public key from the secret passphrase, refering to the Whitepaper:Nxt:

The secret passphrase is hashed with SHA256 to derive the account's
private key.
The private key is encrypted with Curve25519 to derive
the account's public key.


nBit to leading zeros in Block Hash I am trying to understand how can I check if my Block Hash satisfies or not the nBits.
For example, for block 506679 (https://blockchain.info/block-index/506679):

nBits: 404454260
Block Hash: 000000000000000015A8D88216918C8DE090268A5E7F53FEEF72CD111F7F27FF

How can I double check that this Block Hash satisfies the nBits?
PS: I have already read the What does the nBits value represent? but I could not find the answer.

The bits value you have written is in decimal, in hex it is 0x181b7b74

We split this into the exponent and mantissa as shown in this answer: https://bitcoin.stackexchange.com/a/61951/51948

0x18 in decimal is 24, so we calculate the target to be:
0x1b7b74000000000000000000000000000000000000000000

Now as the target takes up 24 bytes, out of the total 32 bytes for a block hash, the remaining 8 bytes must be 0's in order for the hash to be less than the target  (as well as the rest of the number being less than, of course). Usually leading 0's are omitted for readibility, but 8 zero bytes is written as 16 zero characters in hexadecimal, which is why the hash must have at least 16 leading zeros - which it does.


Is it possible to add funds to an already-open lightning network channel? I would think that user A on a channel should be able to add bitcoins to a channel using the following steps:

Create a transaction sending more money into the main multi-sig account
Create a refund transaction for the amount in that transaction, using that specific transaction's output as the input to the refund transaction
Send the refund transaction to the channel partner for signature
Post the transaction created in (1) to the blockchain

Are there problems with this method? Is it possible to "top up" a LN channel in this (or any) way, using only one additional on-chain transaction (rather than the two you'd need to close and reopen the channel)?

This proposal (or similar solutions requiring an on-chain transaction) would move funds in the channel back from user B (Bob) to user A (Alice).  This is useful, because a channel may have more traffic in one direction, meaning at some point no more transactions can flow in that direction.  A single on-chain transaction is preferable to the two that would be required to close and then reopen the channel.

However, to say that this is adding money to the channel is incorrect.  That is not possible without reopening the channel.  Let me illustrate:

Let's say that Alice and Bob each contribute 0.5 BTC to opening transaction of the channel.  This means there is a total of 1 BTC in the channel to begin with:

Alice (0.5) ================== (0.5) Bob

After some time, more traffic has gone from Alice to Bob than from Bob to Alice.  This means that Alice's side of the channel is depleted, but Bob's still has plenty of funds:

Alice (0.05) ================== (0.95) Bob

Now, let's say that Alice sends Bob an on-chain transaction (not over the channel), to essentially buy back some of her BTC:

                  on-chain
              -----(0.45)---->
  +--->--->--->--->--->--->--->--->---+
  |                                   |
Alice (0.5) ================== (0.5) Bob
              <----(0.45)-----
                 over-channel

This works to rebalance the channel, but it does not add any funds to it.  There is still only 1 BTC in the channel.  The funds from the on-chain transaction goes into Bob's personal Bitcoin wallet, and is not on the lightning network.  It does nothing to increase the size of the channel.

This technique may prove to be useful to prevent channels from becoming unbalanced, so I don't mean to imply that this is not useful.  It is also important to note that a similar technique could work by using an alternate lightning route from Alice to Bob:

            routed through Charlie
              -----(0.45)---->
  ===============(Charlie)=============
  |                                   |
Alice (0.5) ================== (0.5) Bob
              <----(0.45)-----
                 over-channel

This would eliminate the need for an on-chain transaction.  However, if an alternative route exists, it would probably make more sense to leave the Alice-Bob chain unbalanced, and simply route payments along the Alice-Charlie-Bob route.


What is a workaround to fundrawtransaction for watchonly addresses I have imported watchonly addresses in Bitcoin and trying to createrawtransaction with input watchonly listunspend which has spendable=false, scriptSig=empty.

after that, I'm getting an error on fundrawtransaction with message "Signing transaction failed"

I know it's unsigned and can't calculate fee but if I put in order
createrawtransaction
signrawtransaction
fundrawtransaction
sendrawtransaction

still, it gives me an error "Signing transaction failed"?

A bitcoin address, watchonly or not, represents a public key.  This public key has a corresponding private key.

If you import a watch only address the corresponding private key is not imported.  So you cannot spend any unspent outputs from those addresses.

If you want to send bitcoin to the watch only address, you have to make sure you know the corresponding private key or your bitcoin will be lost.

Choose an unspent output from another address where you know the private key.  Take this output when you run 'createrawtransaction'.  Sign the transaction with this private key then 'sendrawtransaction'.

Optionally before you 'sendrawtransaction', decode your hex string with 'decoderawtransaction' and make sure everything is correct.


Link an account to another one Is it possible to have an account which is linked to another. For example i have an account with 0 address and i have another one with 1 address, I want to if someone send bitcoin to 1, the bitcoin go to 0, and i want to it would be possible to me to see 1 transactions.

I think solution for your use case is HD wallet where a bunch of keys is created from a single seed. There are 2 types of public/private key sets you can create with in HD wallets. Type 1 where you create sequence of keys with same seed. Type 2 where you can create a tree of keys using its branches and levels in your organisation or specific business. Type 2 below:


How come Merkle tree is more efficient when tree branches are not stored in blockchain? Suppose we have 8 transactions in a block X as follows and we know every node's hash value of the whole Merkle tree (that is, including intermediary nodes such as 45). Then if someone claims transaction t exists in X and it's located at 6. To verify this, we only need to look up hash values at 7, 45, 0123 and hash up to the top and compare with Merkle root 01234567.

I assume (based on this) Merkle tree is faster than hashing the concatenation of TXID0 ~ TXID7 directly is because hash algorithm runs faster on small files (even run it ~log(N) times) than on a large file (i.e., concatenation of N TXIDs, N is 8 here) at one time.

But reading this post, it seems that only Merkle root and N TXIDs are stored in a block and we have to recreate tree structure every time we verify a transaction, which would actually run hash functions ~N times instead of ~log(N) times (if I was correct mathematically).

  My questions are:

  Does hash ~N times  still faster than hash one time on N
  concatenated hash values?
  Why is Merkle tree not stored? Is it due to storage consideration?

The speed of the hash is roughly linear in the number of bytes processed: SHA2 processes block of 64 bytes at a time, and the time taken is equal to the number of blocks processed.  Computing a hashtree processes more blocks due to the intermediate levels but almost all the processing can be done in parallel unlike the linear hash which must be done sequentially.

A node only verifies a block once.  For that purpose it doesn't matter much if the hash is a tree or linear though if the parallelism is exploited computing a tree hash is faster.

[And Bitcoin Core uses vector instructions to processes tree hashes in parallel for a several times speedup. It doesn't currently bother using multiple cores for that, though it could.]

A lite client, however, does not validate a whole block, it normally doesn't even fetch a whole block.  Instead, it wants to know if a transaction is in a block.  Here, the hash structure matters a lot. If a linear hash were used the only way to prove that a transaction is in a block to a lite client would be to send it the whole block.  With a tree hash one need only send it log2(n) values and the transaction itself.

The tree isn't stored in current Bitcoin implementations because there is no operation that would really benefit from it being stored in the implementations. Proving a lite client was paid is a relatively infrequent operation and recomputing the hash tree is inexpensive. An implementation could start storing it if it had a reason to do so.  TXIDs aren't stored either as they can just be computed from the transactions themselves.


What is special about a private blockchain based on proof of stake? I recently came across a paper published in 1988 called "A quorum-based commit and termination protocol for distributed database systems". I could not read it because it is not free, but to me this sounds very similar to what a private blockchain using proof of stake for consensus achieves. I have a hard time believing that's all there is to it considering all the hype going on. With that in mind, I have the following questions:

Is chaining blocks together the only innovation here? Why not just have trusted validators sign transactions in permissioned distributed databases? We have had these technologies for decades. What is the difference?
Couldn't a 51% attack where someone has private keys for a certain transaction rebuild the chain from that point on for basically free? How does this achieve any realistic level of immutability?
Why would financial institutions want to 1. Pay to store competitors data 2. Allow competitors to see their data?

I want to understand what everyone is finding so new and exciting about private blockchains.

I have not read the paper, but here are some thoughts.

Private blockchains make little sense (to me). But of course maybe a clever person will figure out a killer app for/on private blockchains. To me they are analogous to corporate intranets of the mid/late 90s. Those were hyped up as well. IMO a public blockchain is the way to go, perhaps with encrypted transactions, or perhaps using Zero Knowledge Proofs (ala Zcash) if privacy is important.

To comment on your questions:

Chaining blocks together provides a little more security as you could not just change one transaction in block X you would have to recalculate the hashes for each block forward and get others to agree to that change. In a DDB one could just delete/alter/change an entry.
This would really depend on how the private blockchain is set up. Do we need others to accept each block? Would others recognize our new rebuilt blockchain? What consensus algo are we using here?
Blockchains offer a lot (in the right user case). In the case of banks transactions can be encrypted and only the parties involved have the keys to decrypt. Why have a blockchain to store competitors data? Well, what if the blockchain is used only for inter-bank transactions, and not for internal ones. Then there is a immutable (hopefully) record of transactions between banks.

Keep in mind that private blockchains are in their experimental stages. Banks like to make announcements for publicity, this does not mean that they have a working model or using the technology commercially. More often than not it is simply an intent to explore the possibilities that the technology can provide.


Can you "undo" an nlockTime transaction by spending a single UTXO of it before lockTime's block happens? Let's say I have a wallet X with money from 3 unspent outputs (UTXOs) A, B and C.

I make an nlocktime transaction to spend 2 of my 3 UTXOs (A & B) to wallet Y, 1 month in the future, sign it, and give it to someone (actually the owner of wallet Y) so that this person can broadcast it later.

Now, let's say a week later, before the nlocktime's block happens, I go and spend one of the UTXOs of the nlocktime transaction (A), but not the other (B).

Will the person that receives the 1st transaction be able to spend the UTXO B in the end? Or would my 2nd transaction render the entire 1st transaction invalid?

Thanks

Since one of the inputs of the nLockTime transaction has been spent already, the nLockTime transaction becomes invalid, as not all referenced inputs are available for spending.

This is described in the Bitcoin developers guide explicitly as a way to cancel a locktime transaction:

  If any of the signers change their mind, they can create a new non-locktime transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an input to the locktime transaction. This makes the locktime transaction invalid if the new transaction is added to the block chain before the time lock expires.

Before the time or block height specified for the nLockTime transaction is reached, the transaction is considered invalid and will not be stored or relayed by (other) nodes. This has been weakened in 0.9.0 so that transactions one block within nLockTime are accepted for relay but not yet for inclusion.


Why does Bitcoin Core mention "Coinbase transactions", and what are they? Quote:
"category" : "str",                  (string) The transaction category.
                                           "send"                  Transactions sent.
                                           "receive"               Non-coinbase transactions received.
                                           "generate"              Coinbase transactions received with more than 100 confirmations.
                                           "immature"              Coinbase transactions received with 100 or fewer confirmations.
                                           "orphan"                Orphaned coinbase transactions received.

Source: https://bitcoincore.org/en/doc/0.20.0/rpc/wallet/listsinceblock/
I get "send" and "receive", but what are "generate", "immature" and "orphan"? And why is Coinbase (the exchange?!) mentioned several times in core (no pun intended) Bitcoin Core functionality?!
Once again, there's nothing but cryptic, very short "descriptions" of this, leaving me (and supposedly many others) guessing wildly.

Coinbase transactions are the coin generation transaction of a block. They are the first transaction in a block. These are special transactions which do not spend any UTXOs and only create UTXOs "out of thin air". Hence UTXOs created by coinbase transactions are categorized as "generate".
Coinbase transactions are completely unrelated to the exchange named Coinbase. They named themselves after these special transactions.
UTXOs created by a coinbase transaction cannot be spent until they have more than 100 confirmations. This is known as the coinbase maturity period. While there are less than or equal to 100 confirmations, the transaction is considered to be "immature". Once there are more than 100 confirmations, the transaction and its UTXOs are considered to be "mature".
The reason there is a maturity requirement is because sometimes blocks do not become part of the main chain. These are referred to as stale or orphan blocks. To avoid issues where a transaction spends a UTXO from a coinbase of a stale block, the consensus rules require that enough blocks have been mined on top of the block with that coinase transaction such that it is extremely unlikely to be reorged out of the main chain. But for the coinbase transactions that are part of stale blocks, they are categorized as "orphan".


Bitcoin-qt read block error I am using linux mint 14 and was in the process of loading block files. I had a power failure and now it tells me failed to read Block. I would delete the blockchain and start over but IDK where to find it. I am not worried about loosing anything. Please help I am frustrated. I tried uninstalling but this did not work. Please be detailed in response I am a noob.

Start the client on the command line with the flag -reindex.


how to make Instant Payment Forwarding so basicly im using block io API.
this is the respond:

{
  "status" : "success",
  "data" : {
    "network" : "BTC",
    "forwarding_private_key" : "L1xyqqzeM3V9mX2Cq75gudcD6HV7Vt6FfXzCEjQ5yKTH7wu43yhL",
    "forwarding_address" : "12eYNpH7chSAyTMcGCyq1rd93kURQSYHif",
    "to_address" : "16GyhGWV4xNEFRKLQ27CGY6epcRMg2mdWm"
  }
}

this is a JSON right,,??
now i want to show only forwarding_address to user using javascript or PHP.
can someone show me how to doit.

Are you asking how to decode the JSON? Unless I'm missing something, that would just be json_decode($response)['data']['forwarding_address']


Address that can pay "commission"? There is a use case where person A needs to send person B, .9 BTC.  Person C, who set up the transaction, should get .1 BTC as commission.
I know this is possible to do with a traditional "bitcoin wallet" by creating a transaction with two payees.  The problem is that for usability reasons, the payment needs to be "bip-21" compatible, which basically means it has to be of the form bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>] which only allows for one output address.
So my question is, is there a way to make some "intermediary" address that will forward .9 to A and .1 to C?  Or is there some other way to do this within the constraints of bip-21?

This is not possible.
The Bitcoin protocol (currently) has no affordances to control what a recipient can do with coins they receive.


Why verifying later blockchain is slower? I'm truly lost about how bitcoin works.

I understand a blockchain contains all transactions ever made. So, what things need to be verified while I'm downloading the whole blockchain? If it's just the hash of each block, the processing/verification speed of earlier blocks should be same as later blocks, right?

Only better guess I have, is that if anything need to be indexed, then that would explain why later blocks are slower. So is this the case?

Earlier blocks had fewer transactions, and so were smaller. Later blocks have many transactions, and so are much larger.


PoW 51% attack vs. BFT 1/3 attack? So from what I understand, Bitcoin's PoW is prone to 51% attack, but as a distributed system it is also prone to BFT's 1/3 attack right? I think it's mathematically proven that in a distributed system, if you have more than 1/3 bad nodes collaborate together, then you cannot safely reach a correct consensus no matter what?

So for Bitcoin, there are two types of possible attack scenarios, one is if a miner node consistently has more than 51% computing power of the whole network then it can double-spend indefinitely and basically has unlimited cash to spend.

The other is if more than 1/3 of the nodes in the whole network are bad guys working together with modified malicious node code then they can potentially stop the correct block being accepted and make it impossible for others to know which is the correct longest chain, thus prevent valid transactions being processed and recorded.

So are my understandings correct?

So from what I understand, Bitcoin's PoW is prone to 51% attack, but as a distributed system it is also prone to BFT's 1/3 attack right?

No. Bitcoin is not a "consensus system" by any of the traditional definitions: It never reaches a state from which it can't, at least, theoretically roll back. In theory today's blocks could get undone years from now, but in Bitcoin the computationally difficulty of that increases over time.

As a result the impossibility results for consensus don't generally apply.

  The other is if more than 1/3 of the nodes in the whole network are bad guys working together with modified malicious node code then they can potentially stop the correct block being accepted.

Nah. So long as an attacker does not manage to partition the graph of honest nodes, they could control (say) 99% of the nodes and the network would continue to run just fine. There isn't some magic threshold number of nodes where partitioning happens,  you need only have a single honest peer to be completely functional.


What are some commonly used commands for Bitcoind shell command line? I just installed the bitcoind daemon on my ubuntu, but i was wondering what are some of the most commonly used commands for bitcoind?

Also is there a cheatsheet for this?

thanks

To find the list of most common commands type

bitcoin-cli help

for a list of all commands refer to the bitcoin client API.


boost::thread_resource_error I am getting this error in the debug.log of bitcoind:

EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorEEEEE
boost::thread_resource_error

It happens every 2 to 4 hours, and I need to restart bitcoind.

What I do is I request recent transactions every 2 seconds, via json-rpc.

Does anybody else got this error? Is there a way of avoiding this error?

UPDATE:

I actually managed to figure out it is related to calling walletlock. Whenever walletlock is called (via json-rpc or command line, doesn't matter), a new thread is spawned and it doesn't die. Looks like a bug.

It seems to be an error from the Boost library that is thrown "thread-related resources cannot be acquired". You probably should contact the dev team about this error, from your description it appears to be a memory leak.


spend a specifc UTXO Is there any methods to pick a particular UTXO and send it to a particular address in bitcoin regtest mode using bitcoin-cli other than createrawtransaction and sendtoaddress

You can use fundrawtransaction and specify a particular input to be used in the transaction. Bitcoin Core will then choose the rest of the inputs to meet your output amount automatically.

You can also use lockunspent to prevent specific UTXOs from being selected for coin selection thereby limiting which UTXOs can be used. Then any time that coin selection is used to create a transaction (i.e. in sendtoaddress, sendmany, fundrawtransaction, walletcreatefundedpsbt), only outputs that are not locked will be selected.


Is there a generally agreed on protocol for creating proof of solvency? After the MtGox incident, a lot of Bitcoin exchanges started pursuing audits and creating a proof of solvency / liability to prove to their users they remain solvent. While proving that one owns the required amount of coins is fairly easy, I am wondering - has anyone created a generally acceptable protocol for proving how much an exchange owes its customers based on the account balances in their database without revealing users' private information?

Greg Maxwell has described a way in which this is possible using a blind solvency proof, allowing users to verify that their amounts of Bitcoin are being stored by the system without revealing to an outsider what they are and how many users exist in the system. Clients of the service are able to individually prove their own balances in the tree and raise the alarm if they are not included or if the information is not correct, with the tree then becoming a proof of fraud. The scheme pointedly doesn't verify these funds exist and are spendable by the service.

Details about the system have been collected from IRC quotes, and at least two implementations by molecular and olalonde exist on github.

  While proving that one owns the required amount of coins is fairly easy

One exchange, BitStamp has taken it upon themselves to try and create their own "proof of reserves" system by periodically (every few months) accumulating all of their Bitcoin holdings into a single output, in an attempt to prove tht they actually hold all the Bitcoin they should. This mirrors something Mt Gox did in 2011 by moving 424242 BTC at the request of users on IRC. In the process, BitStamp is putting themselves at huge risk of losses. Bit flips errors are pretty common in computers, if they have even a single one when signing that transaction all of their customers money will be destroyed. It reduces their customers privacy, opens them up being physically attacked during that period, all sorts of nastiness. It's not really a solved problem, though it looks simple on the outset.


funding and spending a "no-multisig/no segwit" P2SH tx I got inspired by this thread:

Single signature P2SH redeem script

Assume I want to "hide" my address as long as can be. So I want a P2SH tx, which only shows a redeemscript (hash of my pubkey) on the blockchain until spent. I try to go analog to a multisig, but use just the pubkey as redeemscript. The funding tx would hash160 the public key, and use it as redeem script. This would be a payment to a "type 3 address", with this code in the "tx_out pkscript".

A9: OP_HASH160
14: OP_Data14 (= decimal 20 and the redeem hash)
87: OP_EQUAL

Would the spending tx have this in it's scriptsig?

<sig><pubkey><OP_CHECKSIG>

(instead of the way it is done in multisigs:
<sig><pubkey 1-n><OP_CHECKMULTISIG>)

Looking what happens on the stack:

sig
pubkey
<OP_CHECKSIG>

<OP_HASH160>
redeem hash
<OP_Equal>

For this to work, the <OP_HASH160> opcode would have to know, that the pubkey and the <OP_CHECKSIG> would need to be hashed together (to be compared to the redeemscript hash which follows for <OP_Equal>) ...

I think the same question applies to multisig. There is just two or more pubkeys followed by <OP_CHECKMULTISIG> (instead of <OP_CHECKSIG>).

Now I understand, why there was no answer - it gets really long :-)

So I answer it by myself. I am with bitcoin core (getinfo) version 150100, on OpenBSD (ksh) and OSX (bash v3):

I solved it on testnet, and got the tx to go through. Some information from @nick here:
Does OP_HASH160 consume the top stack element?

I was wondering, if this holds true:

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

Obviously it does. Here is the whole cycle... First I try to have a look at the stack with input and output scripts (as per link above):

sigscript:     <sig> <redeem script>
pubkey script: OP_HASH160 <RedeemScriptHash> OP_EQUAL

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

  Input SigScript (push data on stack)  STACK:
  Execute pubkey script  a. this would first push first OPCODE of pubkey script on stack and execute  STACK:
  OP_HASH160

  b. this command consumes top stack element, and replaces with hash
  STACK:

  c. the next elements of the pubkey script is pushed to stack  STACK:
     OP_EQUAL
  OP_Equal verifies top two stack elements, if untrue --> invalid
  If true, script ends with "true" on top of stack  STACK:
  verify if script is P2SH (... ok, it is P2SH ...)
  clean the stack, and run sigscript again  STACK:
  pop top stack element, and run it as script  a. the top element of the redeem script is OP_CHECKSIG   STACK:   OP_CHECKSIG

  b. CHECKSIG would verify pubkey and sig, and return true ...

To see if this is correct, assemble a funding tx on testnet/regtest. When using coinbase tx (mined block), need >100 confirmations! Start with creation of a redeemscript and address for this tx:

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

The redeemscript's address would start with a "2" on testnet. Now create the funding tx. Search for an UTXO, that we can use, and note down tx and vout.

UTXO_TXID=d260e120647360dcfc8606e242c6389acece3ee585d5e0d76a26b87b08b322e0
UTXO_VOUT=0
VALUE=49.9997
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$REDEEMSCRIPTADDR'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX | awk -F '\"' '{ print $4 }' )
bitcoin-cli -regtest decoderawtransaction $SIGNED_TX
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

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

At this point, the funding transaction is sent. Now the spending tx, we need a new address to receive the funds from the P2SH address:

RCVADDRESS=$( bitcoin-cli -regtest getnewaddress )
echo $RCVADDRESS

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

create the raw tx, sign it, and send it (maybe the amount needs to be updated):

UTXO_VOUT=0
UTXO_OUTPUT_SCRIPT=$( bitcoin-cli -regtest validateaddress "$REDEEMSCRIPTADDR" | awk -F '\"' '/scriptPubKey/ { print $4 }' )
VALUE=7.7699
RAW_TX=$( bitcoin-cli -regtest createrawtransaction '''[{"txid":"'$UTXO_TXID'","vout":'$UTXO_VOUT'}]''' '''{"'$RCVADDRESS'":'$VALUE'}''' )
bitcoin-cli -regtest decoderawtransaction $RAW_TX
SIGNED_TX=$( bitcoin-cli -regtest signrawtransaction $RAW_TX '''[{"txid": "'$UTXO_TXID'","vout": '$UTXO_VOUT',"scriptPubKey": "'$UTXO_OUTPUT_SCRIPT'","redeemScript": "'$REDEEMSCRIPT'"}]''' '''["'$NEWADDRESS_PRIVKEY'"]''' | awk -F '\"' '{ print $4 }' )
UTXO_TXID=$( bitcoin-cli -regtest sendrawtransaction $SIGNED_TX )
bitcoin-cli -regtest getrawmempool
bitcoin-cli -regtest generate 1

At this point I could see, that my newly generated RCVADDRESS contained the value (bitcoin-cli -regtest listunspent | grep -A5 -B5 $RCVADDRESS):

... "amount": 7.76990000

I had one smaller observation, which is not yet fully clear to me: the scriptsig was changed in the final tx. It had the signature, and behind should follow the redeemscript. This redeemscript was "extended" in this way:

  23210355ef94c6e097752f303d685e4011b9dba8c1cd1382f8fa68bf2de0d523f18fffac

The 23 at the beginning would be the length indicator for the following pubkey, but this would include "ac"... Not sure, why bitcoin core extends it this way.

Now that I got it to work with simple P2SH, I can try SegWit-P2SH :-)


The risk of sending money to a xpub generated address Suppose the owner of xpub share the xpub to others, and someone send some money to a xpub generated address.

If the owner of xprv does not know the path used to generate that new address, is that means money has lost forever and will always live in the UXTO.

That depends on the derivation path which was used for the xpub and derived address, to which the funds were sent to.

The xprv "owner" can scan "standard" derivation paths to determine whether these keys where used (funds were sent to these), by parsing the blockchain transaction history. If a standard BIP44 key derivation path schema was used, it can scan the following addresses by incrementing the index.

Let's say, the owner shared the xpub key M/44'/0'/0'/0. It can then search the following derivation paths for example to determine which one received funds.

M/44'/0'/0'/0/0
M/44'/0'/0'/0/1
M/44'/0'/0'/0/2
M/44'/0'/0'/0/3
...
If a significant number of consequent keys are unused, the wallet may decide to stop the scan.

If arbitrary derivation paths were used which are unknown to the "owner" instead of standard ones, the space to scan can be very large.


Are addresses which start with 3 multisig addresses? I've just downloaded bitcoin-core 0.17.1 and it seems all the new receiving addresses I create start with 3 instead of 1.

I always thought addresses which start with 3 were multisig addresses.  Anyone know why default non multisig addresses are now 3 and what does this mean?

Those are P2SH (Pay-to-script-hash) addresses. You can read more about different address prefixes here: https://en.bitcoin.it/wiki/List_of_address_prefixes

Decimal prefix  Hex Example use                 Leading symbol(s)   Example
0               00  Pubkey hash (P2PKH address) 1                   17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem
5               05  Script hash (P2SH address)  3                   3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX

Multisig addresses will be a P2SH address type so they will also start with a 3, because you cannot create an address out of a script unless it is either a P2PKH or P2SH (or segwit script with Bech32 address type). You can send Bitcoin to a multisig script, but if it is not hashed, and put into a pay-to-script-hash script, it cannot be represented as a standard address type.


What is the Bitcoin spot price and how is it calculated? I was offered to buy Bitcoin for today's spot price (MtGox to be specific). So, I am wondering, what is the spot price and how is it calculated? Is there a standard tool to look it up?

Just like with other commodities, there can be multiple "spot price" numbers.

With gold, for instance, there can (and usually will) be different price on the Comex exchange versus the price the at the auctions in London for local delivery there.

So when referencing the spot price, that is ambiguous until the specific market whose prices will be used are clearly defined.

Even then there is the issue of the the bid/ask spread at any point in time.  Since there is no regulations defining how spot price is computed, there is ambiguity between whether the highest bid offer should be the spot price, or the lowest ask offer.  Others might consider the value from last trade as being the spot price.  Another approach is to find the value exactly in the middle of the bid and ask and deem that as the spot price.

BitPay uses an algorithm that attempts to be fair in determining "spot price" by using multiple exchanges:

https://bitpay.com/bitcoin-exchange-rates

And Coindesk provides a proprietary spot price service where "spot price" also is computed using data from multiple exchanges:

http://www.coindesk.com/price
http://www.coindesk.com/coindesk-launches-proprietary-bitcoin-price-index/


Why are p2sh and CHV forward-compatible but not backward-compatible? The OP_EVAL BIP says that "Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:

An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"

The later p2sh and CHV BIPS list only condition (1).

It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).

Question: what would be the disadvantage of making OP_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?

This would ensure that situation 1 never happens since all OP_EVAL/p2sh/CHV transactions are invalid for old clients/miners.  Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.

You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.

Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all.  If 75% of the hashpower decided to change the validity rules they couldn't -- the clients don't rely on their checks.  The clients (exchanges included!) would promptly proceed to ignore the mutinying miners.  But OP_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool.  Nobody seems to be talking about that.

Requiring everybody to upgrade is just not realistic for such a small feature.

And clients must already rely on miners to fully validate transactions, because it is always possible a transaction they think is valid is actually half of a double-spend. Never accept 0- or 1-confirmation transactions unless they are from somebody you can trust.


P2Pool Hardfork 14.0 where and when is it decided? I have read on here that hardforks are a point where the pool with the biggest stick gets to decide which course the blockchain will take. Has the hardfork only just begun? When is the fork ultimately decided and has this one already passed the decision of the largest pool? Are most pools based on P2Pool's open source code? Is P2Pool calling for a fork that may not ultimately happen? Or have they worked in code from the other side of a fork into their own code? Do pools gravitate to different standards or always generally find some consensus? This one has the word attack in the fine print. Is this a step to eliminating an exploit? Is there an attack that could exploit the weighting and timing of the share system?

How long does a fork last? How many coins have been lost to forks and is there a tally? Sorry I know, that's a lot of questions.

This has nothing to do with any proposed hard forks of Bitcoin.

The hard fork being referred to is internal to P2Pool, and has already happened.

P2Pool has something called a sharechain is parallel to Bitcoins blockchain, only using a 30 second block time rather than a 600 second block time. It is internally used for tracking mining progress in the pool, and ordering payouts. It has the same features as the Bitcoin one, in that it is completely in consensus between all the P2Pool nodes and has very specific rules for what is acceptable and what is not. Some rule altering is a hard fork, where previously invalid things become valid after the change.

The reason a hard fork needs to happen is that BIP66 enforcement will cause all subsequent version 2 blocks to be invalidated, anybody mining a version 2 block after this point in time will be throwing away money. P2Pool had to be internally hardforked to support version 3 blocks, or risk just burning all of the miners income on rejected blocks. This Bitcoin soft fork will happen very shortly, when the average version of the last 1000 blocks is 2.95, which is why P2Pool had to make such a drastic change in such a short period of time.

P2Pool is unlike all other centralized pools in its operation and management. Other pools simply updated their Bitcoin nodes to the latest version of the software and anyone mining with them accepted the soft fork by proxy.

  I have read on here that hardforks are a point where the pool with the biggest stick gets to decide which course the blockchain will take.

This is not correct. A hard fork is controlled by the users of the network, not the miners. The miners must mine blocks which the network views as acceptable, if they don't the nodes in the network will simply reject their (to the rules they have) invalid block and ban the peer that sent it to them.

  Has the hardfork only just begun?

There is no accepted proposal for a Bitcoin hard fork.


Bitcoin i have been asked to send money for a private key Hi i have been asked to send money for funds that are nonspendable to receive a private key to unlock it, it's from bitcoin investing. How safe is this as i'm worried i wont receive the payment. It's currently sitting in my blockchain wallet account and it displays the funds as nonspendable until unlocked with a private key

This is most likely a scam! there have been a similar question recently Why do I have to deposit BTC as missing turnover

There is no need to send bitcoin or money to receive a private key or unlock a bitcoin wallet, be careful.


What are best practices around toggling between multiple wallets in bitcoind? I've created a couple wallets on Core to experiment with and want to dedicate one wallet as a live one.  What is the best way to move between those wallets inside the command line?  When I toggle to a wallet that is not the default in the GUI and try some bitcoin-cli wallet commands it get an error

Wallet file not specified (must request wallet RPC through /wallet/<filename> uri-path)

Is it just a matter of passing a wallet file name into the command? Or is there a better way to manage multiple wallets? Other best practices to a multi-wallet setup (i.e. don't)?

For future reference, thought I'd respond to my original question with what I've found out to this point. Haven't fully answered the original question yet but the approach I'm using at the moment to toggle between wallets is:

bitcoin-cli -rpcwallet="filename" [command]

Any other thoughts on best practices would be great!


Is it possible to earn BTC by processing transactions? Where does the money go? Is it possible for any person to setup his wallet application to process transactions and make some more BTC?

If you run an Escrow service, yes, you could get paid to process transactions. But that's probably not what you're asking about.

In normal cases, transaction fees go into the reward for a new block being mined and are earned by the miners that create the new block. This takes specialised hardware and software. If you want to get your feet wet in this area, you ought to look into mining at a pool.


What transactions will be included in the next block? The miners decide whether a transaction will be included in the block.

What information do miners have about unconfirmed transactions?

How can I know, in detail, what transactions are going to be included in the block?

You can see what a miner sees at this very moment, provided that your wallet is synched, by calling getrawmempool true in your bitcoin console. What you'll get is broadcasted transactions not yet included in a block.

In short, miners scan this list and then allow the valid transactions with a higher fee to be included first in the block they are about to mine.


Around EUR 40 to withdraw from MtGox? I just withdrew around EUR 940 from my MtGox account and transferred it to an account in a European bank that does not charge anything for incoming international transfers.

MtGox charged me a bit over EUR 40 for making this direct transaction from their Japanese bank. I'm a verified user.

Maybe it's my lack of experience with them, but I feel this is little short of robbery. 40 euros? Anybody has a similar experience?

If you used the japanese bank its not a european transfer, but an international wire, and intermediate banks took their share on those fees.

I often say "with international wire, expect to loose 2-8% on random intermediate bank fees", sorry to tell you that but, thats the traditional obsolete banking system of the real world.

Afaik the mtgox fee for that is more or less 15.46 euro,you probably had around 25 more euros on "intermediate bank fees", ask for more info to your bank about international wires.

Actually receiving 900 for 940 sent is not so bad for an international transfer, be happy I seen worst ;)

Also, even with those "intermediate" added fees, it could be worth it when all other withdrawal options are delayed, like sepa or okpay taking 1-2 weeks .


How I can delete useless addresses? In Bitcoin app wallet
I created many addresses, which I need to delete. I tried to press, clamp, enter the settings. Nothing helped. Is it possible to remove unnecessary addresses?

Is it possible to remove unnecessary addresses?

Many wallets can show you a list of all the receiving addresses they have generated.
Some wallets do allow you to view a list of only those addresses with a non-zero balance.
Wallet developers probably don't want to allow deletion of addresses because of the customer support issues that would be raised if money were subsequently sent to an address that had been deleted from a wallet. They'd have to also provide a way to re-create deleted addresses.
So just providing a list of addresses with non-zero balances probably seems like a more sensible option to many wallet developers?


Are there any Bitcoin wallets with native I2P integration? Tor usage seems to be fairly common with Bitcoin, but I have heard less about efforts of integrating with the I2P efforts.

Tor and I2P both have their pros and cons, but I am curious to here about what I2P efforts have been made to this point and why more attention has so far focused on tor.

C++ may be viewed by some as more suitable for Bitcoin use than Java which I2P currently heavily relies upon

https://github.com/monero-project/kovri

Kovri:

To cover, veil, wrap (Esperanto).
A secure, private, untraceable C++ implementation of the I2P anonymous network.

Once complete this project should ease of integrating Bitcoin in both a private and secure manner.


Does cryptocurrency ETF use block-chain technology? As you know, one of these days trends is cryptocurrency ETFs that the CES doesn't approve it yet. But there are some questions about them and their functioning. Is it necessary to build them over block-chain technology? If yes, would someone explain it? and in case the answer is no, why?
Question: In other words, the main question is about how do they implemented and function.

Is it necessary to build [Exchange Traded Funds] over block-chain technology?

No.

in case the answer is no, why?

Imagine an ETF based on stocks in gold mining companies. Those companies own open-cast mines and rock-crushing machines.
An exchange can buy and sell shares, or funds based on those shares without directly themselves operating any open-cast mines or rock-crushers.
Rock-crushing machines are not suited to keeping track of sales and purchases of stocks and shares, or of funds based on them.


Incentive for miners to keep mining once reward get very low Currently each winning miner receive 12.5 bitcoin or 12.5*10 000 dollar per successfully mined block and the amount of bitcoin receive is divided by 2 approximately each 4 years.

The incentive to play the game fair and keep mining is pretty high, but what will happen once that reward get very low like 1 bitcoin or even less, even if the price get big like > 100 000 dollar it will be less and less rewarding to keep adding hashing power for the miners to protect the network and more and more tempting to try a 51% attack even if it just for breaking the confidence in the network.

so what could be the solution to keep the network protected, my guess is that some miners who are pretty invested in the game and own a lot of bitcoin/hashing power will always and forever keep a sufficient amount of machines ready to be powered ON at any sign of a 51% attack attempt, keeping the network virtually protected while not costing too much

it will be less and less rewarding to keep adding hashing power for the miners to protect the network and more and more tempting to try a 51% attack even if it just for breaking the confidence in the network.

This is a pretty weak assumption. We don't make any calls for necessity in the Bitcoin hashrate growing, there's no security assumption around that, it's just an observed property that presently it happens to be growing.

Bitcoin miners are assumed to be operating with a single goal: profit. If somehow causing the thing which is giving you profit to fail is adventurous to you, then we can just rest easily on the knowledge that the underlying basis for Bitcoin to exist is incorrect.

  The incentive to play the game fair and keep mining is pretty high, but what will happen once that reward get very low like 1 bitcoin or even less, even if the price get big like > 100 000 dollar it will be less and less rewarding

If the cost for operating the hashrate exceeds the revenue generated, miners don't mine. The whole system ends up with an equilibrium of having barely profitable mining hardware- regardless of how much profit there is to be made doing it. If the fee volumes don't ultimately cover for this, there will be less mining.

  forever keep a sufficient amount of machines ready to be powered ON at any sign of a 51% attack attempt

You assume incorrectly. There is not large farms of idle hardware simply laying around. Large facilities require a significant amount of upkeep, large amounts of power are not available instantaneously, and if there was large amounts of ready-to-go obsolete hardware, it would doubtlessly be so inefficient as to be worthless towards any cause.

  so what could be the solution to keep the network protected

Failure of the incentives means complete failure of Bitcoin as a whole, to pretend otherwise, or to pretend that there's some secret bullet which hasn't already been deployed, is disingenuous.


Privacy concerns for a publicly displayed Bitcoin address If I publicize a "request address" with the intention of allowing people to support my online efforts, am I risking my privacy?  i.e. if many people send me Bitcoin via that address, ostensibly that leaves a visible chain of money going into that "account" (for lack of a better word).

Even if I immediately transfer money from that "request address" into my main wallet address, there is still going to be a money trail, no?

What can be done to mitigate that?  Should I change the address every time someone sends me money, or perhaps every week or month?

As a for-instance, ThePirateBay has a Bitcoin address on their main page; it looks like they've received 12.3 Bitcoins via that address.

This is the design of Bitcoin; you can use multiple wallets to obfuscate the transactions (or third parties etc.), but ultimately there is always a paper trail that anyone can access; the privacy comes from not being able to tell who is operating any wallet.

If this public-ledger is a concern for you, you should look at various privacy coins such as Monero (here's a guide to the most common ones I just Googled), as this is the whole reason they exists instead of their users just using Bitcoin.


I lost my wallet, can someone just help me with my investigation? Im from Argentina, living in Spain, so im sorry for me english.
I will try to explain:
Back in 2013, i had a butterfly equipment...i bought one to resell in Argentina, and i did mining like few months, and i remember using a "pool" to do that.
I sold machine, forgot totally about btc, i even change my laptop many times....
2021: Im desperated for this covid problem, im inmigrant in foreign country and is really hard. So i tried to remember things...to search in my email...in my google activity...etc...etc
I found out the pool, was Bitminter, i realized was like not working, but i wrote to support and they answered to me right away, cause my hotmail adress was no longer valid !!
So they kindly attached my google account, and i logged in!
I saw just cents of btc....and i realize i had the option "pay out auto", and i can see the transactions made to my "wallet"....but i HAVE NO IDEA WHAT WALLET I USE....even what pc i was using .... i change pc all time... is so frustrating.

some kind soul with any idea? thanks a lot !!!

too many clues means no clue at all. there isn't no clue. you already said u changed laptop manytimes . just forget about. you can't dnothing without the backup.
but if you using some online wallet to receive that btc. you can search your email to see if there are record fromexchange or online wallets. this is the only chance. good luck.


Bitcoin core outgoing transactions On The bitcoin core wallet you don't have to wait for it to sync to after your outgoing transaction in order for the transaction sent from the wallet to be confirmed and arrive at the addressee, does it? It's all about paying an appropriate transaction fee, right?

I only ask because on 2 attempts now after consulting bitcoinfees21 I have tried to establish a transaction fee that will be enough to be sent before the transaction bounces back and still no avail, separate question but it's a three day window until the transaction bounces back if still not confirmed, right?

Any help would really be appreciated. Thanks ...

First of all, transactions do not "bounce". Once a transaction is broadcast, it can confirm or remain unconfirmed indefinitely. There is no point where your transaction "expires" or the transaction "bounces" and the coins return to you; anyone who has a copy of the transaction can, at any point in time, rebroadcast the transaction and remind the network that the transaction still exists and can still be confirmed.

In order to send Bitcoin, you must be fully synced. If you are not fully synced, you risk spending coins that have already been spent and thus creating an invalid transaction. Furthermore, your wallet cannot know how much Bitcoin you actually have without being fully synced. While you can spend while unsynced, there is no guarantee that the transaction you are creating will actually be valid.


"Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "1",
            "ScriptSig": {
                "Asm": "3045022100aa4cfe7482c52e961b617658d8029b524f8fe2a33ae3a4acd1d4f46684e8703f022077db4cd5b21413761b44e5511ddb45a91f2cbff52537677c2703a6f1f2cea6e4[ALL] 02763d72701702a421c464eb3a8dad8bd653d5fc2bddd1b08f1563d14952fda861",
                "Hex": "483045022100aa4cfe7482c52e961b617658d8029b524f8fe2a33ae3a4acd1d4f46684e8703f022077db4cd5b21413761b44e5511ddb45a91f2cbff52537677c2703a6f1f2cea6e4012102763d72701702a421c464eb3a8dad8bd653d5fc2bddd1b08f1563d14952fda861"
            },
            "CoinBase": null,
            "TxInWitness": null,
            "Sequence": "4294967295"
        },

If you go to https://blockstream.info/testnet/tx/ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498?expand and see the output #1, you'll see that it's an unspendable OP_RETURN output. Remember that TX Outputs are zero indexed, so maybe you're trying to spend "Vout": "0"?

That ScriptSig matches perfectly with output #0. Just change the Vout field of first Vin as I said above. The second input is also okay.

In other words,

   "Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "1",
            "ScriptSig": {

should be

   "Vin": [
        {
            "TxId": "ed34d4d2b9953a4ef585a13454a00501783675752b640b8cc68235afe5495498",
            "Vout": "0",
            "ScriptSig": {


If Bitcoin is traceable, how bitcoin scams are exist? Let me write an example. A hustler give some people his bitcoin address and these people transfer some bitcoins to his wallet. According to the term, which says that bitcoin transaction is traceable so my question is that why the hustler uses this method? He knows that he can be tracked!

Bitcoins can be exchanged to dollars in questionable exchanges like BTC-E or LocalBitcoin. These exchanges are not interested in the source of Bitcoin, do not co-operate with authors (police) and thus scammers are able to do cash out stolen Bitcoins. You can only see the Bitcoins go into the exchange, but the exchange won't give you, or the authors, the details who is the user who is cashing out.

Furthermore, when more legit exchanges try to make sure they follow Know Your Customer rules and demand the users to show the proof the Bitcoins they are selling are not stolen, there is a backslash from Bitcoin community. Some libetarian parts of Bitcoin community do not wish to destroy Bitcoin fungibility, e.g. making sure that criminally obtained Bitcoins cannot be discriminated from legally obtained Bitcoins. This is because much of Bitcoin transactions are fuelled by dark markets which are outright illegal.

Please see recent discussion with Evolution exit scam.