Topic: [need help] The technical less technical, on the latest (core) update (Read 777 times)

Okay, now I got it! Thanks for both your help and the thorough explanation guys, much appreciated 

For example:

A merchant chooses to take on the nominal risk and accept transactions with 0 confirmations as long as everything else about the transaction looks good.

The merchant realizes that some of the customers won't include enough fee in their transactions.

Once an hour, the merchant spends all the bitcoins received in all the unconfirmed transactions from that past hour in a single big transaction that sends the bitcoins to another address owned by the merchant.

The merchant adds up all the fees in all those unconfirmed transactions and discovers that the customers paid a total of 0.25 mBTC.

The merchant adds up the size of his transaction (in bytes) plus the size of all the unconfirmed transactions (in bytes) and then figures out how much fee should be paid for that many bytes.

The merchant discovers that the total fees that should be paid for all those bytes for fast confirmation is 2.3 mBTC.

Since 0.25 mBTC of fees are already paid, the merchant pays 2.05 mBTC in the transaction that he creates (2.3 mBTC - 0.25 mBTC = 2.05 mBTC).

The miners can't confirm the merchant's transaction until the customer's transactions are confirmed (since the merchant used those transactions as inputs to his transaction).

In the past, the miners would see that all those customer transactions paid insufficient fees and they would never confirm them.  The merchant would be stuck with a bunch of unconfirmed transactions and nothing he could do about it.  That's because, in the past, most miners didn't look ahead and see that there was a high-fee paying "child" transaction that was dependent on those "parent" transactions.

Now, any miner that is using 0.13.0 will see the total fees that they can earn by confirming both the low-fee "parent" and high-fee "child" transactions all in the same block.  As such, in the interest of increasing their revenue, the miners will confirm those miserly worthless "parent" transactions because the generous child transaction has made up for the difference and the miners can't get at the revenue from that "child" transaction unless they include the "parent" transactions at the same time.

In other words, the child transaction pays the way for the parent transactions so that they can all get confirmed. (Which is why it is called "child pays for parent").

---

Similarly, you can (in some circumstances) create a child transaction to pay the fee for an earlier transaction of your own.  Here's an example.

You have an empty wallet with no bitcoins.

You receive a payment of 0.5 BTC.
You receive a second payment of 2 BTC.
You create a transaction that sends 0.5 BTC to someone else and you pay no fee.
You check the size of the transaction and realize the fee should have been 0.1 mBTC.

Now there are three possibilities...

Possibility 1

• Your wallet spent the 2 BTC output that you previously received.
• Since the value of the output that you sent to someone (0.5 BTC) is less than the value of the input you spent (2 BTC), your wallet creates a 1.5 BTC "change output" that it sends back to an address that your wallet controls.
• If your wallet has "coin-control" features, then you can now create a new transaction that spends that 1.5 BTC output in a new transaction to yourself.
• If your wallet does not have "coin-control" features, then you can now create a new transaction that spends your entire 2.0 BTC remaining wallet balance (0.5 BTC + 1.5 BTC = 2 BTC) in a new transaction to yourself.
• Lets say this new transaction should normally pay a fee of 0.075 mBTC, you can instead pay a fee of 0.175 mBTC and cover the cost of both transactions (0.1 mBTC + 0.075 mBTC = 0.175 mBTC)

Possibility 2

• Your wallet spent BOTH the 2 BTC output that you previously received AND the 0.5 BTC output that you previously received as inputs to the transaction.
• Since the value of the output that you sent to someone (0.5 BTC) is less than the value of the sum of the inputs you spent (2.5 BTC), your wallet creates a 2.0 BTC "change output" that it sends back to an address that your wallet controls.
• If your wallet has "coin-control" features, then you can now create a new transaction that spends that 2.0 BTC output in a new transaction to yourself.
• If your wallet does not have "coin-control" features, then you can now create a new transaction that spends your entire 2.0 BTC remaining wallet balance in a new transaction to yourself.
• Lets say this new transaction should normally pay a fee of 0.075 mBTC, you can instead pay a fee of 0.175 mBTC and cover the cost of both transactions

Possibility 3

• Your wallet spent the 0.5 BTC output that you previously received.
• Since the value of the output that you sent to someone (0.5 BTC) is exactly equal to the value of the input you spent (0.5 BTC) your wallet didn't create any "change output" to send back to your wallet.
• Since there is no "change output", there is nothing available for you to create a "child" transaction from.
• You won't be able to create a "child pays for parent" transaction yourself.
• However, you could create a transaction that sends 0.175 mBTC to the person that you sent the original transaction to.
• That recipient could now spend in the same transaction BOTH the 0.5 BTC that they received from you AND the 0.175 mBTC that they received from you, sending 0.5 BTC of that to another address that they own, and paying a 0.175 mBTC fee with the remaining value.
• Since the 0.5 BTC was received in the unconfirmed "parent" transaction, the 0.175 mBTC fee in this child transaction pays for both itself and the parent

This second transaction must spend an output from the first.

No, both fees will be paid, but the sum of the fees needs to be enough to cover both transactions.

Okay, so when for example I did a transaction that ain't confirmed yet because for let's say the fees were low; I could broadcast another transaction with a higher fee, and then when these 2 transactions get processed, I only pay a total miner fee for 1 transaction (in this case, the one with the higher fee)?

You misinterpreted that. It is a local node policy for accepting transactions. It means that you can create a transaction that spends from another unconfirmed transaction which has a low fee. The new transaction can have a higher fee that covers the fees of both transactions. These transaction will be considered for inclusion in a block together whereas previously they were considered individually.

Under the Mining transaction selection (“Child Pays For Parent”), https://bitcoin.org/en/release/v0.13.0#mining-transaction-selection-child-pays-for-parent

Or did I misinterpreted that?

Segwit is there and can be used on the testnet and regtest networks. It is there for experimentation and testing, but will not be activated on mainnet. 0.13.0 will never be able to use segwit on mainnet.

Where do you see this?

Bitcoin Core previously had an internal miner which would use your CPU to mine blocks. It has been removed.

Hello guys. Regarding the latest (core) update, would someone be so kind to explain them to me in a simplified and shortened way? I see a huge list of all kinds of improvements/changes/bugfixes/etc (https://bitcoin.org/en/release/v0.13.0), but for me, I might as well be looking at an Arabic, Chinese or Russian site (stuff I can 'read', but don't understand either what they're saying/meaning).

So this new update, 0.13, from a users perspective, I could derive the following 3 updates (the rest was to tech savy for me); kindly correct me if I'm wrong on them, and fill me up on what I might have missed:
1) The update is 'Segwit ready'. Whilst Segwit is not yet implemented, this update lays the building stones or requirements required for when Segwit does get implemented.
2) Miners cannot 'discriminate' low fee transactions anymore; i.e. miners cannot select anymore to process high fee transactions favorable over low fee transactions.
3) You cannot use the software itself anymore to mine with your CPU.

...