text:
Is the OP_PUSHBYTES_X opcode always required after OP_RETURN?
Is the OP_PUSHBYTES opcode always expected after OP_RETURN?
For instance, the 2nd output of transaction 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 is:
OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64

Would
OP_RETURN
68656c6c6f20776f726c64

work just as well? If not, where in the bitcoin core source code is the requirement for the OP_PUSHBYTES code enforced?
Is there a difference in requirement here (aside from the 80 byte limit) between standard and non-standard transactions?
From bitcoin.it, it seems OP_PUSHBYTES is not required but I've not yet found an example main net transaction without one.

Related: If no push opcode, how does item still end up on stack

My existing answer stands, but as I feel we're talking past each other due to different assumptions about what Script notations mean, let me add this to dig deeper into that.
I'm going to change the literals in your question a bit for simplicity, and try to answer the question:

I see an output with scriptPubKey OP_RETURN OP_PUSHBYTES_3 686c77. Would an output with scriptPubKey OP_RETURN 686c77 also be valid and/or standard?

The first point is that in your notation, the string OP_RETURN 686c77 simply has no meaning. It does not correspond to any script at all. I don't mean that such a script would be invalid; I mean that literally this cannot be translated to actual script bytes.
For background, the script OP_RETURN OP_PUSHBYTES_3 686c77 corresponds the script bytes whose hex encoding is 6a03686c77 (6a being OP_RETURN, and 03 being OP_PUSHBYTES_3). My assumption is that what you mean by OP_RETURN 686c77 is the script whose hex bytes are 6a686c77, i.e., the same bytes as before, but with the OP_PUSHBYTES_3 byte dropped.
However, those script bytes would not be denoted OP_RETURN 686c77. It would be denoted OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP (because without the 03 bytes, the 3 bytes that follow are interpreted as opcodes, rather than as a literal).
If your question is about the script OP_RETURN OP_ENDIF OP_FROMALTSTACK OP_NIP (hex 6a686c77), the answer is that by consensus rules this output is valid (even though it has an OP_ENDIF without corresponding OP_IF!) because Scripts are not executed or interpreted until they are spent, and an OP_RETURN output like this is obviously unspendable. The only consensus rules governing scriptPubKeys is that they cannot exceed 10000 bytes, but there are absolutely no rules restricting what those bytes can be. As for standardness, the answer as of Bitcoin Core 27.0 is no; the requirement for OP_RETURN outputs to be standard is (among other things) that the OP_RETURN is only followed by pushes, not by other opcodes.
To add to the confusion, there exist other human-readable notations for Script, including a common one which just never uses OP_PUSHBYTES_xx. In the Bitcoin Core notation, the script whose hex bytes are 6a03686c77 is simply denoted OP_RETURN 686c77 (with the 03 byte, and the pushing, implicit in the hex constant). So if you ask about OP_RETURN 686c77, it really matters what you mean by that. Either you've switched to another encoding (for the same script, and nothing changed), or you've described something meaningless.

Another valuable answer! I was not aware of the intricacies around notation. Had I been, I'd have perhaps used all hex in the question. I.e. Is  6a68656c6c6f20776f726c64 a non-standard but valid output scriptPubKey, and is it practically equivalent to 6a0b68656c6c6f20776f726c64? The last section of your answer covers that and I'm glad of the grey-matter upgrade from the rest.

This is a notational issue, resulting from how you're choosing to write the Scripts in readable form.
This question simply makes no sense when you look at the actual binary encoding of Scripts, because the way to have a literal like "68656c6c6f20776f726c64" in Script is through what you call OP_PUSHBYTES_11. It's a stretch to call it an opcode even: it's simply a specific byte which means "the next 11 bytes in the Script encoding are a literal that is to be pushed onto the stack". If you'd drop that byte, the bytes of your literal would instead be interpreted as opcodes, resulting in OP_RETURN OP_ENDIF (invalid) OP_FROMALTSTACK OP_FROMALTSTACK (invalid) (unfinished push of 32 bytes).
There are multiple ways to write Scripts in human-readable form, but for example Bitcoin Core's disassembler will denote your script as OP_RETURN 68656c6c6f20776f726c64. The byte corresponding to what you call OP_PUSHBYTES_11 is implicit in the length of the hex string that follows.
Also note that all of this is completely unrelated to OP_RETURN. OP_RETURN is typically followed by a byte push like this, but it does not have to be. And the rules for how to encode byte pushes in Script apply always, whether the push follows an OP_RETURN or something else.

Yeah, there is a number of questions mentioning an OP_PUSHBYTES_X and i believe it is because they use rust-bitcoin which names the size prefixes this way: https://github.com/rust-bitcoin/rust-bitcoin/blob/554a5eb40c94cc7de7a42903cc7ae2fbc2bbd73a/bitcoin/src/blockdata/opcodes.rs#L77-L337.

Would say a coinbase tx (non-standard tx) with an output of OP_RETURN 68656c6c6f20776f726c64 be accepted by a node (assuming work threshold is met)?

@Lee I think you're missing the point. OP_RETURN 68656c6c6f20776f726c64 is exactly the same script as what you're calling OP_RETURN OP_PUSHBYTES_11 68656c6c6f20776f726c64, so yes. The difference is just how we're choosing to write that script in human-readable notation.

Yes, I'm not getting it yet! Wouldn't the script be OP_RETURN 0b68656c6c6f20776f726c64 with the OP_PUSHBYTES_11 being 0b?

Got it; all bytes after OP_RETURN are arbitrary (up to size specified in the output's ScriptPubKey Size field). One may add a PUSHBYTES byte as a courtesy to future readers/parsers, but its irrelevant to Bitcoin Core.

See my updated answer, no the byte is absolutely not optional. It is just that in some ways of writing the script an OP_PUSHBYTES_11 is emitted for it, and in others it's not (because it is implied by the fact that a hex character string follows).

@Lee The script 6a0b68656c6c6f20776f726c64 contains two operations: 6a (OP_RETURN) and 0b68656c6c6f20776f726c64 (OP_PUSHBYTES_11 followed by 11 bytes of data.) The OP_PUSHBYTES_11 is always there; it's just a question of how you display the script. In the more explicit style of displaying it, you show the OP_PUSHBYTES_NN, followed by NN bytes of data. In the less explicit style, you can just show the data; if you have 11 bytes of data, that ALWAYS means there is an OP_PUSHBYTES_11, so you don't really need to show it. But both ways, it's the same script with the same opcodes.

It's slightly silly that there are two different ways people display the same script, but it's not ambiguous (because data in a script ALWAYS requires a push opcode, and you can tell which one just by looking at the data.)

@GlennWillen always from a standardness point of view (tx accepted to mempool, forwarded by nodes). From a consensus (valid only if found in mined block) viewpoint it could, I think, be omitted.

It is not necessary for a data push to follow an OP_RETURN.
By consensus, it is not required that an OP_RETURN be followed by a data push. Encountering an OP_RETURN stops Script execution immediately with an error.
By standardness, a transaction may contain a single output with a bare script starting with an OP_RETURN. This OP_RETURN needs not be followed by a data push.

Script Notation:
OP_RETURN <11 bytes hexadecimal>
and
OP_RETURN PUSH_BYTES_11 <11 bytes hexadecimal>
are synonyms.
They both translate to 0x6a0b<11 bytes hexadecimal>.
I didn't know this when I asked the question...

Standardness of arbitrary bytes following OP_RETURN
For clarity, my question should have been:
Does 0x6a<any_bytes> in a ScriptPubKey, where the first byte of <any_bytes> is not the correct PUSH_BYTES value,  mean that the resulting transaction is 1. non-standard or 2. non-consensus-valid?
1. Yes, it would be non-standard (not accepted to mempool/not forwarded by nodes).
2. No, it would be consensus valid (acceptable if seen in an otherwise valid block) so long as the ScriptPubKey like this was <10000 bytes.

Credit to Pieter Wuille's answers/comments. I wrote this to help me get to grips with it!


text:
What was Satoshi's approach/sample code for implementation of web apps?
A quote from satoshi on the bitcointalk server, May 26 2010:

I'm also recommending this approach for the implementation of web
apps.  I just posted some sample code showing a suggested way of
implementing this.

Does anyone have a reference to this code?
Can anyone write a succinct description of the approach?

Wasn't this just referring to showing a new receiving address every time a payment is received?

@RedGrittyBrick I believe so.

I believe the post they were referring to is this one, posted 24 minutes prior, where they say:

The idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the "bylabel" functions.  You can freely change their address without worrying about tracking all their old addresses.
A good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:

// Get a new address whenever the current one has received anything
if (strAddr == "" || getreceivedbyaddress(strAddr) > 0)
   strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address

I think the description and code are self-explanatory: check if the address has been used, and if so, generate a new one.

source: Stack Exchange

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

sort: votes


text:
Send coins with Electrum from encrypted wallet created with Bitcoin Core
I am totally new to bitcoin. I have google'd this a lot now. I created a wallet with Bitcoin Core GUI and encrypted it (settings -> encrypt wallet...). Then I took a receiving address from the wallet (file -> receiving addresses...) and sent some bitcoins to that address from an exchange (bitstamp). I confirmed with https://blockchain.info/ that the bitcoins have arrived to that address.
Now I want to spend the coins. I can't use Bitcoin Core because I don't have the resources to download the entire blockchain, so I want to use Electrum for sending coins.
How do I import an encrypted wallet.dat created with Bitcoin Core to Electrum and send coins? If I try to open the wallet.dat with Electrum then I get Error cannote read wallet file

related: Can I import my wallet from my bitcoin core for electrum?

Every wallet can create it's own way of storing data. There's no protocol in bitcoin,that defines the way, how a wallet is structured. In your case it might be best to extract the private key, and load it into Electrum, like here:
http://docs.electrum.org/en/latest/faq.html#can-i-import-private-keys-from-other-bitcoin-clients

How to export private keys from Bitcoin Core
In Bitcoin Core, you can use the dumpprivkey command.
Once you have your private key, guard it very carefully keeping it very secure and, do the following in Bitcoin Core to gey your private key (once for every individual address):

Open Bitcoin Core.
Go to Help --> Debug.
Go to the Console tab.
type: dumpprivkey "{address}"
Do step 4 once for each address with BTC in your Bitcoin Core wallet.
Write down your private key exactly on paper only for security, or use copy and paste. Do not ever save the private key anywhere on a phone or computer.

Done. Note that you do not need to wait for Bitcoin Core to update before exporting your private key.

Usage:
>dumpprivkey "address"
Reveals the private key corresponding to 'address'.
  Then the importprivkey can be used with this output
Arguments:
  1. "address"   (string, required) The bitcoin address for the private key
Result:
  "key"                (string) The private key
Examples:
  > bitcoin-cli dumpprivkey "myaddress"
  > bitcoin-cli importprivkey "mykey"

Importing private keys into Electrum
Then, you can import your private keys into Electrum.

Open Electrum and go to Wallet --> Private Keys --> Import
Exactly fill in all your private keys, one private key per line. Press enter for a new line.
Click on Import.
Done.

Electrum will update with the balance for all of your imported addresses.
Note: If you just do not have enough HDD storage for Bitcoin Core you can enable prune={MB>550} in your bitcoin.conf file to reduce the file storage requirements for the blockchain, accessible from Settings --> Options.

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


text:
is there any API like blockchain.info and bitcore with tutorial?
is there? I'm finding it hard for starters to look it up without tutorials via the net, blockchain.info tutorial(on youtube and a single one) seems to be good but getting API key on blockchain.info is pretty hard. meanwhile bitcore has nothing but a 48-hour reply community. is there an API with a tutorial while they have an active community? TIA

Check out 21. There are some bitcoin tutorials as well as a developer community.

Bitcore has excellent documentation and examples... It sound like you are familiar with their forums but maybe not their developer site?

Get Started: https://bitcore.io/start
Guides and Tutorials: https://bitcore.io/guides
API Docs: https://bitcore.io/api

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


text:
How to Install block.io in your site?
how to install https://block.io/docs in your site? I have a running VPS and a domain now and seems pretty having a trouble regarding installing their API. Pardon me because I don't seem to get the tutorials in their documents. please someone enlighten me. thanks!

Which functionality are you wishing to install/use in your website ?

This question is unclear. You don't install an API, you use one. Is this about how to install a environment in which a software package runs (which seems more appropriate for stackoverflow), or about how to write code for that particular site's API (which is probably better answered in their support forums).

Pardon my question Pieter, yes I will their API but how do I implement it? I'm sorry I don't have much experience in the API's.

I still have no idea what you're asking. What are you trying to implement? What is your site's goal, and how do you need block.io for it? It's like asking "How do I install HTML?" when your goal is creating a blog.

never mind this Pieter I am moving forward and get how to install the block.io, sorry for the trouble!

You need to sign up on their website and get an API key, then build and deploy web services on your VPS that interact with both your website and their API.

Hi will, I already have one and bought their $49 for 2k addresses, are you a freelance or a working guy? where can I message you privately? I need a teacher and if you need a payment, then please tell me. thanks!

@Pachupappy Hi, apologies, no, I don't have any bandwidth for this at the moment. That said, maybe you can figure it out. You can learn a lot by trying if you stay perseverant. :)


text:
Does the reference client Bitcoin Core determine the consensus rules?
Does the reference client Bitcoin Core determine the consensus rules? Why should we care what is in the BIP if when there is a discrepancy between the BIP and the Core codebase (like we saw recently with Core's implementation of BIP 125, admittedly for policy rules rather than consensus rules) the BIP is ignored?

In the case that any implementation attempts but ultimately fails to follow a specification that is a failure of the process. Perhaps the BIP was unclear or not sufficiently rigorous, perhaps the implementers made a well intentioned error. Regardless one of the reasons we have a BIP process is to avoid failures like these. The implementer should understand what they are implementing and the rationale for implementation details from reading the BIP. When they look at another implementation of the BIP it should match what is laid out in the BIP. Any (re-)implementation should not have to decide whether it should follow the BIP or whether it should follow what is in the Bitcoin Core codebase (certainly in the case of consensus rules intended for all implementations).
Consensus rules (and to a similar extent policy rules though at least on the base layer consensus rules are more concerning than policy rules) are extremely tricky to change especially at short notice. For bugs that pose systemic risks (e.g. an inflation bug) an emergency fix would be pushed and distributed at short notice and clearly any discrepancy with a BIP would not be our greatest concern. I think generally running code trumps words but with systemic risks and emergency fixes I don't think this would always be the case.
On whether Bitcoin Core determines the consensus rules in the case of such a discrepancy between its codebase and the BIP, there is a strong case for that today at the time of writing. Many consider Bitcoin Core to be the reference implementation and it is certainly the dominant implementation on the network at the time of writing. However, this is not guaranteed for the rest of Bitcoin’s existence. If at some future time consensus changes were made in Bitcoin Core that were strongly opposed by the broader Bitcoin community there would most likely be efforts to build and run an alternative implementation. Hopefully this will never happen but clearly Bitcoin’s consensus rules shouldn’t be hitched entirely to the views of the Bitcoin Core maintainers and contributors at that time. For example the Bitcoin Core maintainers and contributors should not have the ability to change the block reward schedule or to claim funds for themselves from particular addresses without community consensus. It is clearly not reasonable to expect the community to have to accept this because Bitcoin Core is argued to be the ultimate arbiter on the Bitcoin consensus rules.

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


text:
What does the Bitcoin Core RPC createmultisig do? Should it be deprecated?
What does the Bitcoin Core RPC createmultisig do? What would I use it for? Should it be deprecated?

The documentation for the createmultisig RPC is here. It is a utility RPC rather than say a wallet RPC.

Creates a multi-signature address with n signature of m keys required.
It returns a json object with the address and redeemScript.

As always it is hard to know if anyone is using it but the deriveaddresses RPC offers a superset of the functionality offered by createmultisig and so deriveaddresses would be recommended over createmultisig.
It was discussed whether the createmultisig RPC should be deprecated here. It was argued that rather than the RPC being entirely deprecated (and potentially breaking downstream projects if any are using it) documentation could be added to encourage users to use deriveaddresses instead so that createmultisig is effectively "soft" deprecated. This could be added in a future PR.
Personally I'm considering removing the associated RPC functional test when I run the test runner locally as I don't think the RPC is being used and hence the test is offering minimal value. But it won't be removed from the test runner in Core without deprecation of the RPC and that looks unlikely at the time of writing.


text:
Why is there no forced signaling during the LOCKED_IN phase of BIP 8(LOT=true)?
Why is there no forced signaling during the LOCKED_IN phase of BIP 8(LOT=true)?
During the MUST_SIGNAL phase of BIP 8(LOT=true) a threshold of miners have to signal. The next phase after MUST_SIGNAL is LOCKED_IN. Signaling in the LOCKED_IN phase is recommended rather than mandatory. Why?

The state transition diagram of BIP 8 is here.
The specific change you refer to was made in this BIP PR by AJ Towns. Once we move into the LOCKED_IN phase of BIP 8 the soft fork is definitely going to activate at some point and so any requirement to signal is unnecessary. The MUST_SIGNAL phase makes it clear to the network that signaling is being enforced by the network. In the LOCKED_IN phase (which only begins after a difficulty adjustment period, 2016 blocks, where the threshold of signaling has been met) it is clear to the network that the soft fork rules will be enforced in future.


text:
How do I make multisig transactions using hardware wallets truly trust minimized?
I am experimenting with multisig transactions using hardware wallets. Is there some general guidance on what I should and shouldn't do to make the process truly trust minimized?

Ben Kaufman did a tweetstorm on Twitter on the 10 rules for verification on a Bitcoin hardware wallet.

Rule #1: DO NOT TRUST THE COMPUTER SCREEN.
The very reason for using a hardware wallet is that your computer IS
compromised, trusting it makes using the hardware wallet an expensive
security theatre (or 2FA at best). Always verify on the HWW device
screen!
Rule #2: Verify your "receive" addresses BEFORE accepting funds.
A compromised computer can be tricked into displaying addresses that
belong to an attacker. The only way to make sure you own the addresses
is to display them on the HWW device and verify they match.
Rule #3: Verifying change address should be done by the device when sending funds, not before like receive addresses!
It is pointless at best, and misleading at worst, to verify them
beforehand like receive addresses. All hardware wallets support
verifying the change address belongs to you AT TIME OF SIGNING A
TRANSACTION. Verifying before that is pointless and error-prone.
Now let's talk some multisig...
Rule #4: Verify the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
This is not 100% mandatory - but if you're no expert - you really
should do it. If a hardware wallet doesn't support displaying the
xpub, (like Trezor), it could be fine to just verify each address on
it - so long as you verify consistency on all other devices as well,
but I wouldn't recommend such a device for non-experts.
Rule #5: Verify "receive" addresses on EVERY device of the multisig quorum.
This is especially true for at least one address (see next rule) but
recommended for all. If using a device that you haven't verified the
xpub of on-screen, you should verify all receive addresses on it!
Rule #6: While it is best to verify each receive addresses on ALL devices in the multisig setup - you might choose to trust a specific
one, verifying the xpub/ first address on all - then the rely only on
the "trusted" device - ONLY IF YOU ALSO VERIFY XPUBS...
By that, I mean verify on the "trusted" hww used for general
verification, that the xpubs are consistent for all cosigners. This is
needed only once with wallets like ColdCard, Cobo Vault, Bitbox02, and
Specter DIY - since they allow saving the multisig xpubs on the
device.
With Trezor T - you have to verify the xpubs of cosigners every time -
which is why it's not recommended for that purpose - with Trezor One
it's simply not possible...
So while you might use a Trezor in a multisig, I would not recommend
it to non-experts.
Rule #7: Do NOT use Ledger in a multisig setup! (unless you are an expert or have a very good reason...)
Ledger currently does not allow verifying multisig addresses on the
device - nor displaying the XPUB on its screen.
This means you have no way to verify it was not swapped by an attacker
in your multisig setup - EVEN IF YOU DO A SUCCESSFUL TEST TRANSACTION!
It is still possible for a (very) sophisticated attacker to make you
think it worked, while it was him signing for you...
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and
rely on that paper list for your day to day verification. This is very
useful for multisig! - where devices might be distributed in various
places.
Rule #9: Multisig change verification should be the same as with Rule #3 - on the device at the time of signing.
Popular devices (besides Ledger as said), can verify that the address
you send from and the change address used belong to the same multisig
wallet (from same xpubs).
If they fail to verify the change address - they will show it as a
standard, independent, recipient - in that case YOU SHOULD NOT MAKE
THE TRANSACTION. This is valid for both single sig and multisig!
(although even more relevant for the latter).
Rule #10: Hardware wallets cannot verify your balances - and that's great!
Verifying balances requires getting information from the Bitcoin
network - i.e. you need to be online - which would make hww more
vulnerable... This is where a full node comes in!
It is strongly recommended that you run your own Bitcoin full node -
and use it as your main source for verifying your balances and
transaction history! For redundancy, you could double-check against
block explorers or another node (use a different device for either!).
One last thing: These rules apply to any device you use as a
segregated signing device - be it a "traditional" hardware wallet, an
airgapped laptop, a mobile phone etc.
If you want to separate your keys without having a security theatre,
you should verify on your signing device!
Please note: Some things here might not be fully accurate for the
expert user (especially around multisig address verification), but for
the less advanced users' sake, I have tried to be on the safe side
when things get tricky...
Also check out some more info on multisig setups over at
https://btcguide.github.io (Michael Flaxman guide)

To minimize even more trust is to build the tx and sign it yourself in a raw transaction, but that opens up too many other pitfalls for most users.

The following info helped me understand the Trezor T: The Model T is stateless and doesn't store the XPUBs of the other cosigners. So, the computer must provide the XPUBs to the T.  A malware infected computer could lie about / swap those XPUBs, so fw 2.1.8+ shows the cosigners' XPUBs on the T's screen for the user to manually verify (every transaction). Coldcard, Cobo, etc don't need XPUB verification for every transaction because they store the cosigners' XPUBs on the device when the quorum is setup (and you have verified the XPUBs at quorum setup time).

I have a question about what is meant by using the trusted HWW for "general verification". Is this in the context of setting up the quorum and verifying the receive addresses, or sending to an address owned by the multisig quorum, or when signing/spending from a multisig UTXO?


text:
I have written a test for an open Bitcoin Core PR. Should I open a PR to the author's fork or wait for it to be merged?
I have written an additional test for an open Bitcoin Core pull request (PR). Should I seek to extend the PR by forking the author's fork of Bitcoin Core and opening a pull request to his PR branch? Should I wait for it to be merged and then open a new PR? Or should I suggest it in the comments of the PR and allow the author to add it to the PR if the author is happy with the test code I have written.
This question was asked by brikk on IRC and has been paraphrased.

It depends on the situation. When the change is a few lines of code it is sufficient to show the author the patch and they will amend the pull request. You can do this using a ``` diff in the comments or link to your branch in the comments.
If it is a bigger change, to avoid the clutter of the GitHub UI you can surround it by <details><summary>patch to do foo</summary>```diff ... ```</details>.
However, if it is a really significant change you should probably open a PR to the author's fork of the Bitcoin Core repo asking to merge yourfork/yourbranch into PR-author/PR-branch.
One difference between posting the patch in the GitHub comments vs linking to your branch is that the former will continue to exist even after you delete your branch. Somebody may be curious to look at the patch years later.
This question was answered by vasild on IRC and has been paraphrased.
edit: Jon Atack adds that for commit sized proposals a reviewer generally provides a link to a commit in their fork of the Bitcoin Core repo (or even a link to a branch) and the PR author will then pull in the commit adding it to the PR. An example is here.

Rebased with four commits pulled in from @jnewbery's master...jnewbery:2020-07-split-already-have branch as well as the changes in #19611.


text:
Sending encryped messages using INSaNe. Messages not sending
I forked INSaNe https://github.com/CryptoCoderz/INSN from github, changed genesis hashes, mined, and sended some coins between two localhost wallets. When i tried to send message from first address to second address i get this error: ERROR: SecureMsgEncrypt: Could not get public key for destination address.
How to fix it? I tried manually insert public key but nothing, still same error. Please help me!


text:
incorrect teredo ipv6 address advertising
I have an issue with teredo addresses. After network issues or router reconnect the teredo tunneling interface address changes but bitcoind stays still unaware of it and continues to advertise the old (incorrect) ipv6 address.
Should I raise the issue on github on this?
Can somebody check if this exists on regular (not teredo) ipv6 interface?
Thanks.


text:
How do I get started debugging Bitcoin Core functional tests?
I would like to get started with debugging Bitcoin Core code. I have heard debugging Bitcoin Core functional tests is a good place to start as they are in Python rather than C++ and they are easier to understand. Any recommendations or good resources to help me do this?

To understand the functional tests, I think it's important to start with an understanding of how bitcoind works and how the RPC interface is used.
Start Bitcoin Core in a terminal window in regtest mode (a local test network that does not connect to any peers by default):
$ bitcoind -regtest

Keep an eye on the output! This is your debug log, and important messages are printed there -- many tests even check to make sure a certain message was printed.
In a second window, get a list of commands:
$ bitcoin-cli -regtest help

You can get help for any specific command:
$  bitcoin-cli -regtest help getnewaddress
getnewaddress ( "label" "address_type" )

Returns a new Bitcoin address for receiving payments.
If 'label' is specified, it is added to the address book
so payments received with the address will be associated with 'label'.

Arguments:
1. label           (string, optional, default="") The label name for the address to be linked to. It can also be set to the empty string "" to represent the default label. The label does not need to exist, it will be created if there is no label by the given name.
2. address_type    (string, optional, default=set by -addresstype) The address type to use. Options are "legacy", "p2sh-segwit", and "bech32".

Result:
"str"    (string) The new bitcoin address

Examples:
> bitcoin-cli getnewaddress
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getnewaddress", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/

Give it a try!
$ bitcoin-cli -regtest getnewaddress
bcrt1qua6ku8kkx4m57tg6q44wh00h58vpk7lm8h82sy

Now go take a look at a simple test like wallet_resendwallettransactions.py and note the syntax node.getnewaddress() -- by this point you probably know exactly what that does and what the return value will be.
To go deeper and understand how the test framework launches and configures individual nodes, read test_framework.py. You'll notice many of the functional tests pass configuration parameters to the start_nodes() function.
To get a dictionary of those command line parameters, execute:
$ bitcoind -help

These are the key tools I think and the in-program help information is an invaluable resource. By going through functional tests and looking up the rpc commands and launch arguments, you'll eventually get an instinct for how the more complicated tests work.

Either I completely missed it, or this answer does not answer how to debug the tests.

There are a few different resources I would point you to.

For more information on functional tests in Bitcoin Core (with guidance on writing them) I would check out the functional tests README.
For a case study on debugging the functional tests Sjors Provoost wrote a blog post back in 2017. (Some of it may now be outdated but the general thought process is excellent.)
There are a couple of presentations Fabian Jahr did at Bitcoin Edge Dev++ on the functional test framework and debugging.
Fabian held a workshop at Advancing Bitcoin on Debugging Bitcoin Core
Fabian has also been drafting a debugging doc which contains guidance on debugging both unit and functional tests. It is targeted to MacOS users currently so may not be as helpful if you are on Linux or Windows.
Finally Gloria Zhao has been drafting a doc with more information on the functional test framework.

That should be enough to get you started! Any questions feel welcome to post them on the #bitcoin-core-pr-reviews channel on IRC.


text:
How can I earn BTCs inside my BITCOIN CORE WALLET desktop app?
HI. Yes this is my question, Bitcoin Core is not a Mining software?! So, how can I create profit at my wallet? I have CPUMiner in my windows 7 32Bits, there exist a stratum pool adress to mine btcs to my wallet? Please help me and Thanks.

Bitcoin core is a mining software.
You can use rpc setgenerate to turn on the mining process.
However, it is nearly impossible for a normal CPU to mine a block(to get rewards) now.
At present, you can't earn anything with a normal CPU now even you join a mining pool. (Thanks to @Murch 's correction)

He shouldn't join a mining pool its even then impossible to get profits.

I don't get it. Why not ? He can earn very little bitcoin at least, although the reward is less than the cost.

I sincerely doubt that he can earn anything at all with CPU mining Bitcoin. Are you actually mining Bitcoin with a home computer and even getting any payouts at all?

@KevinChia the pools probally wont even recognise his haspower so low is it

@Fyah Okay, I get it.

@Murch Sorry, I'm not. So recently you cannot earn anything with a desktop even you join a mining pool?

You haven't been able to for several years.

Could you please edit your answer to correct it?

authors: Александр Голайдо


text:
How do miners detect double-spending?
Assuming I spent 1BTC, then waited a few months and then spent it again. How is this detected? Do the miners go through the entire blockchain to assure the coin was never spent before?

The other two answers explain what has to be done to discover doublespends. I'll try to explain how it works.
There are no "balances", there are "coins"
A common misunderstanding is that there is a register of balances for addresses, and when you spend bitcoins, some of your balance gets deducted from your address. Actually, that's not a good description of what's happening. Under the hood, it's more akin to receiving a "coin" whenever you get paid, and drawing upon your available "coins" when spending.
Spending "coins"
When someone sends you a transaction, they create an "unspent transaction output (UTXO)". This UTXO is uniquely identifiable e.g. the first output of the transaction with the id X. UTXOs are like coins: They have a specific value and can only be spent completely. To spend part of one, you have to give up the complete coin, get back change.
Example:
You have two Unspent Transaction Outputs ("coins") worth 0.03 BTC and 0.09 BTC. They were created as "first output of transaction X" and "third output of transaction Y" respectively. You want to send 0.10 BTC to Bob.
You cite these specific two UTXOs as inputs to your transaction Z. I.e. you order "I want to spend the first output of transaction X, and the third output of transaction Y. I'm converting them to first and second output of transaction Z. – Here are the signatures for X.first and Y.third.".
X.first   0.03 BTC                       Z.first    0.10 BTC (spendable with Bob's signature)
                       ---- tx Z  --->
Y.third   0.09 BTC                       Z.second   0.02 BTC (spendable with your own signature)

In this example, you use up your two "coins", to give one "coin" to Bob to pay 0.10 BTC, and get back the change as another new "coin" which goes to yourself. Your transaction Z spent X.first and Y.third, and converted them to two new "coins" Z.first and Z.second.
Now, as described by Greg and Jestin, every full node has worked through the whole blockchain. Every single transaction references one or more "coins" that get spent, and creates new "coins" as in the example.
While a node works through the blockchain, it keeps track of the "coins" that exist, and updates this database with every transaction that happens. The database is referred to as the Bitcoin network's "Unspent Transaction Output Set". So, when you're up to date, the node has a list of every "coin" that is available for spending.
Back to the question
So, you sent 1 BTC to Bob one month ago. Now, you're trying to use the same "coins", X.first and Y.third a month later to send money to Carol. The nodes look at their "coin" database, and see that they are not in it. They can immediately say "Those coins have already been spent.".

Great answer, do you have more sources on the "balance" vs. "coin" misunderstanding?

@GerdMarvin: Check out the following: How is a wallet's balance computed?, How does the network know my current balance?, What is an “unspent output”?, Can someone explain how the Bitcoin Blockchain works? (second answer)

Yes, miners check the blockchain to ensure all new transactions are valid before including them into a block.  However, it also depends on your definition of "miner".  If you mean the people running ASIC miners as part of a mining pool, then no, they do not generally check for the validity of transactions or blocks.  They simply hash block headers to calculate nonces.  If you mean mining pool operators, then yes, they need to check the validity of transactions and blocks, otherwise the blocks their pool produces will be rejected by the rest of the network.
Also, miners are not the only nodes on the Bitcoin network that validate transactions.  Full nodes, which relay transactions through the network, also perform checks to ensure transactions are valid before relaying them to other nodes.  You would have a very hard time even getting your invalid transaction to a mining node, let alone having it included in a block.

Yes, they do. Mining software indexes the blockchain database so that lookups like this are relatively quick (that is, they don't have to laboriously search through gigabytes of transactions).


text:
./learncoind not connecting to DigitalOcean Droplet
I'm on video 5 of the Learncoin youtube series and I am getting an error when I try to run ./learncoind
2016-04-07 03:40:40 connect() failed after select(): Connection refused
2016-04-07 03:40:40 trying connection MY-DROPLET-IP:9333

I have my SSH key setup for the droplet and the keys live in my ~/.ssh/id_rsa folder. I can access my droplet from the CLI using ssh root@MY-DROPLET-IP and then entering my SSH key password and my root password.
I don't really understand why ./learncoind isn't connecting.

If you run netstat -antlp | grep LIST on your droplet, is anything listening on port 9333?


text:
Force a fork - is that possible?
I am having a question regarding forks. We had a discussion about attacks on bitcoin in class recently. One of the attacks was about how an attacker gains some advantage if he is able to mine a block and hold it back. He would release the block only if another miner finds a block in order to create a fork.
After that we had been discussing if it would be possible to create a fork somewhere in the past. Let's say an attacker decides now I would like to fork the blockchain 2 days ago. He starts to mine blocks from the time in the past and tries to create a longer chain. As soon he has a longer chain, he releases it and hope that the chain forks.
My question is now: Is that actually possible? Is it possible to fork the blockchain somewhere in the past if we are able to create a longer chain and release it later?
I tried to find some information but all I get is hard fork information.
Thanks in advance

The answer by Pieter Wuille below is correct. I only want to say that we usually use the word "fork" when it changes consensus rules. Reorganizing the chain is called 51-attack (when somebody gains profit) or just reorganizing the mainchain :)

I understand your comment but what exactly do you mean with consensus rules? If 2 miners create a block in the same time, there would be a fork. Is this a change of consensus rules?

yes, we can call this situation as a fork.

It is absolutely possible - but not necessarily feasible - for an attack to branch off in the past, and create a new majority chain from that.
However, it effectively means that you or the miners who are participating in this attack need to mine faster than the rest of the network combined. Otherwise, you'll never be able to 'outrun' them, and the further back you start, the less likely it is you'll ever catch up.
For this reason, this is also called a 51% attack. For anything further back than a few blocks, you almost certainly need a majority of the hashrate to succeed.

I know the 51% attack but you would call even this situation a 51% attack?

Yes, absolutely. It's a majority hashrate attack.


text:
How to use JSON-RPC in C++ in Linux?
Which library I must use for JSON? Where is RPC call example ?
How to use RPC of bitcoind or bitcoin-cli? or better Electrum API to get all new (maybe pending) transactions which appears in Bitcoin net?

Like popen()? Or system()?

Possible duplicate of How to interact with bitcoind using C++?

How to use RPC of bitcoind or bitcoin-cli?

bitcoind - bitcoin deamon = core value of the software (bitcoind -printtoconsole -debug=1)
bitcoin-cli - bitcoin command line interface = allows you to "query' the blockchain that you had download previously with bitcoind. (bitcoin-cli -getinfo previously getinfo which was removed from v0.16, not sure why.)

So bitcoind provide the RPC "interface" in which you can query with bitcoin-cli (or a library in c++ you will find...).
You must run bitcoind before using bitcoin-cli.
Basically bitcoin-cli communicate with your node bitcoind so in other words your current blockchain state.
bitcoin-qt - Graphical bitcoin software = bitcoind + graphical interface
(You can find a graphical console embedded in which you will use bitcoin-cli command)

I am not sure why you chose C++
If you are going to build something where you need the speed of C++ then understandably stick with it.
Otherwise to simply perform some RPC calls use something simpler like python or PHP.
Here is a tutorial on how to do RPC calls via python:
Bitcoin & Blockchain Programming #007 – RPCs via Python
And via PHP:
Bitcoin & Blockchain Programming #005 – RPCs via PHP

Your direct question is about a fine JSON-RPC library in C++, and the direct answer to it is:

libjson-cpp &
libjson-rpc-cpp

But if I wanna target your intention, there is a well-developed wrapper for Bitcoind-json/rpc interface here. It will save you massive time!

Even though it is a C library, you could use Jansson in C++ apps, too. See: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#C


text:
How verify (in C++) input signature?
First small problem: blockchair.com give me only output scripts, not input - is any blockexplorer online with it? I read binary data and this may be hard recreate my sample data and verify.
I test BTC block 500186. First is coinbase tx =
 d45f88974168a7c1d04c9501872ee04ad2a1c4ef2d855afdc2a69c69d7802543

and I don't analyse it because has not previous transactions.
 Next is a bit odd transaction =
 95637dddd99653a6421086e6ab9326341d47f5c29a3cea521e0d2dd6b7c693b1;

 odd because script is short:
 1600149471ea5ecd8f6c51cbe1793df6f5c8ee1894a694

this can I also skip.
Next is
83951f7cb7db18e22f30f319ecbfba2adfc0828a31a0df4edecb46a580c4df10

has script
483045022100df7b1f04615972c7e9d05e9c6c176b95f1a9fc9b73e86eb6d6747336da118a4d02202021d00dab65b6000ef2fcae7525427d1dbec40a2def4196111b8b11c5247bfd012103eafee16adb27d36dc89e4aae0d1b5e0f8ddb2c9136612dc733ec65b1db128cca ,

it give me signature:
 3045022100df7b1f04615972c7e9d05e9c6c176b95f1a9fc9b73e86eb6d6747336da118a4d02202021d00dab65b6000ef2fcae7525427d1dbec40a2def4196111b8b11c5247bfd01
and key
03eafee16adb27d36dc89e4aae0d1b5e0f8ddb2c9136612dc733ec65b1db128cca
and hash of previous tx =
132d98c0bf70264d224f8a2d19325a1f34edd5fddd387939c1f51dd9790aead5

I amd computing r and s numbers:
first has 33 bytes, second 32 bytes (should be 32 + 33?)
 r =
 2100df7b1f04615972c7e9d05e9c6c176b95f1a9fc9b73e86eb6d6747336da118a
 s =
 2021d00dab65b6000ef2fcae7525427d1dbec40a2def4196111b8b11c5247bfd

RecoverCompact can't recover becasue is 33+22 not 32+33 bytes, if I exchange r and s, is also bad; next scripts give me s and r for example 32+32, 33+33 bytes etc.
Question:
how compute r and s ?
RecoverCompact (from Bitcoin sources) hs parameter hash - it is hash of current or previous transaction?
After recover I must obtain second array of script from frist array of script + hash?

In case it helps, here is how you get r and s from a pubkey in Python.

Main problem : is CKey::Sign and CKey::SignCompact but only one CKey::RecoverCompact. It is impossible recover key from normal signing message?

@Saku you want to get the private key to Signature or you want to verify the Signature meccing with the public key?


text:
Do dormant bitcoin wallets go stale?
I have a bitcoin wallet. There is not much money in it, and I do not want to run bitcoin-qt all the time.
I have a question. If I save it securely, so I can recover it at any time, but do not run it actively with bitcoin-qt, does the wallet go stale?
In other words, if, hypothetically, I have my wallet.dat safely in a file but without any software actively running it, will I be able to reinstall bitcoin-qt after an arbitrarily long period of time, read wallet.dat, and use the money stored in it?
Or will it somehow be completely out of sync?
Thanks

There is no expiration date for when an output can be spent.

After reading several good (and a couple of useless) pages, I understand what the issue is. Yes, if I back up a wallet and never do anything with it, I will be fine.
However, if I back up a wallet and CONTINUE TO USE IT, after a while the backup wallet will be useless if a hard drive crashes and I lose my active wallet. The old backed up wallet would have zero balance.
That was the concern that I was recalling. It does not apply to a wallet that is saved and not used.

I believe that what you are saying about bitcoin-core wallets is no longer true from version v0.13.0 which implements hd wallets. Specifically, if you create a new wallet (with version v0.13.0 or above) then encrypt it (you want to), then backup the wallet file, you can keep using the wallet as much as you want (without creating new backup) and the backed up file will still allow you to recover all your past transactions and private keys (it will not have a balance of zero).

Thanks. I appreciate that and it is good news. What if the wallet was created before 13.0, but used all along and now is used with v0.13.1.0-g03422e5?

Your current wallet is not an hd wallet so you are exposed to your back up file not having all keys in it after a while. The best thing to do is create a new wallet under v0.13.1 (simply restart bitcoin-qt having removed the wallet.dat file), then encrypt this new wallet, and make a back up of it. Then write down a bitcoin address for this new wallet. Then close down bitcoin-qt and restart it with the old wallet.dat file and transfer all bitcoins to the new address.

Thanks a lot. I did exactly what you suggested, created a new wallet, transferred the money, and and backed up the new wallet. (encrypted of course). I appreciate your thoughtful advice.


text:
What if a pair of double-spent transactions are collected into a new block?
Let's say, Alice sent a bitcoin to Bob, and then immediately sent the same coin to another address controlled by her. A honest node collected these two transactions into a new block.  Would the node be able to detect that this pair of transactions are double spent?

A node that collects them into the same block is by definition not honest, as it is a violation of the consensus rules that outlaw double spending.

When Alice sends the bitcoin, she spends an Unspent Transaction Output (UTXO) created by a previous transaction. To create a doublespend, she has to use the same UTXO as an input for another transaction.
As every full node keeps track of all existing UTXO, it is trivial for all nodes to recognize these transactions as doublespend. A block containing two conflicting transactions would be invalid, and thus would not be accepted by any nodes.


text:
How can the government tax you using bitcoin
Bitcoin is decentralised and anonymous so how can governments issue /enforce taxes on any transactions made with bitcoin?

How did the government issue or enforce taxes in a cash based society? By investigating people who seem to have more than they report.

very similar to http://bitcoin.stackexchange.com/questions/50699/how-would-tax-and-government-revenue-be-enforced-in-a-bitcoin-run-society

Yes, but we can't close as a duplicate unless one or the other gets an answer.

I guess the answer is we don't know. As If the answer is, they can't then I'm sure they will have to make it illegal or how will government and society function.

The current IRS action is focused on transactions that earned money then were traded out for dollars, without declaring the capital gains.  So it is not the BTC that is being taxed, it is the dollar increase.

Governments can set up laws and regulations and then set up "departments" to monitor and enforce.
Whether it is successful or not is another question. No doubt they will have to skill up and understand how digital currencies really work, maybe monitor a few people, monitor the flow of their btc's and audit them, create some "high profile" cases to be made examples of etc.
One can draw an analogy with cash.

Bitcoin is (...) anonymous

You won't go to the governmental office to say you have created a wallet.
But they have huge control over your ISP probably and can check what are you send/receive to/from Internet...

VPN would "solve" this.

The government wants you to convert back in the future, then pay taxes on capital gains and sales that follow.


text:
What happens to bitcoin when Segwit2MB activates?
Specifically what will happen with bitcoin in wallets. Do I have to try and quickly buy "Segwit coins" if the value of bitcoin core drops?
Do I have equal amounts of Segwit and core coins?
If so wouldn't that initially double how much I have assuming the value is the same initially?
Is it even a hard fork?
If the answer isn't relevant to Segwit2MB than what happened with Ethereum and Ethereum classic did it hard fork and I have the same questions about it.
Sorry if my terminology is poor

In the event of a chain fork, any Bitcoin that you have now before-the-fork will also exist after the fork on both chains. So if you have 1 BTC now before-the-fork and segwit2x activates causing a chain fork so there is segwit2x chain and non-segwit2x chain, then you will have 1 BTC on the segwit2x chain and 1 BTC on the non-segwit2x chain. However spending your 1 BTC on either chain can result in the 1 BTC on the other chain being spent too since the transaction would be valid on both chains because you are spending a coin from before-the-fork. This is known as transaction replay.

authors: Роман Кошурников


text:
How to update index when payment is received with Blockchain PHP API?
I want to start accepting Bitcoins payment on my site, I got the callback and the index working fine, the only thing is that it won't update the index once the payment is received, I'd like to give the user some kind of live feedback when the payment is received, how can I do that?
Below is what I got.

Index.php

<?php

$api_key = "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx";

$xpub = "xpubxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

$secret = "xxxxxxxxxxxxxxxxxxxx";

$rootURL = "https://xxxxxxxxxx.org/BlockChain";

$orderID = uniqid();

$callback_url = $rootURL . "/callback.php?invoice=" . $orderID . "&secret=" . $secret . "&username=Teste" . "&password=qwerty123";
$receive_url = "https://api.blockchain.info/v2/receive?key=" . $api_key . "&xpub=" . $xpub . "&callback=" . urlencode($callback_url);

$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_URL, $receive_url);
$ccc = curl_exec($ch);

$json = json_decode($ccc, true);

$payTo = $json['address'];

 echo $payTo;

?>

Callback.php

    $secret = "xxxxxxxxxxxxxxxxxxxx";

    if ($_GET['secret'] != $secret) {
        die("Stop doing that!");
    }

    else {
        //Register new user, insert more days, etc...

        //# START DEBUG #
        $fff = fopen("text.txt", "w");
        $value = $_GET['value'] . " - ";
        $fw = fwrite($fff, $value);

        $txhash = $_GET['transaction_hash'] . " - ";
        $fw = fwrite($fff, $txhash);

        $invoice = $_GET['invoice'] . " - ";
        $fw = fwrite($fff, $invoice);

        $value_in_btc = $_GET['value'] / 100000000 . " - ";
        $fw = fwrite($fff, $value_in_btc);

        $username = $_GET['username'] . " - ";
        $fw = fwrite($fff, $username);

        $password = $_GET['password'] . " - ";
        $fw = fwrite($fff, $password);

        fclose($fff);
        //# END DEBUG #

        echo "*ok*"; //Tell blockchain everything is ok, so they stop.
    }

    ?>

Your callback will update your server but the user would have to refresh the page to see the change, or you could use AJAX (but that can be wasteful as it will send several requests until there's an update). I'd suggest you use their websocket API to monitor for a transaction so that you can notify the user live on the page.
Below is a simple example, just be sure you update the address variable with the address you want to monitor. You can put your PHP output in the javascript like     var address = <?php echo $payTo; ?>;

User Page

Waiting for Payment...

authors: Павел Панков


text:
Bitcoins disappeared on import into Electrum
A few years ago I received some bitcoin in Bitcoin Core (~0.4 BTC). Then I transferred some to Kraken (~0.1 BTC) and a few weeks later transferred some back (~0.1 BTC). Then I backed up wallet.dat and formatted that computer.
Now I wanted to sell these bitcoins. I opened the wallet by putting wallet.dat into the correct directory and then running bitcoin-qt -rescan. Bitcoin Core is not synchronized. For some reason it only shows the initial inward transaction of ~0.4 BTC (even that time range is not yet synchronized), but not the other ones.
Then I used listaddressgroupings, which gave me one address and used dumpprivkeys to export the private key for it. I pasted that private key into Electrum. After synchronizing, Electrum shows the initial inward transaction of ~0.4 BTC, but also an outward transaction of the entire sum 2 months later.
Stealing my wallet.dat would have been extremely difficult, because my computer is encrypted and I strictly run Debian with only software from the official repository. Even if the money got stolen the smaller transactions to and from Kraken should show up in Bitcoin Core and Electrum.
I'm a software developer, but I don't know how Bitcoin works specifically. Does anyone have any ideas what could have happened to my Bitcoins?

The change from the 0.4BTC and the transfer back would have gone to different addresses. They should also be stored in your backup of the wallet.dat, but you wouldn't have imported them to Electrum if you only did the one key. You could wait to see if the other transactions show up if you wait for a bit more synchronization to happen. (Especially if they were apart a large time.) Otherwise you may have an incomplete backup.

Thanks, that makes sense. Maybe listaddressgroupings doesn't actually give all addresses then. Is there a way to extract all addresses for which there is a private key stored from a wallet.dat?


text:
Does bitcoin / blockchain provide any protections similar to credit cards such as chargebacks?
I understand that if I make a bitcoin payment my purchase is recorded in the blockchain and cannot be reversed. My bitcoins are gone. But all transactions imply a vendor providing a product. So ...

Does the system record and link the record of my bitcoin spend to the product I'm buying? If so, how?
Does bitcoin/blockchain at least record the total transaction such that I have at least a contractual right to the product I've purchased?
How can I be sure I will receive the product I purchased in a timely fashion (or at all)? Why wouldn't the vendor just keep my bitcoin and tell me to get lost?
Consumers use credit cards BECAUSE they are protected against such ripoffs via chargeback and other rules. I gather bitcoin/blockchain doesn't provide such protections. Are we talking about 'caveat emptor' aka let the buyer beware? If so, that's fine for small purchases but sounds hopeless for any purchase where I can't afford to be ripped off.

Bitcoin does not compete with credit cards, it competes with the dollar

Maybe my answer here is helpful: http://bitcoin.stackexchange.com/a/51637/208

Does the system record and link the record of my bitcoin spend to the product I'm buying? If so, how?

No. But entities (like governments, secret services, companies, or individuals) my attempt to do so.

Does bitcoin/blockchain at least record the total transaction such that I have at least a contractual right to the product I've purchased?

Total transactions: Yes. As in "total number of transactions in the blockchain".
As in "total transactions you ever made": Your wallet records this. Bitcoin does not provide a way for you to prove that you purchased something (Does anything actually provide a way to proof this? I don't think so.) but you can prove that you're in possession of the private keys necessary to have made a certain transaction.

How can I be sure I will receive the product I purchased in a timely fashion (or at all)? Why wouldn't the vendor just keep my bitcoin and tell me to get lost?

You can only believe in promises or have a contract assuring you that (e.g. a promise by or a contract with the trading platform you're using). The currency you're using doesn't matter at all for this.

Consumers use credit cards BECAUSE they are protected against such ripoffs via chargeback and other rules. I gather bitcoin/blockchain doesn't provide such protections. Are we talking about 'caveat emptor' aka let the buyer beware? If so, that's fine for small purchases but sounds hopeless for any purchase where I can't afford to be ripped off.

You seem to confuse currencies and payment methods a lot. Have a look at this answer.

But all transactions imply a vendor providing a product. [..] Does the system record and link the record of my bitcoin spend to the product I'm buying? If so, how?

Not all of them. If I pay the kid across my street to mow my lawn, I would hardly say he's a 'vendor.' In any case, if there's a chargeback, he's not going to have a paper trail to prove that he mowed my lawn - it's just going to be my word against his. It's not clear how chargebacks protect people in this case. If the arbitrator generally finds in favor of buyers, it hurts the kid across the street when he really did the work. If the arbitrator generally finds in favor of sellers, it hurts me when I pay and the work doesn't actually get done. If the arbitrator tries to decide who's more trustworthy, it's pretty much going to be a crapshoot.
How do credit cards deal with this situation? They don't. They never give the neighbor's kid the ability to open a merchant account.

How can I be sure I will receive the product I purchased in a timely fashion (or at all)? Why wouldn't the vendor just keep my bitcoin and tell me to get lost?

Credit cards might guarantee that you receive a product, and maybe even ensure that the product is as described. However, they don't guarantee that the product is any good. If you're buying music or a game, it's hard to see how a credit card company could decide something so subjective. How do you find out whether a game or piece of music is good? Reputation. We're just taking reputation one step further.

Consumers use credit cards BECAUSE they are protected against such ripoffs via chargeback and other rules.

Bitcoin escrow/arbitration services do exist, though you must agree to use them before the transaction in question, making them an opt-in rather than opt-out system. Given that there's no stampede of customers towards those escrow services, that suggests that most customers don't care about escrow, and most of them only use arbitrated systems because of the hassle of switching.

Are we talking about 'caveat emptor' aka let the buyer beware?

Yes, we are.

Bitcoin does not formally provide any protections similar to credit cards such as chargebacks. But if you are buying something from a legitimate retailer that is specifically accepting bitcoins, you have all the effective protection of a credit card. You even have protection on the Dark Web. I was a vendor on Silk Road and what struck me was the high level of trust involved between vendor and customer. And such sites have feedback mechanisms. So you can always register your displeasure over something. A legitimate dark-web vendor will certainly at least consider your request for a refund or a return, and the same certainly goes for a regular retailer. Frankly I wouldn't worry about it.

HAHAHA, your answer just look stupid with what happened to Silk Road.


text:
Restore keys from keypool
So, I generated a new address with getnewaddress and made a payment to it. Soon after the computer bitcoind ran on shut down (due to loss of power) and after booting it up again my wallet doesn't know of the address anymore. I'm assuming all that happened was that the newly generated address wasn't written to disk in time. But the keys should still be in the keypool, right? How do I restore the keys and import them into the wallet? I still have the address.

Keypool keys are already in wallet.dat.  That's the whole point of the keypool.  When you run getnewaddress, you get the address corresponding to the oldest key in the keypool, and a new key is generated and added to the keypool to take its place.
So if your hypothesis is right, the key is still in the keypool, and if you execute getnewaddress again, you should get the same address as you got before.  Then you'll know you have the key.  bitcoind may not expect that there are already transactions on that address, so you might have to run bitcoind -rescan to pick them up.


text:
reusing an address how can I get the confirmations
I would like to reuse an address I was thinking of using blockchain.info api which returns the amount sent to the address if confirmation reach the set parameter. When I send more BTC to the same address the confirmation parameter no longer works. Is the another solution for this?
https://blockchain.info/q/getreceivedbyaddress/adressxxxxxxxxxxx?confirmations=4

Don't reuse addresses, don't use blockchain.Info, don't use this party APIs.

Jannes is there a free api provider that you can recommend ?

Everything starts with running your own full node: bitcoincore.org


text:
Bitcoin node sync
I want to install a Pruned Bitcoin node with limited connections. I will be connecting to it with JSON-RPC to interface with my web application. What happens when I want to fetch information about an address that is not in my pruned blockchain on my node? Can someone explain this to me?

The pruned node will always have the full set of UTXOs available. This includes all spendable transaction outputs, also the ones of addresses that you hadn't been watching previously. If you want to look up old transactions of a previously unwatched address, your node will not be able to provide the information if you have already pruned those blocks. You'd either have to redownload and resync the blockchain to look for them, store the full blockchain in the first place, or use a third party service to look up the information.

I was under the impression that if I was looking up a transaction that was not in my local blockchain, my node would fetch the transaction from another node and return it to me?

@Nelson101: That's actually a good question. Clearly, if you are looking for a specific transaction it would work that way (you just request it by it's txid). However, when you try to look up all activity of an address, I don't think that full nodes would do this by default, but it could work of course. They wouldn't by default, because it tells the node they ask what addresses exactly one is interested in. Actually, that would be a good follow-up question.


text:
Tried to fix unconfirmed transactions, remaining balance gone!
apologies if some of the details aren't relevant, I'm not quite sure what's going on and I'm getting desperate!
I'm using the latest version of MultiBit HD. 2 days ago I bought some BTC (I already had a little in my wallet) and tried to make 3 payments. They appeared at blockchain.info pretty quickly, and I could see in MultiBit that they had been seen by peers, but remained unconfirmed. The transaction fee for each was set to the default (0.0001 BTC), making the fee-per-byte 19.231 sat/B for one transaction and 44.444 for the other two.
As I couldn't work out why it was taking so long I tried to cancel the transactions, so that I could resend with a higher fee, but the option to reset the blockchain & transactions (as per the MultiBit manual) doesn't seem to exist in the current version. Restarting MultiBit did nothing, neither did reinstalling.
I then tried "repair wallet", hoping that this would have the same effect - instead, my remaining balance disappeared! A small amount of BTC has appeared as unconfirmed though - has my balance just somehow become unconfirmed? Why/how do I avoid this in future? And, what should I do about the outstanding transactions? The intended recipients are starting to get annoyed with me, and I can't just buy more BTC and send that with a higher fee in case the old transactions suddenly decide to work!
Any help would be extremely gratefully received - even if it's just to tell me how not to make the same mistake again! Transaction ids:
d86bc86b30495d4150a0fb1733038cb0c3fced57803de0e91ad4c13326b28d58
2a8191e9ab4f3d96cdf5a557146d470a0c78a4c7b1b64051c0f90417407019a3
b854be622f4e4fa7229c14b2054b62e4ddd4441e993085fe9f229798e7215f16
TIA :)

Follow up: my balance is back, leaving this as yet another "unconfirmed transaction" question... I've tried everything in the other answers though (can't double spend - dug out my old PC to fire up a second copy of MultiBit, and it's showing the same exact stuff as the primary copy). Might just have to double pay & write this off as a loss...


text:
What happens when "Request expires" in Electrum?
If I understand correctly, wallet is a collection of private keys.
Electrum client, in "Receive" tab has this form to request money.
Every time new "Receiving address" changes, Electrum has to generate new sequence:
private key → public key → bitcoin address

What I'm unsure about, is whether Electrum ever deletes private keys that were generated, consequently making some bitcoin addresses it previously generated no longer controlled by me?

As long as you only work on the GUI, Electrum won't create private keys it doesn't generate again when you restore the wallet. On the console, you can increase the gap limit which can cause Electrum to not generate the private keys you already used to secure funds if you don't also increase the gap limit after restoring your wallet. But this doesn't mean your funds are lost, afterwards, if you keep the seed. For one thing, you can increase the gap limit in your stored wallet, for another thing, your funds will become "unlocked" after you used the restored wallet enough to make Electrum generate the private keys, again.
The "receive money" functionality of Electrum only is a built-in note program. You note for yourself that you're expecting a payment of 30 mBTC from Mark until January 18th. If he didn't pay until then, Electrum will tell you that his payment is overdue and you can get angry at him. However, Electrum has no means of sending Mark an email or something, and therefore doesn't do so. It's just notes for you. Furthermore, these nodes aren't restored when you restore your wallet via your seed as they remain on your computer and aren't sent to a cloud service.
And no, Electrum won't delete the private key corresponding to the public key corresponding to the address you noted as the receiving address, afterwards. That'd be a really bad thing. Just imagine, Mark is 10 minutes late with his payment. Then, the money he sent slightly too late would be lost forever.
You can even find this out for yourself: If you go to the tab "Addresses", you will see your wallet's addresses. The receiving address in the tab "Receive" always is the upper most unused and unmarked address, but the address is already there, before you create the receive note. And so, of course, is its corresponding public key and the private key which corresponds to that.
The only things happening when you tell Electrum that you plan to receive money, is that the note in the receive tab is generated and the address is assigned a label (which you can see in the addresses tab), which is just another local note.
You can of course hand your addresses out to people (in arbitrary order), without telling Electrum that you plan to receive money on them.

Can you please clarify first sentence, especially this part Electrum won't create private keys it doesn't generate again when you restore the wallet?

When you created your wallet, Electrum showed you a seed. You should not show this seed to anyone as anyone who knows it can steal your money. But you should keep it available for yourself in case your computer fails. If your computer fails, you can install Electrum on your new computer and restore your old wallet using the seed. This means that you don't lose your money if your computer fails.

Thanks, learning all those technical details makes it feel a lot safer about managing my BTC. Great answer.

@UTF-8 do I understand correctly Electrum stores hashes from seed phrases on their servers? and those seeds are effectively paired with all the private BTC keys which are in your Electrum wallet?
if so, is it better to store private keys or seeds on your paper wallet backup?

@ivan866 Please post a separate question regarding this.


text:
How to share the blockchain across local network residing on 1 PC, not copy?
Shared blockchain... I have a server PC that is on all the time and runs a copy of bitcoin core 24/7.
My main personal computer I use separate for everything else including and I use both Bitcoin core and Armory.
Each time I open either of these I have to update the blockchain to my computer, no big deal if it is only a day or two behind but it means I have two copies of the same blockchain, one on each PC. Would be nice to not have that increasing disk space used on my main personal PC.
Rather than doing a copy from the server PC, is it possible to set up somehow, somewhere in the config file of either or both wallets to share the blockchain that will always be up to date on the server PC across my LAN ?

I don't know whether it works because I don't use Bitcoin Core, but if you're on a Unix system, just softlinking to the blockchain data via some network protocol (like SFTP where you don't have to set up anything besides installing an SSH server, which you probably already did, on most distros) probably works.

I wouldn't try to have both bitcoinds attached to the same storage, that sounds like a recipe for disaster, if it'll start at all.
You can either tunnel the 8332 port on your personal computer to the remote server like this:
ssh -L 8332:localhost:8332 <remoteip>

This'll basically say "whenever I connect on the local port 8332, open a connection on the remote end to localhost:8332, i.e., your server's 8332 port, and tunnel all traffic through it". So this mimicks a local bitcoind but transparently passes everything over to the server. No need to share at all.
The other option is to add the following line to your bitcoin.conf file:
rpcconnect=<remoteip>

This will make bitcoin-cli connect to the remote bitcoind instead. You also need to make sure you actually allow incoming connections on the server, so this may be a bit less secure than the SSH variant above.

Bitcoin Core uses LevelDB which relies on mmap filesystem access - something that is generally available for network storage.

I'm yet to solve this as I held off until I got a NAS , so I will want to stick the blockchain on that and I suppose one of the bitcoin clients has to service it while other clients can just look on, haven't tried your suggestions above yet.

If you can run bitcoind on the NAS itself (e.g., dockerized on Synology and similar) you should do that and expose the RPC port to the LAN. Otherwise you could mount a volume on any other machine, run bitcoind there, possibly with the -datadir=<volume-mountpoint> option so that it stores the data on that volume, and have that bitcoind expose its RPC port to the LAN.


text:
Thin Client and OP_RETURN
I'd like to better understand how a light client works. As far as I know, a light client stores locally only the block headers (80 bytes each) and it receives a new block header on average each 10 minutes.
I've essentially two questions:
1) How can a light client retrieve a transaction given its hash? I'd like to get back the complete transaction so to read out the data after the OP_RETURN code.
2) How can the light client be sure that the retrieved transaction is really the one in the longest blockchain? Does it simply check if there are 5 blocks already confirmed after the transaction's block?
Thank you very much

1) The easiest way within the protocol is probably to add that transaction hash to a bloom filter, send the bloom filter to a remote node with filterload, and request each filtered block. This will send you only the transaction you're interested in. (It will also send some extra transactions that match the bloom filter because they're false positives.) See BIP37 for more details about how this feature works. This is how BitcoinJ based light clients find transactions relevant to them.
Knowing the block height that this is included at would simplify this enormously, as you will only need to look at one block, instead of the entire chain.
2) No. They get the block headers for the entire best chain. This goes from the genesis block to the current tip. (This is currently 450000*80=36MB) They then check that the relevant block is somewhere in that chain.

thank you for the explanation! Can I also ask you what are the minimum requirements for a thin client in term of RAM and CPU ?

Pretty much nothing. Strictly speaking, you don't even need to keep all of the block headers once you've checked that they connect to the genesis block. You could keep only the chain tip, and the ones you're interested in. The primary issue with thin clients is not the resources they use, but their inability to check whether a blockchain is valid.

Ok, now I've got it. To be sure the blockchain is a valid one, we need the complete blocks with all the transaction, so a full node right?

Right. You need all of the blocks to enforce rules like not letting the same output be spent twice.

Hi @nick , if I am a thin client (bitcoinj) and I know both the tx_hash and the block_number, what kind of message do I need to send to my peers to get back the complete transaction?

@gatb27 Once you know block_hash, and tx_hash, you send the bloom filter with filterload. Then you send getdata, with an inv type of MSG_FILTERED_BLOCK, and the block hash. This documents the low-level details. https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors Let me see if I can work up some example code for you.

I've just studied the different kind of messages on the developer guide :)
I'd like to ask for the last favour: I'm interested in a snippet of code in python (jython for bitcoinj) that given a tx_hash and block_number, it returns the hex after OP_RETURN in the tx_hash output. Where can I find a guide for learning how to do it? :)


text:
How a Light Node can get a block?
I'd like to better understand how a light node can retrieve a complete node. If I understood correctly, I can consider a light node a node which is part of the peer-to-peer network that receives and stores only block headers, which means around 80 Bytes every 10 minutes (of course with some approximations).
Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the getData message, which other nodes can reply with a block message.
Do you have any hints on how to evaluate how many bytes the light client must send for the getData message and how many bytes must be received? I think it could sufficient to retrieve only one block from the network since the light node can validate if this block is part of its local head-only-blockchain.
Thanks for the support :)

Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the getdata message, which other nodes can reply with a block message.
Do you have any hints on how to evaluate how many bytes the light client must send for the getdata message and how many bytes must be received?

It depends on how big the block is. The block is 0-1 MB prior to segregated witness activating, and 0-4 MB afterward. In general, the earlier the block is from, the less data it contains.
There's some overhead for the message header, but it's 24 bytes, so it doesn't really matter.

Ok thank you! Is my way of thinking about the exchanged messages correct ?

There's overhead for message framing, and keepalive messages. It's not exactly 80 bytes/10 minutes.

What is the best approximation we can do to evaluate this overhead?


text:
Transactions confirmed on Blockchain but nothing received to my Blockchain wallet
I need some info/help. I have sent some Bitcoins to my Blockchain wallet. They have all be confirmed and done with. But it has been 2 days now and nothing has shown on my wallet.
This is the transaction on Blockchain,
https://blockchain.info/address/14kQfsxstFMjhL1RJAngoiEU13BaVUVjbS

Possible duplicate of Wallet not updating with balance and database error

The final balance and total received sit at:

Final Balance  $ 395.48

So I assume you haven't been able to access the coins yet. What wallet are you using? Is it possible that you have multiple addresses in your wallet and you need to manually find the privatekey/balance of 14kQfsxstFMjhL1RJAngoiEU13BaVUVjbS? Because from the Blockchain everything seems fine.


text:
Installed 2nd Bitcoin client and invalidated blockchain progress
over the last couple of days I synchronized the block chain on an old version of Bitcoin QT where I still had funds in my wallet. It started out 90 weeks behind, then over the course of 4 days updated until it had 23 more weeks to go. At this point any progress stopped, seemingly getting stuck for 24 hours or longer and I couldn't find a solution to make it continue its synchronization.
I then installed Unlimited Bitcoin since I heard that new clients would synchronize much faster. I assumed that both clients would build their block chain separately from each other but the Unlimited Bitcoin installation corrupted any progress that Bitcoin QT had made and upon starting it the next time, it had to re-synchronize now being more than 200 weeks behind.
Unlimited Bitcoin however seems to refer to QT's progress status, also being 200+ weeks behind and not updating any quicker.
What would be the fastest way to get the blockchain up to date on my hard drive in a way that the funds on my QT wallet can be used?
Thanks in advance.

BU might have changed their default installation directory, but I doubt it. Then it sounds to me that you were running two copies of Bitcoin software working with the same blockchain data. Even when not running them at the same time, I'm not surprised that this might corrupt the block data. (If you've run them at the same time, no wonder at all, although I thought there was a lock in place to prohibit that.)

Don't run more than one Bitcoin software from the same directory.
Pick whatever flavor you may choose to run, install a current version of that.
Wait until synchronization is finished. Later blocks take longer than earlier blocks due to more content.


text:
How can I officially prove that a Bitcoin private key is owned by an entity?
I am the co-founder of an early-stage startup that aims to prove existence of various qualifications (academic, professional...) via the Bitcoin Blockchain.
In order to validate a piece of data, an issuer (say a university or other issuing body) would have to send a small transaction from their wallet which is managed by us.
Is there any way to officially prove (in this case in UK legislation) that a specific legal entity is in possession of a bitcoin private key and, therefore, to the coins associated with it? I know of a "statutory declaration" but is there anything more specific I can do?
Basically I would like to transfer ownership of the wallet to the customer, in order for myself to be criminally punishable if I upload qualifications to the Blockchain without their consent.
Is this at all possible?
Thanks!

A middle man trying to create a business around being a middle man with a technology thats supposed to remove intermediaries?
It seems like you could accomplish what you want with multisig wallet and counterparty.
In the example I have in mind,
The issuer could create an asset that represents qualifications. The issuer could invite their practitioners to a 2-of-2 multisig address and send the asset to that address.
Although we can't confirm if only those two parties have the keys, we can see where the asset came from (but it one scenario it can also be issued by the multisig address and never moved). We can rest assured that it would require both parties, one of which being the individual, to create a proposal to move the qualification asset. And these proposals will be rejected.
Another perk is that the asset can correspond to a centralized system.
Predictable, there's no place for your business in this mix, but that's probably the point, so I would like to thank you and your investors, in advance, for their charity in bringing this idea to the world. Should probably do an ICO

Thanks for your suggestion. I regret to inform you that the idea of using blockchain technologies to certify the existence and validity of documents is one of the oldest around. Check out "BlockCerts" (blockcerts.org) and "Proof of Existence".

@AlbertoDeca and counterparty, and Factom, other metalayers. Your monetization won't be inherent to the technology, but you could sell a service as long as nobody figures out how simple it is.

The whole point of digital signatures is that ownership of the private key is never shared. The owner of a key pair can only prove that he is in control of the private key, but there is no way of proving that nobody else has a copy of the private key. Of course, if someone creates a key pair and signs and publishes a message to the effect that he is the sole owner of that key pair, he'd have a hard time arguing that another message signed using that key was not signed by himself.
Your description sounds a bit vague, it is unclear to me what you mean by creating a wallet - do you mean the software (in which case the user would indeed be the owner of the keys) or the wallet data? In the latter case, you cannot prove that you don't keep a copy of the private keys.

I would create a wallet using the software. Then the private key would be in my possession. I'd like to transfer possession of that private key to the customer, but this would make it hard, as you and the other responder say, for them to prove that somebody else sent a tx instead. I would not have an answer to this dilemma...

The only valid solution is to let them create a key and never share the private half with anybody (including you.)


text:
In a private blockchain network, can we delete the first N blocks and reassign the N+1th block as the genesis block?
I am aware of the data loss caused by deleting the first N blocks. But I am curious to know whether such a task is possible or not. If so, how to practically implement it?

In a consensus change of a system, anything is possible if all participants agree - you simply all switch to different software. So the answer is obviously yes, but perhaps that is not what you want to know. Could you clarify why you would want to do that, or what you would hope to achieve by doing so?

With blockchains, you can basically do anything with a hard fork.  In the case of private blockchains, you will have a much easier time getting consensus for a hard fork, perhaps as easy as the authority running the blockchain dictating that everyone must accept an upgrade.
The genesis block is hard-coded into the software.  To re-assign a later block to be the new genesis block, you would need to hard-code that block into a newer version of the software.  This will only be recognized as valid by nodes running the newer version of the software.  Assuming gaining consensus isn't an issue, this is possible.
Another thing to be concerned with is block height, and all calculations based on it.  It's easy to modify the client to start counting at N+1, but this also may need to be taken into consideration when calculations are made.  This will effect things such as difficulty targets and halvings.  If you modify all relevant code to take this into account, you should be able to keep things working correctly.

Can you specify some more things on how to do the implementation?

Not really.  This is just an overview of what would need to be done, and I likely missed a few things.  Personally, I feel like this is a strange way to solve a problem.  My guess is that whatever problem you have could be better solved another way.

You also need to consider whether there's an associated data structure, like the UTXO set, which is needed to validate new blocks. If there is, that data structure will need to get to new nodes somehow, preferably by downloading it from existing nodes and checking the data against a hash distributed with the upgrade client.


text:
even after 0.0005BTC Fee, My transaction is unconfirmed
I made a transaction of approx 1 bTC.
MT transaction id is
https://blockchain.info/tx/44f8a9939776bac1b98dffb4fe72d5ad97f3b2171c3b717677e9ae03b6bcef4d
but it is still unconfirmed even after the 0.0005 Fee.

now it is confirmed

Don't use fixed fees! Fees are not per transaction, they are per byte (size of the transaction matters).
The size of the transaction is based on how many inputs you use. Mostly, that's not under your control.
You transaction above is 815bytes.
You fee: 0.0005 0BTC.
~= 0.000613 BTC/bytes
The current feerate to get confirmed within the next 10 blocks is 0.00136386/1000bytes (March 8th 2017).
Your fee is way to low to compete with other transactions.


text:
Is it possible to Send the total balance of Bitcoin from the Wallet using rpc without having to specify the exact amount?
I know we can send coins using the move, sendtoaddress and sendfrom commands from the console or commandline.
However these commands require to specify an "exact" amount, meaning you need to check the balance before you execute the commands.
Is it possible to just send all coins to an address or to oneself in the same wallet using just one command.
Hopefully someone understands what I"m talking about here.

Yes, this is possible, but you still need to check the wallet balance first.
However, you need to know the fee, as you usually specify how many BTC are supposed to arrive at the destination, rather than how much is being sent in total.
The sendtoaddress command takes 5 parameters: address, amount, comment, comment-to, subtractfeefromamount. This last option, subtractfeefromamount, is what you need.
So if your entire wallet balance is 0.1337 BTC, you could issue:

bitcoin-cli sendtoaddress "address" 0.1337 "" "" true

Also, you can't use move, as that does not actually issue a Bitcoin transaction, but only updates internal balances.

How many satoshis are deducted as transaction fee?

Bitcoin has a floating fee per byte rate. You can either configure what that rate is, or let estimation do its work.


text:
technical requirement to running a Bitcoin node
I want to run a full node in order to support the network, however i am wondering about what are the technical requirements to do so.
how much RAM(for utxo) do I need? and what internet throughput will be sufficient?

Bitcoin.org suggests the following minimum system requirements:

Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.
145 gigabytes of free disk space
2 gigabytes of memory (RAM)
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 140 gigabytes the first time you start your node.
6 hours a day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.

As of 2019 this answer is no longer up to date. At least not with respect to disk space. Today you need at least 250 GB.

@Thorkil feel free to update the answer, although the website suggests 200 GB not 250 GB


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

Are you interested in orders on an exchange (which never reach the Bitcoin blockchain) or withdrawals/deposits into an exchange (which are recorded on the Bitcoin blockchain) ?

I'm interested in the way how the exchange handles the user's wallet. I have some spaces in knowleges about work of exchange. So I want to know what happens when the exchange closes my order and about the flow of btc from one wallet to another.

Does exchange work directly with my wallet or I have to make deposit/withdraw to exchange account?

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

Thanks for response! As I understood, the flow is something like: I deposit bitcoins to a wallet controled by exchage (transaction is added to blockchain) In a case of order execution no new transactions are opened in blockchain, but updates the value of btc on my account. And a transaction is opened when I withdraw btc back to my wallet. Is it correct?

Yes, that's correct.

authors: ราชัน ไร้พ่าย


text:
How do I set up a Bitcoin account that I can transfer money to my checking
I am not sure how to set up a Bitcoin accout. I downloaded Bitcoin Core but have no idea what the hell I'm doing

Possible duplicate of I am new to Bitcoin, how can I get started?

It isn't necessary have the bitcoin COre to start to use Bitcoin.
If you are a beginner, I recommend you to read the site below:
https://bitcoin.org/en/getting-started
I have started opening a account in a exchange to buy bitcoins and transfering for a wallet.

The most important thing for you to understand is the importance of the Private Key.
The second point for utilizing Bitcoin is understanding that the address (public key) is where you target where to send Bitcoins to, and where to receive Bitcoins.
Once you know that it is important to Secure and never share and be cautious where you import your private key, then you can gain Bitcoins and reliably use them throughout life.
Check out this website BitAddress.org and observe how it gives you the Private Key (secret) and Public Key (share)
There is also a video tutorial about it: Video about using BitAddress.org and importing the key into an online wallet.

authors: محمود اخلاقی


text:
Is it still possible to do cpu mining for experimenting?
Commercially speaking I know it worse than pointless! But please, be gentle and don't remind me. Neither bother about being insulting or patronizing because I ask such a 'stupid' question. Thank you for your comprehension.
The reason I'm wanting the - already four times over obsoleted - cpu mining is because I don't want to earn money with it. It's all about being curious about how Bitcoin works. Not an altcoin or something else. It's about learning about BC.
CPU mining is the only option left. Asic usb miners are sold out everywhere. Raspberry Pi don't support GPU mining, do they ? And I really don't want to buy a dedicate device - because I want to know how it technically works. Do CLI stuff to make it work.
If this wasn't serious to me, I really wouldn't bother asking around how to do it.
So, now that's out of the way...

Is it today still technically feasibly to do solo cpu mining ? (on Rpi3)
If not, how come ?
If it is feasible, is there an online guide, tutorial, ... I could use ?
Optional: Why are people so reluctant about this ? It's not that I'm going to crash the BC system, am I ? :-)

It's perfectly fine to me to download the bulk data with a faster computer and upload it to the rpi.

re: reluctance, it's just that the question has been asked so often (e.g. http://bitcoin.stackexchange.com/q/12294/5406). ;) You may want to read up on regtest. If you set your bitcoind to regtest mode, you create your own simulated network and can mine instantly.

Okay - from where I can switch to 'real', well, mining ?

I don't think it's possible right now, because CPU mining power is so low that you wouldn't even be able to mine shares in a mining pool. You would be treated the same there as solo-mining: your cpu would be running full load and would just find duds.

Solo mining is what I seek - and yes - I don't expect anything else than duds. :-)

related: How can I start mining Bitcoin?

What do you actually expect to learn from this?  I can understand wanting to see what happens when a proof-of-work is found, but you won't ever get that far.

Yes it is technically feasible to solo mine with a rpi3. The 'fastest' miner you could run would be minerd. However, there is a slim-to-none chance you will ever mine a block on the bitcoin mainnet, but there is still a chance! I would save the trouble of building minerd and use bitcoind's build in block generator
bitcoin-cli setgenerate true 1
You don't need to worry about crashing other bitcoin nodes, they will validate if your newly mined block is valid.
If you are looking to have some fun with mining on the rpi take a look at bitcoind's regtest mode. Regtest mode lowers the mining difficulty to the absolute minimum level of difficulty. This means you can mine 1000's of your own blocks per hour on a rpi3.

Note that Bitcoin Core 0.13.0 removed the internal mining capability. As to the probability of winning at solo-mining, playing the lottery is much more profitable, see one, two, three related questions.

Not related to Bitcoin, but you can mine Magi coin, a coin whose algo is M7, and is for CPU-only mining.
https://bitcointalk.org/index.php?topic=735170.0