The code you're looking for is in CreateNewBlock.
The usual way transactions are added to a block is by sorting by priority. The priority of an input is the value being spent in the input multiplied by the number of confirmations it has. The priority of a transaction is the sum of all the priorities of the inputs. See this line:
dPriority += (double)...
input_value_in_base_units is the number of satoshis that the input is worth. One Bitcoin is worth 100,000,000 satoshis.
input_age is how many blocks the input has been present for. An unconfirmed transaction has an age of 0, and one that has 100 confirmations has an age of 100.
The whole mempool won't fit in a block; getblocktemplate returns enough transactions for a block. Blocks are, by default, limited to 750kb by policy, but many miners increase the size to the block limit of 1mb (which can be done by command-line flag).
The specific piece of code that decides on the transactions that should be included in a block can be found ...
I've found what was wrong. It seems that technical info is not up to date to the current Bitcoin Core version (0.11.2.0). Since version 0.11 (12 July 2015) the minimum relay fee is 5 times bigger (from 1000 Satoshi to 5000) so the transaction has not enough fees to be relayed.
Here you could find a discussion about the topic.
Bitcoin Core doesn't use an oldest-first selection but a more complex solver, it will probably end up spending outputs you don't want to in this particular case. You can do manual selection of the outputs you want to spend using the Coin Control section of the advanced GUI, which will let you ignore the dust if you don't want to spend it.
Since transaction priority has never really been a consensus based "protocol", it was never really that valuable to have it in the core code. Miners can and DO change the priority how they see fit. I see it as less code to maintain in the end and since Bitcoin is meant to be a free market network, the fees paid will prevail
First of all, this is a slight oversimplification: after taking transactions with fees, the standard policy is that priorities of remaining transactions are weighted by age and amount transacted. For each input to the transaction, the age of the input being spent (counted by number of confirmations) is multiplied by the bitcoin amount of the input, and the ...
The relevant source is this:
if (AllowFree(dPriority)) // at least medium
if (AllowFree(dPriority / 1000000)) return tr("highest");
else if (AllowFree(dPriority / 100000)) return tr("higher");
else if (AllowFree(dPriority / 10000)) return tr("high");
else if (AllowFree(dPriority / 1000)) return tr("medium-high");
Firstly, the priority mechanism was not a consensus rule. Originally it was just a few hundred kilobytes of space reserved in a block (100 kb IIRC) for transactions that had a high priority. But this was not a consensus rule; it does not have to exist. After blocks started getting full, many miners, out of the interest of getting as much income as possible, ...
As long as all selected transactions are valid, you may select any transactions you want.
You should check that there are no double spends among the selected transactions and that you keep any transactions which build on each other in the correct order, i.e. if TX B spends an output of TX A, TX B has to be listed after TX A in the block if you select both.
Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine ...
Priority was calculated based on the age of the inputs. Older and larger inputs were given a higher priority than new and low valued inputs. This allowed transactions to pay no transaction fees but still be included blocks.
So what used to happen is that 50 kB of a block was reserved for transactions that paid no fees. Transactions were selected for ...
The (close-to¹) highest block reward is achieved by including the transactions with the highest fee per weight. Deviating from that, miners are free to include any valid transactions at whim. They may for example choose to include their own transactions, transactions for their business partners, or transactions subsidized by out-of-band payments over other ...
With 150GH/s, at the time of writing, you would find one block every 1500 years.
That means if you were solo mining, you'd be able to control the contents of a block once every 1500 years.
Or in other words: not at all.
If you are the pool itself, or are solo mining you can use the prioritisetransaction command to add weight to your own transaction, if you are a client of a pool you do not have any control over what you are mining.
Selection by "age x value" creates an arbitrary nobility for early adopters/large hodlers. Early adopters having old coins would be able to cut in line any time, large hodlers could cut in line by transferring a large amount from themselves to their change output. Neither of the two characteristics is in any relation to the actual resources on the network ...
Generally, no miners still use the priority system for selecting transactions. You can easily test this by spending a very old UTXO (e.g. 1 BTC that has remained unspent for several years) and paying no transaction fee. If miners still are using priority, your transaction should be confirmed relatively quickly (hint: it won't be). Otherwise, your transaction ...
First of all: there's no guarantee that it will be free after 15 days. Some miners used to have a policy that made spending old coins potentially free. But miners can change those policies and will likely go for highest fee first, as that earns them the most money. If the network is busy that means there will be hardly any free transactions going in.
They won't be lost. But it won't be easy to get them recovered.
The wiki page on Transaction Fees mentions the following:
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 10,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
So if you have 1,000,...
Depends on the software. You can construct a transaction that spends whichever utxos you want, so yes, you can send someone the exact amount of the sum of dust transactions. As for the transaction fee, the network may or may not relay, but even there, you may be able to get a friendly miner to mine it.