Why would more confirmations help in a 51% attack scenario? After the 51% attack on Bitcoin Gold. The developers of the cryptocurrency recommended the exchanges to increase the confirmations. I don't understand why increasing the confirmations would help if the attacker has control over the history of the blockchain. I'm missing something for sure.

If the exchange waits for 6 confirmations (1 hour) and sends the dollars then, it could be possible that no one even noticed that there was such an attack. Then a scammer could pay out twice.

But if the exchange waits 12 hours for example, some miners will probably recongnize that they do mine on a shorter chain within this time.

In the bitcoin system, 6 confirmations mean in more than 99.9% of the cases that the transaction is done. There are only a few scenarios in the bitcoin history when that was not the case.

But you need less mining power to attack Bitcoin Gold. So I would aggree that the exchanges should wait longer.


Why are transactions with no outputs not relayed by default? I was reading this thread about making a transaction without an output:

Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)?

The answer is that outputs under a certain value are considered "dust" or "spam".

What is the reasoning behind this? If the input value minus the output value is above the getMinNonDustValue minimum limit, why would the transaction be considered "dust"? The coinbase of the block containing this transaction would simply be allowed to be of higher value, which is how fees usually work.

If my understanding is correct, the network would benefit greatly from a transaction with no outputs. It's fairly easy to circumvent this rule anyway; one could simply add an output that matches getMinNonDustValue and increase the input by that same amount. Allowing a zero output transaction would mean less network load, less data storage requirement, and most importantly less CPU cycles required because the output script is not necessary in this transaction. There is also the added effect of making miners happy by introducing a new rule that allows "donation only" transactions where all Bitcoin go to the miner who solves that block.

The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are many good changes that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just as you said, this can be easily circumvented.


What does the sequence in a transaction input mean? Following a transaction input:

What is the meaning of the sequence number? What does the 4294967295 tell me?

Original meaning of nSequence in transactions

nSequence is a 4 byte input level feature. The original meaning of nSequence was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than 0xFFFFFFFF (4294967295 in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher nSequence value. Once a transaction was received whose inputs had an nSequence value of 0xFFFFFFFF it would be considered finalized and mined. In that implementation, replacement transactions did not have to pay additional fees, so there was no direct incentive for miners to include the replacement. Also, no built-in rate limiting prevented overuse of relay node bandwidth. Hence, this feature was disabled later as it was possible for an attacker to use up all the bandwidth among full nodes at only a small cost to himself, creating a denial-of-service vulnerability. This made it difficult for spenders to adjust their previously sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.

  Opt-in Full Replace-by-Fee Signaling

Then came the proposal for Opt-in Full Replace-by-Fee Signaling. It considered a transaction to have opted in to allow replacement of itself, if any of its inputs have an nSequence number less than 0xFFFFFFFE. It also required higher fee than the previous relayed transaction

  Absolute and Relative Locktime

Transaction with nLockTime is used to prevent the mining of a transaction until a certain date (specified in block no. or time). BIP 68 activation defined the meaning of sequence numbers for transactions with an nVersion >=2. nSequence was repurposed as a relative locktime. That means it prevents mining of a transaction until the input that the transaction is spending has reached a certain age in blocks or timespan.  If nSequence > 0xEFFFFFFF then there us no consensus meaning to the sequence number and it can be included in any block under all currently possible circumstances. If nSequence <= 0xEFFFFFFF, it implies relative locktime.

If nSequence <=0xEFFFFFFF, then the sequence's 22nd bit determines if the relative lock-time is time-based or block based. If the bit is 1, the relative lock-time specifies a timespan in units of 512 seconds granularity. If the bit is not set (i.e. it is 0), the relative lock-time specifies a number of blocks. The value of the relative locktime, is then interpreted from the first 16 bits of the nSequence. The below figure shows how nSequence is evaluated.

  Use of nSequence with CHECKSEQUENCEVERIFY (CSV) opcode

CSV is a script level opcode that is used to lock the spending of a particular output of a transaction until certain blocks/time from when the transaction containing the output was mined. When the user is spending this UTXO in a transaction input, he must set the nSequence value in that input greater than or equal to the CSV parameter. The value in CSV must match the format in the corresponding nSequence value. If CSV is specified in terms of blocks, then so must nSequence.

  Other miscellaneous points

Currently, if nSequence = 0xFFFFFFFF, the sequence number has no effect on the transaction.
If nSequence = 0xFFFFFFFE, then it implies that the transaction uses locktime but does not opt-in replace-by-fee.
Plain vanilla transactions created from Bitcoin Core uses nSequence=0xFFFFFFFE, because they want to use nLocktime to prevent miners from pulling the transactions forward. The nLocktime used in such transaction is set to the last mined block.

For more information on Locktime refer here.

  Future potential for nSequence

As can be seen from the description above, a number of bits remain undefined. This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future. For example,

If nSequence > 0xEFFFFFFF then the remaining 31 bits have no meaning as this condition can be satisfied by just setting bit (1<<31).
If nSequence <= 0xEFFFFFFF then the bits 23 to 30 have no meaning.
Also, only first 16 bits are used to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive).


Using a programming API with blockchain New to using BTC and the Blockchain.

My understanding is that (for the Bitcoin), one can download/install btcd.

Then, one has to use btcd to synchronize the "local" Blockchain with the "main" Blockchain(?)

If so, what is the best API that one can use to access the data in the Blockchain?

I saw this:
https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

For example, I have seen blockchain.info - but - I am not sure that one can download this and have it "point" to one's local btcd.

Any suggestions, help or hints would be greatly appreciated.

TIA

blockchain.info API is not related to Bitcoin-core, you can send commands to Bitcoin-core without the need to blockchain.info

for example to get full details about non-wallet transaction enable txindex and call getrawtransaction for wallet transactions call gettransaction and so on.

You can find all RPC calls here and you can send RPC commands from PHP, Nodejs etc..

if you want to have the full blockchain synced locally you can use bitpay insight (open source blockchain explorer).

or simply as you suggested you can use blockchain.info API without installing Bitcoin-core.


What other lightning nodes are there besides Eclair Core for running a full node lightning? I realized that in order to receive lightning payments from others, you need to first run a lightning full node. I found this one from Eclair: https://github.com/ACINQ/eclair

Are there other full node lightning implementations like Eclair node that are just as reliable?

There are a few lightning network full node implementations, that follow the LN specifications. Note that in many ways the specs, and software, are considered experimental, and should be used at your own risk.

C-lightning is written in C
LND is written in Golang


What is the right way to restart bitcoind if it crashes? I am very new to this and apologies if it has been asked before but I can't seem to find a clear answer after looking extensively.

I am trying to run a full node. I started bitcoind -daemon and everything worked fine, the blockchain was syncing. It crashed the next day because I hadn't set my options for swap memory correctly.

After fixing that issue, I did bitcoind -daemon again and it looked like everything was being done from the start. Should I be doing bitcoind -reindex-chainstate from now on if the process stops? Or did I not understand correctly and simply doing bitcoind will resume syncing but requires some verification first?

Also, in any of the above cases, is it the same process once the blockchain has synced?

This is on a Raspberry Pi 3B+ with an external HDD for storage.

Thanks a lot in advance.

If you check in your debug.log you should be able to see if there is any error when you started the node. Probably when the node shutdown uncleanly some of the tables were in an inconsistent state.

Presuming everything is fine and it is not stuck, it is okay to just start with bitcoind -daemon and it will do what it needs to.


If my service only accepts Bitcoin, will there be a lot of missed customers who only have non-Bitcoin crypto currencies? I'm about to release a service which only takes payments in Bitcoin.
I'm wondering if this will impact me negatively in terms of not getting business from people who own other crypto currencies.
I don't reject the others out of ideological reasons, but for practical ones:

My hard disks are already overflowing from the 335.8 GB Bitcoin blockchain.
I barely trust Bitcoin Core to run on my computer -- I don't trust non-Bitcoin clients whatsoever.
Even if I did have the storage space and the trust, I would have to learn the respective RPC APIs (assuming they exist) for each "altcoin" as well. It took me a very long time to grasp the Bitcoin Core API.
Any kind of reliance on a third-party service is unthinkable due to KYC/AML BS, as well as the obvious risk with getting my money stolen if somebody else "holds them for me".

Is there any way around this? Is there some kind of mega-trusted "multi-coin" client which doesn't need to download the entire blockchains, yet is able to securely and locally handle multiple of the biggest altcoins, so that I could support those for payments?
Or would anyone who has altcoins also have Bitcoin? I get the feeling that they are very, very few, but perhaps they are also more likely to spend their coins compared to the stubborn "HOLDers" of the increasingly valuable Bitcoin?
I know myself that I'm very unwilling to part from any of my Bitcoin, especially as the price is increasing... It's just a fact for me, but I can't speak for others. I don't have any other crypto currencies myself, and the times I've looked into them, I've just been put off by their software. (In the cases where software even exists!)
Advice?

If my service only accepts Bitcoin, will there be a lot of missed customers who only have non-Bitcoin crypto currencies?

It takes few seconds for exchanging altcoin to bitcoin or fiat to bitcoin if someone is really interested in paying for something and only holds altcoins.


How is mining difficulty defined (formula)? The result of sha256(s) that miners attempt is a 256 bits long number (64-digits hexadecimal number).

I understand that this 256bits number should be lower than the target threshold, the target threshold being itself a 256 bits long number with a number of leading zeros.

Target threshold is encoded with 4 bytes in the block's headed, as 0xEEMMMMMM in hex notation. EE being the 1byte exponent and MMMMMM being the 3bytes mantissa.

How exactly are these exponent and mantissa translated to the actual 256-bits long target threshold?

The nBits field is basically scientific notation in base-256 (256 is 2^8). As an example, we take the one found on the Bitcoin.org Developer Reference: 0x181bc330 (Big-Endian order). This is split into two parts, the 0x18 exponent (24 in decimal), and the 0x1bc330 mantissa. The mantissa is 3 bytes long, so subtract 3 from the exponent and then raise 256 to that power, and multiply by the mantissa just as in scientific notation:

  0x1bc330 × 256 ^ (0x18 - 3)

Giving the target, the mantissa followed by 21 0x00 bytes, or 42 zeroes in hexadecimal.

See this answer for another example: https://bitcoin.stackexchange.com/a/61967/51948

EDIT: You can also think of it as allocating the number of bytes given in the exponent, in this case 0x18=24 bytes, and than filling the first 3 bytes with the mantissa.


Problem using op_checksequenceverify (op_csv) with relative time flag i have trouble in using op_csv. The spending condition is not match to my expectation.

FUNDING

Redeem Script Hex: 03010040b27576a91451d2a5e04d25ceaa86e600a6ec34bd24431c675d88ac
Redeem Script Asm: 03<010040> OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 14<51d2a5e04d25ceaa86e600a6ec34bd24431c675d> OP_EQUALVERIFY OP_CHECKSIG

P2SH base85 address: 2NFRizqW8XpNQm7nxYvFpYTvYsy3BqgsEx2 (bitcoin testnet3)

Based on my mentioned redeem script, i set time parameter as 1 along with OP_CHECKSEQUENCEVERIFY. Now my expectation is once blockchain confirms this TX, supposedly, miner will accept my spending TX after 512 seconds.

here is my funding tx
https://testnet.smartbit.com.au/tx/318462c4f6fef6e3c4fc58e8803c1ca43f20d162ca41d5c74f9e89725d8b300d

SPENDING

02000000010d308b5d72899e4fc7d541ca62d1203fa41c3c80e858fcc4e3f6fef6c4628431000000008b483045022100f995ccfb8ce2bda36c4ec0f37f067ee6c87c58043155b3a583da201ffaaa4db50220794d23e402b3f0a9579ab9bb8fbb573eba8cffed27542c162b629aa0f914b10d01210292dbb331c39d84611fbaa8e225d781ec50c2ed21fbf311bfeb869042f4b3e1781f03010040b27576a91451d2a5e04d25ceaa86e600a6ec34bd24431c675d88ac0100400001d40c0600000000001976a91451d2a5e04d25ceaa86e600a6ec34bd24431c675d88ac00000000

i set this TX's version as 2 and input's nsequence as 03010040. Now, i am waiting for blockchain to confirm my funding tx. Not so long, my funding tx was confirmed with date 2019-11-24T10:46:05Z. Now, I expect that 2019-11-24T10:46:05Z + 512 seconds = 2019-11-24 10:54:37 is time miner will accept my spending tx. As the result once my funding TX has been confirmed then i can spend immediately without any relative time restriction. ANYONE know what is happening?

here is my spending tx
https://testnet.smartbit.com.au/tx/a68a821e06c1156d5fe80f3662c941142ed2ce1a57e597ce05bf167bce21fe2d

P/S: i further test by changing time parameter in redeem script from 1 to 4 and 5, then the result is slightly match to my expectation.

i manage to find answer for myself.

OP_CSV date consensus is based on median time past (mtp), not block's confirmed date.

once funding tx above has been confirmed, it is located in block#1609592 with block MTP is 2019-11-24 09:05:26 (UTC 0). At same time, chain's MTP is 2019-11-24 09:25:27 (UTC 0)

now come to spending tx, since utxo's confirmed date i used is 2019-11-24 09:05:26, plus 512 seconds = 2019-11-24 09:13:58. Therefore i can spend immediately as chain's MTP is more than 2019-11-24 09:13:58.


Unknown factor in bitcoin pool breakdown Some time ago the breakdown was dangerously close to heaving too heavily towards Deepbit with only a small part unknown/single person miners. Now there's a 34% unknown factor.

What caused this? Are these botnets? People deciding their amortised profit stablises anyway? A drug cartel laundering money?

It is unlikely that we will account for most of the activity, as Bitcoin allows for high anonymity. Some of that hashing power is believed to come from some botnet, but one can't be sure. You could try looking for the owners of the IPs that relay the new blocks and check who they are, but that would be a tedious work that could be easily hidden, for example by relaying blocks through TOR.


How to complete install of bitcoin-0.17.1 on linux (fedora 29) So I downloaded and unzipped bitcoin core. I now have bitcoin-0.17.1 sitting in my home directory . What next? How do I install and run this? (Obviously I am a newb, help much appreciated.)

After extraction files from the tar ball you have to install the contents of its bin subdirectory into the /usr/local/bin directory using the the install command. The install command is part of the GNU coreutils available on nearly every Linux distribution, and the /usr/local/bin directory is a standard location for self-installed executables (you may edit the commands below to use a different location).

If you use sudo to run commands as root, use the following command line:

sudo install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.2/bin/*

If you use su to run commands as root, use the following command line:

su -c 'install -m 0755 -o root -g root -t /usr/local/bin bitcoin-0.14.2/bin/*'

See reference here

You can then just run bitcoin-qt to startup the GUI


sum(VOUT) > sum(VIN) -- Is this a possible scenario? I have a transaction. This transaction was taking a value from AddrX and sending it to itself in a "split" of sorts. In the transaction there is one VIN of 98000000. This transaction split the stack and has two VOUT. They are both 49000000.5. There is a transaction fee of 1.00.

In this case, the total VOUT is 98000001 which exceeds the total VIN of 98000000. However, that difference is found in the transaction fee.

From what I have understood about the blockchain and transactions, the transaction fee is: Fee: sum(vin) - sum(vout) so it results in a -1 transaction fee.

My issue here is that if I were building a database to track this address I would end up subtracting 98000000 from their balance, and then would add the two incoming values of 49000000.5 which would end up placing their total balance after this transaction to 98000001 which would be incorrect. Now, I could add logic to remove the transaction fee incurred from this manually; however I would have assumed that this transaction would be invalid because the total VOUT was greater than the total VIN.

Could this situation be possible? So far from transactions I've seen, the transaction fee has already been applied to one of the VOUT and thus would not cause this error. If it is possible, how can I detect this and remedy it?

Such transactions would be invalid. While you could create them, all nodes would reject them as invalid and such transactions would never confirm. If this were possible, then it would be possible to create money out of nothing (except in Coinbase transactions) and that should be impossible.

You have either constructed your transaction incorrectly, or are interpreting it incorrectly.


What does "generate" mean when it appears as a transaction's type? What is "generate" as a bitcoin transaction type? Why are "generate" transactions labeled as "immature" for 100 blocks? Is this type of Bitcoin transaction spendable?

"Generate" transactions are coinbase transactions. These are a special type of transaction that is included in a block by a miner. They can not exist outside of a block. They generate new coins to an address configured by the miner. Those coins can not be spent until they have 100 confirmations. The reason for this is to prevent a messy scenario in which a block becomes disconnected or is no longer in the most-work valid chain, meaning the newly generated coins do not exist on the ledger any more.


Verification of untypical scriptSig I want to be able to redeem a P2SH output with a script doing a multisig but also additional checks. The scriptSig to redeem this output thus has to provide enough signatures, as well as some specific data, that is then compared to what's in the redeem script. To my understanding, a scriptSig like this cannot be constructed using signrawtransaction, but needs to be put together manually. But then it's very prone to errors... Is there still an easy way to check the correctness of this self-constructed scriptSig? Like a RPC call to the verifying function, a miner would call, when validating the transaction?

Assuming that you are able to create the raw redeeming transaction yourself, it is possible to pass a signed transaction to bitcoin core's signrawtransaction (or signrawtransactionwithwallet on new releases), along with a json to describe the utxo being redeemed, to verify correctness.

In this example I'm setting up a json for redeeming a p2wsh scriptpubkey that has the very simple, single opcode redeemscript CHECKSIG, where the input's amount is one BTC.  The input's txid in this example is just FFFF...FFFF.

'[{"txid":"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF","vout":0,"scriptPubKey":"0020EE6BB86B44339392BAE631C8F61DD8F009243C635ADAB33C0B20923A2794BF22","redeemScript":"AC","amount":1}]'

I've built the raw transaction redeeming this utxo, which is :

02000000000101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000FDFFFFFF01F0B9F505000000002321027777777777777777777777777777777777777777777777777777777777777777AC0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030EFF833692060EB20ABF63FDE930AD0F59BFDDF3FAD321AA5C85435120306FD101AC00000000

To check the validity of this spend, pass both the utxo and transaction to bitcoin core's signrawtransactionwithwallet :

$ printf '%s\n%s\n' 02000000000101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000FDFFFFFF01F0B9F505000000002321027777777777777777777777777777777777777777777777777777777777777777AC0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030EFF833692060EB20ABF63FDE930AD0F59BFDDF3FAD321AA5C85435120306FD101AC00000000 '[{"txid":"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF","vout":0,"scriptPubKey":"0020EE6BB86B44339392BAE631C8F61DD8F009243C635ADAB33C0B20923A2794BF22","redeemScript":"AC","amount":1}]' | bitcoin-cli -stdin signrawtransactionwithwallet

{
  "hex": "02000000000101ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000fdffffff01f0b9f505000000002321027777777777777777777777777777777777777777777777777777777777777777ac0347304402203333333333333333333333333333333333333333333333333333333333333333022055555555555555555555555555555555555555555555555555555555555555550121030eff833692060eb20abf63fde930ad0f59bfddf3fad321aa5c85435120306fd101ac00000000",
  "complete": true
}

To check the correctness of your script, simply replace the relevant values in the utxo and build the spending transaction.
The situation is a bit more involved when validating constraints such as relative and absolute timelocks.  To have extra assurance, you could use Regtest and Testnet to try out your scripts, and even then, if the script is very exotic (maybe using undefined op_nop codes, or other forms of non standard-ness), the transaction be easily redeemable on regtest\testnet but at the same time almost impossible to redeem on mainnet.


How to best explain these transaction fee spikes? How to best explain these transaction fee spikes?

Are these spikes actually transaction fees or accidentally taken as transaction fees because remaining amount not credited back to sending address during partial amount transfer? Is it really possible to differentiate between these two cases?

First of all you'd have to look at the spikes and see if they are the result of single transactions with a high transaction fee or if there were more transactions overall that day.

If you see individual transactions with a very high transaction fee then I'd say it's pretty likely to be a mistake by the sender. Here, for example, is the explanation for the spike on January 10th.

  I've been doing raw tx's without a problem for weeks I guess the
  exhaustion of working over 12 hours per day for the last week has
  clearly taken its toll.

In general though, there is obviously no way to know if someone paid a very high transaction fee on purpose or not.


Law / country specifics to start Ripple Gateway There is requirement in https://ripple.com/wiki/Gateway_Integration_Manual
Gateways should comply with the BSA, have AML policies and require KYC information.
As i understand this requirements can be accomplished only by banks, funds or other financial institutes, am i right?
if so, what is the minimum starters level of capital need to make own gateway?

According to Ripple the url https://ripple.com/wiki/Gateway_Integration_Manual for the Gateway Integration Manual is "DEPRECATED". Ripple says "This page has been replaced with the new Gateway Guide on ripple.com. Please refer to that document instead."

Here is their newer doc: https://ripple.com/build/gateway-guide/

Ripple does not prohibit those who are not "banks, funds or other financial institutes" from building a gateway. Just the opposite. It is in Ripples' best interest if widespread (Ripple compliant) adoption is made. In their example Ripple uses "a fictional online currency exchange named “ACME” and its users as examples, to show how ACME can expand its business to include being a Ripple gateway".

Businesses that link the Ripple network to the rest of the world such as "online financial services, such as payment systems and digital currency exchange" are businesses which could build a ripple gateway.

Looking at the list of Ripple Popular Gateways shows some of the types of businesses which could become gateways:

https://ripple.com/knowledge_center/gateway-information/

These include Panama Bitcoins (http://ptycoin.com/ripple), SnapSwap (https://snapswap.us/ and https://snapswap.eu/), and LakeBTC (https://www.lakebtc.com/) amongst many others.

To answer your query about "AML policies and require KYC information" the specific compliance regimes for this depend on the jurisdiction your ripple gateway lies within, and where your customers reside. For example if your theoretical Ripple Gateway was physically located within the USA then American AML KYC legislation would apply to your business. The same would apply if your gateway was outside of the US, but traded with US citizens residing in the USA. Other jurisdictions will have other legislation. Many crypto businesses have implemented their own brand of AML KYC specific to their own jurisdictional requirements.

There are more countries which do not have definitive crypto legislation than countries which do, so the applicability of traditional legislation itself is even in question for example the lack of a definition of what bitcoin is in each country can create a situation in which it is not clear whether or not legislation including AML or KYC applies to cryptocurrency, or even more undefined internationally, Ripples' legal financial exposure in transferring value globally in affected countries. This will be different in each country.

To answer your question "what is the minimum starters level of capital need to make own gateway?" the level of capital required would depend on the nature of the market you intended to serve. Different markets would require varying levels of financial commitment, the depth of the trust line you wanted to maintain would affect this, and the scope and geolocation of your organizational and technology infrastructure would also come into play.

Overall, it is highly beneficial to understand the law in each jurisdiction your Ripple Gateway will do business in. The opposite is also true.


How do bitcoin nodes sync with the INV mechanism? In When and how does bitcoin node sync itself? it is described that there are a number of ways for nodes to synchronize on the blockchain state.

How does (legacy) INV mechanism works?

If I understood correctly it goes like this:

I get the announcement from a peer that he found a new tip in his blockchain. (so called INV message)
I send him the block locator message with last 10 hashes from the tip of my blockchain.
Me and him could be on different branches so he has to detect which hash do we have in common (the hash where fork happened). Or we are on the same branch and he just advanced the branch by one hash. NOTE: If he does not find the common hash he will ask me to send hashes further back my chain (fork happened somewhere earlier).
When he detects the common hash, he will send me the headers from this hash up to the newly found hash. I validate each header, stopping if a header in this process is invalid.
If his chain is now longer than mine (edit: and download the transaction part's of his blocks, verify them then) I switch to new chain.


How to read the transaction pages on blockchain.info? I read the original Bitcoin paper and think I understand it but I'm having a hard time relating it to the transaction pages on blockchain.info.  For example, sometimes there are 2 outputs and neither of them is back to the sender (what the paper would call "change") which seems to violate the rules of splitting and combining described in the paper.

Is there a good guide on how to read these diagrams?

Change for a transaction doesn't have to go back to the original address: part of it can be sent to the receiver, and the other part can go back to a new address. That way it's slightly harder to trace where the money went, as you don't know which part was the transfer and which part was the change.


How to implement getrawmempool? I’m trying to get all transaction ids in the memory pool as json array. I just finish downloading bitcoin core and do now know where to begin. Any help would be appreciated!!

You can use the command bitcoin-cli getrawmempool to get a JSON array of all transactions that are stored locally in your mempool.

Since v0.9 release you can also pass a verbose boolean to get more info related to the transactions in your mempool like size, fees, or ancestor/dependent transaction within the mempool.

Do note that there is no one global copy of the mempool. The mempool is node dependent and stores valid transactions that your node has seen but has not yet been confirmed in the block. Since you have just downloaded and spun up your Bitcoin Core node, your mempool information might be limited when you compare it to nodes that have been running for days.


What is the proper way to update C-Lightning? I downloaded the latest github .zip for version 0.6 and unpacked it but when I check the version I am running it returns:

v0.5.2-2016-11-21-1644-g1616fcb

Any idea what I did incorrectly? What's the proper way to update C-Lighting from the terminal in Ubuntu?

I just deleted the original folder and installed from scratch.


What was the price of Bitcoin in USD when bitcoin cash forked? What was the USD price of Bitcoin on the various exchanges when bitcoin cash forked?

The price of Bitcoin was around $2900 USD on August 1st. The price slightly went down to around $2600 the same day.


Transferring bitcoins from my blockchain addresses to an exchange? What are the specific steps, in order, required to transfer my bitcoins from their blockchain wallets to a bitcoin exchange?  Please be specific.  Thanks

Assuming you mean "blockchain.info".

Go to your exchange, deposit/bitcoins section. It should give you a bitcoin address, copy it.
go to your wallet, "send money"
enter the copied address and the desired amount
hit "send"


Does a user have to update blockchain to participate in this situation? Say a node was offline for a week. After one week, when this node becomes online again, this node has a blockchain which is shorter than the current blockchain.

If a miner sends block to this node, this node will start to compare this block to his blockchain. However, because this node was offline for a week, this node will determine that the newly created block does not match with his blockchain and conclude that this block is false. So I think this node must be updated to the current version of blockchain and then participate.

Am I understanding correctly?

Thank you in advance.

Yes your understanding is correct, the node must update itself with the blocks generated and accepted after it went offline(in your case about a week ago).

Whenever a node receives a new block, it first looks at its header called blockheader which contains the following:

1.Version (32-bit version the node that mined the block was running).
2.Hash of the previous blockheader
3.Merkle root of transaction
4.Timestamp (approximate time of generation of block)
5.Target for block mining puzzle
6.nonce (solution of the puzzle)

To verify a new block each node computes the hash of the previous blockheader and checks for proof of work. In your case the hash of the previous block-header will not match, so the received block will be considered invalid. Also, the timestamp included in the newly received block will be far ahead in future form the last known block of the validating node which will indicate(not explicitly) that the node was out of date for some time.

To come back in the mining game, the recovered node has to query few up-to-date nodes for all blocks generated after the failure time, apply these new set of transactions to the obsolete blockchain, update the UTXO as per required.


What new JSON-RPC calls are available with SegWit activation? For example, I can see getblock now returns two fields for a block's size:

size (all data) and strippedsize (base block size, NOT including witness data)

Are there any more RPC updates to interact with witness data? Like return the number of segwit transactions in a block? Or return the wtxid or witness data from a specific transaction?

As you mentioned, strippedsize was added as a parameter to getblock() that shows the block size excluding witness data.

txinwitness has been added as value to the response from getrawtransaction() and decoderawtransaction().

That's all I was able to pick up from the RPC... I suspect looping through the transactions in each block and checking for the txinwitness value could get the number of segwit transactions.


Setting up lightning with bitcoin-core I have some questions about bitcoin-core and lightning-network-daemon.
I have succesfully set up a bitcoin node running on Ubuntu Server 20.04 by following this tutorial: https://bitcoin.org/en/full-node.
This is my node: https://bitnodes.io/nodes/81.166.125.218-8333/
I am planning on installing lnd using bitcoind as the backend, by following this tutorial: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md
In this regard, I have the following questions:

What is the relationship between my bitcoin-core wallet and the lnd wallet?
What fee should I set to make my lnd node as profitable as possible?
What other recommendations can you give to help out a bitcoin- and lnd-noob like me?

Thanks in advance for all answers!
Best regards

The Bitcoin Core wallet and the LND wallet are completely separate wallets. LND relies on Bitcoin Core as a source for the blockchain data, nothing more.
The profitability of your node depends on where it is situated in the network's topology. If you want to run Lightning to earn money, you will need to pick reliable nodes as channel partners, but also try to connect some distant parts of the network, or situate yourself on shortest paths in other ways. I don't think it's possible to give a blanket recommendation for fees. You may find this talk from the Chaincode Lightning Residency useful: transcript, video. Then maybe just start with the defaults, look around what others are doing and experiment a bit. You could also pop into the Lightning slack and ask the present experts for advice on that.
Generally, just play around with it a bit, don't worry too much about the proft when you're just getting started. Familiarize yourself with the wallet setup and figure out the backup situation (static channel backups) first. Don't put too much money on the line, it's a hot wallet.


Powering the Butterfly Labs BFG0005G ASIC Miner I got this machine since 2013. I want to put it in use just for the heck of it. It has a USB port for interface with my pc and a power jack. Unfortunately i don't remember where the adaptor is, so how do i power this thing? What volts does it require, is it center positive? Center negative?

I couldn't find any info online.

If it's the 5GHs in this picture:

https://i.pinimg.com/originals/30/5e/a0/305ea076f1dac979e04f44cb4de04ed5.jpg

Then the power adapter looks like 12V @ 7.5A. You might even find one on ebay (check the connectors look right in the photos think you want barrel tip)


When should I use -reindex-chainstate and when -reindex What is the difference between the options -reindex and -reindex-chainstate?

Is one of the options faster?

When should each option be used?

-reindex:

wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index

-reindex-chainstate:

wipes the chainstate
rebuilds the chainstate using the blocks in the index you had before

The latter should be strictly faster, as it does not need to rebuild the block index first. Perhaps the progress bar during reindex confuses you: that progress is only for the rebuilding of the index. The recreation of the chainstate happens after that rebuild is completed.

You should use -reindex only when you were running in pruning mode, or if you suspect the blocks on disk are actually corrupted. Otherwise, when you only suspect corruption of the chainstate (which is far more likely), use -reindex-chainstate.


Step by step to make a SPV bitcoin node As I know, there is a light node version called SPV.
for now I have started a full node and it has downloaded 82222 blocks, but I don't want to have a full node with full blockchain, my purpose is to have a node that provide me:

check balance or unspent amount for an address
sign and broadcast a transaction

is this possible?

By design, Bitcoin Core is a fully validating Bitcoin node and does not have an SPV client mode.

If disk space is your primary concern, you can run Bitcoin Core with pruning active. This will delete old blocks from disk but maintain a full UTXO set which is sufficient for full blockchain validation.

Bitcoin Core can serve SPV clients, although there has been discussion to deprecate this service or at least switch the service off by default. Before using an SPV wallet yourself, you should understand the tradeoffs for both security and privacy.

There are other software libraries capable of running a bitcoin wallet with Simple Payment Verification. One such library is bcoin which is written in nodejs:

https://GitHub.com/bcoin-org/bcoin


Coinbase transaction smaller than .001 btc? & Blockchain says my Bitcoincore wallet is invalid I'm trying to figure out how to send tiny transactions, like 10 cents.  Coinbase says the minimum is .001btc.  That seems rather large.  Is that just a coinbase requirement?
Also, my blockchain wallet says that my bitcoincore wallet receiving qr code is an "Invalid Bitcoin address: "  Why?

Also, my blockchain wallet says that my bitcoincore wallet receiving qr code is an "Invalid Bitcoin address: " Why?

It might be that your Blockchain.com wallet doesn't yet support the Bech32 address format (addresses starting bc1...) introduced four years ago.


When a Ripple-Gateway charges a fee for third parties exchanging their IOU, how is it determined who pays the fee? When a Ripple-Gateway charges a transit fee for third parties exchanging their IOU, who pays the transit fee?

When a Ripple user sends funds, he sets the amount that he wants the recipient to receive and the system will offer a proposition on how much the input for the transaction needs to be.

Upon execution the transaction is atomical (either it happens completely or not at all). The system will use the ledger to find the optimal path and the sender pays all transit fees occurring along the path.


How to make a CryptoCurrency (preferably using Scrypt) in depth I'm looking for a proper guide to creating a CryptoCurrency. I know this probably won't be easy, but I'm really determined, and do know how to code in some languages. (C++ Beginner).

I've heard a link say to apply a new genesis block to the code, don't even know where to start with this stuff.

You can follow the discussions at How To Clone Scrypt Based Altcoins for Fun and Profit

Direct Link:
How To Clone Scrypt Based Altcoins for Fun and Profit ?


Can I estimate time to confirm based on the number of existing transactions awaiting confirmation? Blockchain.info says that right now (1/14/2018) there are approximately 42,000 transactions awaiting confirmation.  It also says that the average size of a block is 1,700.  If the target is 10 minutes per block, that suggests that there are roughly 4 hours of transactions yet to be confirmed.  If a transaction carries with it an "average fee", is it reasonable to assume that it will take approximately 4 hours for the first confirmation, and an hour more for 6 confirmations, given these numbers?  Is there any reasonable way to estimate how that time would change given a change in the fee (other than just accepting some website's recommended fee)?

This is an impossible question to answer, because there will likely be new transactions added to the mempool continuously.

If more transactions get confirmed than are added, the mempool will shrink in size, and lower fee txs will confirm.
If less transactions get confirmed than are added, the mempool will grow in size, and it is likely that higher fee txs will confirm.

As a user, the total number of transactions shouldn't be of concern to you, instead you should look at what the fee rates of currently confirming transactions are, and plan accordingly. If your tx needs to be confirmed ASAP, you should set a fee slightly higher than what you are currently seeing. If you can afford to wait, you can set the fee lower, and hope that the mempool will shrink in size (but this is fundamentally unpredictable, it depends on the actions of all other useres).

Ultimately, you'll really only care about the number of txs paying a higher rate than you are willing to. Those txs are the ones that will affect how long your tx takes to confirm.


Maintaining bitcoins instead of maintaining digital wallet and syncing the blockchain, is it okay if I just use paper wallet now and later import the addresses in digital wallet?
Will I get all my transactions to show up in digital wallet?

Yes that would work. In fact, depending on the wallet, you can even import the address (the public part) and see the transactions. Only when you want to send bitcoins would you need to import the private key.


cloning bitcoin how bitcoin find new nodes I am studying blockchain, cpp and crypto so I cloned bitcoin and created a new altcoin.

everything it is working fine as I expected, but i have some questions which i could not find a answer.

the question it is about nodes,let me explain my case.

I have now 3 VM's running the bitcoin clone wallets which it is a new coin now.

vm 1 = it is connected to the node 100.00.00.0

coinname.conf

addnode=100.00.00.0

vm 2 = it is the server which provide the ip: 100.00.00.0 for the vm 1

vm 3 = random wallet as well connected to the ip 100.00.00.0 for the vm2.

coinname.conf

addnode=100.00.00.0

I removed the nodes and dns from net.cpp for do this experiment ok?

strMainNetDNSSeed[][2]

pnSeed[]

so I started do experiment, turning of the VM 2 which provides the ip for the wallets connect.

after this the VM1 and VM3 lost the connection, fine I expected that.

so my question is, how the wallet VM 1 and VM 3 will connect by themselves and keep the networking running if the VM 2 if the server it is offline? and as well if the 2 users don't know the ip it is sharing the nodes?

I searched this topics bellow but i could not find what I am looking for.

How does bitcoin find peers?

How do bitcoin nodes initially find peers?

https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

EDIT:
the user bellow was right, after while the other wallets get the peers and nodes , so does not matter anymore if the VM2 it is offline, the network keeps on, amazing thing about bitcoin. :)

The client has to download a list of peers when it connects for the first time to the network. Known peers are broadcasted by nodes who previously knew other nodes. All this chain starts however from at least two IPs which are known to both of nodes.

Your clients will check for known peers, after they downloaded a list of known peers from the VM2 (based on your examples) to establish a connection in the event of hardcoded or conf nodes fails.

To be more precise:

The Bitcoin client has a number of sources that it uses to locate the network on initial startup. In order of importance:

1) The primary mechanism, if the client has ever run on this machine before and its database is intact, is to look at its database. It tracks every node it has seen on the network, how long ago it last saw it, and its IP address.

2) The client can use DNS to locate a list of nodes connected to the network. One such seed is bitseed.xf2.org. The client will resolve this and get a list of Bitcoin nodes.

3) The client has a list of semi-permanent nodes compiled into it.

4) The client can connect to a well-known IRC network, irc.lfnet.org, and find other nodes that way. (This method has been removed as of version 0.8.2)

5) It takes IP addresses from the commandline (-addnode) or bitcoin.conf file (addnode=).

Step 5 in particular:

Just add in your bitcoin.conf (or yourcoin.conf) file an addnode=ip.ip.ip.ip parameter as per your nodes.

With this method you can add every kind of peer, from personal PC to server and exchanges nodes or whatever.

Hope it helps.


What keeps bitcoins mined in testnet from being used in mainnet? I've been reading up on how transactions actually work, but I'm not sure I understand how testnet bitcoins are kept from being spent on mainnet. My best understanding is that coins are actually references to transactions on the chain, so referencing a testnet transaction on the mainnet chain would not work. Is this correct?

Yes, that's correct. A mainnet node would just see those transactions as invalid because the outputs they attempt to spend are not in its database. It would have no idea that there is some other network on which they are valid.


Online Bitcoin Script simulator or debugger? Is there an online simulator that would allow me to step through, debug, or simulate the execution of a Bitcoin script?

Highly recommend btcdeb by kallewoof. Among other things, you can step through scripts including verify signatures. It is written in c++ and compiles using autotools.

btcdeb

Bitcoin Script debugging utilities.

This is a set of tools used to debug or construct scripts for use in Bitcoin.

btcdeb> help
step     Execute one instruction and iterate in the script.
rewind   Go back in time one instruction.
stack    Print stack content.
altstack Print altstack content.
vfexec   Print vfexec content.
exec     Execute command.
tf       Transform a value using a given function.
print    Print script.
help     Show help information.


How do altcoins tell each other apart? So there are hundreds of live and even thriving altcoins today. They are all basically a clone of Bitcoin and operate basically the same.

But when you run the mining client for any given coin, how does it know which coin to work on? How does the software know to connect to Litecoin and not Dogecoin, or some other scrypt coin? I realize that when you mine you download the whole blockchain and work on it locally, then when you solve the proof of work for the next block you broadcast it to the network, but this doesn't seem like enough. How do the blocks stay with their respective coins?

Because all these altcoins run on different TCP ports and furthermore (fair) nodes won't relay invalid messages (wrong blockchain, i.e. based on different genesis block, different magic value,  etc.) or IP addresses of nodes running other altcoins.


"comment" and "to" of malleated transactions I'm using the bitcoin core wallet and trying to build some programs around it. I see that comment and to can be added to transactions locally. If I understand it correctly, both are stored in local database and are not public information.

The question I have is whether this will help with malleated transactions. For example, if the transaction I initiated is changed a bit (still valid) and added to the blockchain, would the bitcoin core client attach the comment and to to the malleated transaction when I query for recent transactions?

No, it would not because the malleated transaction is technically a different transaction. Transactions are identified by their hashes, not the inputs or the outputs of the transaction. Since malleating a transaction means that you are changing part of the transaction, its hash will also change. This means that the malleated transaction is actually a different transaction and will be treated as such. So no local information from the original transaction will be added to the malleated transaction unless you explicitly add it.


How do light clients connect to the network? I have a few questions regarding light clients (such as Electrum and Multibit).

Are they connecting to full nodes directly (using port 8333) or to another kind of server on another port?
If they do not connect to the bitcoin network directly (on port 8333), why is that? Why is it necessary to be a full node (with the whole blockchain) to communicate in the bitcoin network?
In the case of Electrum, it seems to connect to an Electrum server, which runs a full node. What are the advantages of doing so instead of connecting directly to the bitcoin network on port 8333 (assuming that it would be possible)?

Are they connecting to full nodes directly (using port 8333) or to another kind of server on another port?

Electrum no, Multibit yes.

  In the case of Electrum, it seems to connect to an Electrum server, which runs a full node. What are the advantages of doing so instead of connecting directly to the bitcoin network on port 8333 (assuming that it would be possible)?

It is a different trade-off. Electrum relies on other servers to index the addresses used in the chain, and queries them. Multibit (and other so-called "SPV clients") ask full nodes to scan the chain for them, but as normal full nodes don't have (or need) a full index of all used addresses, this isn't as efficient.

There is also a privacy trade-off. Electrum's privacy relies on the Electrum servers not being compromised (you can run your own, but few users do). Multibit's privacy relies on the BIP37 bloom filter mechanism for letting full nodes scan the chain for them. This method has been shown to be significantly flawed however, and the (randomly selected) nodes it queries transactions from could easily learn a lot about the wallet.


Missing btc in personal wallet I am missing BTC in my personal copay wallet.

https://live.blockcypher.com/btc/address/1HJKHvzxRjKFDcHopyLqLgL3RhWAGipgYY/

https://live.blockcypher.com/btc/tx/7b99ec55d467578ec3fece195e21a2922f974768210d9ec349dbcd9c57a768e4/

If you did not send the Bitcoin's then someone has access to your account or private key. This could happen many ways, if you have ever shared your login details with anyone or, your backup seed, logged in through internet cafe's or strange computers or if your phone or computer are hacked to name a few possibilities.


What exactly does the "fraud management system" of blockchain checks? Basically, we are webhosting company and accepting payments through Paypal and 2checkout currently.  Due to risk of service being used for spamming,we manually review orders after payment gateway verifies payment and card owner identity. Likewise, 2checkout verifies payer's identity and history of fraud/stolen card associated with it than mark payment as verified.

We want to start accepting bitcoin but as per my initial research I am afraid with the risk of misuse of service.I know the bitcoin's main advantage is that you don't need to provide any identification which is stopping me to add it as payment gateway.

As far as i researched, blockchain verifies transactions on the basis of # number of confirmations which is correct to legitimate the payment. I believe this verifies the source of bitcion and spendability of it.

Question : are there any other aspects in blockchain's "fraud management system" which can assure merchants that payer is legit?

Bitcoin is focused on assuring that the payment is legit.  It doesn't help at all with the payer.

Waiting for confirmations gives you very strong assurance that the payment is genuine and final, and that neither the payer nor any outside authority can do anything to reverse it.  The money is yours, full stop.  There are no chargebacks.

However, you don't get any verification of the payer's identity.  There are no names attached to Bitcoins, only addresses which are effectively anonymous.  (Theoretically there are ways one can try to trace a Bitcoin address back to the person who holds it, but it's unlikely that you'll want to devote the necessary time and resources, and you chances of success are still pretty slim.)

So if someone pays you in Bitcoin for an account which they then use to spam, you can cancel their account and keep their money, but you have basically no other recourse.  You probably won't be able to find them to send nasty letters or pursue legal action or call the police.

Of course, along the lines of "keep their money", you could require Bitcoin customers to put down a large deposit, which you keep if they abuse your system.  However, this could discourage legitimate customers, who now just have to trust that you will return their deposit as promised if they behave; by the same token as above, they have very little recourse if you don't.


Wrongly Transferred! If for some reason I made a wrong transfer to an unknown blockchain account, how do I know who is that belongs to?

In the first place I think it is unlikely a "wrong transfer" because the Blockchain address is not something you can make typo error. I am very suspicious how people can transfer my btc out without my authorization.

Many thanks for answers.

I made a wrong transfer to an unknown blockchain account, how do I know who is that belongs to?

In general you cannot readily find out who owns an address.

If the owner of the address is especially careless, a great deal of detective work may allow their identity to be discovered eventually. This is not a trivial process.

  I am very suspicious how people can transfer my btc out without my authorization.

They don't need your authorization, they only need to have once seen your private-keys. That gives them complete control for all time over any funds subsequently arriving at addresses associated with your private-keys.

As an example, many online-wallets (also called web-wallets or hosted-wallets) give control of your private keys to employees of the hosting service and to anyone who hacks that service. So any dishonest ex-employee might be able to empty your wallet. This sort of thing happens with depressing regularity.


Is there an Android Bitcoin app that can interact with other Android Apps on the same device? Suppose I'm developing a Bitcoin-based Android app.  It could do anything: user pays Bitcoins to play a game, order a pizza, accept charitable donations.  Whatever it does, it does it in Bitcoins, and it's targeted to people who are Bitcoin savvy and probably already have the ability to access Bitcoins on their Android device.  I don't want to deal with the user's wallet, nor do I want the user to have to trust their wallet to my app.

I can think of two ways to do this:

1) there already is a Bitcoin wallet app that runs an  Android Provider that my app can access.  When I need to send Bitcoins from the wallet, my app communicates with the Provider, and the other app gets the user's approval and protects their wallet from my app stealing their Bitcoins.
2) There is a Bitcoin wallet app that I can send an Android Intent to, and as in #1 that other app confirms the user's approval before any Bitcoins leave the wallet.

So I have two questions:

Am I missing another way to do this?  To make an app that can send the user's Bitcoins without me touching the wallet directly but using some other app they already trust?  (And without cutting and pasting a Bitcoin address.)
Assuming this is the way to do it, are there any such Android apps?

A search of Google Play for "Bitcoin" turns up many results, but from a small sample the only ones I've seen that actually transfer Bitcoins seem to work off QR codes or NFC.  They will interact with other Android devices, but I don't see one that interacts with other Android apps on the same device.  But then again, I doubt the description for end users would have information like that.

The answer is the integration-android subproject of bitcoin-wallet.

Start with the source repository for
the Bitcoin Wallet.

The source code for in-app payments is in the BitcoinIntegration.java file, which is under the integration-android directory.

Instructions for compiling this subproject and example source code for using it are given in this slide presentation by Mr. Schildbach

There is also a sample android app that demonstrates this feature.

My thanks to Andreas Schildbach for personally sending me the answer to this question!


How to operate bitcoin core .14 without downloading the entire blockchain with limited hard drive space of 50gb free? I only have 50GB free on my main drive. I read that the bitcoin blockchain is 120gb and you have to first download the entire thing then you can downgrade it to something smaller. how can someone with limit space download a pruned version of the blockchain? Is it possible to put bitcoin core with the 120gb blockchain on a ubuntu virtualbox image that I can use on other computers with it pruned?

If pruning is enabled, old blocks are deleted on the fly while new ones are being downloaded.

With -prune=550 (the minimum value), you're able to run Bitcoin Core v0.12+ with just a few GB of disk space.


How to see the number of segwit transactions in a block Now that segwit is active I am interested to know how many segwit transactions are in each block.

The Blockchain explorers I've looked at don't seem to be tracking this info.

Is there any service that would allow me to view the number of segwit transactions which are in each block.

Look here under "Transactions (Segwit)" tab:

https://oxt.me/charts

And here's a page showing exactly what you're looking for:

http://segwit.5gbfree.com/countsegwit


Lost my BTC or they've been stolen I have a blockchain.info wallet. Last night I decided to set up a wallet for my daughter so I signed out of my account. Created one for her and then had difficulty signing in to mine, I had about 8 attempts then gave up. I then noticed in my email I had an email from blockchain telling me of each of the failed attempts which was me. I then managed to get into my wallet and 99% of my BTC had gone. Is this a security feature or has someone stolen them? Thanks. I have checked the new wallet in case they were there but sadly they are not.

Blockchain.info's My Wallet stores your Bitcoin wallet in encrypted form. This means that anyone that knows your wallet identifier can retrieve the encrypted form of your wallet. One can of course only use/open the wallet with the encryption password.

This does however mean that anyone that retrieved your wallet identifier can try to guess your password as many times as they want. Once they got the encrypted version of your wallet, they can use smart brute force techniques to crack your password.

So, you could have been hacked if both

Someone got hands on your wallet identifier. Maybe you mailed it or mentioned it somewhere. Maybe you got malware or a spoofing browser extension.
You have a weak password so that regular password crackers were able to find your password fairly easily. Try to avoid passwords consisting of only existing words or only lower case characters f.e.


How to get unspents for inputs using bitcoinjs-lib? I would like my simple wallet app to automatically select UTXOs for inputs. I realize that I can't accomplish this with just bitcoinjs, but is there something I can add to it to keep track of unspents? Or is there a way to use some sort of API to automatically select unspents? I do see that it is fairly easily done with btc.com, but I would like to be able to do this with altcoins as well. Thanks in advance!

I would like my simple wallet app to automatically select UTXOs for inputs. I realize that I can't accomplish this with just bitcoinjs

I assume that you are not creating a SPV wallet. In this case,

  is there something I can add to it to keep track of unspents?

No. You have to check if there are UTXOs on your address to be spent even if you store them on your app. Because these UTXOs you stored on your app might be spent by another wallet.

  is there a way to use some sort of API to automatically select unspents?

Yes. This website offers some APIs to select UTXOs with different cyptos( Bitcoin, Litecoin, Dogecoin, and Dash).


On quering the blockchain, can someone read what transaction took place? Like considering the Alice Bob ex where Alice is the customer and Bob is the merchant. If Alice and Bob signed a contract where alice will pay bob on the delivery of a service. The transaction took place at time "t".

Can some one query the blockchain at time "t+10" and see what was the actual contract signed between alice and bob?

We're implementing bitcoin-blockchain smart contracts in OpenBazaar.

OpenBazaar smart contracts are not part of the blockchain. The blockchain stores the multisig contract only; it serves as a depository for the money to stay before a product is delivered.

However, smart contracts are viewable at a later time, and either party can prove that the contract was in fact signed by their counter-party. Whether a public entity is able to view these contracts depends on how the contract was transferred between the two parties. Contracts are general means of exchange, so they can be transferred privately (e.g. via GPG-encrypted email), or publicly (e.g. by publishing plaintext on reddit).

In all cases, contracts are typically GPG triple-signed with public keys, and this signature is verifiable by anyone. If the physical identity of the person holding a GPG key corresponding to an OpenBazaar identity is known, they can be hold liable in traditional law court.

Of course, one of the points of OpenBazaar is pseudonymous transactions between merchants and buyers whose physical identity is not known. In that case, the contract may be displayed in a traditional court, but the court will be powerless. On the contrary, we employ arbiters and mediators that are able to resolve such conflicts of interest between pseudonymous parties, and who can themselves be also pseudonymous if they so desire.


How would interest and fractional reserve banking work in a limited money supply? Suppose Bitcoin lenders (banks, creditors, investors) issue loans with interest. As the total supply of bitcoins approaches the 21M ceiling, the total amount owed in outstanding interest will exceed the money supply.

This is the same as existing banks: they actually hold only a fractional reserve of funds, and the economy as a whole owes itself more money than there is in existence.

The difference is that reserve banks can print more money (yes, with inflation). Bitcoin can't.

An economy can continue to operate, I assume as long as there is enough circulation for a debtor to pay back his interest. However, since interest is compounded, it grows at an exponential rate: over time, wouldn't the total debts eventually outstrip the coins in circulation available to repay them?

Would Bitcoin find itself in a situation similar to the current global economic crisis? How would it correct itself?

It doesn't matter very much because the economy can trivially create substitutes for currency. Anything that has the same capabilities as currency (fungible, easily exchanged, limited supply) can also serve as currency.

A good example would be a Mt. Gox code. Mt. Gox may or may not have 100% reserves, but it doesn't matter. A Mt. Gox code for 100 Bitcoins is basically as good as 100 Bitcoins. If you don't fully trust Mt. Gox, maybe it's as good as 99.5 Bitcoins.

Also, you can "print money" without actually being able to produce currency. For example, say I want to buy a car today and need 2,500 Bitcoins to do so. If someone loans me 2,500 Bitcoins in exchange for an insured IOU to pay 2,600 Bitcoins in six months, the 2,500 Bitcoins I borrowed to buy the car are still in circulation. But there is also now an IOU in circulation that is also worth 2,500 Bitcoins. As that note comes closer to maturity, it's value will go up. So just by time passing, the effective number of Bitcoins in circulation will go up.

This is bad news to the people who don't like the way a modern economy works, oppose fractional reserve banking and currency controls, and think that Bitcoins will bring on a new economy where banks can't create money. But I think it's pretty obvious that the same kinds of things will happen.

The whole Bitcoin system itself is an example of creating money out of thin air.


Bitcoin privacy metrics? I'm looking for a numerical privacy scoring system that estimate the degree of linkage between the members of a key pool (or even just individual key pairs). Ideally, the method should be easy to understand and apply.

I'm aware of "taint analysis" as offered by blockchain.info. There's also discussion in these papers:

Anonymity of Bitcoin Transactions
Evaluating User Privacy in Bitcoin
Privacy-Enhancing Overlays in Bitcoin
Quantitative Analysis of the Full Bitcoin
Transaction Graph

What else has been done to quantitate Bitcoin user privacy? I'm most interested in ways to compute a benchmark score that tells a user how closely linked the the members of a key pool are, or how closely linked two individual key pairs are.

Here is a great video in which they asked: given 1 address I know belonging to someone, how many other addresses can I associate with that particular wallet. It turned out to be about 75%.

The method detailed in the video uses a few assumptions about how wallets work.

Multi-input heuristic: All inputs in a transaction belong to the same wallet.
Shadow change heuristic: Change public keys have never been seen before on the blockchain.
Consumer change heuristic: Transactions from consumer wallets have 2 or less outputs.
Optimal change heuristic: Wallets do not spend unnecessary outputs. This means that a transaction with say 2 inputs of 0.5 each and 2 outputs of 0.6 and 0.4, the 0.4 is assumed to be the change address belonging to the same wallet. This is because if the intended payment is 0.4, the wallet would have chosen a single 0.5 input.


Are "move" operations logged? Are "move" operations logged somewhere in the wallet or somewhere else?

If so, can the "move history" be retrieved, and how?

edit: apparently the command listtransactions lists some move operations, but not all, and I have no clue if there is some criteria, or it is simply bugged.

Yes, all move operations add an accounting entry to the wallet. If listtransactions doesn't show the move, this is most likely to be a problem with listtransactions.


Is proof-of-stake a viable alternative / augmentation to proof-of-work? Meni mentioned Proof of Stake as a possible way to augment Proof of Work as the underlying mechanism powering Bitcoin confirmations.

Is it viable? What are its downsides? Who has analyzed it? (I don't see a lot of people on this thread)

This answer might be enough to make proof-of-stake not needed.


Which cryptocurrency has the smallest block time? What is the lowest block time of any cryptocurrency? I don't mean the time of an individual block, but the target time per block.

What is the shortest reasonable block interval?

There was a coin called Flashcoin that tried to do 6-second block times. I don't think that's being actively mined anymore as another Flashcoin appeared a year later (60-second block times).

Ethereum is planning a 12-second block time. Vitalik makes an argument for why that's probably the minimum for now here. Of course, ethereum hasn't been released yet, but Fastcoin with its 12-second block time is probably considered the lowest block generation time currently.


Payment confirmation (3rd's party point of view) On my site I want to allow two parties to trade between each other without me posing as a middle man. That means that vendor would provide his own address to which a negotiated amount would be deposited. My site would only scrape the public bitcoin transaction list for given address to find out if the payment was done to trigger post processing on my site.

Since people generally reuse bitcoin addresses, checking an immediate balance will not give me a proof that transaction really came through, thus I want to parse all transactions for a given address, filter out those transactions that are older than defined time frame (assume I have timestamp of offer's creation time) and calculate the sum from the rest.

Is this a valid solution or am I missing something?

Why not require the merchant to have a unique address and not allow reuse? They could give you an xpub so you can generate them yourself if that's easier. You don't care if the buyer reuses her address.

I'd be careful with depending on time frames. That sounds fragile.


Does Electrum require the Satoshi client? Bitcoin Armory is a client that sits on top of the official bitcoin client. Bitcoinj is a totally different client, separate from the official bitcoin client. Does Electrum also need the official bitcoin client, or is it separate?

No, Electrum doesn't require Bitcoin-Qt to be installed on your computer. Electrum and BitcoinJ aren't full clients, though, so they do rely on Bitcoin-Qt at some level -- Electrum through the Stratum network and BitcoinJ through the Bitcoin network's SPV mode.


How can I find out if an e-wallet service uses a fractional reserve system? A comment on this answer pointed out that the total amount of bitcoins in circulation could appear to go above the limit of 21m if wallet services use a fractional reserve system. However, in that scenario you actually no longer have bitcoins - instead, you have some kind of bitcoin-credits that rely on a specific 3rd party to be used.

If my understanding is correct, it should be possible to determine through the blockchain whether a given e-wallet service:

Definitely isn't using fractional reserves for a given account, or
Might be using fractional reserves

How would this be done? Has anyone summarised this information for a selection of e-wallet services?

There are two types of EWallets, hosted (shared) EWallets and hybrid EWallets.

With hosted EWallets, all the coins are shared (all customers funds are combined) in the host's EWallet.  Examples of this are Paytunia.com, Instawallet.org, EasyWallet.org, WalletBit.com,  as well as the online wallets with the exchanges, such as MtGox.com, Bitfloor, etc.

Hybrid EWallets are those that operate locally either from the browser (using Javascript) such as how Blockchain.info/wallet and StrongCoin.com operate or from a client like how Electrum (Windows, Mac, Linux, Android) or BitcoinSpinner (Android) operate.

With a hybrid EWallet, the private keys are kept locally but transactions route through the EWallet provider.  To protect from loss, the browser-based hybrid wallets store an encrypted copy of the data from the wallet online with the EWallet provider.  The provider doesn't have the password to decrypt the wallet stored with them and thus has no potential to spend your coins stored with them.

So your risk of fractional reserve exists only with the hosted EWallet providers.

One method these providers could prove they are not a fractional reserve would be to submit to sporadic financial audits.  None do this today.

Another option would be for the EWallet provider to treat each account as if it were a standalone wallet.  That way the blockchain would verify that the coins received have not been spent.  No EWallets operate this way either.

When multisignature becomes functional, this will likely be a security feature available from one or more EWallet providers.


Does restoring wallet.dat require the same paths and configs in servers? I have a Bitcoin core server (Server 1) which is working well. Now I am testing backing up and restoring its wallet on a new server (Server 2).
Imagine that the server 1 has these configs:

blocksdir=/btc/blocks
datadir=/btc/data # wallet.dat file is here in  the wallets directory

Now, I want to move the backup file (wallet.dat) to the new server which its default paths are like this:

~/.bitcoin/wallet.dat
~/.bitcoin/blocks

Do I need to have the same paths in the server 2 for data and block directory as the server 1? Or can I move the backup file to the default path of wallet.dat in server 2?
Should I copy the download blockchain from the server 1 and move them to server 2 too?

A wallet.dat file contains no information specific to a particular install of Bitcoin Core, or its configured data and wallet directories.

You can freely copy just the wallet file to another instance, without having to copy the block data or other information such as peers, mempool, etc.


double spend problem and trust I am very new to bitcoin and sorry if the following is too simple. As far as I understood, if there is a double spend problem, the longest chain - collecting most work - will take over. However, suppose this chain happens to extent the fraudulent, then the there is no way for the network to be aware of the fraud unless some user complains that he did not recieve the money and finds a way to tell the network. Am I right ?  if so how can he inform the network, I mean blockchain-speaking. Is it a just a matter of a public information taht would ruin the trust on blockchain and that gives an incentive not to be fraudulent ?

A blockchain cannot be fraudulent. The blockchain that is "the blockchain" is the valid chain with the most work. If there were a chain which included a transaction that was the double spending transaction but not the original and that chain had more work than a different chain, then that chain is "the blockchain" and is the correct one.

If a blockchain contains two transactions which conflicts with each other (i.e. the original and the double spend are both in the chain), then that blockcahin is completely invalid and no one would accept it unless they specifically modified their software to accept it.

If a user is defrauded because someone performed this sort of attack (broadcast a double spending transaction and the double spend confirmed), the user has no way to tell the network nor does the network care if such an attack occurred. What happened was completely valid to the network so long as only one of the two transactions (either the original or the double spend) is included in the blockchain. This risk is why it is recommended that you wait for a transaction to be confirmed and have multiple confirmations before accepting a payment. The chain containing that double spend is not fraudulent.


Comparing UTXO transactions with Accounts transactions I have seen few websites that compare number of transactions and fees between Bitcoin and Ethereum.
Examples: https://www.flippening.watch/ and https://cryptofees.info/
What does the high number of transactions and fees indicate for a network in this comparison? Does it mean one is used more and better than other?

The only thing which Ethereum community or other altcoins community does better is marketing. I won't even consider it better or sometimes consider scammers or frauds or people trying to spread misinformation. I have never seen such hatred and misinformation being spread in any industry about something like Bitcoin which is the biggest reason why all this exists.

There are few related questions that have highlighted the difference in UTXO and accounts in past:
UTXO model vs. account/balance model
Why is there "Change" in Bitcoins?

https://cryptofees.info/ uses CoinMetrics according to the footer of website. Coinmetrics has mentioned in a post that you cannot compare transactions of UTXO chains with Accounts based chains:

The third column is txCount. That refers to the number of transactions happening on the public blockchain a day. Be aware that for low-fee blockchains, it’s really easy to fabricate a whole bunch of transactions. So this isn’t necessarily that reliable! Additionally, UTXO networks like Bitcoin can batch a whole bunch of transactions into one, so txCount underestimates those ones. You have to therefore be careful comparing the number of transactions on Ethereum with Bitcoin; by its very nature, Bitcoin typically has more transactions than that datapoint suggests. Naively comparing the UTXO to account based systems by transaction count is like watching motorway traffic and comparing the number of buses versus motorcycles to guess at how many people are making trips. Maybe there are the same number of buses and motorcycles – but each bus might have 50 people inside of it.

https://coinmetrics.io/on-data-and-certainty/
Mean transaction fee for Bitcoin and Ethereum according to Coinmetrics:

Outputs per day in Bitcoin:

https://bitcoinvisuals.com/chain-output-count-day
You can also check: https://transactionfee.info/charts/payments-per-day/ (The payments metric counts the number of outputs a transaction has and subtracts one to exclude the change output. If a transaction has only one output, then it’s counted as one payment. The purpose of this metric is to provide a more accurate representation of real economic activity on the Bitcoin network.)

There are lot of other differences and its difficult to compare but things that one should consider while responding to marketing trolls:
Bitcoin doesn't have failed transactions involving any fees: Do we have failed transactions in bitcoin?
Blocksize and Transaction Size (the answers are not updated and gas limit has increased): https://ethereum.stackexchange.com/questions/1106/is-there-a-limit-for-transaction-size/
Bitcoin has max 1.5-2MB of block per 10 minutes on an average
Bitcoin transactions and size: https://twitter.com/murchandamus/status/1262062602298916865

You need smart contracts for batching in Ethereum according to below links:

https://ethereum.stackexchange.com/a/71271/
https://ethereum.stackexchange.com/a/84064/
Lets consider if Bitcoin had no batching and I had to somehow send BTC to multiple people:
3f99102c76af2ecfe7c7da826cbefd8a5d4465ac2c63e88a975df89b23c8bf5d has 1 input and 5 outputs
Size for each input and output involved in tx
   Input: 91 vB

   Output 1: 32 B
   Output 2: 32B
   Output 3: 32 B
   Output 4: 31 B
   Output 5: 32 B

   Size of original tx: 344 / 235 bytes
   Virtual size / weight: 263 / 1049

   Fee for original tx: 0.00019 BTC
If you create 5 transactions to use one input and different outputs mentioned in above tweet, 91*4=360vB extra will be required or maybe more.
If same fee rate is used (73 sat/vB), 0.00026 BTC extra fee will have to paid
SO YOU PAY DOUBLE FEE FOR DOING THE SAME THING and 5x transactions!
One of the reasons batching is used by lot of people in Bitcoin: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

Bitcoin has few layer 2 solutions that are used and thousands of on-chain transactions have moved to off-chain. I couldn't find a website that could show approximate transactions and not even sure if its possible to do it for LN, but below links have related information:
http://bitcoinkpis.com/layer2
https://bitcoin.clarkmoody.com/dashboard/
https://1ml.com/statistics


Could any one show me how to get pubkey in Bitcoin Core? I am new in Bitcoin Core, and I want to get my public key. Could anyone please show me how to get the pubkey?

Try:

$ bitcoin-cli getaddressinfo '<your address>'

{
  "address" : "address",        (string) The bitcoin address validated
  "scriptPubKey" : "hex",       (string) The hex-encoded scriptPubKey generated by the address
  "ismine" : true|false,        (boolean) If the address is yours or not
  "iswatchonly" : true|false,   (boolean) If the address is watchonly
  "solvable" : true|false,      (boolean) Whether we know how to spend coins sent to this address, ignoring the possible lack of private keys
  "desc" : "desc",            (string, optional) A descriptor for spending coins sent to this address (only when solvable)
  "isscript" : true|false,      (boolean) If the key is a script
  "ischange" : true|false,      (boolean) If the address was used for change output
  "iswitness" : true|false,     (boolean) If the address is a witness address
  "witness_version" : version   (numeric, optional) The version number of the witness program
  "witness_program" : "hex"     (string, optional) The hex value of the witness program
  "script" : "type"             (string, optional) The output script type. Only if "isscript" is true and the redeemscript is known. Possible types: nonstandard, pubkey, pubkeyhash, scripthash, multisig, nulldata, witness_v0_keyhash, witness_v0_scripthash, witness_unknown
  "hex" : "hex",                (string, optional) The redeemscript for the p2sh address
  "pubkeys"                     (string, optional) Array of pubkeys associated with the known redeemscript (only if "script" is "multisig")
    [
      "pubkey"
      ,...
    ]
  "sigsrequired" : xxxxx        (numeric, optional) Number of signatures required to spend multisig output (only if "script" is "multisig")
  "pubkey" : "publickeyhex",    (string, optional) The hex value of the raw public key, for single-key addresses (possibly embedded in P2SH or P2WSH)
  "embedded" : {...},           (object, optional) Information about the address embedded in P2SH or P2WSH, if relevant and known. It includes all getaddressinfo output fields for the embedded address, excluding metadata ("timestamp", "hdkeypath", "hdseedid") and relation to the wallet ("ismine", "iswatchonly").
  "iscompressed" : true|false,  (boolean, optional) If the pubkey is compressed
  "label" :  "label"         (string) The label associated with the address, "" is the default label
  "timestamp" : timestamp,      (number, optional) The creation time of the key if available in seconds since epoch (Jan 1 1970 GMT)
  "hdkeypath" : "keypath"       (string, optional) The HD keypath if the key is HD and available
  "hdseedid" : "<hash160>"      (string, optional) The Hash160 of the HD seed
  "hdmasterfingerprint" : "<hash160>" (string, optional) The fingperint of the master key.
  "labels"                      (object) Array of labels associated with the address.
    [
      { (json object of label data)
        "name": "labelname" (string) The label
        "purpose": "string" (string) Purpose of address ("send" for sending address, "receive" for receiving address)
      },...
    ]
}

See https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/getaddressinfo/


Bitcoin mixing and transaction sizes I'm pretty clear on how a Bitcoin mixer obscures transaction history, but I don't understand how an observer is not able to reasonably link the source and destination wallets simply based on the transaction sizes.

Example,

I deposit 100 BTC into a mixing service's wallet
Over some time the mixing service places 100 BTC into another wallet
I have created.

If an observer has some interest in tracking me, they can view all wallet balances and determine which have had 100BTC placed into after my initial transfer to the mixing service. Assuming I don't use the end wallet for any other purposes, an observer simply needs to look for all wallets where about 100 BTC was deposited in them recently. This is probably a small list, and becomes even smaller as the amount to launder grows. If I wanted to launder 10000 BTC through a mixer, there are probably very few wallets that will have this amount deposited into them over such a short period.

The answer seems to be, "keep transactions small when mixing" but in a network where there is not much activity (compared to fiat currencies) it seems like tracking down laundering activity isn't very hard.

The mixing service could use various means to obfuscate the mixing - for example:

It can make you send coins to some off-line address, then send you your coins from its own supply of bitcoins before introducing your coins into the circulation again. This way it would appear that the transaction took place before you send the coins to the mixing service, and thus be harder to link
The service could split your Bitcoins into many smaller amounts and launder them each individually
It could deposit some of your money into some eWallets or similar services that use a shares pool of coins
It could use your money to purchase mining hardware and mint you fresh coins
The service could pay your money back to a few of your receiving addresses, making finding the final amount harder

Generally, there are many creative options of hiding things in the Bitcoin network, you just have to use your imagination.


How long does it usually take to mine a bitcoin block? I am quite new and wondering how long it would take with a single GTX 680? EDIT: I am using a pool.

For solo mining with a single GTX 680, which will produce 120 Mhashes/s, you would expect to find one block approximately every 98 years.

At the current difficulty, solo mining is inadvisable under practically all circumstances.  Pooled mining should be done instead.

Furthermore, mining utilizing graphics cards is rapidly losing viability with the release of FPGA and ASIC-based mining hardware, which operates at far greater efficiency.  Unless you have exceptionally cheap electricity or have a use for the heat output from the graphics card(s) (e.g. heating your house for winter), graphics card mining is unlikely to be profitable for you.

Additionally, mining with NVIDIA graphics cards has pretty much never been worthwhile, as they are far slower and less efficient than comparable ATI/AMD hardware, conflating the above issues with graphics card mining.


How many confirmations is enough if block creation rate is volatile? Right now, the number of blocks created is increasing at a rapid rate.  In addition I tried to import coins into a MtGox account and noticed that even after 8 confirmations the funds aren't available.

Traditionally, the funds were available after 6 confirmations.

After thinking about this, it makes sense that if many blocks are claimed in multiple successions and not enough time has passed, it may be reasonable to wait a period of time before accepting the transaction.

My question is: What is the formula that should be used when counting the number of confirmations required for a tx?
Should I take into consideration the rate of change? ...over what period?

This question seems to be relevant during the increase in hashes coming from the new ASIC line from BFL and Avalon.

Shorter answers:

The number of confirmations you "should" require for a transaction is entirely up to you.

OK, that's not particularly helpful, I know.  For me, looking at the current environment, I'm not planning on doing anything that would justify forcing a wait for any more than 2 confirmations under normal circumstances*.

The level of security that you get by waiting for n number of confirmations is basically constant.

If at some point in the past, you made an informed decision that n number of confirmations was "good enough", then n should be just as good enough today, possibly better.

Longer answers:

When I make the claim about 2 confirmations, I'm betting against the existence of an entity X who would be able to make the following sequence of events happen (YMMV):

X sends me some number of Bitcoins in a transaction that spends some output A.
That transaction is included in a block accepted by the network at height h (confirmation #1)
A block is accepted by the network building on top of that one at height h+1 (confirmation #2)
I do the thing that entity X paid me those Bitcoins to do.
An alternative chain of at least two other valid blocks, including heights h and h+1, is announced to the network and spends output A to some other place, probably owned by X.
The newer chain is built upon (most likely, but not necessarily, by X him/herself: miners, especially those that got the coinbase rewards from the honest chain, will tend to work on the honest chain for no other reason than it's what they saw first), locking in the double-spend.

Building off the previous note, n confirmations sets the bar for being able to successfully pull off a double-spend attack at a level that increases exponentially with n.

If I think it's unrealistic to expect someone to be able to reliably and cost-effectively do this under normal circumstances* at n=2, requiring n=3 feels a bit paranoid, and don't even get me started about n=6.
Furthermore, even if someone were capable of doing this, they would have to stand to gain more from their victims than some significant proportion of the block rewards before even attempting it.
The opportunity cost of a failed attempt is the sum of all the block rewards that the would-be attacker could have received if he/she participated in the network honestly.

Some thoughts about major hashrate increases and lucky bursts:

Even if the network hits an extremely lucky streak and several blocks are mined in the course of a very short time, the expected amount of work it would take for an attacker to reverse a buried transaction stays the same.  In this way, lucky streaks (and overall increased hashrate) by honest nodes actually increase security, whereas lucky streaks are required for an attacker with <50% of the network hashrate.

Where an increase in network hashrate becomes a bigger concern is when this increase tends to favor a single entity (which could itself be a group of entities).  As this entity gets a higher and higher share of the total network hashrate, reversing transactions buried 6 confirmations deep in the chain becomes a more and more realistic proposition.  According to the calculation from Satoshi's original whitepaper, an attacker with 45% of the network hashrate would have a 30% chance ((.45 / .55) ** 6) of being able to "catch up" from being 6 blocks behind and reverse your supposedly "confirmed" transaction.  So, on average, with those odds (which are high enough to make a lot of people on-edge), this attacker would have to stand to gain more than 70% of the rewards from 6 consecutive blocks in order for this attack to be worth it.

Why is n=6 the recommendation?  I don't know.  My out-of-the-blue guess is that this made a lot more sense back at a time when someone with a lot of extant general-purpose CPU/GPU power could more easily generate blocks than today.  Today, since so much of the honest network hashrate is running specialized computing devices (ASICs), the network hashrate has risen so dramatically that it's unfeasible to expect there to be an untapped reserve of computing power that can come out of the blue and overtake the network at large (which is why I've said "possibly better" above).

Why would MtGox wait more than 6 or even 8 confirmations before accepting incoming transactions?  I don't know, but it doesn't surprise me; that organization never really struck me as having a deep understanding of Bitcoin, despite how important it was to their business and despite the apparent fact that they were running bitcoind with in-house customizations.

*Normal circumstances assume there's no network anomaly going on like the hard fork of March 2013, we're not talking with HUGE transaction volumes, and I have no reason to believe the major mining pools are collectively out to get me.


Electrum: display redeem script of a P2SH utxo I use Electrum with a multisig wallet. I would like to figure out how to prove ownership of a "coin".
I understand that I need to share the whole redeem script so that it's hash can be verified against the UTXO I want to prove ownership off. And then I need to sign a message using at least N of M (as defined when creating the multisig wallets) private keys corresponding to the public keys in the redeem script.
My question is how can I display the redeem script in Electrum, in a human readable way that allows to clearly identify N, M and all of the public keys?
How can I display the data structure encoding the redeem script on the blockchain, whose hash constitutes the ps2h address (without spending the UTXO)?

I did not find a good answer, so I coded a small GUI to perform signatures using private keys, verify a signature using a public key (or an address) and verify a p2sh M-of-N multisig script against a list of N public keys and the parameter M.
This information is easy to find with a simple right click on an address in Electrum (View Details).
https://github.com/PiRK/signverify
I made it primarily for BCHA, but it works for BTC if you paste a legacy p2sh address instead of a CashAddr.


How can Bitcoin be stolen? If each bitcoin has a ledger (Peer to Peer) and contains all the transaction history since it was mined, then how come it can be stolen?
For example, Bitcoins were stolen by hackers from Mt. Gox. If the Bitcoins each have a ledger it would show its owner and the Mt. Gox account. So it would be traceable and hard to trade if stolen.
Maybe I am not fully clear, would appreciate clarification - thanks!

I believe the large threat of theft of Bitcoin or digital assets is through hacking into your account located on an exchange or possibly your wallet.  I do not believe you find theft at this point in time elsewhere.  In the future we may see qubits or quantum computing being able to conquer the blockchains security.  But as of now I believe it is through people hacking your accounts.


Signature on transactions with multiple inputs My question is that, suppose there is a txn tx(k) paid from user u to v, that refers two txns tx(i) and tx(j) as it's inputs. Also, both these inputs are meant for different public keys of u, say, Pk1(u) and Pk2(u).

How does u sign tx(k) for v, i.e. how does she convince v that she owns both of those public keys? Does she sign tx(k) with both Sk1(u) and Sk2(u)?
Thank you.

In short words: yes, if you want to redeem two previous outputs in one transaction - you should sign twice.
The steps for creating such transaction are:

create "template" of transaction for redeeming first output
hash it. this will be digest1.
sign the digest1 with your privkey1. this will be signature1
create "template" of transaction for redeeming second output
hash it. this will be digest2 (not equal to digest1 !)
sign the digest2 with your privkey2. this will be signature2
create the transaction itself with {pubkey1, signature1, pubkey2, signature2}

note: steps 1,2,3 can be made by Alice who has privkey1. steps 4,5,6 can be made by another person, say Bob who holds privkey2. step 7 can be made by everyone