Topic: how does transaction fees work (Read 370 times)

Sorry! I am neither a developer nor a technical specialist so I would not be able to help.

You can use the level 1 bitcoin network for this, as long as the person receiving the payment is willing to accept the risks associated with unconfirmed transactions.

When someone write a check for payment, the person receiving the check has no way of knowing if the bank account the check is being drawn on has enough money, or if it is even still open (or even if the bank account exists). To mitigate this risk, stores accepting checks document the identity of the person giving the check, so they can go after the person if the check does not clear. Similar precautions can be made for physical stores accepting modest amounts of bitcoin. Also, the store can only accept transactions that meet certain criteria, such as minimum fee rates, or the RBF flag being sent to false.

It would probably be better to use the LN for in person crypto transactions, as these are generally instant (assuming there is an available route), and are much cheaper than on-chain transactions.

Yes, as long as your altcoin supports SegWit, it can implement its own Lighting network (or something similar thereto). If your coin supports SegWit, its LN can even support atomic swaps with the bitcoin LN (or any other LN), provided there is at least one node supporting this. I am not sure if LN is being actively implemented, or if there are any LN nodes on any of the altcoins, such as Litecoin that support SegWit.

I have made a post about this hope is helpful to you too
https://bitcointalksearch.org/topic/pay-very-low-fee-when-u-make-a-btc-transaction-5348773

I believe this is the part that you're looking for: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L54-L59

If the actual time is less than 1/4 of the expected time, then it will be equal to 1/4 of it, not any lower.
If the actual time is more than x4 of the expected time, then it will be equal to x4 of it, not any higher.

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?

Thanks for the information

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

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.

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

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/

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?

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.

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.

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.

 

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.

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.

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

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.


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

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 

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.