text:
Do we need to maintain the ability to do a reorg over 100 blocks?
The protocol requires that freshly generated coins wait 100 blocks before they can be spent in order to avoid polluting bitcoin addresses with bitcoins that are "uncreated" by a reorg that invalidates the block that created them.
If we decide that "the chain with the most difficulty" means "the chain with the most difficulty over the last N blocks" and pick a good N, it could make some things simpler AND make transactions at a depth of at least N immune to a 51% attack.  Thus, it limits the value of cornering the market in hashing power.  Such "cornering" could happen without being noticed, so it has begun to worry me.
If I remember correctly, we've already done this by (sometimes?) making checkpoints in the Satoshi client at sufficiently large depths when new clients got compiled.
N = 4032 would ensure that two difficulty levels are spanned.
N = 100 would change the pain of a 100-block reorg from something barely tolerable to something impossible.
If the protocol were changed to use this, then a UTXO database based on the results of the blockchain up to the checkpoint block could replace the gigabytes of blockchain that we currently use for validation.
EDIT: Why I asked: It would be nice to validate a UTXO database so that one didn't have to build it from (always increasing GBs of) downloaded block data.  We validate transactions before passing them on, but do we validate them when we download a(n old enough) block?  I think we trust that whatever (old enough) block we get from a peer contains good transactions, so we don't hunt all previous blocks to validate them.  If this trust is already being used, as I suspect, perhaps it is more useful than we know.  I asked a related question: Would a normalized, hashed, protected chainstate reduce miner storage costs?.  I'll have to explore the work on making a UTXO Merkle tree as that seems promising.

Clients today only store the UTXO, the blocks are optional and completely unused for anything other than serving to other peers. Reorganization is served by undo blocks which are stored separately. You always need to have all the blocks at some point in time to build your UTXO though, there's no getting around that.

What makes you think it's a bad thing that coinbase transactions need to be mature before they can be spent? It also serves as a (small) protection against a miner doing something really bad. The evil block might expose a big problem and tank the BTC price, making the reward worthless as well. Or other miners might quickly come to a consensus to fork the chain and orphan the evil block.

I don't think it's a bad thing.  I think it's a great idea.  What's bad is pain, and waiting for coinbase transactions to mature is a good way to avoid that pain.  I suspect I wrote something that puzzled you and I haven't addressed it yet so if you can explain a bit more, I'll do my best.

A) Coinbase maturation is a consensus rule, and would require a hardfork to change. B) 100 blocks is less than a day. Hell, exchanging your bitcoins for fiat will take you longer than that.

@Nick, I still think one of us is not understanding the other.  I didn't mean to propose changing the coinbase maturation.  I intended to suggest that making it impossible to do a reorg at some depth ("N or greater") would solve more problems than it would create - if N is big enough.
I like revising my strategy for rhetoric, so if you don't mind quoting what I wrote that seemed to propose a change to the maturation, I will thank you.

If the protocol were changed to use this, then a UTXO database based on the results of the blockchain up to the checkpoint block could replace the gigabytes of blockchain that we currently use for validation.

You can already do something similar to this by turning on -prune. That can cause your node to stop working if the reorg is more than 288 blocks, though as you noted, that doesn't happen often.
That still requires you to download the entire blockchain in the first place, of course.

If we decide that "the chain with the most difficulty" means "the chain with the most difficulty over the last N blocks" and pick a good N, it could make some things simpler AND make transactions at a depth of at least N immune to a 51% attack. Thus, it limits the value of cornering the market in hashing power. Such "cornering" could happen without being noticed, so it has begun to worry me.

Suppose a node joins later, after the new chain has been published. From its perspective, the two chains were created at the same time. Because of that, it would naturally choose the one with more work attached to it.
So how do we avoid that? This is a problem that's a lot more complicated than it looks.

The protocol requires that freshly generated coins wait 100 blocks before they can be spent in order to avoid polluting bitcoin addresses with bitcoins that are "uncreated" by a reorg that invalidates the block that created them.

Sure, but we're talking about two levels of consequences. In one circumstance, one person on the network loses money. In the other, the blockchain is forked forever.

Mind that you can also enable prune with a higher target like -prune=2000 (=2GiB) and that the amount of possible blocks/undos is only an estimation (mind the variable block size).
If a reorg with more then 100 blocks would be a dramatic (bitcoin-killing?) event. Blocks nowadays containing transactions summed to a value of ~3000BTC. Reorging 100 blocks would put around 3'000'000 transactions back to the mempool (a value of 300'000BTC).

@JonasSchnelli Due to a regression in syncing logic until very recently the majority of nodes in the network couldn't handle very deep reorganizations either. Hundreds of nodes still run <=0.9.x unfortunately, though they have other problems at present.

@Nick All forks appear to have been created when block one was solved.  One of us (probably me) doesn't understand something the other one knows.  It seems to me that there is a critical number of blocks beyond which a reorg would be so painful that we could choose to just accept the problem - grandfather it in or whatever.

What you're describing could be implemented using broadcast checkpoints, or something similar. You now have two problems: ensuring that no one gains a majority of hashpower, and protecting the broadcast checkpoint key. Either can be used to do evil stuff.

We already had the first problem, but yeah, about that new problem:  That is why I figured it would be a good idea to include the merkle root of the UTXO database (not exactly a checkpoint, as you said, but same idea), once it's structured as a merkle tree, which I think is being worked on (see the discussion on the question I posed, which is displayed in the new paragraph I added to this question).

It seems like you're trying to fix two unrelated problems (sync time, big reorgs) with two unrelated solutions. (utxo commitments, refusing big reorgs) It will be a lot easier to discuss your suggestions if you stick to one topic per question.


text:
Why is my node being flooded with bitcoinj clients from 138.197.0.0/16?
I'm not the only one to have noticed this (discussions on reddit here and here): out of 70 or 80 incoming connections on my bitcoin core full node, about 50 are from just one single network (138.197.0.0/16, belonging to DigitalOcean, an apparently reputable cloud hosting provider) and all running variations of bitcoinj. This just seems peculiar.
I don't have a particularly fast connection here and my upload bandwidth has been saturated by this for weeks, so I'm dropping incoming connections from 138.197 until I figure out what's going on. Since those nodes don't appear to be contributing to the bitcoin network, it doesn't seem like I'm harming it by dropping them, but I still feel bad doing it. But I also don't feel right with over half of my connections coming from one place! So, does anyone know if this is legitimate usage, perhaps an attempt at relaying SPV cients' transactions extra-quickly or the like? Is it a test or experiment of some sort? Or is there something nefarious going on?

this is the back side of decentralization

@amaclin, explain what you mean by that?

source: Stack Exchange

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

sort: votes


text:
Offline wallet (Electrum) + Trezor not signing transactions
When I want to make a transaction I follow these steps

Create order in the ONLINE computer
Copy transaction to a USB
Plug USB to OFFLINE computer
Load transaction from file
Plug TREZOR
Sign transaction

But during the signing process an error popups with a message similar to "Unable to connect to servers ". In my opinion it makes no sense, it is supposed to be an offline wallet. There is no need of a server to sign the transaction. ¿Am I wrong?
As far as i know, both computers use the same Electrum version (2.8.3)

Well, yes, sortof.  Signing a transaction requires the scriptPubKey from the transactions that funded the source addresses, and if you don't have a copy of the blockchain there's no way to get that information.
I believe Armory handles this by including the necessary information in the data it gives you to take offline, but Trezor apparently does not, and does not considers this use case "redundant."

that's normal. Trezor requires the list of input transactions.  your offline wallet did not have them and tried to fetch them.
we will not fix that. the list of previous tx will no longer be needed with segwit.
Electrum issue

If you wanted to work around this issue, you could modify the Electrum plugin to load the necessary info from, e.g., a text file instead of trying to use the internet.  The place you would need to change is shown in this post (.../plugins/trezor/plugin.py).

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


text:
What should you set as rpcpassword and rpcusername in BitCoin?
Every example/tutorial looks the same:
rpcpassword=<somehashofsomesort> and rpcusername=rpcuser

They always use something like rpcuser, and some hash for the password. Why is it like this? Does it offer any advantage to break out of the shell and have your username and password be something you like?
In another place I found this:
#rpcuser=alice
#rpcpassword=DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=

Does setting your username to alice cause you to no longer be anonymous, and that's why everyone has the same username?
Do I even need a username and password?

I suggest you don't use rpcuser and password if you don't need to. If you don't set them, Bitcoin Core will use a cookie in your .bitcoin directory as a mean to identify you.
Besides rpcuser and rpcpassword are deprecated now, you're supposed to use this python script to generate a password and copy the output in your config file like this : rpcauth=[user]:[long random string]
But once again, I suggest you don't use it if you don't need it.
As for the alice username, it's just a common placeholder name originally used in cryptography, "Alice" and "Bob" are the two parties that try to communicate, Eve is the passive eavedropper that tries to snoop on their private conversation and Mallory is the active attacker that tampers messages or disrupts communication. I think there's no harm using it as a rpcuser name though.

can you please elaborate on this cookie in .bitcoin/? Where can I get more info about the filename, file contents, encoding, etc?

The .cookie file is pretty straightforward, it is a plain text file that contains only a string in the form __cookie__:<32B of randomness>. It is automatically generated inside the datadir when Core starts.

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


text:
How long a high-priority transaction takes to evaluate
I am missing something so far in reading this (excellent resource). I read the part about transactions for the most part, but I don't understand the actual code evaluation part, and how long it takes. So if you have a low-priority transaction (because of a low-fee), it could take "a long time" to run, or potentially never. If you have a high-priority transaction (high fee), then it will get run "quicker" or "with higher probability". My question is what actually is happening between the moment of a transaction being "created" and it being "added to a block". I wonder if your code is actually run before the transaction is actually added to the block and validated, or it's never run until fully validated. I wonder because this seems like a huge performance slow-down in resource-intensive applications, and I wonder what people do there.
Here it says:

A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes on average, thereby adding those transactions to the blockchain.

So my question then basically is, if your code doesn't evaluate until that 10 minutes passes, or when the code actually evaluates. Basically what happens between a transaction being created and when it is incorporated into a block.

When a transaction is published to the network, every node that hears about that transaction will check to see if it is a valid transaction according to the network's rules. If it is not valid, it will be discarded, but if it is valid it will be added to that node's mempool. Nodes will relay valid transactions to their peers in the network, but there is also no requirement for a transaction to be known to all nodes before it is included in a block. A miner can put their own valid, but otherwise not published transactions into a new block they have mined.
Similarly, when a node hears about a new block, it will check to see if the block is valid according to the network's rules. If it is, then the node will update it's blockchain record to reflect any state changes incurred by transactions in that block.
With each subsequent block that builds off the block of interest, there is a higher degree of certainty that the transactions included in the block of interest will be permanently included in the blockchain record.

Wondering where I can find more information on this, I'm not seeing it here in the transaction section.

What other information are you looking for? @MCCCS added a good answer as well. But the crux of it is that when a new block is found, nodes will update their blockchain record (and thus UTXO set) to include the changes made by transactions that were included in that block.

I guess I'm looking for "transaction validation process".

I'm not sure what other info to point you towards exactly... but the answer on this Q has some info about what constitutes a valid tx: https://bitcoin.stackexchange.com/questions/77912/how-miners-validate-each-transaction?r=SearchResults . There is a little more info about how transactions are serialized here: https://bitcoin.org/en/developer-reference#raw-transaction-format . The ultimate reference for expected behaviour of the network is the source code itself: https://github.com/bitcoin/bitcoin/tree/master/src

Validation of a transaction is a sub-millisecond operation. The most critical part of a transaction's journey is when it'll be included in a block. There's a 1 MB (plus 3 MB witness) transaction limit in a block. The mempool is usually larger than the block size limit, and therefore the block space is a scarce resource. Thus, miners only choose the transactions with the highest fee/kb ratio. If there aren't many high-fee transactions, then transactions with less fee/kb will also be collected. Miners are free to choose their transactions to maximize their profit, but the choice of transactions is not related to the time it takes to validate a transaction.

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


text:
How to start using signrawtransactionwithkey instead of signrawtransaction
I am following this tutorial, which says to use signrawtransaction. However, I get:
error code: -32
error message:
signrawtransaction was removed in v0.18.
Clients should transition to using signrawtransactionwithkey and signrawtransactionwithwallet

The API call in the tutorial shows this:
$ signedtx2=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex2 | jq -r '.hex')

How do I do that same thing using the new signrawtransactionwithkey API? I started by generating a 256-bit private key:
https://gist.github.com/rietta/3640002
Now I'm not sure what to do. I guess I am to do something like this, but not sure exactly how to define it using CLI variables and such to make sure it's going to work.
signrawtransactionwithkey  "0200000001cfe62b9f1c52bc2998f9a0e6d6ee35430c93ec653d5691935178147a43090fee0000000000ffffffff01f0afd320766191d4c5c088ac00000000" "[\"cSXHtKRXWnCLWhuie8WC13cKF3qdnKL8vG3BiRpxgCXZkK2CHe9u\"]"  "[{\"txid\":\"ee0f09437a1478519391563d65ec930c4335eed6e6a0f99829bc521c9f2be6cf\",\"vout\":0,\"scriptPubKey\":\"a914111111111111111111111111111111111111111187\",\"redeemScript\":\"5221033d9aecbced8e776c03d283f6c0d64c6a301ad142d74d500fe8860c9b362fa4932102a4df3cb4e5286e180b7c68e323c778e32350a604d4f4a74c290d1c60c721687a52ae\"}]"

Looking further, I need to base58 encode the key.

signrawtransactionwithkey is for when you want to sign a raw transaction with a key you have that is not in your wallet. In that tutorial the key is just a key in your wallet, so you can avoid the issue of exporting the key by using signrawtransactionwithwallet instead.

If you just want to sign the raw transaction as it's shown in the tutorial, please use signrawtransactionwithwallet instead. It would be like below.
$ signedtx2=$(bitcoin-cli -named signrawtransactionwithwallet hexstring=$rawtxhex2 | jq -r '.hex')
$ bitcoin-cli -named sendrawtransaction hexstring=$signedtx2
69c9ef4d1adb48596c470146ee9b60593023b6eb870b79ef666a8c9369768469


text:
How to receive payments online to single address per user in scalable way?
Suppose we are building online casino/market and want to receive payments.
To be scalable, safe and have good user experience, we:

cannot generate new address for every single payment. Having single deposit address is a lot easier. Also users always can deposit to old address by mitake even if generated new address.
cannot check listreceivedbyaddress because regulary checking hundreds of thausands of addresses is not scalable. Also large RPC output when single user make thousand of deposits.
we should do not rely on external services online blockchain API.

We absolutely cannot use any RPC call that will list complete and growing list of transactions like all transactions for wallet or all transactions for address.
So, the most sensible way should be checking by listsinceblock to parse all transactions "per analysed block" and joining to user balances by destination address - incrase user amount in our online service and mark this payment as "completed" to not count it second time. Simplest way of marking this transaction as "already resolved" is to store its ID as "already used" in same SQL transaction that incrases user balance.
But I heard that it is possible to change transaction id in block chain, so is such solution safe?
How can I use RPC calls to receive payments block after block and which data can I use to mark payment as resolved to be safe from duplicated deposits on single payment?
TL;DR how "big players" like Cryptsy do receive payments?

Relevant question: http://bitcoin.stackexchange.com/questions/19567/does-the-original-bitcoin-client-scale-to-contain-millions-of-addresses

Use Bitcoin Core in server mode and use it's notification functions:
server=1
blocknotify = curl\yoururl
walletnotify = curl\yoururl

Set them up to make a call to your app.
This way, you won't be making expensive RPC calls to Bitcoin Core. You will only be receiving notifications for operations  that Bitcoin Core itself already is making. So you won't bring any extra load to Bitcoin Core. You will be limited by it's own scalability.

how "big players" like Cryptsy do receive payments?

Most big players are relying on Bitcoin Core's scalability running in server mode without bringing extra load to it as far as I know.

But I heard that it is possible to change transaction id in block
  chain, so is such solution safe?

Not after they have received a confirmation. So the method you described works if you wait for the blocknotify call for a TX before you update your users balance.

Strictly speaking it is not true that transaction IDs cannot be changed once they have received a confirmation. If a fork confirms the same transaction with a different ID and the fork then becomes the longest chain, then the ID has effectively been changed.

Yep. True. I thought a bc fork was too far out of the scope of the question.

+1 but I see a disadventage of this. This will cause problem in situation when wallet is working but web service is down (for example for maintance) and notify will be missed. But, with conjuction with scaning last blocks on startup of exchange, this can definately bring some improvement. Will accept this if no better answer during bounty will show up.

I strongly suggest you implement a separate service that will talk to the wallet and let your exchange software talk to that service. Do not make your exchange talk directly to Bitcoin Core. And yes what you are saying is true. If you miss the first 6 confirmations, then you will not receive notifications and you will need to query Bitcoin Core. If you implement a wallet service and separate it from your exchange, this should be easier to avoid.

Cryptsy is generating a new address per user.
Once generated it remains the same so there is no risk to deposit to "old address".
This is scalable and also easier to associate deposits to the right user independently from the sending address.

single-address-per-user doesn't guarantee scalability - if you check deposits by calling RPC transactions for address, it will not be scalable. After hundreds of deposits it will always return a huge list of transactions

That's not the best way, you can listen websockets transmitting new transactions in the network and refresh your address balance only if they appear in new transaction

I know it's late to answer but I provide my solution which handles most of the risks.

First of all, I prefer to generate a new address for any time when user wants to deposit; But if the condition doesn't let, there is another solution!

Solution: There is a getreceivedbyaddress API which gives the total amount of received Bitcoins for an specific address. I use this and a database for tracking user's deposits.
Here is the way I track it:
var totalReceived = (RPC request including the address in params field)

var lastDeposit = (DB query for fetching the user's last deposit's data)

if(lastDeposit.amount < totalReceived) {
   // insert a new deposit record for user
   // record includes the following fields:
   // 1. userId (Obvious)
   // 2. amount
   // 3. diff
   // 4. ts (for sorting, etc)

   insertNewDeposit(userId: userId, amount: totalReceived, diff: totalReceived - lastDeposit.amount)
}

// fetch the user's balance from db
var currentBalance = (db query)

// calculate the user's new balance (based on the new deposit)
var newBalance = currentBalance + (currenctBalance - lastDeposit.amount)

// update the user's balance in db
updateBalance(userId: userId, balance: newBalance)

You should use this method before any others which may require the latest balance of an address (user).

This will always track the balance of an specific address (user) even if the web service goes down; right after your web service gets online, when the user requests something related to the balance, this method will update and keeps the track of the balance!
The code could have been more optimized!
Regards :)


text:
Pending incoming BTC to Coinbase
I sent BTC from lending platform to Coinbase on Jan 2nd.  Still shows pending.
Can anyone provide any info and assistance in getting this transaction completed?
f69f851197a7b9bd8cf3e85a2436ed51e1049fa4b277273e074708de34540288
https://live.blockcypher.com/btc/tx/f69f851197a7b9bd8cf3e85a2436ed51e1049fa4b277273e074708de34540288/

You can download Electrum and create new transaction from output with higher fee, it's called "Child pay for parent"
You hsould have access to oone of output addresses.

Thank you.  How do i find one of the output addresses?

It's seems being confirmed, thakfully.  Electrum allows child pay for parent by simply two clicks of mouse, otherwose, there are complicated tutorials, google "btc child pay for parent"


text:
How much trust is placed on Satoshi Nakamoto?
Is the safety of bitcoin dependent on the creator of it being a trustworthy person? Or would it be safe to use even if it turned out the creator's day job was working at the NSA?

related: Does the creator of BitCoin hold a 'master' private key?, Do “the official bitcoin developers” control Bitcoin?, Who is Satoshi Nakamoto?, Have any cryptography experts vetted the bitcoin source code?

These are 2 questions in one. 1st (is looking for him really justified?) is really primarily opinion-based. The 2nd (and 3rd, which is mostly a follow-up of 2nd) isn't and I believe is legit: with all the news-frenzy about who Nakamoto really is(are?), a lot of people would potentially ask the very same question(s), regarding how much Bitcoin depends or not on their trustworthiness, identity, alive status, etc. Might be worth to change the title to the 2nd question to make it more relevant.

@JoePineda I've deleted what you described as the first question.

Is the safety of bitcoin dependent on the creator of it being a trustworthy person?

No, the safety of Bitcoin is not at all dependent on the identity of its creator.
The source code is public. The paper is public.

Or would it be safe to use even if it turned out the creator's day job was working at the NSA?

Again, the genesis of Bitcoin is unrelated to its current state or future state, except through the data of the blockchain.

see also have security expert vetted bitcoin source code

He does own a LOT of bitcoins. If he chooses to dump them on the market for whatever nefarious motive, it would cause a major disruption.

And a) a potential lead to unmask him, b) a great opportunity to buy cheap. ;)

he seems to own ~1/16 all bitcoins from some estimates... it would be possible to "dump" them (ie nearly "give them away" for free, quickly which would tend to be deflationary) but this is against the rational interests of anyone who wishes to maximize their own wealth.... it would be like dumping stocks.... is there any history of that such a thing being done other than during a panic?

@vzn - it's completely commonplace in markets (ie, such as the major world stock markets) that large players "dump" some of the instrument, for one sneaky reason or the other.  it's completely ok, legal, normal and commonplace, particularly in short-term scenarios


text:
Getting Error "Unable to sign input, invalid stack size (possibly missing key)"
I have created a key from using coinstring, and then imported it into my wallet. Then I ran:
bitcoin-cli signrawtransactionwithkey "$rawtxhex" "[\"$mykey$\"]"

But it results in:
Unable to sign input, invalid stack size (possibly missing key)

Any ideas? My mykey is not actually a variable, I am hardcoding it in my specific case so I know it is present.

What type of address did you make from the private key?

@AndrewChow what do you mean? I just pasted the private key directly in that command.

Before you can sign a transaction with a private key, you need to send Bitcoin to an address that is controlled by that private key. What type of address did you send to? P2PKH? Segwit? Something else?

@AndrewChow can you please direct me to some documentation, I am not sure what you're talking about. How can I send bitcoin to an address if creating a transaction requires signing something with the key in the first place?

You don't need to sign anything with the key first to send to an address controlled by it. You need to sign the transaction when you are trying to SPEND those coins. Receiving coins on an address does not require the private key at all except to produce the address in the first place.

Can you post what $rawtxhex is? How did you create it?


text:
Why the blockchain isn't just a Merkle tree
I am reading this and now wondering why the blockchain isn't just implemented as a Merkle tree, or the reverse, why you can't just have a single data structure (i.e. a transaction chain) instead of the block chain with nested Merkle tree of transactions.

It seems to me the block is just there to make the merkle tree work, since it requires bottom-up calculation and doesn't support appending to the tree very well, so instead you want to create a small compact tree and group it into blocks. Please correct if wrong.

Don't understand why you need to "prove that a specific transaction is included in a block".

A bitcoin full node independently validates the history of the network. To do so, it must validate each block in sequence (which includes all transactions in each block).
A merkle tree provides a cryptographic commitment to some data, but does not hold that data itself (it just holds hashes of the data). So a merkle tree alone is insufficient to validate the history of the network. Nodes need block and transaction data to do so, not just the merkle tree commitment.

I don't see it yet. I could imagine just putting the data as another field in the merkle tree nodes (leaf nodes). Or why not just have blocks and no merkle tree. Basically, why not just have one data structure instead of these two or three.

The merkle tree is not included in a block, only the merkle root is. The merkle root serves as a cryptographic commitment to the transactions being included in the block (it is part of the block header, and the block header is what is hashed to find a valid PoW). Including it allows lightwallets a mechanism to verify that certain transactions are included in the longest valid chain, in a much less resource intensive way than a full node’s full validation process.

Merkle tree IS in the block. The Merkle root is in the header only (which is what you meant by the looks of it).

@Jannes I meant that all intermediate nodes in the merkle tree are not stored explicitly, as a node can use the block to compute the entire tree itself. Storing the entire tree explicitly would be redundant, a waste of blockspace.


text:
Bitcoin Shop - question
I am thinking about how are these all 'bitcoin shops' working.
Imagine i go to a web page called http://bitcoinshop.smth where all i see is:
Price of the Bitcoin
And all i can do is "Buy".
Of course the price of the BTC that they display is the lowest Ask price at the exchanges +X$ Fee they want to earn - makes sense.
Now the question is,
what is happening behind the scenes?
I can imagine two situations:
a) They have BTCs in their wallet, so when i hit BUY - i get their BTCs out of their wallet at the price of the Exchange + their fee.
But what if they bought them for 200$ and the price dropped to 100$ on the Exchanges? How do they manage that?
b) They are having market links to several exchanges and when i hit BUY they immediately place a BUY order on the exchange with the given price. Of course this is simplified as they should be looking into the order book and check the quantities and so on.. but nevertheless.
Still i see some issues: 1) They can't guarantee the order to be filled with the quantity i asked for, 2) They can't guarantee that at the time i hit BUY the price will be exactly as i wanted to buy. Well yes if the price goes down they get the money, but if the price goes up - well my BUY shouldn't be executed as i would have to pay more than i declared.
This reminds me the old-days @ electronic exchanges - there was a regulation for this that the price has to be guaranteed for the buyer, but that's a different story.
Does anybody know how is that managed?
And additional question, what if i come with a request to buy 10000 BTCs,
i wonder how is that managed..
Example Shop:
https://www.4coins.pl/en/

Their wording is a little funny but it sounds like they act as a middle man and cannot guarantee a price until they have facilitated a deal. I assume the conversion rate shown on the main page is only an estimate. In that case they don't have to worry about price volatility as they are putting that burden on you the buyer.

§4 Terms and Conditions of Service
The Service uses the services of online payment provider Dotpay S.A.,
  whose office is located at ul. Wielicka 72, 30-552 Cracow, Poland.
Using the 4Coins.pl via online payment provider user transfer funds to
  the 4coins.pl’s account in PLN currency. The amount received by the
  Service is reduced by 1.9 % of its value as a commission charged by
  the online payment provider.
Service under an order for the total service credited to the account
  searches offers on the market BTC – bitcoin and mediates on the
  principle of matching user with the available range of offers.
Due to the nature of the market BTC website does not guarantee the
  execution of transactions on the presented course. Given course is
  presented only in the form of information.
After the service, the user will be informed about the parameters of
  the transaction, and may order the withdraw of their units BTC –
  bitcoin.

Argh i didn't read it!
Now it seems like you place an order,
a) if they can fill it: you get the BTCs
b) if they can't fill it: you get a message SORRY


text:
p2sh addresses in elements
I'm building a script and have it's hex representation, then I convert it to a pubkey and address, which results in something like: 3NqNAUBEWarVjKerLcCnPrTGbaQ4QFcAfr or 2N7aFmKeUXbTSowccnkzJ44BZj8HFqLUUdm (when I set testnet parameters)
in elements when I try to build a transaction with createrawtransaction to put some coin to that address I get:
Invalid prefix for Base58-encoded address
I've tried to build a descriptor with sh() and import it but that won't work because custom scripts are not supported.
Is it possible to use P2SH in elements? How do you generate the address from the script hex (it looks like it's different from bitcoin)?
PS: the script is built with python bitcoinlib like this
redeemScript = CScript([winner_key, OP_CHECKSIG, OP_IFDUP, OP_NOTIF, cashback_key, OP_CHECKSIGVERIFY, blocks_b, OP_CHECKSEQUENCEVERIFY, OP_ENDIF ])

where keys are hex representation of bytes, blocks_b is an int represented in bytes.hex(), I'm not really sure this is working, but I think there is something I'm missing on how to generate the address first.

the parameters to create the address are different from the bitcoin ones and elements may also have blinders, TL DR, use rust-elements for instance.


text:
Generating zero-amount transactions in regtest mode?
I'm setting up a larger test network of regtest nodes in which all of them should be easily capable of creating blocks and sending transactions.
To this end, I'm looking for a simple way for the nodes to be able to submit new transactions into the system, without requiring them to either previously mine blocks, or to introduce a convoluted setup process, e.g, where every node first loads a pre-filled chain state and wallet.
So far I had the hope that it would be possible to create new wallets and addresses and then simply send zero-amount and zero-fee transactions. So far, my efforts are met with a "Transaction amount too small" error.
One 'solution' I found is to write a script that creates new wallets, mines (at least) 101 new blocks to a new address, unloads the wallet and repeats. However, I then would need to distribute the wallets and the blockchain data to all nodes. This seems like a really tedious and error prone setup step to enable a reliable a regtest environment.
Is this possible, can bitcoind in regtest mode be reconfigured to accept transactions of value 0? Or is there any other easy way to initiate new addresses or generate new mock transactions, similar to the generatetoaddress call for blocks?


text:
Is it possible to forward bitcoins without the private keys?
According to this question, there isn't an easy way to automatically send bitcoins from one address to another and I think that it might be useful.
So I thought about creating a website were people could upload their wallets and choose a destination address where the coins would be sent to. A bitcoin daemon would be constantly checking the balance and forwarding any received transactions. But then I was confronted with the problem of securing a collection of online wallets.
When a transaction occurs, what part of the message is signed by the owner? Since the destination address is always the same, is it possible to send the bitcoins without storing the private keys on the server?
Probably the whole transaction is signed (which means that I need the key because the input is unpredictable), but I don't know much about this so I might be missing something here.

For the same purpose, it might be easier to create Javascript application that executes locally, in web browser, and merges two wallets.

@Serith Yes, probably. In a few months it might be possible to add private keys/merge wallets in the main client so this kind of service would not be needed.

Short answer: no.
Longer answer: to 'forward' coins one needs to spend them out of the first receiving address, and to the next one. in order to spend them, one needs to sign a transaction using the private key associated with the first receiving address.

It is currently not implemented by any client that I know of, but it is possible to create a signature for a transaction that doesn't include the outputs. The trick is using the SIGHASH_NONE signature type. This would allow you to fill in the output later on, and still send it.
Another possible solution that has been suggested (but again not implemented) is having auto-clean addresses - addresses that are marked specially so that if ever a payment arrives to them, it is immediately moved to another address.

So I thought about creating a website were people could upload their
  wallets and choose a destination address where the coins would be sent
  to.

That's not possible if you don't want the website to have all the private keys.  What would be possible would be to have the website monitor a set of addresses and email you whenever funds are deposited to any of them.
There's a free online wallet service called My Wallet which does exactly this, offering "Payment Notifications via Skype, Email, Google Talk and HTTP Post".

There is no concept of "forward".  Bitcoin only has transactions.
Transactions are used to irreversably transfer coins from one address to another.  The bitcoin network also has no concept of ownership beyond the holder of the private key.
If you could transfer coins without the private key there would be no security to Bitcoin network.  People could simply take other users coins at will.
If you think about it for bitcoin to work each transaction MUST ALWAYS be signed by the private key for that address.


text:
Is it safe to authorize Coinbase to withdraw cash directly from my bank account?
I wanted to buy Bitcoin. Coinbase said that they could transfer money directly from my U.S. bank account and convert it to Bitcoin, and then I'd have a Bitcoin address and could give people Bitcoin or pay with it for things. I went ahead and signed up and requested a transfer of $100.
Here's why I am worried: Coinbase asked me to provide my credentials to my online banking while I was on the Coinbase website, both my username and my password. I thought that should have happened on my bank's website with SSL connection, not through Coinbase. I went ahead and did it but now I'm worried. Coinbase said that the transaction wouldn't go through until January 6, 2016 because of ACH and the holidays, which is fine. I'm just worried because I have several paychecks worth of money in that bank account.
(I did not access Coinbase from Android or any other mobile device. I used my desktop PC with Google Chrome web browser.)

They don't  need your password to process the ACH in the future. this sounds like they used your banking credentials to verify that it really is your account. You should be able to change your password on your banking account now and be safer.

Thank you, as you were correct! I had no problems with my initial transaction, nor any problems later. I did not need to enter my banking credentials ever again on Coinbase.


text:
Making an altcoin (for fun, not to use), and after finding MerkleRoot and genesis block, I still get errors
I'm making a PoW/PoS hybrid coin for fun (nobody will actually use it).  I already found the Merkle root and mined the genesis block and got the nonce and things like that.  I inserted them into the correct places (or so I thought) in main.cpp and main.h.  I also deleted the checkpoints from the coin I cloned from.  I now get this error:

bool LoadBlockIndex(bool): Assertion `block.GetHash() == hashGenesisBlock' failed.

What should I do?  It does not make sense to me, as this error normally means that there is trouble related to mining the genesis block.  If anybody wants to see the source code, it's at GitHub:  https://github.com/hale6666/kaluricoin
Thanks!

I don't think you'll get anyone here helping. Best to try BCT


text:
With peerblockfilters=1 hundreds of "btcwire 0.5.0/neutrino" connections are downloading TB from my Bitcoin node
I run Bitcoin Core 0.21.0 from a data center, unmetered, with compact block filters enabled (blockfilterindex=1 peerblockfilters=1).
Soon after the restart, I get a huge number (140-200) of connections identifying as btcwire 0.5.0/neutrino, from all over the world. They are responsible for vast majority of download bandwidth (90%+).
This only happens when node is signalling CBF support via peerblockfilters=1.
I am aware "Neutrino" is a proof-of-concept light wallet using CBF but it doesn't explain neither the vast dominance in terms of connections number (~75%), nor in terms of bandwidth (90%+).
Incidentally, "Neutrino" is also a surveillance company owned by Coinbase :)
Any guidance is welcome!

It appears that btcwire is the Bitcoin p2p module of btcd and neutrino is Lightning Labs's implementation of BIP157/158 (compact client-side block filters (CBF)). I suspect that the agent identifier btcwire 0.5.0/neutrino indicates LND (Lightning Network Daemon) instances which are configured to allow or prefer CBF for synchronization. Given your experience and since CBF support was only added to Bitcoin Core in 0.21.0, it looks like the demand for the CBF network service far outstrips the few listening nodes that provide the CBF network service at this time.
I expect that the load will be distributed better as more Bitcoin Core 0.21.0 listening nodes come online.


text:
Vanitygen: Impossible addresses?
I'm currently attempting to modify Vanitygen to suit a particular purpose. However, I'm running into an issue with "impossible" addresses. For example, from the stock Vanitygen available on Github I get this output:
./vanitygen -T mR
Prefix 'mR' not possible
Hint: valid testnet addresses begin with "m" or "n"

While the following works:
./vanitygen -T m
Difficulty: 1
Pattern: m
Address: mh8e8yUtsmhCm6PTkuHV85ozEV5iNibmbp
Privkey: ***************(doesn't matter)

I get similar results for this set of options:
./vanitygen -F script 3Ro
Prefix '3Ro' not possible
Hint: valid bitcoin script addresses begin with a "3"

and
./vanitygen -F script 3R
Difficulty: 836
Pattern: 3R
P2SHAddress: 3R1jUHTrESWgCC812LrgwHErc9Y3UL7XeL
Address: *********(doesn't matter)
Privkey: *********(doesn't matter)

So, I'm trying to determine why Vanitygen is saying that these particular prefixes are not possible. For both of these failures, the failure occurs within get_prefix_ranges(). However, this isn't a programming question, necessarily. What I'm trying to uncover is some underlying principle that I may be missing that would render these particular prefixes impossible.
Perhaps a couple of questions may help me answer this myself:
When Base58Check encoding the version+publickey+checksum, how exactly is the encoding processed? Is the input broken into 6-byte words and then converted into Base58 format (seems implausible because you could theoretically have something like 111111 (binary) in the checksum that would be > 58). Or, is the whole version+pubkey+checksum converted to a BigNumber and then essentially Mod 58'd for each character.
If the latter is the case (which seems probable), in what order does this occur? Using the example of 80FAFBFC (2163932156 decimal):
x = 2163932156
result[0] = x % 58 = 6
x = floor(x / 58) = 37309175
result[1] = x % 58 = 37
x = floor(x / 58) = 643261
result[2] = x % 58 = 41
x = floor(x / 58) = 11090
result[3] = x % 58 = 12
x = floor(x / 58) = 191
result[4] = x % 58 = 17
x = floor(x / 58) = 3
result[5] = 3

result = [6, 37, 41, 12, 17, 3]
Convert to Base58 values:
result = [7,  e,  i,  D,  J, 4]

Would the result be displayed as: 7eiDJ4 or 4JDie7?

This is due to the "version" byte and the way bitcoin addresses are made with base58.
The procedure is pretty straightforward:

the version byte
the RIPEMD160 of the SHA256 (known as HASH160) of the sec format of the public key (don't worry too much about this part, just know it's 20 bytes long)
the checksum (4 bytes long)

Concatenate these and you have a 1 + 20 + 4 = 25 byte string which then gets encoded into a base58 string to form the bitcoin address. Note that parts 2 or 3 can be pretty much anything, but the version byte is specific to the network.
For your case, the version byte of testnet is 0x6f.
The documented procedure for calculating base58 is here.
Here is a simple python program to demonstrate how this is done:
alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
def b58(x):
    a = ""
    while x > 0:
        x, r = divmod(x,58)
        a += alphabet[r]
    return a[::-1]
print b58(0x6f0000000000000000000000000000000000000000)
print b58(0x6fffffffffffffffffffffffffffffffffffffffff)

The result of this program is this:
mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc

That is actually the range of possible addresses within testnet. This is because anything before mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H would result in the first byte being 0x6e and anything after n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc would result in the first byte being 0x70. Running vanitygen should confirm:
$ vanitygen -T mfWxJ3
Prefix 'mfWxJ3' not possible
$ vanitygen -T mfWxJ4
[...]

It's important to keep the version number in mind when generating vanity addresses for this reason.

So, the resulting Base56Check string is in numerical order (reverse of the order it is determined). When creating an offline address, is the payload for RIPEMD160(SHA256()) the hex (unaltered) public key?

It's the sec format of the public key, which is either compressed or uncompressed which goes into the HASH160. R is actually before f in the Base58 alphabet. The order of the alphabet is 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz.

Yep, R before f, I realized the stupidity of that comment when I made it -- edited it out ;). I still don't understand what you mean by "sec" format? Can't be "secret", then it wouldn't be a public key...

this should give you a better idea. Basically, it's encoding the public point (x,y) into a single byte array.

Ah, thank you very much! While that particular page didn't answer my question, it helped me find this: https://tools.ietf.org/html/rfc5915

That particular code doesn't produce the result specified. This is because the inputs don't include the 4 byte checksum. Add a further 8 zeroes or 8 f's to the input to receive the stated results.


text:
OP_EQUALVERIFY Problem
I'm making a full-service wallet, I already made the UTXOs selection algorithm and now I want to push the transaction hex bytes. It works when I push only a transaction with only 1 input, but if I try to push the hex from a tx I made with 2 inputs from the same account, I get this:
OP_EQUALVERIFY: non-equal data

Here is my decoded hex:
{
   "lock_time":0,
   "size":339,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"3a896625fce1f18ce4c3139863359631d5677cff4e4fd8dac25ca6327c0dadd8"
         },
         "script":"473044022070f3b03cca6a75038ffe150be347a97d0e07adc857cc93e245739db55e3a6d36022051eb72b21e35a5e7309e1864f00e1b107a5b5262d80b1128e9fb45fbe7971c7b012102bb05325000709d3a3d8063f9913777859b8fa30b83e4c4f981bb2d9781b7c91a"
      },
      {
         "prev_out":{
            "index":1,
            "hash":"436094120d4412c32b97738f9051a32a237c037abe31cafbdc8a02d16f2a659c"
         },
         "script":"483045022100da7abc59e24d2afea9219ee24d1f3df4e1b9a2efa154d9704ed903210abfdb40022015a8237d38e18f558172872af1aa5c244b38c3ad8f594463c0dcad18dbfcf5f5012102bb05325000709d3a3d8063f9913777859b8fa30b83e4c4f981bb2d9781b7c91a"
      }
   ],
   "version":1,
   "vin_sz":2,
   "hash":"c5991f9f044f9d829fc01eeda76f36a514271270f9f891ea7b584f504ed404ea",
   "vout_sz":1,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 7ff85ee854794422531b7b5c3d380c5f50011a4e OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1CfeMTtDP9HNjc8vsuuHGgUfABexvW5Qkf",
         "value":350000,
         "script":"76a9147ff85ee854794422531b7b5c3d380c5f50011a4e88ac"
      }
   ]
}

Links for the transactions being used:

https://blockchain.info/tx/3a896625fce1f18ce4c3139863359631d5677cff4e4fd8dac25ca6327c0dadd8
https://blockchain.info/tx/436094120d4412c32b97738f9051a32a237c037abe31cafbdc8a02d16f2a659c

My address is 1FebYgpxQ1exSNdJENkbmNPmSfsiP3kZiT.
And my code using the BitcoinJS library is the following:
key = bitcoin.ECPair.fromWIF(privatekey);
var tx = new bitcoin.TransactionBuilder()
var sum_outputs = 0;

var input_utxos = defineInputs(utxos, amount);

for(var a = 0; a < input_utxos.length ; a++){
    tx.addInput(input_utxos[a].tx,a)
    sum_outputs+=parseInt(input_utxos[a].amount);
}

tx.addOutput(to, parseInt(amount));
var change_amount = sum_outputs - parseInt(amount);
if(change_amount > 0) {
    tx.addOutput(from, change_amount);
}

for(var a = 0; a < input_utxos.length; a++) {
    tx.sign(a, key);
}

result = tx.build().toHex();

console.log(result);

So my questions are:

Why is this working with 1 input from my address and not for 2 inputs?
How can I correctly sign the second input that I assume is the cause for the error?

At the current moment, I looked at both of the source transactions and the indexes have been spent already. Did you successfully solve your problem?

@NayukiMinase yes. thanks. i will post my own answer

So... I found out what was wrong. The problem was in this part of the code when i was adding the inputs. I was adding an index to each input based on which number of input it was.
for(var a = 0; a < input_utxos.length ; a++){
    tx.addInput(input_utxos[a].tx,a)
    sum_outputs+=parseInt(input_utxos[a].amount);
}

but the index i was supossed to send was actually the index on the transaction outputs. so it had to be like this
for(var a = 0; a < input_utxos.length ; a++){
    tx.addInput(input_utxos[a].tx,input_utxos[a].n)
    sum_outputs+=parseInt(input_utxos[a].amount);
}

The index was gettable from the api that provided me all the utxos for an account. In this case, it was called n and was inside the transaction object itself.


text:
How does Transaction Remote Release work?
How exactly does TRR (Transaction Remote Release) work?
What are the similarities (and differences) with the way TOR works?

TRR is like Tor in that it chooses random routes, and uses public key cryptography to secure communications. The major difference is that where Tor creates long-lasting bidirectional channels, TRR would use low-latency single-use one-direction transaction forwarding. At time of writing, there doesn't seem to be a public TRR implementation, so I'm basing this off of this paper.
There is one missing part, though.
Tor uses something called "perfect forward secrecy." In Tor, the private key of a node is useful for pretending to be that node, but it can't be used to decrypt communications after the connection has closed.
To see why this is useful, imagine the following scenario: Your ISP captures a TRR encrypted communication. They see that the first encrypted portion was sent to A. They find A, and get their private key. They decrypt the first layer of the message, and see that the second node is B. Repeat until they see what transaction was hidden within.
This works even though A, B, and C never kept any logs of where they sent the transaction. The way to fix this is either:

use the node's private key to establish an intermediate key, and throw the intermediate key away after the connection closes, or
rotate the node's key very frequently, at least every hour.


text:
Basic transaction validation rules, Node accept to pool policy
I am trying to collect all infromation about adding and verification transaction to Blockchain.
Exist 2 types : add transaction to RawMemPool and add Transations included in block.
Could any experts in this question verify that collected information is actual and correct?  Thank you

I'd refrain from using the term "sidechain" because that has a special meaning which is not equivalent to competing chain tip, or "forkchain". You have an empty line in the inputs list, and extraneous space after "( " in the second to last line. Coinbase input coin is smaller or equal to reward and fees; you don't have to claim all of it for the coinbase to be valid. However, I don't think that your question works well on our platform, we work well for answering specific questions. Other mediums are better suited for open-ended requests for feedback or collaborative development.

Nice work though. :)

fixed Coinbase fees constraint. Thank you. What is the correct term for mainchain branch you can offer?

I'd call it the "best chain", but I've seen other names for it such as "main chain", "canonical chain", "primary chain", and "longest chain". The other chain branch I'd call "shorter fork", or "stale fork" once it has been obsoleted. As long as both tips are at the same height, they are just two "forks", because it is unclear which one will succeed, but you can name them for recognition of course.

You would probably get more out of it, if you posted it to reddit or bitcointalk and asked for feedback. Those platforms are more suited for such a topic.

https://bitcointalk.org/index.php?topic=1182712 posted on Bitcointalk Welcome anyone who can help complete this rules, will post on bitcoin wiki once  all information will be verified


text:
Transactions that have outputs value more then inputs value possible?
Transactions have 2 ways to get into blockchain in bitcoind:

mempool -> newblock
newblock no in mempool

lets check AcceptToMemoryPool function
https://github.com/bitcoin/bitcoin/blob/c719cefc417cc578f48b33069b764339a61054ce/src/main.cpp#L876
CAmount nFees = nValueIn-nValueOut;

in case outs > ins
nFees<0
if (mempoolRejectFee > 0 && nFees < mempoolRejectFee) {
        return state.DoS(0, false, REJECT_INSUFFICIENTFEE, "mempool min fee not met", false, strprintf("%d < %d", nFees, mempoolRejectFee));

negative nFees will be rejected all is good in this point
ok
lets check Connectblock  function
https://github.com/bitcoin/bitcoin/blob/c719cefc417cc578f48b33069b764339a61054ce/src/main.cpp#L1805
for each tx in block we do:
nFees += view.GetValueIn(tx)-tx.GetValueOut();

https://github.com/bitcoin/bitcoin/blob/c719cefc417cc578f48b33069b764339a61054ce/src/main.cpp#L1826
 CAmount blockReward = nFees + GetBlockSubsidy(pindex->nHeight, chainparams.GetConsensus());
if (block.vtx[0].GetValueOut() > blockReward)
    return state.DoS(100,
                     error("ConnectBlock(): coinbase pays too much (actual=%d vs limit=%d)",
                           block.vtx[0].GetValueOut(), blockReward),
                           REJECT_INVALID, "bad-cb-amount");

At this point we calculate max possible reward for this block: all tx fees + mining reward
then we check that coinbase reward not more then this value
what if same miner create and include transaction that have inputs for 1 btc and have outputs for 2 btc, so fee for this tx will be -1 btc
then miner can set reward for coinbase transaction to  25 btc  + all fees - 1 btc.
so this (block.vtx[0].GetValueOut() > blockReward)  return True
as result we have Transaction, that  create more coins then received, inside blockchain
Where is my error?

That isn't allowed, even within a block. Here is the code that checks for that:
main.cpp: ConnectBlock
    if (!CheckInputs(tx, state, view, fScriptChecks, flags, false, nScriptCheckThreads ? &vChecks : NULL))
        return error("ConnectBlock(): CheckInputs on %s failed with %s",
            tx.GetHash().ToString(), FormatStateMessage(state));

main.cpp: CheckInputs
if (!Consensus::CheckTxInputs(tx, state, inputs, GetSpendHeight(inputs)))
    return false;

main.cpp: CheckTxInputs
for (unsigned int i = 0; i < tx.vin.size(); i++)
{
    const COutPoint &prevout = tx.vin[i].prevout;
    const CCoins *coins = inputs.AccessCoins(prevout.hash);
    // [11 lines snipped]
    nValueIn += coins->vout[prevout.n].nValue;
    // [3 lines snipped]
}

if (nValueIn < tx.GetValueOut())
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(tx.GetValueOut())));

main.cpp : line 1346  and line 1352   why checking 2 times?

@bitaps Dunno. Why not, though?


text:
Does block size effect Miner's Hashing speed?
From my last question:
Bitcoin Block Size - What are the rules?
I learned that the block size can vary from a few kB up to a MB. This leads to my next question:
Does the block size effect a miner's hashing speed? (i.e does a very large block decrease hashing speed?)
If so, what are the details of that relationship?

Only block header gets hashed, and it has fixed size, so the total block size doesn't matter.
From Wiki:Block hashing algorithm

The body of the block contains the transactions. These are hashed only
  indirectly through the Merkle root. Because transactions aren't hashed
  directly, hashing a block with 1 transaction takes exactly the same
  amount of effort as hashing a block with 10,000 transactions.

That is not correct.  The transactions of the block have to be hashed to create the merkle tree.  More transactions means a larger merkle tree consisting of more hashes.

@theUnhandledException That's a small one-time cost on adding transactions, though. Bitcoin will start requiring fees before the cost of these hashes becomes substantial.

While the block header is always the same size, one component of the block header is the Merkle Root which changes with each included transaction.  The Merkle Root is a hash based on a Merkle Tree of all the transactions of the block.  Creating the Merkle Tree requires 2(n-1)+1 hashes.  The Merkle tree will need to be updated periodically to include new transactions as they occur.
To save computing power in pool mining the pool server computes the Merkle Root and then provides it to all miners in the pool.  In solo mining each miner will need to compute and update the Merkle Root.  Current transaction volume is relatively low so the amount of computing power required to update the Merkle tree isn't significant.  However if Bitcoin ever reached VISA level transaction volume (~4000 transactions per second) computing the Merkle tree would require significant computing power, possibly even dedicated CPU/GPU acceleration just for Merkle tree calculation.
Information on scalability issues for high transaction volume:
Capabilities of Bitcoins and their place in the future

To save computing power in pool mining the pool server computes the Merkle Root and then provides it to all miners in the pool. But each miner participating in the pool works on a unique share. Thus, a 4 TH/s miner exhausts the entire nonce range in about 1/1000th of a second, requiring 1000 shares (each with a unique extranonce) per second, correct? That's quite a lot of times the pool server would need to change the extranonce and update the Merkle root, just for shares intended for one pool participant. Multiply that by 1000 participants, and you need a lot of computing power, no?

The answer was written in 2011 (although it would still work today if the nonce range was 64 bit).  Today (2015) no pool uses this method.  Instead the provide each miner with a partial merkle tree, the static elements of the coinbase txn, and the rest of the header.  The miner adds the extra nonce to the coinbase txn, computes the merkle root hash, sets dynamic values in header (like timestamp) and passes that to the ASIC hardware as a binary blob.  Most ASICs reduce the precomputaiton workload somewhat by cheating a bit on timestamps (get another 4 bill tries by incrementing timestamp).


text:
OP_CHECKSIG signature hash type 0
On the Bitcoin Wiki's OP_CHECKSIG documentation:

Firstly always this (the default) procedure is applied:

the public key and the signature are popped from the stack, in that order. If the hash-type value is 0, then it is replaced by the last_byte of the signature. Then the last byte of the signature is always deleted.

The signature format is:

0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]

In case if hash type is 0 then we should  get last byte from [S]
and remove it I think it will corrupt signature!
Maybe I don't correctly understand this documentation. Could anybody explain the correct behavior in this case?

Methinks it should say copy, not replace.

I this error in specification?

@user15358 I don't see this text in https://en.bitcoin.it/wiki/OP_CHECKSIG anymore.

Fair warning, the bitcoin wiki is often the summation of years of unverified brain dumps. A non negligible portion is out of date or was never correct to begin with.

I'm curious to know how this works, as there's a test vector with a SIGHASH of 00 that I can't verify using pybitcointools. It seems changing the 0 to a 1 won't work; there's no real reason why is there?

@WizardOfOzzie, changing the SIGHASH type will invalidate the signature, as it changes the hash that is signed.

@StephenM347 OK, so that's because the signed Tx form has the hash type appended; but if the SIGHASH type is 0, why does it act as 1?

@WizardOfOzzie, not sure exactly what Bitcoin Core's behavior is with non-standard sighash types.

I've done some testing with pybitcointools and one of the BitcoinCore test vectors with a SIGHASH of zero. See Pastebin here. I have no idea how this works, since we're hashing the final transaction (ie including the signature), which returns the TxID c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73. This makes no sense whatsoever, anyone know what's going on here?

@sipa Can you comment on the above comment of mine?

I've done some testing with pybitcointools and one of the BitcoinCore test vectors with a SIGHASH of zero.
For SIGHASH =0, the Tx which is signed
It's just a matter of appending 4 nullbytes, instead of 01000000, to the signing transaction.
The Core software checks for this non-standard hashtype now, however we can see there's no problem in validating these rare transactions since the code only checks for SIGHASH ACP, SINGLE & NONE. See Python-Bitcoinlib's code for a Python interpretation
See this test vector, where the hash being validated is 11743b220e9e24e89abd4ff124a2740531fe7d7f9b4e26de14710a532fd543e2.
FWIW, Pybitcointools needs to have the txhash function edited so that instead of if hashcode:, it reads if hashcode is not None:. The else clause in that function was confusing me, but it appears to be for hashing signed transactions (ie to return the TxID)


text:
Why is CheckBlock called twice when processing a new block?
Once the Bitcoin node receives a message with a new block, it calls the ProcessNewBlock function:
 else if (strCommand == "block" && !fImporting && !fReindex) // Ignore blocks received while importing
{
    CBlock block;
    vRecv >> block;

    CInv inv(MSG_BLOCK, block.GetHash());
    LogPrint("net", "received block %s peer=%d\n", inv.hash.ToString(), pfrom->id);

    pfrom->AddInventoryKnown(inv);

    CValidationState state;
    // Process all blocks from whitelisted peers, even if not requested,
    // unless we're still syncing with the network.
    // Such an unrequested block may still be processed, subject to the
    // conditions in AcceptBlock().
    bool forceProcessing = pfrom->fWhitelisted && !IsInitialBlockDownload();
    ProcessNewBlock(state, pfrom, &block, forceProcessing, NULL);
    int nDoS;
    if (state.IsInvalid(nDoS)) {
        assert (state.GetRejectCode() < REJECT_INTERNAL); // Blocks are never rejected with internal reject codes
        pfrom->PushMessage("reject", strCommand, state.GetRejectCode(),
                           state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), inv.hash);
        if (nDoS > 0) {
            LOCK(cs_main);
            Misbehaving(pfrom->GetId(), nDoS);
        }
    }

Inside this function, CheckBlock and AcceptBlock are called:
// Preliminary checks
bool checked = CheckBlock(*pblock, state);

{
    LOCK(cs_main);
    bool fRequested = MarkBlockAsReceived(pblock->GetHash());
    fRequested |= fForceProcessing;
    if (!checked) {
        return error("%s: CheckBlock FAILED", __func__);
    }

    // Store to disk
    CBlockIndex *pindex = NULL;
    bool ret = AcceptBlock(*pblock, state, &pindex, fRequested, dbp);
    if (pindex && pfrom) {
        mapBlockSource[pindex->GetBlockHash()] = pfrom->GetId();
    }
    CheckBlockIndex();
    if (!ret)
        return error("%s: AcceptBlock FAILED", __func__);
}

Inside the AcceptBlock function CheckBlock is called again:
if ((!CheckBlock(block, state)) || !ContextualCheckBlock(block, state, pindex->pprev)) {
    if (state.IsInvalid() && !state.CorruptionPossible()) {
        pindex->nStatus |= BLOCK_FAILED_VALID;
        setDirtyBlockIndex.insert(pindex);
    }
    return false;

Why is the CheckBlock function called two times when processing a new block?

I suspect this is an artifact of the way the code used to work. As to why it hasn't been taken out, it's probably just out of caution, or a "Don't fix it if it's not broken" mindset. Bitcoin Core coders are very cautious, and reasonably so since it's a piece of software that is the main interface to the network for many big players in the industry.
In addition, on master right now, CheckBlock contains a check at the beginning to avoid doing the same work twice. (Added in this commit.)
if (block.fChecked)
    return true;


text:
How does a blockchain store any data?
I read here that since Bitcoin is a networked ledger, it is a good way to back up data. I would like to know two things:

How does a blockchain store 'any' data? I would like to know more about a blockchain's anatomy that enables it to do so.
If anyone can store data in blockchains, what prevents blockchains from becoming astronomically larger? Even today, a Bitcoin client takes forever to synchronize.

I honestly can't tell if that site is a joke. Poe's law in action, I guess.

Most people think of Bitcoin as a currency, but this is only one use of its protocol & network.

No. It is just a currency. The Bitcoin protocol can be used for different services, but the Bitcoin network is certainly not for gene distribution, or any other form of data back-up. That is not the intention of Bitcoin. You can, however, abuse the protocol to store unnecessary unrelated information. And yes I say abuse, because we as normal Bitcoin users have to download larger blocks for reasons that are opaque to us and no not necessarily concern us (like your genetic code). They are interfering with the purpose of Bitcoin.
Getting to your questions now:
you cannot really store data in Bitcoin in a normal fashion, simply because that is not what Bitcoin is concerned with. You can, however, embed additional information in transactions, which are broadcasted and distributed to the network, in multiple ways, thus essentially storing your information in the blockchain. This assumes you know the storage format of course, since you need differentiate the ordinary transaction information from your additional data.
No nothing prevents the block chain from getting arbitrary large. In practice, however, this will not fill your hard drive so fast (especially if you take Moore's law into consideration), because you need to pay a fee for each transaction per kilobyte.

Actually, the size limit on blocks prevents the block chain from getting arbitrarily large at least in limiting the growth.

@Murch I was not talking about finite time necessarily. With enough time it gets arbitrary large.

@Murch what is the size limit on blocks? I would like to read more about it.

@MikeC For example here: https://en.bitcoin.it/wiki/Funding_network_security#The_Blocksize_Limit

The genome clocks in around [700 MB] (https://medium.com/precision-medicine/how-big-is-the-human-genome-e90caa3409b0)


text:
Arbitrage in Bitcoin exchanges
How efficient is the bitcoin market? I am confused after comparing buy prices in exchanges operating in different currencies.
For instance, I see that 1 BTC amounts to 347 USD at the moment at one exchange in the US. In an exchange 'Localbitcoins', the lowest buy price I can find is 437 AUD.
Now, at the current exchange rate, 347 USD ~= 393 AUD. It seems to me even with some exchange fees that might be imposed, one can earn arbitrage profit by simply going long in one market and shorting in another. I am sure this is not the case. Am I missing something?

possible duplicate of Why don't people buy at one exchange and sell at another?; also see Is anyone taking advantage of different prices across exchanges?, or any of the other questions under the [tag:arbitrage] tag.

To answer your question let me give you an example of what some people do in order to try and take advantage of market arbitrage with Bitcoin.
As you know, Bitstamp and BTC-E are two of the biggest exchanges that are trading Bitcoin. If you look at the BTC price on BTC-E you can see it is always lower than that of Bitstamp.
If you were to go to Russia (or know somebody in russia that trades bitcoins locally) they go by the BTC-E price there. So, if you find a guy in Russia that can sell you coins at BTC-E price, if you are located in the US you can sell your coins here at Bitstamp's price. Same goes for Huobi (which is in china).
In order for arbitrage to work you need to know people in different countries who can sell bitcoins locally for you at that market price.
So go out there and make those connections whether it be in the trollboxes, forums (bitcointalk) or other means.
Hope I helped.

After some research, it turns out that at certain exchanges, some premium is generally paid because of added privacy and quick delivery.
For instance, some exchanges do not require customers to present their IDs, and simply work as a conduit between potential sellers and buyers that live close to one another. People seeking extra privacy or want to avoid hassles are happy to pay above market price for bitcoins.


text:
Why scriptPubKey is a series of commands?
I am not fully understanding the design purpose of the scriptPubKey in the transaction output.
I think the tx's (say tx1 here) output could just be the receiver's public key's hash.
Then when the receiver want to send the money to another one, he only needs to create the transaction tx2 (with receiver's public key and the sig of the previous transaction).
Then the bitcoin net work could check:

Is the public hash(tx2.public_key) = t1.output.hash_public_key?
Verify(tx2.sign, tx2.public_key, tx1)

a+b can approve that this transaction is created by the receiver.
Therefore, I am not quite understanding why we need to save
OP_DUP OP_HASH160 next_receiver_public_key_hash OP_EQUALVERIFY OP_CHECKSIG
in the tx.output.

Therefore, I am not quite understand why we need to save

Because scripting system allows more possibilities. https://en.bitcoin.it/wiki/Script#Scripts

Why Bitcoin need to provide that kind of the flexible, but use some enum to restrict the possible transaction type.


text:
The begining of Bitcoin
I want to ask, how was the first Bitcoin made? And how can it be made? Every time I think of Bitcoin, these questions come to my mind.

Pretty much the same way as all other Bitcoins have been made. I think you should make more clear what exactly you're not understanding about it.

First bitcoin was created when the first block (and blockchain) was created.
Here is more important informations: https://en.bitcoin.it/wiki/Genesis_block


text:
Explain how CoinJoin enhances anonymity, in plain English?
I just learned about CoinJoin, but I don't really understand all the jargon being thrown around. Can someone explain how this works where a 10-year-old can understand?

Alice wants to transfer 1 BTC from address A to address B
Bob wants to transfer 1 BTC from address C to address D
CoinJoin gives them a way to combine their transfers into a single transaction that has two inputs (A and C) and two outputs (B and D). Someone observing the blockchain no longer knows which one of the outputs is Alice's and which one is Bob's.
Because of some cryptographic magic behind the scenes, the participants of the shared transaction (there can be more than two of them) do not have to trust each other. Compared to traditional Bitcoin mixers, there is no possibility of coins being stolen. Also, CoinJoin transactions are compact and incur no additional fees (besides the usual transaction fees)
This is an example of a CoinJoin transaction: https://blockchain.info/tx/e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b
Blockchain.info has already implemented CoinJoin support (branded as Shared Coin) into their web wallet.

@user16874 No, there is only 1 transaction generated, no intermediate. The trick is a complicated protocol (set of steps) that must be performed by participants to construct that transaction so that it is both private and secure for all.  If you mix your coins with strangers, it is possible that so-called "tainted" coins may be mixed with yours, however this is true whenever you buy bitcoin.

How to deal with coinjoin in BitcoinCore? @Rami

This is a quote from Andreas' book.
Chapter 5
Section: Transaction Chaining and Orphan Transactions

As we have seen, transactions form a chain, whereby one transaction
  spends the outputs of the previous transaction (known as the parent)
  and creates outputs for a subsequent transaction (known as the child).
  Sometimes an entire chain of transactions depending on each other—say
  a parent, child, and grandchild transaction—are created at the same
  time, to fulfill a complex transactional workflow that requires valid
  children to be signed before the parent is signed. For example, this
  is a technique used in CoinJoin transactions where
  multiple parties join transactions together to protect their privacy.

Here is a very extensive and relatively simple explanation of coinjoin.

Multiple users sign a transaction, instead of just one user. Now it's hard to tell which user initiated the transaction, hence increased privacy.


text:
How to change RPC port for bitcoind? (rpcport=xxx in bitcoin.conf doesn't work)
I'm running a testnet bitcoind node and I have been doing RPC calls on the default port 18332.
I have added this line to ~/.bitcoin/bitcoin.conf:
rpcport=19832
And restarted the bitcoind service. I even restarted the whole machine.
But for some reason it is still accepting RPC calls on port 18332, and trying the same on port 19832 gives "connection refused".
It is definitely using the settings in bitcoin.conf, for example if I change rpcuser or rpcpassword (and restart again) I have to use the new user+password in RPC calls, the old ones don't work anymore.
But somehow the port does change.
Am I doing something wrong? Is the setting called something else than rpcport=xxx ?
I know I can probably also define the port manually on the cmd line (using bitcoind -rpcport=xxx or something) when starting bitcoind, but I want to have everything configured in bitcoin.conf (where it belongs) and have it all started automatically.
P.S. I am connecting on localhost, i.e. on the machine itself. I am also running the ufw firewall, and it is configured to accept connections on both 19832 as well as 18832 (so it's definitely not the firewall that's blocking things here).
(edit) FYI here's the complete bitcoin.conf file:
testnet=1
server=1
daemon=1
txindex=1
rpcuser=XXXXXXXXXXXXXXXXXXXXXXX
rpcpassword=XXXXXXXXXXXXXXXXXXX
rpcallowip=127.0.0.1
rpcport=19832
onlynet=ipv4
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

And here is how I perform RPC commands:
curl http://XXXXXXXXX:XXXXXXXXX@localhost:18332 -H 'content-type:text/plain;' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getwalletinfo","params":[]}'

This works OK although note it connects to 18332. If I change localhost:18332 into localhost:19832 it doesn't work anymore (Connection refused).
In case my version is relevant, the result of getwalletinfo contains "walletversion": 169900.

How you're running the bitcoind itself? Could you also try to run just this conf file ? https://pastebin.com/mKWmKs00, also try with 127.0.0.1 instead of localhost in the curl command.

@Зелёный I start bitcoind with sudo systemctl start bitcoind or sudo systemctl restart bitcoind. Tried your bitcoin.conf file (and changed the username and password to something new, so I'm sure this .conf file is used) and restarted the service, but unfortunately same result: it allows connection on 18332 (using new user&pasw) but not on 19832. Also tried 127.0.0.1 instead of localhost with curl but again no difference. Strange huh?

I cant reproduce your problem, because on the same configuration is working for me. Maybe something wrong with your systemctl service, run command and show the result systemctl cat bitcoind.service.

@Зелёный Result of systemctl cat bitcoind.service: https://pastebin.com/raw/JQS0yuJH Thanks a lot for your attempts to help. Just to be sure, you are also testing with testnet? (not mainnet?)

Yes, I tested it with testnet and mainnet. To be honest IDK, why it's not working for you. Here is my service https://pastebin.com/raw/r4hrPkvt also my bitcoin config exactly like this https://pastebin.com/raw/mKWmKs00.

@Зелёный Hmm very weird. And your walletversion from getwalletinfo is also 169900 ?

Yes, it is. Try my service and bitcoin configuration.

@Зелёный Have done that, but unfortunately no difference. Very weird :( Well, thanks for all the help attempts. Much appreciated. I will just keep using the regular port for now, and maybe reinstall my entire machine at some later time.

Could you:
print the result of running "sudo lsof -i | grep bitcoind | grep LISTEN" (you'll need to be give the root password)
And can you also give us the result of running manually: "sudo systemctl start bitcoind; "
then "/path/to/bitcoind -conf=/home/[your
homedir]/.bitcoin/bitcoin.conf". Does it honour the correct port when run manually?

Oops - that should be "sudo systemctl stop bitcoind"

@AlistairMann Here's the result: https://pastebin.com/raw/MVcuVnWd When stopping the service (and checking with sudo systemctl status bitcoind to be 100% sure it stopped) and then starting manually, the lsof output is the same (well, other processIDs, but the three listen ports are the same.

I've deleted my last request because I've managed to replicate your problem on my own machine. Will report back shortly.

Found the solution: rpcport needs to be in the [test] section
Please update your original config file to read:

testnet=1
server=1
daemon=1
txindex=1
rpcuser=XXXXXXXXXXXXXXXXXXXXXXX
rpcpassword=XXXXXXXXXXXXXXXXXXX
rpcallowip=127.0.0.1
onlynet=ipv4
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
[test]
rpcport=19832

And restart the daemon. Also take a look at Can't specify rpcport for testnet for related changes to other options. We were being warned what to do in the log file. ~/.bitcoin/testnet3/debug.log includes the line Warning: Config setting for -rpcport only applied on test network when in [test] section.
We could have picked this up faster had (we read the log file! And if) the example bitcoin.conf made a mention of now requiring sections.
Would be great if you could make this the ticked solution instead!

It looks like a bug: I've also replicated the same behaviour on my machine using the current version, Bitcoin Core Daemon version v0.17.99.0-g2945492424934fa360f86b116184ee8e34f19d0a freshly downloaded from github. However I notice @Зелёный above was unable to replicate it, so perhaps the bug is in a library you and I share and he doesn't, rather than in  bitcoind. Certainly there are no outstanding issues there that seem relevant.
I'm going to pick through the source to see if I can spot what's happening.  Depending on what I find I might open an issue with them. Let me know here and I'll update you.
In the meantime I would suggest adding -rpcport=19832 to your command line - it was always honoured here!

Thanks! Got it to work with the -rpcport=19832 on the command line (I added it in /etc/systemd/system/bitcoind.service)


text:
Best way to mix bitcoins? mixer, coin join (shared send), dark wallet, stealth addresses?
When you want to anonymize a few hundred BTC, what would be the best (safest) way?
I can think of these alternatives:

Deposit to and withdraw from exchange (like Kraken, Bitstamp, etc)Pros: reasonably safe (especially when using a solid, trusted exchange).Cons: not really anonymous, major exchanges must subject to KYC laws and have strict identification rules.
Mixing service (like bitmixer.io)Pros: very anonymous.Cons: can't really estimate the risk, you have to trust some anonymous 3rd party who can decide to disappear with your coins. Also, it can be expensive (depends on circumstances and requirements, but I'd consider 3 BTC fee to mix 300 BTC kind of expensive).
Coin JoinPros: pretty much risk-free (don't have to trust anyone).Cons: is there a steady, easy, accessible way to setup large coin join transactions? The shared send feature of blockchain.info/wallet? Sharedcoin.com?
Dark Wallet / Stealth AddressesPros: as far as I understand, this offers high anonimity without the need no trust anyone, although I'm not 100% sure of how this works technically.Cons: To my knowledge it's still in development, unstable, not suitable for usage with large sums of money?

What your take on this? Any other options?

I would say connect to tor, create a blockchain.info account, send you bitcoin there, then send the bitcoin to https://shapeshift.io to another currency which you have a wallet setup, then back to a second blockchain account, then to wherever you want.
This is pretty much 100% untraceable, as it goes via anonymous wallet - anonymouswallet - converted to another blockchain, sent to anonymous wallet, then converted back to bitcoin through another anonymous wallet! You can't track that transaction on the blockchain.
Enjoy :)

How would one handle the emails needed for the three accounts (2 blockchain.info and one shapeshift)? If I understand https://blockchain.info/wallet/anonymity correctly, they will be able to link my email address to my account. Doesn't this defeat the whole idea?

@andreas-h, probably, don't use Blockchain.info. Use a local wallet like Electrum or Mycelium and create two accounts. Both wallets allow for connection over Tor and can create multiple accounts. If you need a new email for whatever reason, there are several services which will give free email. I have used Tutanota.com in the past.

You could try this site:
http://silentvault.com/tiki-index.php?page=SBC
It looks like a good option. They're geared toward privacy. Simple mixing of coins is free. They're also based in Panama, which will make it more difficult for anyone from elsewhere to access their records.

Could you be more elaborate why it "looks like a good option"? Do you have to trust a third party? Do they have sufficient volume?

The source of shared send in blockchain.info is open source. https://github.com/blockchain/Sharedcoin
The limit which blockchain.info offers for shared send is 50BTC. You can check the code and modify the max limit but to mix the coins you should have enough transactions.
check lines 62 and 63 in below code:
https://github.com/blockchain/Sharedcoin/blob/master/website/src/piuk/website/SharedCoin.java

How does this solution compare to the ones that OP presented? Why does your link solve the asker's question?

it was an answer to this : is there a steady, easy, accessible way to setup large coin join transactions? The shared send feature of blockchain.info/wallet? Sharedcoin.com?

I see. Perhaps you should make that more obvious in your answer, as I didn't pick up how answer and question fit together, when I was skimming over them. Also, preferably, answers should respond to the complete question, your answer reads more like a comment on his question than an answer.


text:
Would it be possible for an 8-bit microprocessor to create a bitcoin keypair?
Context for question: With the latest security breaches around modern CPU's (Spectre / Meltdown) I was wondering if we could generate ECDSA keypairs on cheap, small and/or simple air gapped (micro)processors.
I have found GitHub repository Bitduino attempting to make an Arduino (an 8-bit microprocessor) create a bitcoin address, but in fact it simply leverages a connected computer that creates the actual keypair with Python. The Arduino merely creates the (possibly true cryptographic) random bytes.
I also found GitHub repository micro-ecc implementing ECC for 8-bit microprocessors, which looks very promising.
Then I guess additionally all that is needed to generate a keypair, are some hashing algorithms; RIPEMD-160 and SHA-256.
And then simply use Base58 encoding, which can be found as C-code in the actual Bitcoin client implementation (so it could be used for a microprocessor).
So to sum it up, my question comes down to: would putting these parts together enable the generation of ecdsa / bitcoin keypairs on a microprocessor, or am I missing something?
If let's say it's not possible simply because of memory limitations, what amount of memory would make it possible? Or if the 16MHz of an Arduino (for example) would be too slow, would an ESP8266 do, or an STM32F4? Or a Raspberry Pi?
Personal context: I would very much like to create a full implementation of exactly this entire process. Starting with a press of a button (on an embedded device) which will result in a string containing base58 encoded private and public keys, while using strong true cryptographic random values. I'm just trying to prevent unnecessary work targeting a platform that cannot ever make something like this work.
I would be happy to write it in 'cutting-edge' Rust on a 64-core machine, but I also realise that would set the threshold so high, the 'average' user couldn't reproduce it. (Also it wouldn't solve my main issue with modern-day CPU vulnerabilities.) Whereas if the end result would be an Arduino library you can simply download using Arduino's board manager, flash the example and it spits out keypairs, that would suddenly make it accessible for a (very) large audience.
I know hardware wallets exists, I am much more interested in creating something like this myself for learning purposes. Also, if the resulting software can be used by other people on very inexpensive and easy to come by hardware, that would be a plus.

They're Turing-complete after all.  I guess the only question would be whether they have enough memory.

As someone who has implemented an ECDSA library, and worked a lot with 8-bit microcontrollers, I see no reason why you couldn't do ECDSA stuff on an 8-bit microcontroller.  I don't think you'll need very much RAM but you will need a lot of code space so I'd start with something like an ATmega2560.  However, I think a 32-bit microcontroller would be way more appropriate.  The Trezor uses an STM32.  Have you seen the ST Nucleo boards?  They are pretty decent and cheap.  And you know hardware wallets already exist, right?


text:
Is there a tool that searches for a specific BTC amount in a specific date range?
Suppose I want to search for a transaction of exactly 445 BTC in the date range 27 July 2013 and Aug 3rd 2013 ... is there an (online?) tool that has this kind of search capabilities?

People who downvote: Please add a comment explaning why you don't like the question (if it is not super obvious, which in this case I don't think that it is). It's hard to improve if you don't know what to improve.

@BitcoinFan we know it's traceable, as it's in the blockchain. It's just a matter of whether there's a tool readily available to find it or not, which is a different issue.

@JohnBensin I think it's not the one, wrong date. But in any case, the question is indeed about finding/building a tool to search for such transactions, not about a specific tx.

Heh, people were expecting an answer, and were surprised to find none. In any case, it's obviously easy to build a tool (search engine) that searches for transactions in this manner.

Blockchair allow you to query the bitcoin blockchain with lots of parameter such as date, BTC output amount, fee amount etc...
Here is your request:
https://blockchair.com/bitcoin/transactions?q=time(2013-07-27..2013-08-03),output_total(44500000000)#
Unfortunately it bring no result but you can change the parameters

Here is the request to search for the Bitcoin Pizza Day transaction https://blockchair.com/bitcoin/transactions?q=time(2010-05-22),output_total(1000000000000)


text:
How was bitcointalk attacked in Dec 2013?
There was a man-in-the-middle attack on bitcointalk on Dec 2013.

News: If you used your password to login between 06:00 Dec 1 UTC and
  20:00 UTC, then your password may have been captured in a
  man-in-the-middle attack, and you should change your password here and
  wherever else you used it. If you were only logged in via the
  "remember me" feature, then you're OK.

How was this executed? Didn't bitcointalk use SSL? Are there technical details on the attack vector?

The general description has been given before me.Here are technical details on the attack vector.
Assuming the following:

The attacker got a certificate that the client will accept, via poor cert validation or other means.
The attacker knows the IP address of the server, and is in a position on the network to do things like ARP spoofing.

Ettercap includes modules for ARP, DNS and DHCP "interventions", and supports direct SSL MITM

Do you have specific knowledge that the attackers got such a certificate, or are you speculating?

I'm just stating a possibility

Sure.
They just hacked their cloudflare account, and set different IP address for the domain bitcointalk. Therefore, every visitor was actually logging into malicious form.

This doesn't address the SSL question.

In cryptography and computer security Man in the Middle is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, an attacker within reception range of an unencrypted Wi-Fi wireless access point, can insert himself as a man-in-the-middle).
Bitcointalk uses SSL.How they got passed it, I don't know

Yeah, I know what Man in the Middle is. The question was about the specific details of this attack, especially SSL.


text:
In which ways is Earthcoin different from Bitcoin?
Also, the name Earthcoin suggests to me that it may be somehow more sustainable with regards to the computing resources required to support it; is there any basis in that?
The official site appears to be http://getearthcoin.com/ which has some pretty logos but is woefully lacking in technical detail. As it probably always the case with an altcoin, it also has a thread on bitcointalk.org which seems to describe a very odd block reward system with some days paying 2 or 5 times the normal block reward.

As mentioned in the BitcoinTalk thread.

Our goal isn't to compete, as much as compliment, create balance, and
  not divert into launching 9 more coins because we can.

It doesn't look there is much difference. It may have a different block time, reward, and cap, but that is standard stuff to change for an altcoin. There appears to be absolutely no technological advance. It donates a percentage of coins to charity but that means nothing if it has no value.

Technical differences

Supports transaction messaging (short messages in the blockchain that can go with a transaction)
Upcoming android app should be the first one to support transaction messaging.
Retargets difficulty after every block so it has resistance to block processing when difficulty spikes due to multipool hopping
Much faster transaction times.  Block target time is 1 minute.
fluctuating mining rewards so coin production varies with seasons (gradual and sinusoidal in nature).  Some say this is meant to emulate boom and bust cycles by mimicking periods of abundance and scarcity.
2x and 5x Bonus payout days to keep things interesting for miners over the long term.


text:
Where are the receiving and sending address descriptions stored?
Are the sending and receiving address descriptions stored in the wallet file, or as some other file managed by the Bitcoin client app?
If I move or copy my wallet to a new installation of the Bitcoin client, will I still have my descriptions for my sending/receiving addresses available?

Yes, all of those are stored in the wallet.dat file. I myself have successfully migrated the wallet file to a new computer and have the addresses and descriptions intact.


text:
Is it feasible to prove the density of found hashes and could that be valuable?
Background
When a miner claims a certain hash power and timestamps a block they solved, they are making a claim that a certain amount of time has passed since they received the previous block.  Intentional shenanigans ("time-warp-attack") may exist when the miner's timestamp is very different from the actual time at which they solved a block.  I was just imagining a method of inhibiting such shenanigans by verifying the density of found hashes.  Here's how that could be done:
How to Measure Hash Density
The number of SHA256 hashes between 2^255 + 2^n and 2^255 - 2^n for any n will increase at a relatively steady rate proportional to the miner's hash rate.  Counting them provides a rough estimate of a miner's hash rate.  A suitable n would have to be chosen for various levels of hash power.
Limiting Data Transfer Requirements
For a miner to prove that they generated a certain number of hashes within a given time frame, they'd have to provide the entire block for each of the generated hashes.  However, only a bit more data than the entire first of those blocks is really needed because they could include the nonce and the transaction set delta between the previous block and the current one each time they found one.  This could verify that they actually generated at least as many hashes as their timestamp suggests, with an error margin of the time it took for them to get the previously solved block and the error on the previous block's timestamp.
Possible Benefits
This might be useful for limiting the shenanigans that messing with timestamps or misreporting hash rate allows.  If it can be tightened up enough, it might squeeze out a lot pf potential "time warp" type shenanigans.


text:
Ways to buy bitcoin (I'm in the US)

Possible Duplicate:
How do you obtain bitcoins?

I just want a straightforward answer, I read a few answers but the explanations are convoluted. Where can I buy bitcoins online? Is there a site or sites? Do/can we buy them with a bank card or credit card or directly with my bank account? If not, how the hell am I supposed to get them lol

There are many sites indeed and some over the counter transaction, but for the sake of being short.
Try: Mt. Gox
You can draw money from your bank account and put it in escrow for BTC and vice-versa... It's known as the biggest bitcoin exchange over the world.