Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
10

Currently no. Any "required fees" are enforced only by the client not the network or protocol. It is up to each individual miners which transactions to include in a block. If forced to make a choice a miner would choose a paying transaction over a nonpaying one however current transaction volume is so low that all transactions (paying and otherwise) can ...


5

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.


5

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)...


5

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.


4

There's a very nice visualization of the most recent 4 hours' worth of transactions and whether they paid a fee or not, and how long it took each one to be confirmed: http://bitcoinstats.org/ Sometimes it looks like fee-offering transactions have a significant advantage over no-fee transactions, other times it looks random.


4

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 ...


4

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.


3

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, ...


3

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. ...


3

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 ...


3

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


3

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"); else ...


3

DannyHamilton from bitcointalk says At a minimum. 0.0001 BTC per kilobyte. That would put you ahead of all transactions that are considered "low priority" which don't include a fee by all miners (and pools) that choose to use the reference implementation. Given how low the exchange rate has been lately, you might even consider a fee of 0.0005 BTC ...


3

According to the Satoshi client transaction exchange behavior, this does not seem to be the case. However, that page isn't written well. Looking at the actual source code, I cannot see any special behavior for transactions to an address in your wallet, but I do see special behavior for transactions from such an address. Thus, I do not think the behavior ...


2

zero fee txs get into blocks all the time. many pools accept zero fee txs that have sufficiently high priority. that is, the inputs are aged and of high value.


2

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. Second:...


2

The priority of a transaction is (the sum of (coin age in blocks * coin value in satoshis) over all the inputs in the transaction) divided by the size of the transaction in bytes. Here's a random example transaction copied from http://bitcoincharts.com/bitcoin/txlist/: It has 2 inputs (both of which have since been spent in other (confirmed) transactions ...


2

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.


2

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.


2

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 ...


1

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 ...


1

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 ...


1

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.


1

The rules for the Bitcoin.org client are to keep the first transaction in which a bitcoin address is spent and to discard without relaying any others that might arrive. So the priority is based on chronological time of arrival. There has been talk of variations that would allow a replacement transaction with a higher fee to supercede an earlier transaction ...


Only top voted, non community-wiki answers of a minimum length are eligible