how does transaction fees work

[sucre45]

Hello all,

I am new to this platform,
I have been involved in crypto for several years. But now I would like to get
But now I would like to delve into developing crypto.

I was wondering now how it works with the transaction costs.
Who or what determines the transaction costs of a coin.

Can the developer set this himself?

Kind regards

[franky1]

when making a transaction
EG
1Alice4bc (0.001) -> 1bob3gh (0.0008)
                          -> 1alic4bc (0.000102) remainder change back to alice

the total going out is less that what alice started with.
this 'forgetful' difference(0.000098) becomes the transaction fee.

there may be many many mechanisms/formulaes that wallets chose to decide how much to 'forget' in the audit of the input and output balances.

some do a calculation of the previous x blocks amount of total bytes/total total fee's collected to set an average price per byte the network is currently allowing.

some look at how many transaction bytes are in their mempool to estimate the demand
some may do more complex stuff.

bitcoin has no hard rule. (which is a flaw) whereby the mining pools can set their own decision of what transactions to accept, ignore into their block

making any fee 'estimation' a guess at most. leading people to end up 'just paying more' (not giving as much change back to themselves)

[BlackHatCoiner]

Who or what determines the transaction costs of a coin.

You do it. If you want your transaction to be quickly confirmed, you'll have to set a high fee, because you'll give a greater incentive to the miner. You can determine it in sat/bytes. The more inputs and outputs it has, the heavier it is and thus, the more sats you'll have to pay.

Can the developer set this himself?

The developers cannot set the fee of your transactions. However, they can set a default limit (in the source code) you can't recede. For example, you cannot pay 0 sats for a transaction, because most of the nodes will reject including anything lower than 1 sat/byte into their mempool, if I remember correctly. Note that it doesn't mean they're invalid transactions; they can be normally included into a block.

[NotATether]

Before you can calculate the transaction fee, you must first calculate the transaction size because the total fee paid increases for transactions with more bytes.

There are two different transaction size formulas used by clients today, the first is the old "bytes" calculator which pre-segwit wallets (or wallets that just don't want to implement segwit) use, whose size is calculated like this:

number of inputs * 146 + number of outputs * 33 + 10 (source)

The other size formula gives you the size in vbytes (virtual bytes), and this is the measurement unit now used by the bitcoin network, and also wallets that support segwit, instead of "bytes" (more on that later):

number of inputs * 68.5 + number of outputs * 31 + 10 (same source)

Now you might be wondering, what are vbytes? They are related to another tx size unit called Weight. vbytes is just Weight/4. To calculate weight, you count the size of the transaction in normal bytes but you multiply sizes of some parts of the transaction by 4:


(source: https://learnmeabitcoin.com/technical/transaction-weight)

And as I mentioned earlier you divide the final result by 4 to go from Weight to vbytes.

Why all these complications for finding the transaction size? Well, developers wanted to make transaction sizes smaller so people would pay less overall in fees. The network fee rate (e.g. 10 sats/byte) did not change with this, just the transaction sizes.

So you will generally see two different units for measuring fee rates: satoshis per byte and satoshis per vbyte. Using 10 sats/byte and 10 sats/vbyte is functionally equivalent as far as the rate is concerned, but because of the way the transaction sizes are calculated by wallets supporting segwit vs wallets that don't support segwit, using fees in sats/bytes will cause you to pay more in total fees than if you paid in sats/vbytes. This is a concern because the majority of wallets are paying in sats/vbyte and with a lot of transactions priced like that, you submitting a transaction with a fee in sats/bytes will cause you to overpay, paying more than what other wallets using the same sats/vbyte rate are paying.

[hosemary]

because most of the nodes will reject including anything lower than 1 sat/byte into their mempool, if I remember correctly.

Just a small correction:
The minimum fee you have to pay for a transaction is 1 sat/vbyte not 1 sat/byte.
A transaction with segwit input(s) can be broadcast even with less than 1 sat/byte.

To OP:
As every block has a capacity of 1 vMB and miners can't include any number of transactions in a block, they prioritize transactions based on their fee rate per vbyte to maximize their profit.
So, the higher fee rate your transaction has, the more quickly it will be confirmed.

The fee rate you need to set for a transaction depends on how fast your transaction want to be confirmed and the network status.

Also note that you can pay a lower fee if you use segwit addresses as inputs.
There are two kinds of segwit addresses.
1. Native segwit: addresses that start with bc1
2. Nested segwit: addresses that start with 3.

[sucre45]

Thanks for the posts everyone, learn a lot from this.

So if I understand correctly it works like this.

the higher the transaction cost the faster the transaction will take place on the bitcoin network.

But how does it work with Ripple, because if I am not mistaken there are low transaction fees and the transactions take approx 15 minutes

sorry if i ask stupid questions 

[NotATether]

the higher the transaction cost the faster the transaction will take place on the bitcoin network.

Transaction confirmation speed depends largely on how much hashpower is mining bitcoin, at a predefined "difficulty" that adjusts itself about every 2 weeks based on the current hashpower. If large numbers of miners suddenly go offline, global hashpower does down, but the difficulty stays the same, so what happens is it will take longer for the network to mine new blocks, so even high-fee transactions end up waiting a long time for the next block to be mined.

But in a normal, healthy network, then yes, what you said is true.

But how does it work with Ripple, because if I am not mistaken there are low transaction fees and the transactions take approx 15 minutes

Probably because they mine blocks much faster than Bitcoin's network.

[franky1]

blocks are made on average (of a rule of 2016 blocks over 14 days) of 1 block every 10 minutes

sometime a block can happen in 2 minutes sometimes in 20 but average is 10 mins
much like trains. they suggest they arrive every 10 miinutes. but some can be early and some can be late

to be in the very next block(train). usually people pay more then a fee other transaction pay. putting you top of the list
its like being at a train station. waving your hand in their air with a stash of bank notes getting the conductor attention to let you on first.(bribery)
so if you need to get on the very next train. arriving in roughly 10 minutes. then you will bribe a higher fee. (purposefully forgetting you left extra cash on the seat for the conductor to pick up)

but there is no hard rule that the pool(conductor) has to let you on no matter what you pay. no rule to enforce a locked amount. its just a barter system of guessing what you think would be a tempting bribe to get on the next block(train) the most

[ranochigo]

Thanks for the posts everyone, learn a lot from this.

So if I understand correctly it works like this.

the higher the transaction cost the faster the transaction will take place on the bitcoin network.

But how does it work with Ripple, because if I am not mistaken there are low transaction fees and the transactions take approx 15 minutes

sorry if i ask stupid questions 

Transactions are instantaneous. The confirmation or the process to include your transactions into the blockchain takes much longer, at least an average of 10 minutes.

Miners mostly consider the fee rates to maximize the fees that they're able to collect within the block. For Bitcoin, this means calculating by vbyte instead of actual size. Older clients still adheres to the 1MB real size limit. Using the vbyte as a metric allows the witness stripped block to be kept within that. While fee rate is generally how miner decides to include your transactions, they can choose some other factors as well, be it their own transactions or transactions that were directly pushed to them for an additional fee.

Certain altcoins are perceived to have faster confirmation due to the quicker block time or less congested network.

[nc50lc]

-snip-
But how does it work with Ripple, because if I am not mistaken there are low transaction fees and the transactions take approx 15 minutes

XRP doesn't work like Bitcoin, so comparison between the two should be avoided.
AFAIK, it has no miners and the fees aren't claimed by anyone but forever removed from the total supply;
That removes the competition for a reward and the hard work to claim it; thus, faster transaction speed.

For the speed, their network only relies on validators and transaction can be "approved" through consensus within seconds so it's fast.
I don't want to argue about the security and centralization issues though.

[sucre45]

thank you all for your answers

i would like to create an app that allows users to quickly and cheaply go through transaction such as for payment in the supermarket etc.

Now I understand more how transactions work on the bitcoin network and how it works at ripple.

Now I wonder which network is best to do this with.
I assume that on the btc and eth network will not work.
Is the bep20 network of binance a good idea or will the transaction costs here also be too large for the concept I would like to implement?


thanks again to everyone who is trying to help me find my way around this.

 

[ranochigo]

thank you all for your answers

i would like to create an app that allows users to quickly and cheaply go through transaction such as for payment in the supermarket etc.

Now I understand more how transactions work on the bitcoin network and how it works at ripple.

Now I wonder which network is best to do this with.
I assume that on the btc and eth network will not work.
Is the bep20 network of binance a good idea or will the transaction costs here also be too large for the concept I would like to implement?


thanks again to everyone who is trying to help me find my way around this.

 

The kind of cryptos that you're choosing is dependent on what the customer wants. You can choose to implement a basket of them to give the option to choose whichever they like.

If you want to use Bitcoin, do it off-chain. Lightning network for example. Choosing most alts either results in lower usage due to the smaller userbase or just extreme volatility. You'll have to do your own research on this part.

[nc50lc]

-snip-
Is the bep20 network of binance a good idea or will the transaction costs here also be too large for the concept I would like to implement?

The problem with those networks is even though the value is the same in the Exchange,
your customers will be limited since technically, it's not related to Bitcoin and [BTC] holders can't send nor receive from your app's Binance chain bitcoin [BTCB].

I agree with the above, a number of payment options will be a good feature.
If you can implement lightning payments into your app, that'll be great.

[sucre45]

I did a little research on bitcoin's lighting network

If I understand correctly it works like this:

From a btc wallet the btc is converted to a lighting wallet. then a node is created and so a payment channel is created. after the transaction is done this channel is closed and sent back to the blockchain.

If we step away from the bitcoin network for a moment.

Is it possible to create a Coin and then create a lighting network and implement this in an app?

[nc50lc]

Partly correct, except the node isn't something that's created, you run a lightning node just like running a cryptocurrency node.
Some SPV wallets have their own implementation of a "light" lightning client.
To create a channel, the bitcoins will be locked through a special "funding transaction", that involves another node.

After a lightning transaction, the user may choose not to close the channel; the user can use it for more LN payments up to the channel's capacity (funds).
The channel should only be closed when the user want to claim his part into on-chain funds.

There's more to that and the info should be available in various sources like for example: The Lightning Network FAQ
And specially from this site: http://lightning.network/how-it-works/ | http://lightning.network/docs/
Lastly, it's getting off-topic, here are some documentations you will need: https://developer.bitcoin.org/

[sucre45]

Partly correct, except the node isn't something that's created, you run a lightning node just like running a cryptocurrency node.
Some SPV wallets have their own implementation of a "light" lightning client.
To create a channel, the bitcoins will be locked through a special "funding transaction", that involves another node.

After a lightning transaction, the user may choose not to close the channel; the user can use it for more LN payments up to the channel's capacity (funds).
The channel should only be closed when the user want to claim his part into on-chain funds.

There's more to that and the info should be available in various sources like for example: The Lightning Network FAQ
And specially from this site: http://lightning.network/how-it-works/ | http://lightning.network/docs/
Lastly, it's getting off-topic, here are some documentations you will need: https://developer.bitcoin.org/

okay thank you for the information, really helped me out =)

[kxwhalexk]

the higher the transaction cost the faster the transaction will take place on the bitcoin network.

Transaction confirmation speed depends largely on how much hashpower is mining bitcoin, at a predefined "difficulty" that adjusts itself about every 2 weeks based on the current hashpower. If large numbers of miners suddenly go offline, global hashpower does down, but the difficulty stays the same, so what happens is it will take longer for the network to mine new blocks, so even high-fee transactions end up waiting a long time for the next block to be mined.

But in a normal, healthy network, then yes, what you said is true.

But how does it work with Ripple, because if I am not mistaken there are low transaction fees and the transactions take approx 15 minutes

Probably because they mine blocks much faster than Bitcoin's network.

The difficulty will be updated automatically every 2016 blocks, but the changed difficulty will be controlled at 1/4-4 times of the previous difficulty.

When a large number of miners fall, there will be slow transactions within 2 weeks, but will slowly adjust in the later time.

[Shymaa-Arafat]

Check this one, although little old
https://en.bitcoin.it/wiki/How_to_cheaply_consolidate_coins_to_reduce_miner_fees

This paper also has a complete section on how to calculate the transaction fee ( in their process of estimating what could be considered dust)
They enumerate all cases & explain in detail
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
.
Also, since u r talking about writing/implementing something urself, u may jump into the fee estimation/handling in this (find the words)
http://diyhpl.us/wiki/transcripts/gmaxwell-2017-08-28-deep-dive-bitcoin-core-v0.15/
I mean to see how it was originally thought about back in 8/2017 & evolved with time

[sucre45]

Thanks for the information

[hosemary]

but the changed difficulty will be controlled at 1/4-4 times of the previous difficulty.

What? Am I getting this right?
Are you saying that in every difficulty adjustment, the difficulty can increase up to 4 times the previous difficulty and it cannot decrease to less than 1/4 of the previous difficulty?
It's the first time I've heard this.
I just made a search and couldn't find any information about this.

Edit:
Can anyone confirm if there's such a rule?