Bitcoin transaction fees

Lordas

@wrapper Yes, it is true. If you reindex your blocks (at least part of them - latest), and coins are not confirmed - they get back to your wallet. I am not sure how this work - wallet stop translating transfer and it was removed from mempool, or another way, but it works. I have tested :)

Lordas

BTW, most of BTC transactions are ~998 kB in size, so my 226 bytes transaction can be freely included… but no :(

wrapper

@Lordas Re: unconfirmed transfers :

Might be worth having a look at p2pool (source code) to see if it would process it. It should process these transfers and take into account age, where’as private pools can be adjusted for maximum profit.

FTC has a higher proportion of p2pool than Bitcoin, and I suspect that is why FTC confirm such transfers, at least somewhat (see dust coin experiment [Ref A:]).

The Bitcoin p2pool sites should include information about the last global mined p2pool blocks. e.g. to look and see if any other similar are being processed

I haven’t time at the moment, but it would be possible to identify p2pool payments in FTC explorer / ABE (during the dust coin payments). They can be distinguished by the fact that the mining fee is distributed instead of to one address.

[Ref A:] https://forum.feathercoin.com/topic/8883/feathercoin-analysis-of-possible-maximum-transactions-block-dustcoin-attack-25-10-2016/13

FlatBlack

@Lordas again, this is a ‘prove’ n ‘documentation’ process actolly, fren…
gud job for doing dis ‘xperimenting’ - kinda ‘out-of-box’ thinking…
:bow_tone1:

Lordas

More than two weeks and situation looks promising, but still no confirmation… :no_mouth:
alt text

wrapper

@Lordas Cool chart, where’s it from, and can we see one for FTC?

Lordas

Chart is from link text. They hardly share their know-how to convert to FTC I suppose…

wrapper

@Laordas Maybe they do? : https://github.com/bitcoinfees

Just checking, seems all there. I’d have put that on Pool20, if it was still running. Looks a very interesting and do-able FTC fork. Great student project.

Let us know if there is a stopper …

Lordas

@wrapper Great!

Lordas

Boring info - 20th day and transaction still not confirmed…
Situation is getting better - mempool become smaller and I still not loosing my hope… I try :cry:

Lordas

Mass BTC selling… bye bye my hopes for fast confirmation…

AmDD

@Lordas said in Bitcoin transaction fees:

Boring info - 20th day and transaction still not confirmed…
Situation is getting better - mempool become smaller and I still not loosing my hope… I try :cry:

20 days?! wow…

FlatBlack

This post is deleted!

FlatBlack

@Lordas
sumthin related wit BTC-transaction-fees…
.
From some forum

Lordas

It has happened! Today after 26 days my transaction was confirmed! :)
At last, woohooo!

Mempool lowering lowering and only around 10K transactions waiting atm, so was confirmed with lowest profit.
It shows how important are p2pools to network and so bad is that BTC p2pool solve only 1-2 blocks per year only…

AmDD

@Lordas said in Bitcoin transaction fees:

It has happened! Today after 26 days my transaction was confirmed! :)
At last, woohooo!

Mempool lowering lowering and only around 10K transactions waiting atm, so was confirmed with lowest profit.
It shows how important are p2pools to network and so bad is that BTC p2pool solve only 1-2 blocks per year only…

What do P2Pools have to do with it?

Lordas

P2pools include oldest transactions in block first, not most “expensive”. I am right?

wrapper

P2pool uses the standard methods to compile the blockchain. Other pools may customize their acceptance https://en.bitcoin.it/wiki/Protocol_rules, to reject low value transactions.

The point was, you should be able to see if you had to wait for p2pool, because, in that case, the transaction fee is shared between miners. Otherwise, a normal pool eventually included your transaction.

AmDD

@wrapper Is the standard method as @Lordas explained? Adding transactions based on age and not based on fee?

wrapper

@AmDD When I looked at the “mining” code, it pulls outstanding transactions into a prospective block / chain of blocks.

There are then rules for rejection of some transactions for dust payments or large temporal anomaly, for instance.

Each miner pool is effectively doing this, via the code in Feathercoin-cli or Bitcoin-cli.

In building up a “prospective block”, there is a probability of each transaction being accepted / rejected, based on the rules. These included having some low fee payments transactions included in the blocks, not just all the high fee transactions and the size of the block.

The code is in main.cpp (will check this).

Here are the rules :

Rule #0 – Is it a valid transaction?

Rule #1 – Smaller amounts pay a fee

If the numbers of coins you are sending is smaller than the “dust payment level” you will be required to pay a miners’ fee. This fee is required in order to prevent users from spamming the network with micro transactions.

Rule #2 – Older coins have less fees

If the inputs you are sending in your transaction are older then there is a greater chance they won’t require a fee. Old coins means coins that haven’t been moved for a long time.

Rule #3 – Smaller transactions require less fees

Each transaction is made out of inputs. The less inputs used to compile a transaction, the less fees will be required. So if you are send 1 Bitcoin and use 4 inputs of 0.25 Bitcoins it is more likely that this will require a fee then if you were to send just 1 input of 1 Bitcoin.

[Ref:] https://99bitcoins.com/bitcoin-fees-explained/

Filling mempool
https://github.com/FeatherCoin/Feathercoin/blob/f296bdcef38b8c0770b43d4edc012e8c7434ac49/src/txmempool.cpp

Creating Blocks
https://github.com/FeatherCoin/Feathercoin/blob/f296bdcef38b8c0770b43d4edc012e8c7434ac49/src/miner.cpp

main.cpp … Allow free
https://github.com/FeatherCoin/Feathercoin/blob/f296bdcef38b8c0770b43d4edc012e8c7434ac49/src/main.cpp

main.cpp - line 855

   if (fAllowFree)
     {
         // There is a free transaction area in blocks created by most miners,
        // * If we are relaying we allow transactions up to DEFAULT_BLOCK_PRIORITY_SIZE - 1000
        //   to be considered to fall into this category. We don't want to encourage sending
        //   multiple transactions instead of one big transaction to avoid fees.
        // * If we are creating a transaction we allow transactions up to 5,000 bytes
       //   to be considered safe and assume they can likely make it into this section.
            if (nBytes < (mode == GMF_SEND ? 5000 : (DEFAULT_BLOCK_PRIORITY_SIZE - 1000)))
 nMinFee = 0;