text:
How do I find a "Bitcoin address" for buying Bitcoin?
I am very new to Bitcoin and just learning my way around my Bitcoin wallet, etc. Recently, in order to try to find out more about buying Bitcoin, I clicked on "Buy Bitcoin" in my wallet, but was immediately required to "enter Bitcoin address" before I could go any further.  I don't know what to enter here, or how to find out.  Can someone enlighten me, please ?

What do you mean by "in my wallet"? Was there some specific web page or program that you were using?

You have to download a Bitcoin wallet first. I suggest you to download Electrum, it's a lightweight wallet with easy UI. It will generate an address for you.

You can generate your bitcoin address via here: http://www.bitaddress.org -- make sure you write down or print out your generated private key. You enter your public key into your app you mentioned.

This is terrible advice.

@MaxVernon No, BitAddress is completely client side and famous. The reason that it was not a good advice was that, that website only generates an address, and doesn't have a wallet that you can use to make a transaction, see your balance, etc.. The main point here is "If someone asks 'How to generate an address', we should also mention that generating an address is not enough make transactions, a wallet is also needed"

@MCCCS - perhaps you could improve the answer by adding that the OP would need to have a wallet setup with the keys generated by bitaddress prior to sending transactions to it to avoid losing their money.  I'd guess it might also be important to add guidance making sure they use bitaddress completely offline.


text:
Blockchain pruning and chainstate
In order to reduce the size of the blockchain, we can use pruning with the bitcoin core client. The description of the option says:

Reduce storage requirements by pruning (deleting) old blocks. This
  mode disables wallet support and is incompatible with -txindex.

If I understand other sources explaining pruning, correctly, it will only keep unspent transaction outputs (UTXOs). This is what's stored in the LevelDB in the chainstate directory. Therefore, I would expect pruning to remove all other files (or rather all blk files) and only keep the chainstate DB. I cannot test this myself right now, hence my question.
If someone uses the pruned mode, can you confirm that it uses around 2.5 GB (size of the chainstate)?
Also, why does pruning disable the wallet support?

Pruning does not only keep the UTXO set. It also keeps the latest few hundred blocks, in order to assist with reorganizations.
Pruning was experimental in Bitcoin Core 0.11, and incompatible with the wallet. Since 0.12, it's a fully supported feature that works fine with the wallet.

So does pruning mean: keeping last N blocks, including necessarily all UTXOs, instead of entire blockchain?

It means keeping (a) all UTXOs, from any time and (b) the last few blocks.

source: Stack Exchange

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

sort: votes


text:
Missing public key in transaction input
I'm in the process of understanding scriptSigs of transaction inputs and encountered some transactions with inputs that seem to be missing a public key.
This is what I expect to see as a scriptSig. A signature and a public key.
ScriptSig: PUSHDATA(71)[3044022017e2af6e1308d431365deeb5739d41a909cf0d61a9c0e48f3ae5b0bd6544bfc5022066e73dd26d71d824552b034b322603cce8b936912b99f4f3df512e502bd7c11e01]
PUSHDATA(33)[03d7b3bc2d0b4b72a845c469c9fee3c8cf475a2f237e379d7f75a4f463f7bd6ebd]

https://blockchain.info/tx/10857ad56f1695559562af8076aea4ccba625ba79a82f75e5658c0c2fa4336c0
However, I've encountered these type of scriptSigs as well. There seems to be no public key. What exactly is happening here?
ScriptSig: PUSHDATA(71)[304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901]

https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

That input spends a pay-to-pubkey output. The output it spends from contains the public key, so it is not in the input.

Is there any way to get the public key or associated address solely from such an input without looking back at the matching output? I ask because that would greatly increase the performance of a blockchain-wide analysis I'm trying to do.

No. You have to look at the output it spends from. You should be doing the same for all transactions anyways.

Any suggestions on how I can quickly query the matching output of an input to get the address and value? When walking over the whole blockchain, it's certainly not feasible to maintain a list of all unspent outputs so far in memory.

Make a database which is periodically flushed to disk that stores all unspent outputs. This database would have the entire UTXO set; you just add and remove things as new outputs are made and spent. BItcoin Core does this, and in fact, it can actually store the whole thing in memory, it just requires 6-7 GB of memory to do so. Otherwise just make it a database which is flushed to disk periodically.

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


text:
What prevents DoS based on near-valid block timestamps?
Upon receiving a newly mined block, the block timestamp validation is performed here:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270
Q1: As for the second check (block timestamp too far in the future), what prevents a miner broadcasting a block that's near the limit in the future and having some of the nodes accept the block, while some other nodes reject the block?
Q2: If a part of the network accepts a block and the other part of the network rejects a block (i.e., not record the block it in its blocktree due to invalid time stamp), can the network recover from this in any way?

It is true that this edge case seems to present an issue, however, the block timestamp will either be valid or not since it is the time since the time embedded in the last valid block with most PoW and not the local time in question.
In the case described, which is not the case but, if may somehow or another be the case otherwise, then some nodes may continue to build upon the block that the other nodes reject. How this would resolve will depend on the percentage of the network split. If 51% or greater of mining power rejects the speculative block then the issue will self-resolve in time as the valid chain is extended further than and having the most PoW. If, on the other hand, 51% or greater of mining power accept the speculative block to build upon then an intervention would be required to pick up the nodes still rejecting or, to discard the invalid chain.
Essentially, if a block complies with the consensus rules (the rules of the reference client) then it is valid.
Others have already stated that it is not wise economically to push the time envelope when mining as it must be decided in advance, so there is an economic disincentive.

Thanks for the 2nd paragraph, however the 1st paragraph is wrong: in this case, the upper bound for timestamp validity is determined as local node's time + network time offset (basically estimate on the local time error based on node's peers). As such it's imaginable that a miner mines a block with a timestamp close to the upper bound, and the block gets rejected by some nodes and accepted by other nodes.     ref: GetAdjustedTime() in https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3398

Alright, I accept that detail had slipped my memory. I will re-evaluate the writing of the first paragraph.

@bgd223 Would it not be the case then that in a few minutes the block timestamp would, in fact, be valid? At worst it requires reconsideration of the block or even less, nothing as per G Maxwell's explanation.

Agreed, assuming there's no mechanism that re-rejects already rejected blocks in any scenario. and DoS based on the lower bound in this case does not seem to apply.

It's normal and not a problem for some of the network to be on one tip block while the rest is on another.  When there is a split like this it will eventually be decided by subsequent blocks.
If a block isn't accepted by a node because its timestamp is too far in the future the situation isn't much different: After the timestamp becomes permissible a future block on that fork that would make that fork the longest chain will cause a reorg onto it. So the only difference between this and a split caused by an ordinary block race is that the nodes that rejected the block will take longer to accept it-- not until both the time is valid and a new block appears on that fork.
No intervention is required.

I'm answering both questions at once. It's not uncommon for the network to split i.e. different nodes accepting different blocks as chain tip. In fact this happens from time to time as two or more blocks are found at the same time by different miners. This gets resolved when the next block is found on top one of the previous blocks. The longest chain is valid.
And a miner can't simply set the timestamp when broadcasting. The timestamp needs to be set before finding a valid nonce. Thus a miner is incentivised to mine with a valid timestamp. If the block doesn't get accepted by the network, the hashrate (and electricity) used isn't compensated.

Thanks for tackling this, but it doesn't really address the questions, here's why:  in the case of a "usual" fork you are referring to, the block trees of differing nodes contain both blocks, whereas in this case, the block trees are essentially different and as such they can't sync/switch to a branch with more proof of work. As for miner's incentive when it comes to timestamp manipulation, sure, the miner is not incentivized, but the question is whether this is theoretically possible or not.

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


text:
How does P2SH unlocking work?
"Mastering Bitcoin" by Antonopoulos in its P2SH section describes how the unlocking and locking scripts are executed and evaluated by nodes. The author gives this as example of an unlocking script:
<Sig1> <Sig2> <redeem-script>

and the locking script:
HASH160 <20-byte hash of redeem script> EQUAL

Then there's this:

The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches: [...]

Questions

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.  Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?
If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?
Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?
Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have   a TRUE on top at the end of execution?

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule. Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?

All scripts begin with the same verification process; the concatenate and evaluate. However P2SH has a special extra step. For P2SH outputs, the redeemScript (as part of the first script evaluation) is pushed to the top of the stack. It is then popped from the stack and evaluated as a script with whatever items are remaining in the stack after the first script validation.
Outputs are determined to be P2SH by the template of the output script. All P2SH outputs follow the same template
OP_HASH160 <hash> OP_EQUAL

Any output script that is in this template will be evaluated as a P2SH output. This means that after the first script evaluation pass (concatenate and evaluate), the top stack item is popped and evaluated as a script.

Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Kind of. Nodes that don't support P2SH would still validate the script as passing because the stack is non-empty and the top stack item is not 0 (OP_FALSE).

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.

Nothing uses the "concatenate unlocking and locking script and execute". That approach was abandoned in Bitcoin v0.3.7 (released in July 2010), as it was the reason for one of the two theft-enabling bugs Bitcoin had in its infancy.
The current approach is to first execute the unlocking script, look at the resulting stack, and then execute the locking script with that stack as initial stack. The resulting top stack item determines whether validation succeeded or not.

Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?

It is not so much a different rule - just an additional rule. Because of backward compatibility, network rule upgrades can only add additional restrictions on previously-valid scripts. They can't make invalid scripts valid, as those would risk splitting the network in two (look up "softforks").

If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?

Whenever a spend (a) validates using normal rules and (b) has a locking script that satisfies a specific pattern, defined in BIP16, an addition P2SH-specific execution follows, whose validation result is what matters.

Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?

This same approach is used for a much more recent network rule improvement, called SegWit, specified in BIP141, which is expected to be activated on the network around August 22nd 2017.

Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Yes, by definition, because P2SH only adds additional restrictions. The specific P2SH locking script just checks whether the spender knows the "embedded" unlocking script (also called redeemscript).

as it was the reason for one of the two theft-enabling bugs Bitcoin had in its infancy.    <-- interesting, what is the other theft-enabling bug you referred to? Are these the only direct-theft-enabling bugs that Bitcoin ever had?


text:
How is spamming of the block chain discouraged by the Bitcoin protocol?
I have heard people imply that there are parties that want to spam the block chain for some reason, for example to get more support for higher blocks.
How is spamming the block chain discouraged by the Bitcoin protocol?

It's not really.
Of course there are transaction fees, but in the situation you describe, where blocks are not already full, the supply of available block space must be lower than the demand, and so you should be able to create many transactions at low fees, and miners will put them in their blocks because low fees are better than none at all.
Or, if you are a miner yourself, or have a deal with one, you can fill up your blocks with your own transactions, with whatever fees you like, since they are all going back to you.  (There is a slight risk here: if you make the fees significantly higher than the market rate, the next miner may choose to orphan your block and include those transactions in her own; then she gets to keep the fees you were planning to pay back to yourself.)
There is a slight disincentive for such a miner in that large blocks propagate slower and thus are slightly more likely to be orphaned.
Other miners might notice you are doing this, if you appear to be getting way more transactions in your blocks than anyone else, and so it might not help convince them to support larger blocks.  But it doesn't really prevent the "spam".

authors: Василь Кричвалувшій


text:
Do all Cryptocurrencies uses same Public key Cryptography algorithm?
I have been trying to read about how Public key cryptography works and I have just understand what public key cryptography is and how it differs from symmetric key cryptography.
I have also just read that the bitcoin uses "Elliptic Curve Digital Signature Algorithm (ECDSA)" to generate Public/Private key pairs, and then

the public key is hashed several times until it looks like the
  familiar Bitcoin address.

I then read here, https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated that Ethereum also uses ECDSA to generate key pair and then the Keccak-256 hash of the public key is taken.
My question is, do all the cryptocurrencies in existence uses the same algorithm to generate key pairs ?, if that is true, can a single Public/Private key pair be used to store multiple currencies given that the public key is hashed according to each cryptocurrency standard ?

Not necessarily.
A cryptocoin can use whatever asymmetric algorithm they choose, and I'm sure some have tried different things, but ECDSA has a big advantage: public keys are generated from private keys.
With asymmetric algorithms like RSA, public and private keys are both generated together.  With ECDSA, you choose a random number (within certain limits), and that is your private key.  Now all you have to do is calculate the corresponding public key from your private key.  This makes new address generation quick, and computationally inexpensive.  It also allows for schemes such as BIP32 HD Wallets.
Also be aware that ECDSA can use the same algorithm using different elliptic curves.  Bitcoin uses secp256k1, but other curves exist as well.
In the end, it depends on the currency.  There is so much diversity nowadays, I doubt very much that they all use the same algorithm and curve.

If you would like to see each step, you can look at some online tools, like https://gobittest.appspot.com/ .
Here you can test all values with different prefix and different net byte. Calculation is the same for all bitcoin based blockchain wallets.


text:
How to find the FIFO chain beginning, the platform to a transaction by Transaction ID?
I have a transaction ID here, recipient address and sender address which I thought to be a transaction from some Bitcoin purchase platform such as LocalBitcons.com but I cannot find my purchase receipt.
Is there some way to find out which party is responsible for the transaction by its transaction ID?

Bitcoin transactions are (intentionally) devoid of extraneous information such as 'sender' and 'recipient'. The inputs/outputs do not contain any information about who owns them, and neither does the ordering of those inputs outputs (eg, FIFO is meaningless in terms of analyzing bitcoin transactions).
That said, while this information is not available publicly, the users participating in a transaction will (privately) know at least some of this information (eg, which coins are theirs). But they will not necessarily even know the entirety of the ownership mapping for any given transaction.

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


text:
How many api calls blocktrail allow per second
How many api calls blocktrail allow per second. On official site mentioned only rate per minute(https://www.blocktrail.com/api/docs#rate_limits). Is this mean that I can make 5 requests per second(or can I do more)?

I believe it means you could do all 300 requests in 1 second if you really wanted to, and then wait 59 seconds for the next minute. Doesn't matter when you use them within that minute, just that no more than 300 are used per minute.


text:
Building blockchain on macOS Sierra (10.12)
I am trying to build a bitcoind client or similar program on my macbook so that I can access the blockchain information for analytics purposes. Honestly, I dont have the slightest clue how-to do this though. Can someone please explain? Or better yet, is their a simpler way to view the up-to-date blockchain information that I am unaware of?

have you try using blockchain.info ?

Well, I want to extract the actual transactions themselves- the entire blockchain

Is it possible to download the information from blockchain.info daily in the form of csv using python?


text:
Energy to confirm one block with state-of-the-art hardware at current difficulty level
An earlier answer claims it would burn around $2M worth of electricity to confirm one block using an ordinary CPU.  See:
Energy to confirm one block?
Can anyone estimate what this figure would be for today's state-of-the-art mining hardware?
E.g., suppose I am presented with a chain of 8 block headers with mining difficulty at or above current level.  Without any other information, how certain could I be that they were generated by current blockchain network?  How much would it cost to create a fake, ignoring equipment cost?

Distinguish what a "fake" chain of blocks is.

@eponymous "fake" that includes a transaction which is not really on the Bitcoin public chain.

I have just added an answer to that question explaining how to calculate this for yourself.  It's not that I don't want to help you directly, but we have had this question several times, with people wanting updates every time, and I want to end the cycle.

@NateEldredge thanks, I come up with $61,502 for one block at $.08/kwh using miner with 111,00 MH/J.

Yes, that sounds right.  A good sanity check is to compare with the current block reward: 12.5 BTC, at a market price of about $6,600/BTC, is $82,500.  So there is a decent  but not ridiculous margin to cover hardware costs, maintenance, cooling, infrastructure, and overhead, and hopefully still turn a profit.


text:
How can a ripple wallet trust server?
How can a wallet using ripple-lib to interact with the ledger be certain it is seeing the real consensus ledger?  If an attacker has control of the rippled server, or the connection to it, what is to stop them from falsely verifying that funds have been received?
Is it just a matter of trusting server operator + certificate authority + https?  If you are currently connected to a legitimate server is there some data you can save that would confirm that future transactions were verified by the same entity?

One option would be to ask multiple servers: that way you can as sure as you want that. Or you could just run a server—it’s quite simple—and point the wallet to it since, presumably, you wouldn’t lie to yourself.

Ideally, if you are using the network for anything significant, you would run your own server.


text:
musig2 with BIP-32 style nonce chain
I am interested in the case where a fixed pool of signers will sign a series of many messages.  As I understand it, musig2 would allow pre-processing, whereby a signature aggregator could collect a list of public nonce pairs from each signer in advance, and then consume one pair from each signer for each message to sign.  Signers would need to save the private key associated with each public nonce, and the aggregator would need to signal which one to use for each signature.
I wonder, could the public nonce list be generated from a chain code in the same manner that BIP-32 allows a list of public keys to be generated?  So, signers would commit to "extended public nonces" (R,c),(S,d), and then the signature aggregator would include a sequence number with each message, to define the nonce key pair in the manner of BIP-32?  Or, better, could the BIP-32 sequence number be replaced with some deterministic function of the message being signed?

See my comment here https://bitcoin.stackexchange.com/questions/110811/why-is-it-important-that-nonces-when-signing-not-be-related/110814#comment125641_110814

I wonder, could the public nonce list be generated from a chain code in the same manner that BIP-32 allows a list of public keys to be generated?

Absolutely not. (private) nonces need to be entirely unpredictable to other participants. If your (public) nonces are generated according to a publicly (to other participants) known xpub, that implies a known relation between the corresponding private nonces. This completely breaks the security of MuSig and related schemes. The other participants will be able to compute your private key after seeing a few partial signatures.
There does exist a scheme that combines MuSig with deterministic nonces, called MuSig-DN (disclaimer: I'm a co-author). It is significantly more complex than just a publicly derivable set of nonces however, and involves zero-knowledge proofs where participants prove to each other their nonces were generated honestly.


text:
Logic thread between output folders and input transactions
I'm studying the bitcoin protocol and I don't have very clear things, for example the logical thread that exists between an output transaction and a subsequent input transaction, where that output is direct.
I realized that the input transaction contains the reference to the output transaction through the Outpoint type, but now how could the input transaction related to the output transaction be identified?
an example
Bob sells a coffee to Alice and Alice pays in bitcoins, then bob spends his input transaction coming from the alice output transaction, Now I want to find and the two Rawtransactions where the alice transaction information and the bob information are contained for connect the two RawTransactions.
I believe that I haven't understood any important steps to do this
Sorry for my terrible English but I'm learning

When Bob sells coffee, Alice first constructs a transaction spending one of her available inputs to an address owned by Bob. The resulting transaction gets put into a block and is given a txidto identify it. The txid is the double-SHA256 of the serialized transaction.
Within the transaction, there may be multiple outputs - one of these will be the output which is locked with the hash of Bob's public key. The output is referenced by its index within the transaction, called the outputIndex. Collectively, the txid and the outputIndex make up the outPoint.
The output which now belongs to bob is an unspent transaction output (UTXO). The bitcoin client keeps a map of all UTXOs in a memory-mapped database, so that they can efficiently be found from their outPoint.
If Bob wishes to later spend the UTXO, he creates a transaction with the input using this outPoint and the outputs containing a (eg P2PKH) script for where the money gets spent. He signs the transaction, and inserts the signature into the scriptSig for the input being spent.
The validator of this new transaction will look into the UTXO set to find the previous transaction where Alice paid Bob, and will extract the txout from it. They will validate the amount being spent, and the scriptPubKey will be evaluated to make sure Bob can spend it. If the transaction is valid, the new transaction outputs will be added to the UTXO set and the original transaction where Alice paid Bob will be removed from the UTXO set.
This makes normal operation of the bitcoin protocol efficient, but it is inefficient for querying historical data as block explorers do for example. The main reason is because the txids are not stored in the blockchain data, only in the UTXO set. To find a txid not in the UTXO set would require scanning the entire blockchain and recomputing the txid for each transaction until you find the one you're interested in.
For that reason, block explorers, or similar software, will maintain a completely separate transaction index from the blockchain archive, where they can discover any transaction based on its txid and find where it is located in the chain. If you are re-indexing the blockchain in such way, it is also possible to add relationships in the forward direction, so that you can find the transaction input which spent a particular output. You would need a lot of additional storage for the txids and their indices.

A stupid question, when bob output is spent and then removed from the bitcoin map of all UTXOs how can it recognize that unspent output belongs to bob? I think that the body of the scriptPubKey and the script sing that bob goes to create when it spends the transaction of alice are the same, but I'm wrong right?

When Alice pays Bob, she embeds his public key hash (the pay-to address) into the scriptPubKey in the transaction output. When Bob later wishes to spend this money, he must digitally sign the spending transaction with the private key corresponding to this public key. He puts his public key and the digital signature into the scriptSig of the input. This signature can be verified by anybody that it matches the public key, and that the public key given matches the hashed one which Alice previous put in the txout.

The signature and public key from the scriptSig are both pushed onto the stack, then the scriptPubKey is evaluated with this stack. The pubKey is first duplicated (OP_DUP), then hashed (OP_HASH160), compared for equality against the PKH embedded in the script (OP_EQUALVERIFY), and finally the signature check is performed (OP_CHECKSIG). If the script evaluates true, it can mean only Bob was able to spend it because only he could've created the signature.

So to create the logical thread between output and future input you have to run the script?

The link between next input and previous output is defined by the outPoint in the txin, but is verified by running the scriptSig of the next input followed by the scriptPubKey of the previous output.

Let us illustrate this using the example given in Mastering Bitcoin.
Joe sent 0.1 BTC to Alice in the transaction having txid = 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18. Below are the outputs of that transaction:
vout": [
    {
        "value": 0.10000000,
        "n": 0,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK"
            ]
    }
]

When Alice spends these earnt bitcoins to Bob Cafe, she references this transaction in the input. Note that the input includes the txid of the transaction through which she earnt her bitcoins and the n=0 which shows output number of that transactions that was directed to the address she controls.
"vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig": {
                "asm": "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
                "hex": "483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf"
            },
            "sequence": 4294967295
        }
    ],

Full nodes maintain a UTXO set through which they can easily cross-verify this data to ensure, the txid and n referenced by Alice has not been spent previously. If Alice wanted to spend more than 0.1 BTC to Bob Cafe, she would have had to reference multiple transactions as the txid and n she referenced only has access to 0.1 BTC.

The question that comes to my answer is the same as the one I gave to the previous post, I avoid duplicating it


text:
bcoin daemon killed over and over again [BCOIN]
I am setting up a full bitcoin node using BCOIN.
I spinned up a VPS on Google Cloud. Specs: 2 CPUs and 7.5 GB of RAM. 500gb of standard storage. OS: Linux ubuntu.
As I start the daemon, things go well at first. Then, I receive less and less blocks and after 10-15 minutes the daemon gets killed.
I even tried to beef up my VPS with 4 CPU and 15 GB of RAM. I also added a SWAP file. Same resault: deamon dead after 10 minutes.
I checked resource consumpion and it seems that there is plenty of spare RAM and CPU. So the VPS set up is not a problem.
Can anyone help me to solve this problem ? Thanks :-)

Are you running the latest version master branch on github? Feel free to tell us your specific config, etc on IRC #bcoin (freenode) or on our slack, https://bcoin.io/slack-signup.html And what version of nodejs are you running? Minimum for bcoin is 10.0... See also this issue: https://github.com/bcoin-org/bcoin/issues/899

At this time, bcoin requires nodejs version 10.0 or greater.


text:
Sorry newbie, I dont get the PoS block creation, to much contradiction
I am sorry for the repeat question but I cant find a clear answer. Most of the time PoS isnt explained in detail (only explaining the advantage) and a lot of sources contradict each other and now I am confused.
I think I get PoW but I dont get PoS:
1) there seems to be two types of PoS. One where everyone bets on the most likely block to be picked and another where one node is chosen to validates the block based on the amount of coins you hold and some other factors... is that right? In the first case who decides which block to pick?
2) In both cases it was mentioned, that there was no need for miners. So if you only bet or validate, who creates the block in the first place or is creating the hashes? Or does PoS not use hashes anymore? If yes how do they validate with the ledges of the other nodes?
3) If PoS uses hashes and taken there is no competition of who completes the hash first, isnt there a risk that the chosen one cant compute the hash in time because of e.g. insufficient ressources?
4) Isnt the security less then PoW? As far as I see it, if the function only chooses one node isnt it in theory possible to alter the blockchain? Hashes arent bond by mining power anymore and the current node is the sole active one...

Welcome to bitcoin.stackexchange. To get a better chance of receiving answers, edit this and remove 2-4 and put them each into separate questions. Please try to make the title useful for other people in the future who have the same question and who are searching for answers.

POS distributes valid block rewards proportionally to stakers. However, majority stakers cannot be unseated if they do not wish to trade their stake. A 51% staker can control/censor the system indefinitely.
POW always allows for new hashrate to come online. If fees increase, new mining will join, thereby diluting a potential 51% miner. Because external hashrate can always be added, the Power of any miner can always be balanced That is not the case with POS.


text:
Could not update Copay to 5.2.0
After you release about "Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Wallets".
I could not update the wallet to 5.2.0. In App Store there is only 5.1.0 version.
Iphone 5se, iOS 12.1
What should I do? And hoe to secure my funds?

To clarify: CoPay has no relation to Bitcoin.SE, it was CoPay that issued that statement regarding the vulnerability. Bitcoin is a decentralized cryptocurrency, and Bitcoin.SE is a technical Q/A help site.

The statement released by CoPay/BitPay says the following:

A security update version (5.2.0) has been released and will be available for all Copay and BitPay wallet users in the app stores momentarily.

If you do not see the v5.2.0 app available yet, I would suspect it will be available shortly. In the meantime, according to the statement above, do not open or run the old version of the app. Wait until the updated app is published, and then upgrade your app and follow any instructions provided by CoPay/Bitpay.


text:
Is encryption really needed for blockchain to work?
Is it right to say that Bitcoin and other blockchains do not use encryption? I read somewhere that blockchains rely on digital signatures and hash functions but not on encryption, and that encryption is only used on the client side (e.g. crypto wallets)… But it seems that encryption is also part of these other cryptographic techniques… So I’m trying to clarify whether blockchain technology needs encryption or not. Thank you!

Bitcoin does not use encryption, and does not need to in order to secure ownership of coins. Ownership of coins is proven by digitally signing a transaction with the owner's private keys. The signature can be validated by anyone using the owner's public key.
Encryption obfuscates data for anyone that is not authorized to view (decrypt) it. Bitcoin cannot encrypt data that is stored in the blocks because the data needs to be able to be validated by all users (to prevent double spending).
Encryption is used, however in wallets to secure one's private keys, but that depends on the wallet software and how they've chosen to implement this type of protection. For example, Bitcoin Core wallet has a way to encrypt the wallet with a passphrase, see RPC Docs - Encrypt Wallet, but this is not essential for Bitcoin, users can use any wallet application.
Edit: As pointed out in the coments, a point of confustion is that Bitcoin uses Elliptic Curve cryptopgraphy, not RSA. This means that a digital signature in Bitcoin does not use encryption like RSA does, but instead an algorthm called ECDSA.

Thank you for replying. In regards to the creation of digital signatures, is there any encryption in the process? I mean, using the private key to sign the transactions involves encryption or not really?

NP, The answer is no, in fact they are completely different algorithms. See https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme and https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Interesting. One last question... I heard that "digital signature is a hash string of the data encrypted with the private key and that pub key can decrypt it to see the hash in clear text"... So this sentence is completely wrong?

Yeah that's not quite right because they are different algorithms. Generally put, "A digital signature is the result of running the data hash through the digital signature algorithm along with the private key."

@Shala There are some digital signature algorithms for which signing is effectively "encrypting with the private key", most notably RSA. This is not true for all algorithms though, and certainly not for ECDSA (also, ECDSA cannot be used for encryption at all).

@ShalaMesk: yes signing and encryption are different, even for RSA. See links at (my) https://security.stackexchange.com/questions/159282/#159289

As @JBaczuk pointed out Bitcoin‘s blockchain does not use encryption. However, other schemes like ZeroCash (ZCash) and Monero do use encryption to send private data to the receiver. In these confidential currencies the miner does not need all the information to verify a transaction. It only learns that the transaction is correct not why it is correct. The transaction details, such as the amount, is then encrypted under the receivers public key such that the receiver can later spend the transaction outputs.


text:
Can transaction be stuck in the 'processing' stage and has not been mined by the Blockchain network?
Can transaction be stuck in the 'processing' stage and has not been mined by the Blockchain network and due to this, it cannot reflect in wallet ?
My friend send me a bit coin but it did not reach me, Can it get stuck in the

Yes, if the fee is not enough then it can take days and then it will be canceled.


text:
Txindex=1: how to recognise the blockchain with this option?
This might be a dumb question: I started the Bitcoin daemon for an initial blockchain download. It immediately started downloading, I edited the Bitcoin.conf file with txindex=1. Stopped and restarted the daemon. How can I be sure the blockchain has txindex=1 correctly set? Should I reminded with the command line Bitcoind -reindex
How can I understand “looking” at a blockchain (day I downloaded from a torrent) that has txindex=1? Thanks

You can check the debug logs (might require -debug flag) and see if it is indexing transactions:
$ tail -f ~/.bitcoin/debug.log

You can also try to get a transaction by txid, and if it returns transaction data, then the blockchain has been indexed for transactions (might have to wait for sync to complete):
$ bitcoin-cli getrawtransaction {txid}

Will this ensure that the txindex contains all transactions, even those from blocks that were downloaded before -txindex was enabled?

@NateEldredge You can test it by fetching the transaction from block 1: bitcoin-cli -datadir=. getrawtransaction $(bitcoin-cli -datadir=. getblock 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 | jq -r '.tx[0]')


text:
Can a non-miner third party help other people's transactions to confirm faster?
If I recall correctly, in 2017, when the mempool was full, there were some guys bumping other people sent transactions that were stuck in the mempool.
Is that possible? How does that work?

No, in general non-miner third parties cannot influence the priority of transactions except by outbidding them.
Unconfirmed transactions can only be reprioritized by either the sender or one of the recipients:

Any recipient (including the sender if there is a change output) can craft a child-pays-for-parent transaction that will incentivize the inclusion of the stuck parent.
The sender could publish a new version of the transaction, if it was flagged as replaceable (via BIP125) upon creation, or if they attempt an outright doublespend.

The service you describe was offered by mining pools. These mining pools would promise to include the transaction in the next block they'd mine in exchange for an out-of-band payment.


text:
Can dust outputs become an economic problem?
I'm thinking about actually economic problems, not about UTXO set size.
One example would be:
Bitcoin adoption gets global and the value of a Bitcoin gets to be ridiculously high, let's say $100,000,000 could that make a large number of dust UTXO (now with a non-negligible value) unspendable? Could that cause any economic problems?
Is there any literature about this?

"Dust" refers to UTXOs whose cost of spending is a significant portion of their total value. In Bitcoin Core's source code, "dust" specifically refers to UTXOs that are smaller than three times their fee at minTxRelayFeeRate. For a Pay to Public Key Hash (P2PKH) output, this is 546 satoshi because an output has 34 bytes and an input has 148 bytes. It's a bit smaller for single-sig segwit outputs.
Given that, an increase of the Bitcoin exchange rate would not directly change the definition of dust, but dust amounts would correspond to a larger amount of purchasing power. On the other hand, the cost of spending such a small UTXO would also be significantly higher, making such payments similarly uneconomic as before, just at higher value.
If the price actually goes up by multiple magnitudes (like the 4,000× you suggest), we may see the minRelayTxFee get reduced by one or two magnitudes. Very unlikely we could even see a hardfork that increases the precision of the amounts on the network to a fraction of satoshis. More likely, the transaction fees on the base layer will be prohibitive for all but the largest payments and smaller payments will live on other layers or sidechains.
Transaction fees in Bitcoin are paid per their blockweight and not per value transacted. This means that on-chain transactions generally don't lend themselves to micropayments since smaller payments have a high relative cost. Micropayments will almost inevitably get pushed out of the blockchain layer to either systems like the Lightning Network, where fees scale with the payment's value, or to off-chain payment systems, where they might be essentially free.


text:
Bcoin vs Bitcoin Core: query your node to list transactions of any address
I am trying to set up a Bitcoin node. It should be possible to query the node through JSON RPC to get a list of all transactions (including UTXOs) of any Bitcoin Address, which doesn't necessarily belong to my wallet. This node should power a wallet application which can be downloaded and used by anyone.
I ve already tried with Bitcoin Core. In the bitcoin.conf file I specified txindex=1. Of course the blockchain was not pruned, but I could only retrive transactions for the addresses inside my wallet.
I learnt that I could add "watch only" external addresses. However, this requires re-scanning the blockchain every time a new address is added, which is a lengthy process. Another option would be to use blockchain.info APIs, but the whole point of my efforts is to avoid relying on third parties.
Finally I found bcoin which is an alternative implementation of the bitcoin client. I read in their documentation that one can create a full-blown table of transactions inserting into the bitcoin.conf file index-tx=true and index-address=true. Anyway, bcoin documentation doesn't specify if by doing this I ll be able to query the node to get transactions for any address I want or only for addresses which are part of the wallet. I 'd rather avoid re-downloading and validating the whole blockchain only to find out.
Can anybody tell me if bcoin can solve my problem?
In case bcoin doesn t serve my purpose, can anybody please tell me what I can do to be able to query my node to find all transactions for any address I want, including those which are not part of my wallet?

bcoin can be run with —index-address or indexAddress: true in bcoin.conf. This will index all transactions by address, a feature I do not think is available in Bitcoin Core.
You can read about the API call here:
https://bcoin.io/api-docs/?shell--cli#get-tx-by-address
Normally switching indexes on or off after a full node is synced would not be allowed. However a recent update to the bcoin indexer module (on GitHub master branch, not yet released or published to npm) allows the user to enable indexing at any time. It will, of course, require a long rescan of all block data to create the indexes.
You can review the indexer update here: https://github.com/bcoin-org/bcoin/pull/758


text:
bcoin.io: Get TXs in reverse order
I am using bcoin for a project.
I would like to retrive TXs in reverse order.
In the documentation I read that I can do that through the "reverse" query string parameter.
Anyway, the documentation doesnt provide any example of how I can pass this paramenter to the javascript API in the getTXByAddress(address) method.
If that's not an option, also the cURL way is fine.
Any suggestions?
Thanks a lot

You're right, the reverse parameter was added recently and the example in API docs were not updated.
https://bcoin.io/api-docs/#get-tx-by-address
The method now accepts a second parameter which is an "options" object. The line in the example should look like this now:
const result = await client.getTXByAddress(address, {reverse: true});

If you want to ask more specific bcoin questions you can find the developers on IRC #bcoin or on slack: https://bcoin.io/slack-signup.html
EDIT: Actually after a second look at the client code, the new options may not be available in the JS method. So thanks for asking! I'll open a PR for this ;-)

Thanks! I ve already solved the problem the cURL way :-)


text:
How to get a readable format of curl with a transaction?
Using curl https://blockchain.info/unspen?active=... with a valid ID I expect an output (according to my book) in a readable JSON format.
Instead I get:
bitcoin@raspberrypi ~ $ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
{"unspent_outputs":[{"tx_hash":"f2c245c38672a5d8fba5a5caa44dcef277a52e916a0603272f91286f2b052706","tx_hash_big_endian":"0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2","tx_output_n":1,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":8450000,"value_hex":"0080efd0","confirmations":314771,"tx_index":47854970},{"tx_hash":"0365fdc169b964ea5ad3219e12747e9478418fdc8abed2f5fe6d0205c96def29","tx_hash_big_endian":"29ef6dc905026dfef5d2be8adc8f4178947e74129e21d35aea64b969c1fd6503","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":100000,"value_hex":"0186a0","confirmations":259154,"tx_index":71083209},{"tx_hash":"d9717f774daab8d3dd470853204394c82e3c01097479575d6d2ee97d7b3bdfa1","tx_hash_big_endian":"a1df3b7b7de92e6d5d57797409013c2ec8944320530847ddd3b8aa4d777f71d9","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":1000000,"value_hex":"0f4240","confirmations":251313,"tx_index":75974855},{"tx_hash":"3f1df69df90d097981ca9c97ad8b6a32daed345565a433f8c8e472b2dab2ac79","tx_hash_big_endian":"79acb2dab272e4c8f833a4655534edda326a8bad979cca8179090df99df61d3f","tx_output_n":1,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":719787,"value_hex":"0afbab","confirmations":245426,"tx_index":79887883},{"tx_hash":"417bdb6f5db3e830407f94d1a82d1667e738b19da3679b7263ebfb913394efdd","tx_hash_big_endian":"ddef943391fbeb63729b67a39db138e767162da8d1947f4030e8b35d6fdb7b41","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":10000,"value_hex":"2710","confirmations":165235,"tx_index":170905487},{"tx_hash":"d049d6039f9d1cb2625bac294d7465b4b1077bd5bc0e30e01e02b184db524c1f","tx_hash_big_endian":"1f4c52db84b1021ee0300ebcd57b07b1b465744d29ac5b62b21c9d9f03d649d0","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":11100,"value_hex":"2b5c","confirmations":162697,"tx_index":174630347},{"tx_hash":"b8a6470c7a38d0983effed00a3f75c74ba371da1387352f35d1df155851ea8d1","tx_hash_big_endian":"d1a81e8555f11d5df3527338a11d37ba745cf7a300edff3e98d0387a0c47a6b8","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":10000,"value_hex":"2710","confirmations":161791,"tx_index":175949432},{"tx_hash":"a2b9570e26e3991fc999c42dc8c6eea7b06514b61814da1a71b56c6ba2ae651c","tx_hash_big_endian":"1c65aea26b6cb5711ada1418b61465b0a7eec6c82dc499c91f99e3260e57b9a2","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":10000,"value_hex":"2710","confirmations":161782,"tx_index":175955161},{"tx_hash":"05230cb8cd8c6a3788ed41433dfdd68a1a608cc8feb3bc1c29d97ce84bec070e","tx_hash_big_endian":"0e07ec4be87cd9291cbcb3fec88c601a8ad6fd3d4341ed88376a8ccdb80c2305","tx_output_n":0,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":10000,"value_hex":"2710","confirmations":161782,"tx_index":175955664},{"tx_hash":"bd345c2bdbb8c17a0c66a8579ea701830e8248ba21b2d73a5dca21d8e9175fee","tx_hash_big_endian":"ee5f17e9d821ca5d3ad7b221ba48820e8301a79e57a8660c7ac1b8db2b5c34bd","tx_output_n":1,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":3020,"value_hex":"0bcc","confirmations":76597,"tx_index":338789479},{"tx_hash":"892275c430610334994cc5836436515057284cc4572775487c1b06a1b49c5ab4","tx_hash_big_endian":"b45a9cb4a1061b7c48752757c44c28575051366483c54c9934036130c4752289","tx_output_n":1,"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac","value":6236,"value_hex":"185c","confirmations":44565,"tx_index":384311717}]}

This was just a problem of the terminal I used on a mac.
Adding | python -m json.tool to the command does the trick, as described here.
Output now is:
bitcoin@raspberrypi ~ $ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK | python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3571    0  3571    0     0  10043      0 --:--:-- --:--:-- --:--:-- 10087
{
    "unspent_outputs": [
        {
            "confirmations": 314772,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "f2c245c38672a5d8fba5a5caa44dcef277a52e916a0603272f91286f2b052706",
            "tx_hash_big_endian": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
            "tx_index": 47854970,
            "tx_output_n": 1,
            "value": 8450000,
            "value_hex": "0080efd0"
        },
        {
            "confirmations": 259155,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "0365fdc169b964ea5ad3219e12747e9478418fdc8abed2f5fe6d0205c96def29",
            "tx_hash_big_endian": "29ef6dc905026dfef5d2be8adc8f4178947e74129e21d35aea64b969c1fd6503",
            "tx_index": 71083209,
            "tx_output_n": 0,
            "value": 100000,
            "value_hex": "0186a0"
        },
        {
            "confirmations": 251314,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "d9717f774daab8d3dd470853204394c82e3c01097479575d6d2ee97d7b3bdfa1",
            "tx_hash_big_endian": "a1df3b7b7de92e6d5d57797409013c2ec8944320530847ddd3b8aa4d777f71d9",
            "tx_index": 75974855,
            "tx_output_n": 0,
            "value": 1000000,
            "value_hex": "0f4240"
        },
        {
            "confirmations": 245427,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "3f1df69df90d097981ca9c97ad8b6a32daed345565a433f8c8e472b2dab2ac79",
            "tx_hash_big_endian": "79acb2dab272e4c8f833a4655534edda326a8bad979cca8179090df99df61d3f",
            "tx_index": 79887883,
            "tx_output_n": 1,
            "value": 719787,
            "value_hex": "0afbab"
        },
        {
            "confirmations": 165236,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "417bdb6f5db3e830407f94d1a82d1667e738b19da3679b7263ebfb913394efdd",
            "tx_hash_big_endian": "ddef943391fbeb63729b67a39db138e767162da8d1947f4030e8b35d6fdb7b41",
            "tx_index": 170905487,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 162698,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "d049d6039f9d1cb2625bac294d7465b4b1077bd5bc0e30e01e02b184db524c1f",
            "tx_hash_big_endian": "1f4c52db84b1021ee0300ebcd57b07b1b465744d29ac5b62b21c9d9f03d649d0",
            "tx_index": 174630347,
            "tx_output_n": 0,
            "value": 11100,
            "value_hex": "2b5c"
        },
        {
            "confirmations": 161792,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "b8a6470c7a38d0983effed00a3f75c74ba371da1387352f35d1df155851ea8d1",
            "tx_hash_big_endian": "d1a81e8555f11d5df3527338a11d37ba745cf7a300edff3e98d0387a0c47a6b8",
            "tx_index": 175949432,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 161783,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "a2b9570e26e3991fc999c42dc8c6eea7b06514b61814da1a71b56c6ba2ae651c",
            "tx_hash_big_endian": "1c65aea26b6cb5711ada1418b61465b0a7eec6c82dc499c91f99e3260e57b9a2",
            "tx_index": 175955161,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 161783,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "05230cb8cd8c6a3788ed41433dfdd68a1a608cc8feb3bc1c29d97ce84bec070e",
            "tx_hash_big_endian": "0e07ec4be87cd9291cbcb3fec88c601a8ad6fd3d4341ed88376a8ccdb80c2305",
            "tx_index": 175955664,
            "tx_output_n": 0,
            "value": 10000,
            "value_hex": "2710"
        },
        {
            "confirmations": 76598,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "bd345c2bdbb8c17a0c66a8579ea701830e8248ba21b2d73a5dca21d8e9175fee",
            "tx_hash_big_endian": "ee5f17e9d821ca5d3ad7b221ba48820e8301a79e57a8660c7ac1b8db2b5c34bd",
            "tx_index": 338789479,
            "tx_output_n": 1,
            "value": 3020,
            "value_hex": "0bcc"
        },
        {
            "confirmations": 44566,
            "script": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "tx_hash": "892275c430610334994cc5836436515057284cc4572775487c1b06a1b49c5ab4",
            "tx_hash_big_endian": "b45a9cb4a1061b7c48752757c44c28575051366483c54c9934036130c4752289",
            "tx_index": 384311717,
            "tx_output_n": 1,
            "value": 6236,
            "value_hex": "185c"
        }
    ]
}


text:
When installing libbitcoin is there an option to deactivate the warnings?
When installing libbitcoin from here with $ ./install.sh --prefix=/home/me/myprefix --build-boost --disable-shared after most of the compilation is done there are checks of the sourcecode with warnings like this one:
In file included from ./include/bitcoin/bitcoin/machine/operation.hpp:159:0,
                 from ./include/bitcoin/bitcoin/chain/script.hpp:31,
                 from ./include/bitcoin/bitcoin/chain/output.hpp:28,
                 from ./include/bitcoin/bitcoin/chain/output_point.hpp:25,
                 from ./include/bitcoin/bitcoin/chain/input.hpp:27,
                 from ./include/bitcoin/bitcoin/chain/transaction.hpp:30,
                 from ./include/bitcoin/bitcoin/chain/block.hpp:31,
                 from ./include/bitcoin/bitcoin.hpp:24,
                 from test/chain/transaction.cpp:20:
./include/bitcoin/bitcoin/impl/machine/operation.ipp:136:15: warning: ‘size_t libbitcoin::machine::variable_uint_size(uint64_t)’ defined but not used [-Wunused-function]
 static size_t variable_uint_size(uint64_t value)
               ^~~~~~~~~~~~~~~~~~

I was under the impression that the compiling was already finished and this is something that comes afterwards. During this process, which took half a day, my Pi runs out of HDD swap (1,7GB) and crashes. Is there an option to deactivate those warnings?

Possible duplicate of When installing libbitcoin there are checks of the code, why is this?

I asked my question a second time because it is a different question, it is about deactivating.

The warnings are simply a byproduct of the compilation as I told you. You can disable the warnings but it won't make the compilation any faster. You need more memory to compile this code presumably.


text:
Would it be possible to store hashes generated in a file, then brush through them to find out if they are under the target?
I have been wondering if it would be possible to generate hashes, store them in a file, then use them as hashes when mining. When you would mine, you would not generate the hashes, but instead, just compare them to the target. This would be much more efficient, right? Anyway, here is some psudo python code i made up:
import hashlib
while True:
    hash = hashlib generate random hashes
    file = open('hashes.txt', 'w')
    file.write(hash)

or something like that.

Creating ‘random hashes’ will always fail. A valid blockhash must not only be below a target value, it must also use the header of an otherwise valid block as input.

While this certainly could work, the chances of the hashes ever being valid are next to zero.
The reason is, the hashes must not only meet the target requirements, but they must also be a valid hash of the block header, which changes with each block.

So most of them would be invalid or low diff shares?

You might have some high diff hashes (after a lot of hashes) but they would all be invalid.

would it would still be possible tho?

If by chance you happened to use the right block header data as input to the hash function. But you'd have to guess 80 bytes correctly.

How could you make it be able to have shares every  time that are compatable with the block header?

Just pass the block header in to the hash function as input

No, like with this whole put the hashes into a file thing?

You can't. The only way is to actually hash the block header data. When I say it could work, I mean it would take a trillion trillion .... more zeroes ... years


text:
Newly generated coins
New to BTC world so my question is how and what can I do with newly generated coins what's the process and how to see balance of that in wallet? Can I send those to paper wallet

You can only generate coins by mining new blocks, but you can receive coins from anybody (via trade or donation). What do you mean by newly generated coins?

New to BTC world

Be very very careful about who you trust. Do your own independent research. Reading old questions on this website is a good start.

what can I do with newly generated coins

People often ask this sort of question after downloading a mining game to their phone and "mining Bitcoin" on their phone. Unfortunately those are not real.
If you have real Bitcoin you already have a wallet, your wallet will show how many bitcoin you control.
Beware of watch-only addresses that let you see bitcoin amounts that you do not own and have no control over.
Beware of "testnet" bitcoins that are worthless.
Newly mined bitcoins are generally associated with a bitcoin-address that is controlled by the miner or mining pool. That address was derived from private keys which will be held in a wallet.
Mining bitcoin isn't something you can do casually.

Well the newly generated coins are in the blockchain.info they were donated to me from a friend and I'm trying to transfer those into my wallet and have been watching tutorials if the proper procedure.


text:
Can i create wallet services of bitcoin core wallet
Is it possible to create wallet url services for bitcoin core wallet

There is no clear definition of "wallet service". Core offers an RPC interface which is  kind of a wallet service.

URL services of wallet so that i can run in web

It's still very unclear what you mean. You want to access it in a web browser?

Is it possible to create wallet url services for bitcoin core wallet

Yes it is possible.
It is possible because Bitcoin core has a Remote Procedure Call (RPC) interface usable with many different programming languages, including those popular for creating back-end web-services accessible from web-browsers.
The developer reference says:

The Bitcoin Core RPC service listens for HTTP POST requests on port 8332 in mainnet mode or 18332 in testnet or regtest mode. The port number can be changed by setting rpcport in bitcoin.conf. By default the RPC service binds to your server’s localhost loopback network interface so it’s not accessible from other servers. Authentication is implemented using HTTP basic authentication. RPC HTTP requests must include a Content-Type header set to text/plain and a Content-Length header set to the size of the request body.
The format of the request body and response data is based on version 1.0 of the JSON-RPC specification. Specifically, the HTTP POST data of a request must be a JSON object

Exactly how you would write new software to use this is a software-development/programming question. For example see How to communicate between Java and bitcoind?

URL services of wallet so that i can run in web

No, the API is RPC based. Maybe you are looking for something with a RESTful interface accessible from an ordinary web-browser or a ready-made custodial-wallet HTTP service - in that case I suggest searching using an Internet search engine of your choice.


text:
how the FruitChains consensus works in bitcoin
I came across the paper  FruitChains: A Fair Blockchain. The basic nakamoto blockchain algorithm seems to be slightly twisted with using fruits instead of directly inserting transaction in to the blocks.
Are the transaction first computationally solved in to fruits and then inserted in to blocks later?
How the fruit chain works in a simple language?


text:
how pool mining works?
To my understanding, miners with small computational capacity are merged within a pool with the advantage to reduce the variance of rewards.
does this miner merge all the computational power so that Pow is calculated quickly??
But it is said that the even in the mining pool , there will be only one miner who will solve the puzzle and the reward is shared by the others miners in the pool depending upon the shares solved by them . The miner leader will identify the ones which are active in solving with providing the puzzle with lower difficulty and share the reward with them.
If there is only one miner finally which solves the problem. How is this miner helped by other miner for computation? if this one miner uses only its computation power then what is different in mining solely?

Whenever a miner makes an attempt to solve the mining puzzle, the probability that this particular attempt will be successful is independent of how many other people are trying and even independent of how many times that miner has tried before this attempt. So, they don't help each other at all in solving the puzzle.
All mining pools do is share the reward in proportion to the difficulty share you were able to compute. Think of it like a casino 777 machine, or lottery. If you win, you keep all the reward. But if you go with 100 friends and you decide to split the reward, you get more consistant income.
Your friends are not helping at all in winning the lottery, your chances of winning are still the same and expected reward is the same. Just that variance is reduced.

Mining is a game of luck, only one miner ends up mining a block but they all compete. Its like buying a lotto ticket. If one person buys a lotto ticket (i.e. mining by themselves), they will get to keep all the winnings to themselves if they win, but there chances are very slim at winning. On the other hand, if 20 people all buy lotto tickets together and agree to share the winnings between all 20 if any of the people wins, they have 20x higher chance of winning together, but get only a 20th of what they would have got if they were alone. That is what is meant by a more consistent income, you get a lot less per block but its more likely that you will at least get something, not nothing.


text:
Why does bitcoin-cli not know about working directory of bitcoind?
I have a /ect/systemd/system/bitcoin.service with the following content and I am wondering, why bitcoin-cli getinfo tells me about a configuration file elsewhere:
error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/pi/.bitcoin/bitcoin.conf)

Content of bitcoin.service, especially -conf=/home/bitcoin/.bitcoin/bitcoin.conf:
[Unit]
Description=Bitcoin daemon
After=network.target
[Service]
ExecStart=/usr/local/bin/bitcoind -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid
# Creates /run/bitcoind owned by bitcoin
RuntimeDirectory=bitcoind
User=bitcoin
Type=forking
PIDFile=/home/bitcoin/.bitcoin/bitcoind.pid
Restart=on-failure
# Hardening measures
####################
# Provide a private /tmp and /var/tmp.
PrivateTmp=true
# Mount /usr, /boot/ and /etc read-only for the process.
ProtectSystem=full
# Disallow the process and all of its children to gain
# new privileges through execve().
NoNewPrivileges=true
# Use a new /dev namespace only populated with API pseudo devices
# such as /dev/null, /dev/zero and /dev/random.
PrivateDevices=true
# Deny the creation of writable and executable memory mappings.
MemoryDenyWriteExecute=true
[Install]
WantedBy=multi-user.target

bacause it not have the information for the rpc framework, this is an comple example of bitcoin.con, click me

Thanks, I now understood that bitcoin-cli is a client to bitcoind and bitcoind has to run in server-mode which has to be specified in the config file along with username and password, right?

yes, correct, I have answered inside this post with more details

I posted both questions but I don't think they are related. The other question is mainly about bitcoin-init.

yes, but include this question.

Assuming your ACLs are in check, you can always use the includeconf in your /home/pi/ config to point to your config file in /home/bitcoin.  Then just name the datadir option in the /home/bitcoin config.  This should allow you to use the authcookie without messing with user/pass.  Not that it's cleaner or easier, its just what I do.

bitcoin-cli has to be run with the same user as bitcoind.
Otherwise it will check for the configuration file in the wrong directory, because the default directory is the home directory of the user the process is run by.

The bitcoin-cli use the bitcoin-rpc, so for used a bitcoin-cli, you must ran the bitcoind with the configuration and when it is OK, you can get command with the bitcoin-cli
A simple file configuration could be it
##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##
# On client-side, you add the normal user/password pair to send commands:
rpcuser=alice
rpcpassword=bob

or you can run the bitcoind with this command bitcoind -rpcuser=alice -rpcpassword=bob


text:
Trying to access an old wallet.dat
So I found my old mining wallet from 2012 that I earned some 0.5BTC on, but I'm having trouble accessing the file. I've tried following the instructions here (opening an old wallet.dat), but I'm running into an error using the pywallet program. It throws
File "pywallet.py", line 852
    _p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2FL
                                                                           ^
SyntaxError: invalid syntax
I've tried adding it into a new install of Bitcoin Core, but it appears as though I need to download the blockchain before it will scan my wallet as it isn't showing me any info about the wallet (like previous receiving address). Let me know if I can provide more information.

You're probably using Python 3: you need to use Python 2 in order to run pywallet

Thanks for the suggestion. I switched over to python 2.7, but was running into the same issues. Managed to clean up the syntax and install bsddb, but I'm running into further issues. Now it is throwing:
File "pywallet.py", line 27, in
from bsddb3.db import *
File "C:\Python27\lib\site-packages\bsddb3_init_.py", line 49, in
import _pybsddb
ImportError: No module named _pybsddb

That one should be harmless: do you have any more error lines?

No. Might it have to do with the change I made on line 27? Before it was 'from bsddb.db import *', but I received an ImportError for no module named bsddb.db, so I changed it to 'from bsddb3.db import *' to match the installed library.

The code should handle that: What version are you using? Latest code for pywallet (https://github.com/jackjack-jj/pywallet/blob/master/pywallet.py) has that on line 20, not 27. Maybe you're using an older version?

I ended up using another tool, thank you for your help and patience though.

While I did wait for the blockchain to download and to see if Bitcoin-Core could simply read its own file. The program failed to read in any of the info from my wallet.dat file, even after following the instructions in the post listed in my initial question. I ended up using walletool, which worked without a hitch. It gave me a list of every public and private key associated with the wallet. It has a script for checking your balance, but I was unable to get it to work reasonably quickly and ended up manually checking the balances of each address using bitref.


text:
Am I Being Prodded By A Bitcoin Mining Scammer?
I had someone approach me via an insta post, because i found his account and liked a photo. He said he was a bitcoin miner and forex trader in LA california, and asked if i was interested in earning returns daily. We exchanged whatsapp numbers and the conversation below happened (hopefully the pictures upload

After this he led me through the process of downloading and setting up a wallet with the app BlockChain (popular trusted app right?) And showed me where the recieving wallet was. I shared my receiving wallet code with him.
He then had me go on the site www.coinmama.com to buy bitcoin for my wallet.
I told him i would do this tomorrow, and am now trying to think the situation over.
Is there a scam around bitcoin mining that involves this process, and what should I be aware of?
I don’t plan on sharing my sending code to anyone, or my bank account. But if he knows my receiving code, is he planning on scamming all the money?
Many thanks for any replies. I have a nominal education on the exchanges but I have a head in me, and a massive scam detector.

He wants you to join him in the restroom?

Bitcoin mining is a real thing, and some people do make profits at it, if they have invested a lot of money in expensive hardware and found access to cheap (or stolen) electricity in some part of the world.  But the profits are not anything like the annual 600000% he's promising.

This is most certainly a scam, the scammer's messages explaining  how Bitcoin works are pretty much nonsensical. Disregard all the jibberish he wrote to you, if you'd like to learn about Bitcoin, this is a great question to start with: I am new to Bitcoin, how can I get started?.
DO NOT use the wallet you created with his help. Just forget you ever created it, if you want to learn to use Bitcoin, you must create a new wallet in the future.
There is a known scam where the scammer will 'assist' when setting up a wallet, and they will copy down a wallet 'seed phrase' that will let them re-create your wallet on a different computer later. It doesn't matter if you change your password, once they have the seed phrase they can have access to your coins.

thanks so much. i communicated with him today, and grilled the f*** out of the conversation. i asked for him to lay out the entire process. he wanted me to go to a website (cryptofuriouz.com) where i would set up an account and “invest” $500US worth of BTC, and he would “manage the account”.  i asked why HIS PHONENUMBER was on the contact page, and he’s like “Oh, i’m the only manager”. So i told him straight up he’s trying to get me to walk my money right to his wallet somehow. He gave up after that. Again, thanks for the reply!

@epc ah, I didn’t see the latter half of your comment, ignore my first reply. I’m glad you got away without being scammed, since scammers are usually good at making themselves look legit to laypeople. Bitcoin is interesting and exciting tech, but it is worth doing your own research to learn about how it works before jumping in. In any case, there is no legit bitcoin service that promises huge returns, be very wary of any situation like that. Happy to help :)


text:
Where is data stored in paper wallet?
I have a question about paper wallet. I can print paper wallet using walletgenerator.net. But I am confused about how the things works, where is the data about wallet coins stored? Is there global database of all wallet addresses and transactions? How my public key is paired with my wallet when somebody tries to send me coins?

Is there global database of all wallet addresses and transactions?

Yes, it is called the blockchain.  You can browse it through various websites, called block explorers: e.g. http://blockchain.info, http://blockr.io, http://blockexplorer.com.  If you use full node software such as Bitcoin Core, you will download a complete copy of this database (currently over 120 GB).

How my public key is paired with my wallet when somebody tries to send me coins?

The paper wallet contains a private key and an address.  From the private key one can compute the corresponding public key, and the address is a hash of the public key.  You can give your address to anyone, and they can send coins to that address; this means that a transaction is recorded in the blockchain showing a credit of coins to your address.  Other than your address, this doesn't need any further information or involvement from you.
You only need the private key when you want to spend those coins.  Importing that private key into wallet software, you can make a new transaction to spend the coins that were sent to you.  The private key is needed in order to sign the transaction and prove that it is authorized by you, the rightful owner of the coins; but this process does not reveal the private key to anyone else.  (As part of this process, the public key will be recomputed from the private key and included in the signature.  That is easier than including the public key on the paper wallet.)

Thank you for explanation, I appreciate it! So if I want to not use online wallet (for security reasons if their site gets hacked), I need to download complete copy of database for each coin, correct? So I need Bitcoin database, ETH database, ... Or is there any way to use paper wallet without downloading core?

@newbie85: If you have a new question, please create another topic.


text:
how to generate a bitcoin address for each user that registers
I'm working on a marketplace type website and i want a bitcoin address to be generated for each user that registers an account. this needs to be done in php with no javascript

If you're running your own Bitcoind for JSON RPC calls via PHP then you can generate new address for each of your customers by this JSON Call command in PHP like this:
echo $wallet->getnewaddress();

This will echo the new address and stores it in wallet variable. Please refer to this doc https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
I hope this helps.
Thanks


text:
Is it possible to explore the blockchain without downloading the blockchain?
I'm doing some experiments involving bitcoin and the blockchain, and I need to access some informations about addresses, block, and transactions. The problem is that I need a lot of data, so I can't use online APIs such as blockchain.info.
I know it is possible to do such things by downloading and accessing directly the blockchain, but this solution is pretty impracticable, given its size. Is it possible to access this data without downloading the full blockchain? For example by directly making some kind of request to the nodes?

Can you include what exactly you need from the blockchain? The answer will depend on what you need and the information that you already know.

For example, I would like to get the amount of bitcoins an address has or the addresses involved in a transaction

To get anything other than blocks, you will need to download the entire blockchain. The only things you can request from a node is a block if you know the block hash, and transactions, if you know the transaction id AND the transaction is still in the node's mempool. Transactions which have already been confirmed cannot be requested as the node will have removed the transaction from its memory and stored it to disk with the block. Everything else requires the full blockchain as they are mostly human abstractions of the blocks and transactions that are not relevant to the network.
The "balance" of an address (besides technically not existing) can only be found by having the entire blockchain and reading through the blockchain and scanning all transactions for any inputs and outputs that are associated with that address. Getting the transactions that an address is involved in requires doing the same thing. This is because addresses don't exist to the network as they are only abstractions for humans to more easily think about transactions. Balances don't exist either as Bitcoin does not use an accounts or balance system for tracking money. Rather it is all based on transaction outputs.


text:
How do I load money into my bitcoin account
I don't understand how I load money into my bitcoin account so I can send it to someone

The process of trading money for some amount of a commodity is known as "buying". So what you are asking is how do you buy bitcoins. The short answer is that you find someone willing to sell them to you and give them money.

Bitcoin is an asset that you can purchase, more like an electronic version of a precious metal coin than like a payment service that you load money into.
To get Bitcoin you need to buy it from someone else or have someone pay you with it for providing some product or service.
To buy Bitcoins you can use services like Bitcoin exchanges (Popular exchanges in the US today are services like Gemini and Coinbase) or you can meet people in person and trade for bitcoin peer to peer (a popular service is localbitcoins).  The set of services available to you will be different depending on where you are.
As always, beware of scams online.  If you have any friends that use Bitcoin you can ask them for advice about what services they use.


text:
ECDSA signature with r value of 31?
occasionally on Android we are generating an ECDSA signature. This turns out to have a "r" length of 31 bytes. Is that valid?
For reference here is a nice diagram outlining the ASN.1 structure of such a signature:
how do you figure out the r and s out of a signature using python
Best regards, Rene

This is valid, and there are even smaller types as well. Be aware that Bitcoin no longer really uses ASN.1 DER, but a even more restrictive subset of it. ASN.1 itself as it turns out is not deterministic or platform independent in many implementations, which is a source of consensus failure. For reference, here is how to encode signatures correctly in Bitcoin, from the text of the withdrawn BIP62.
0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]

    total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.
    R-length: 1-byte length descriptor of the R value that follows.
    R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
    S-length: 1-byte length descriptor of the S value that follows.
    S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
    sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).

DER is a standard and is deterministic (and ASN.1 is always platform independent); it is some implementations that are or were inaccurately described as or claimed to be DER when they weren't. BIP62 or 146 would add the 'low s' restriction (s < n/2), which you don't mention, but there are other Qs on it.


text:
Can I still claim BCH from BTC core wallet after the 'BCH November 13' fork?
I run a full BTC core node and use the bitcoin-qt core client wallet.
I have BTC in this wallet from before BCH was created. I have not yet attempted to claim my BCH.
After the upcoming bitcoin cash BCH November 13 hard fork upgrade activates, will I still be able to claim bitcoin cash (sweep or import from BCC to BCH wallet) from my bitcoin-qt (BTC) wallet?
I assume I can, but have not been able to find an explicit answer to this. I want to be certain I can claim BCH after Nov 13.

It depends on what exactly is changed in the upcoming hard fork, however the devs would not make previous outputs unspendable intentionally.  Your private keys corresponding to UTXO that you controlled at the time of the first fork should still control the same amount of BCH going forward.  If not, users would reject this upcoming fork.

I know that there are years after ... I've had the same problem and today I've found the way to claim it ... finally :)
I've got old BTC from before fork on Bitcoin (so before 01.08.2017). I've been struggling back then (just after fork) how to send it to some other wallet or market to get my cash back ... unfortunately back then I wasn't able to find the way.
From tomorrow I've done the same research again and I've come into this page. I was quite sad when I couldn't find the answer how to do it.
Today finally I've done it :)
What I've done:
On Bitcon Core I've exported my private key (this only can be done with old legacy wallets ... I've got backup of that one). For doing that you need to go to console and write commands:
a) unlock wallet:
walletpassphrase "<here you put your password to the wallet" 600
b) export private key:
dumpprivkey 18wX2UUqNn3W6MLq2urHNMjvEXaZr3hYoL
That (18wX2UUqNn3W6MLq2urHNMjvEXaZr3hYoL ) is my BTC/BCH address. If anyone want to thanks me - you can send some BTC or BCH there :-)
After that you've got your private key to your legacy wallet. That one we will use later on other tool
Download the Electron Cash. I've downloaded windows portable version from https://electroncash.org/
Warning: I've had warning message from Norton Antivirus that the program doesn't have correct signature. Here I was quite not sure ... but as I wasn't able to get my money back ... I still tried to use it.
There wasn't any other warning from NV so I've continued. I've done some tests before I've imported correct private key.
When you start the program, you should create new wallet and then choose 3rd option: Import BCH addresses or private keys.
If you will put here the public BCH address - you would have read-only view for transaction. If you would import your private key - you will be able to send BCH to different wallet.
Send money :)
And that's it ... worked for me :-)
Good luck :)

no, a snapshot was created before the fork, after the fork BCH became it own altcoin and are now separate networks


text:
I run Bitcoin Core 0.14.1, for Segwit they tell me to "upgrade" to 0.13.1. So confusing
Short version of my question: I run Bitcoin Core 0.14.1. Will I be fully compatible with the segwit soft fork after Aug 1 2017 with this version? IOW, I can simply do nothing and be segwit compatible?
The long version of this same question:
I'm running Bitcoin Core] version 0.14.1. I upgraded to that several months ago. I have the full blockchain downloaded. I've been running core since 2014 with periodic upgrades.
I now see all the news about a hard fork and Segwit but finding clear information about how it affects me as a Core Node host and having Bitcoin Core wallets has been difficult and confusing.
The Bitcoin Core website tells me I can choose to "not upgrade" for segwit or I can "upgrade" to 0.13.1. They never say anything like "if you have any version above 0.13.1 you already have Segwit so you're good to go." I want to emphasize that I have not found anyone saying that having any version of Bitcoin Core above 0.13.1 means I'm good to go with the new soft fork.
Sorry, I don't feel comfortable making assumptions. Sure, I know it seems obvious that later versions should include what's in earlier versions, but there has been so much talk about this soft fork and so very little information about what people like me need to do who have a Bitcoin Core wallet and am running core so that I can use that wallet.
This Bitcoin Core page (Segregated Witness Upgrade Guide) says:
"The easiest way to prevent this problem is to upgrade to Bitcoin Core 0.13.1 or another full node release that is compatible with the segwit soft fork. If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases."
"Full nodes run by a reasonable number of users and business to validate the payments they receive need to be upgraded to Bitcoin Core 0.13.1 or another segwit-compatible implementation in order to incentivize miners to follow segwit’s rules after segwit activates."
This is very vague. How do I know what release is compatible with the segwit fork? "Another segwit-compatible implementation", what does that mean? Sorry, it's not clear to me that this means that 0.14.1 is "another segwit-compatible implementation."
Nowhere on this page does it say to upgrade to 0.13.1 or later.
OK, it says "or later" in this paragraph with heading "Not Upgrading", but in a very confusing context:
"For this reason, after segwit reaches locked-in, it is recommended that you either upgrade your full node to Bitcoin Core 0.13.1 or later (or a compatible full node), or that you follow the “not upgrading” instructions in the Full Node section below to use Bitcoin Core 0.13.1 or later as a filter for your pre-segwit software."
I have no idea what this means, especially "a filter for your pre-segwit software."
So does having any version above 0.13.1 of Bitcoin Core (in particular 0.14.1) mean I have segwit and that I'll be on the new soft fork?
If I do have to "upgrade" to the earlier 0.13.1, how do I do that?

Yes, it means 0.13.1 or later. All versions of Bitcoin Core since enforce the SegWit rules. The upgrade guide was written when only 0.13.1 was available, but since then 0.13.2, 0.14.0, 0.14.1, and 0.14.2 were released. Version 0.15.0 will be released soon.
I've filed an issue to get the page clarified: https://github.com/bitcoin-core/bitcoincore.org/issues/411

Thanks for filing the issue, I assumed as much but assumptions don't work for me.


text:
What does it mean that bitcoins have lower transaction costs than more traditional forms of currency?
So I recently bought some bitcoins. I just bought a small amount and mainly for education purposes. I bought it from a site called Coinbase.
Before this, I was told that one of the advantages of bitcoin was that it had very low fees. However, I feel like it's the opposite.
First, to buy the bitcoin, I have to pay a 3.99% conversion fee to buy. I understand that's just the exchange trying to make money - fair enough.
But then when I want to transfer the money to my paper wallet, there's another $3 they want to charge. And it seems that's the case for every transaction and every time you want to move your money around from wallet to wallet, that is a transaction.
So I guess the question is, what does it mean that transaction costs are low? Is that to mean that in theory, in the future it's got potential to be low cost? Is that to mean, its cheap but only for large transactions? Cause right now, it feels like it's much higher than any traditional form of exchange.
Even with VISA and MasterCard, they don't charge 4% exchange fee for purchases in another currency. And bank transfers are essentially free and instantaneous.

In the past, the cost to send a transaction (aka the transaction fee) was literally very low. For a long time, it was basically 0 for many transactions. That is what people meant by "transaction costs are low". While 0 fee transactions are nonexistent now, Bitcoin transactions are still lower in cost than many of the traditional ways of sending money.
A lot of traditional money transfers will charge a fee based upon the amount being transferred. However in Bitcoin, the fee is based on the size of the transaction data itself, not the amount transferred. This means that the fee for transfers of say $100,000 can be the same as the fee for sending $10. And those fees are usually in the order of $0.50 - $1.00. Furthermore, sending money internationally through a bank is usually more expensive than domestically.  Transfers to an account at a different bank also costs more than transfers to accounts in the same bank. None of this matters in Bitcoin. The fee is only dependent on the transaction data itself, not who you are sending to, where they live, nor how much is being sent. This makes Bitcoin much cheaper than many traditional money transfer services.
With credit cards, there is actually a transaction fee, just that the consumer doesn't pay it, the merchant does. This fee is usually just rolled into the price of the product so you as the consumer don't notice that it is being paid. But the merchants do.
Furthermore, transaction fees with all traditional money transfer services is set by the service and unavoidable. But with Bitcoin, you can choose your own fee. You can choose to pay no fee or very little fee. It's just that paying a lower fee means that it will take longer for you transaction to confirm.
Lastly, Bitcoin transactions are irreversible and "settled" much much sooner than any of the traditional money transfer services. With credit cards, you can reverse a credit card transaction up to 180 days after purchase. With banks, it takes days for ACH transfers to clear. But with Bitcoin, a transaction can be final within 10 minutes. Since you can also change the transaction fee, you get some control over when the transaction is confirmed, unlike with other money transfers where you just have to wait for the bank or payment processor to handle it.

Fees were low during the early days of Bitcoin when both adoption and transaction volume was low.
During that time, many Bitcoin-based businesses and Bitcoin advocates promoted "low transaction fees" as a central benefit (and feature) of Bitcoin. They failed to mention (or perhaps foresee) that fees would necessarily increase along with network usage.
Low transaction fees is not a design specification of Bitcoin and, therefore, not a permanent feature. In fact, the white paper describes a "fee market" that should gradually substitute block rewards as a means of sustaining a healthy mining industry.


text:
Bitcoin cash and Bitcoin
If I have 1 bitcoin now, do I end up having 1 bitcoin and 1 bitcoin cash after the BCC hard fork? If yes, how do I make sure I have these two in my wallets? Currently I control my private keys.


text:
Who is for SegWit and who is against? And what is the consensus?
I am a little lost in the whole political landscape of implementing SegWit, I understand that Bitcoin Core is for SegWit but are the miners against it? If not then who is against it and what is their proposal?
I have tried googling to no avail.

SegWit is a large protocol update developed by Bitcoin Core to address some protocol defects, increase the capacity, and lay the groundwork for further protocol improvements in the future. As such, it has broad support among the Bitcoin Core contributors. It also has broad support among node operators with 85%+ being segwit ready, and decent support among Bitcoin businesses. The softfork was ready for activation since November but had been lacking signalling by miners.
This impasse was broken by a combination of the New York Agreement (NYA) that spawned the segwit2x project and the pressure exerted by BIP148 (the UASF).
There is a vocal minority that proposes scale on-chain primarily. Some of them are opposed to segwit altogether, some want it in a different form as for example a hardfork, some of them just prefer bigger blocks but want segwit later as well. The NYA seems to have been found especially to satisfy their wish for a hardfork to a bigger blocksize, where some parts of the community aren't too keen on the 2x part of that. A small group of them has now decided to preempt the decision by creating Bitcoin Cash today which removed segwit and changed the blocksize to 8MB.


text:
Where are the BTC from my paper wallet gone?
https://blockchain.info/de/address/12PDCamPFJexx7aVAhy6nFDxJaq7TihH6b
Hi! I got a newbie question. I sent 0,00025 BTC by Jaxx on my iPhone to a paper wallet created on bitaddress.org. The wallet pub key was 12PDCamPFJexx7aVAhy6nFDxJaq7TihH6b. I can see this transaction on blockchain.info
But now my paper wallet seems to be empty. Where are the BTCs gone? I see an outflow to 1BLgeYFimGM7Dj7PDwaN55auLv7RPevY6P, but what is this?
Thanks for your help.

It seems someone obtained your private key. If you are sure you did not authorize this transaction, consider that paper wallet compromised and never use it again. If you generated the wallet online (just by opening the website), your keys may have been stolen by malware / keylogger of some kind.
If you need to generate a paper wallet, a better way is to download the source code and run it on a computer disconnected form the Internet. Disable all browser extensions or use a freshly installed and up-to-date browser (e.g., if you usually use Chrome, install Firefox just for this task). Check your computer for viruses.