Bitcoin Forum
April 28, 2024, 04:37:21 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
1  Bitcoin / Electrum / Re: How to export Lightning Network transactions on: March 09, 2024, 10:49:02 PM
I have the same question.
According to https://github.com/spesmilo/electrum/issues/8521
the command to do this is
Code:
./run_electrum -o lightning_history
but I'm not sure how to do this using pre-compiled binaries (e.g. using electrum-4.x.x.exe in Windows) instead of using the source code.
2  Bitcoin / Bitcoin Technical Support / Re: Minimize fees on Lightning network on: December 09, 2023, 02:44:58 PM
For example, has the coice of node on Electrum (ACINQ vs. Electrum trampoline vs. trampoline hodlistreco) any effect on future fees paid?
Yes, it depends on the route that your payment had to take to reach the receiver's channel.
The total fee depends on the number of channels that it went through and their respective routing fees.
The more expensive channels that it need to hop into, the more fee that it'll accumulate.

The sent amount is quite high too, it may have been broken-down into multiple separate small amounts to send the full amount.

In terms of those hard-coded trampoline nodes, those have different connections to the lightning network
so it could be cheaper if one has shorter route to the recipient and has active channels to nodes with lower routing fees.
But finding which one will total a lower fee requires intensive research (for the indications above) or testing.

Is there a way to minimize those fees somehow?
The only way I know is to open a channel directly to the recipient's node.
It's recommended if it's an exchange's lightning node where you would deposit and withdraw bitcoins frequently.
Usually, exchanges with lightning deposit/withdrawal option have a note with "connect to our lightning node" message or similar.

I was thinking if there is any indication which ACINQ vs. Electrum trampoline vs. trampoline hodlistreco node is the one with the lowest fees. Apparently this is unknown..

for a 0.027BTC transaction the fee I paid was 0.000164BTC which is comparable to the on-chain fee.
I'd expect LN to be used for small transactions. This is worth more than $1000, and I would keep such amounts on-chain. But: I've seen exchanges that support LN withdrawals, and it's either free, or something like 5 sats. So that makes me think they don't pay high routing fees.

This was on Electrum trampoline.
I've used several LN wallets in the past, but never this one. Does it at least show you the fee before sending the payment? You paid 0.6% fee, which is a lot. From what I've seen, most LN node owners "complain" that they don't make any profit. It sounds like the only route for your (high) payment was through a node with much higher fees than average.

I can't really tell you how to avoid this Sad

Electrum doesn't show the fee. I'm not sure if there's a way to dig into the wallet option to find out what the fee is before even sending. But I guess that's a question for the Electrum devs
3  Bitcoin / Bitcoin Technical Support / Re: Minimize fees on Lightning network on: December 08, 2023, 05:45:36 PM
If you run your own lightning node and open a channel with another node, there is no fee needed. If you depend on people's channel, or not connected directly to someone, you will need to pay little amount in fee.

As an example, for a 0.027BTC transaction the fee I paid was 0.000164BTC which is comparable to the on-chain fee.
This is not possible as of now.

What you you mean "this is not possible"? This is the fee I paid!

The 0.000164BTC is around $7 it is still high maybe the operator is asking for high transaction fees or maybe the fees he is talking about are the ones he paid for opening a channel.

@OP can you make it clear in what node did you open a channel ACINQ, Electrum trampoline, trampoline hodlistreco?

This was on Electrum trampoline.

LN transfer fees are way less and it can't be around $7 unless the transacted amount is a few thousand bitcoins which is unlikely possible to happen so yeah OP is confusing the LN transfer fee with the fee that he paid while opening the channel.

LN node operators set the base fee as less as possible and they are not doing it to make any financial benefits in my opinion.

No this was for a lightning payment.
Since because some of you don't seem to believe me:

4  Bitcoin / Bitcoin Technical Support / Minimize fees on Lightning network on: December 08, 2023, 03:24:08 PM
Lightning network is perceived to have zero fees, but this is not true. In fact, still exist and add up over time.
As an example, for a 0.027BTC transaction the fee I paid was 0.000164BTC which is comparable to the on-chain fee.
Is there a way to minimize those fees somehow? For example, has the coice of node on Electrum (ACINQ vs. Electrum trampoline vs. trampoline hodlistreco) any effect on future fees paid?
5  Bitcoin / Electrum / ACINQ lightning payment TRAMPOLINE_FEE_INSUFFICIENT on: July 04, 2023, 10:12:22 PM
Have been trying for over 3 hours to get a lightning payment through. I am always getting a "Payment failed - No path found" error message, and the log shows "TRAMPOLINE_FEE_INSUFFICIENT".
Very ftustrating, lightning payments are effectively unusable with this.
Related github issue: https://github.com/spesmilo/electrum/issues/8297
Any help from the devs?
6  Bitcoin / Bitcoin Discussion / Re: Algorithm for selecting a low-fee transaction from the mempool on: May 20, 2023, 03:07:22 PM
What you are missing is that you are making the assumption the mempool size remains the same.

We cannot predict what the mempool will do. We cannot predict how many new transactions are going to be broadcast, how large those transactions are going to be, or what fee those transaction will pay. We also cannot predict whether we will find 10 blocks in the next hour or 0 blocks in the next hour. As such, every fee estimation is exactly that - an estimation.

Having said all that, an estimation of 11.7 sats/vbyte for 3 days is on the low side, since we've got over 90 MvB of unconfirmed transactions above this level already in the mempool, even without taking in to account any new transactions. For 3 days right now I would probably go somewhere around 16 sats/vybte which is about 20 MvB from the tip, but it's still just an educated guess.

Not sure how corefeehelper computes those estimates, but I don't think it makes those estimates with the "hope" of the mempool somehow magically clearing in the next days. After all, its estimates dynamically change as the mempool size fluctuates, so I think corefeehelper publishes those estimates periodically under the assumption that the mempool size remains the same at the time of those estimates are published.

Maybe someone from corefeehelper could shed some light.

Also some wallets e.g. electrum provide an estimate themselves based on mempool size and selected fee, so maybe someone pointing to their code on computing this estimate would be also interesting.

The thing to do is to make sure you enable RBF on all your transactions. That way if it gets stuck, you can easily bump the fee higher.

I know the basics, the discussion is about miner logic on selecting transactions and transaction processing estimates.
7  Bitcoin / Bitcoin Discussion / Re: Algorithm for selecting a low-fee transaction from the mempool on: May 20, 2023, 02:33:55 PM
The 10tx-11sat/byte vs. 11tx-10.1sat/byte makes some sense.

I didn't "blame" anyone, I am asking what is the algorithm they use to create a block.

then maybe that algorithm is correct because they are choosing all the highest fees to mine and then the lowest fees. Right now if you check mempool you will see a total of over 122.17 MvB for transactions under 10 sat/vByte which is need over 120 blocks to mine all of that and if you want to get your transaction got confirmation faster then use a high fee for your transaction or wait until your turn to get in a block.

There is no "correct" or "wrong" algorithm for this problem, rather an "optimal" algorithm. I think we can just assume that miners want to maximize their profit, but a greedy algorithm might not be optimal. E.g. see example posted before with the 10.1sat/byte example and https://en.wikipedia.org/wiki/Greedy_algorithm#Cases_of_failure

"wait until your turn" -> not sure what you mean here. That's exactly what I asked in my original post, i.e. if transaction age is a factor. If age is not a factor (which makes sense, since miners don't care and just prioritize higher fee transactions) then there's no notion of a "turn".

I didn't say that the miners are "greedy". I was asking if they are adopting a "greedy algorithm" to choose transcations.
Miners are free to use any algorithm they like in order to choose which transactions to include in their candidate blocks.

In general however, then yes, miners simply prioritize the transactions in their mempool which have the highest fee rate. There are a few exceptions to this - for example mining pools will also include their own transactions with very low fees, Binance pool includes transactions made by the Binance exchange with low fees, they may include transactions they have been paid privately to include, and so on. However, these types of transactions usually only make a small handful of the total number in the block, with the vast majority of transactions simply being prioritized based on their fee rate.

So currently according to https://twitter.com/CoreFeeHelper, a 11.7sat/byte transaction should get confirmed between 3days-1week. But if miners simply choose those transaction with the higher fee (and assuming than mempool size remains the same), then this transaction should never get confirmed as the higher fee transactions will always get priority over it. So maybe we're missing something here.
8  Bitcoin / Bitcoin Discussion / Re: Algorithm for selecting a low-fee transaction from the mempool on: May 19, 2023, 08:38:10 PM
"Typically" would be filling up their mined block with the highest fee transactions as much as possible before the next one is mined so that falls under your "greedy algorithm". They can maybe accommodate some requests in including TXs with lower fees but that's definitely not their priority. They are here for the money after all - let's keep it real.

"Typically" would be filling up their mined block with the highest fee transactions as much as possible before the next one is mined so that falls under your "greedy algorithm". They can maybe accommodate some requests in including TXs with lower fees but that's definitely not their priority. They are here for the money after all - let's keep it real.

Yup. Highest total fees after filling up the blocks is probably how they go, rather than just blind highest fees (e.g. if you can fit 11 txs with average fee of 10.1 sat/byte rather than just 10 txs with 11 sat/byte, that's what they'd go).

You can't really blame "greedy" algorithm, OP. It's a cost-revenue thing, quite literally.

Obviously, you can still see low fee txs, I suspect that's paid for in different ways (e.g. viabtc's paid accelerator... as opposed to broadcasting, which doesn't... accelerate).

The 10tx-11sat/byte vs. 11tx-10.1sat/byte makes some sense.

I didn't "blame" anyone, I am asking what is the algorithm they use to create a block.

They aren't greedy, just that the miners get higher opportunities in this for making more profits than before and when the whole blocks had being completely mined, they still have to depend on the transaction fee to earn their income
You can't say it's greed. If you were them, would you take the low-fee transactions first? Or will you rush to take higher-fee transactions?

This is the logic that miners work with. If two people offer you to do the same work: one at 1$ and the other at 10$, which job will you accept?
This is the principle by which all human beings work.

I didn't say that the miners are "greedy". I was asking if they are adopting a "greedy algorithm" to choose transcations.

Please all read first https://en.wikipedia.org/wiki/Greedy_algorithm
9  Bitcoin / Bitcoin Discussion / Re: Algorithm for selecting a low-fee transaction from the mempool on: May 19, 2023, 02:13:19 PM
So you say it is purely a greedy algorithm?
It's not that there's a certain algorithm which miners have to follow that.
Miners are free to include any valid transaction they want. They can even include a transaction with zero fee, but they include transactions with highest fee rates to maximize their profit.

So to be precise, I'm not saying what algorithm miners should follow. Of course miners are free to choose any transaction they want (or even censor specific ones, despite if this means a lower reward for them).

What I am asking is what algorithm miners/mining pools typically follow.
10  Bitcoin / Bitcoin Discussion / Re: Algorithm for selecting a low-fee transaction from the mempool on: May 19, 2023, 01:55:50 PM
My question is what is the algorithm that a miner picks a transaction from the mempool to include it to a block?
Miners prioritize transactions based on their fee rate. The more fee rate you use for your transaction, the faster it can be included in the blockchain.


Is it a greedy algorithm which just picks the ones with highest fees? Is the "age" of a transaction in the mempool also a factor? Or is it just a combination of fee and a random choice?
It doesn't matter when you have broadcasted your transaction. It all depends on the fee rate.

So you say it is purely a greedy algorithm?
11  Bitcoin / Bitcoin Discussion / Algorithm for selecting a low-fee transaction from the mempool on: May 19, 2023, 01:30:42 PM
I broadcasted a low fee (11sat/vbyte) transaction last week, just at the time when they fees went up.
I knew that the fee was low and that the transaction would take a few days to confirm (according to https://twitter.com/CoreFeeHelper , it would take around 3 days) but it's been a week and my transaction is still in the mempool. Sometimes my wallet (electrum) shows it with a blue "unbroadcasted" icon and I have to rebroadcast it again. I also sometimes use "free" tx accelerator services which basically rebroadcast the transaction everywhere.

My question is what is the algorithm that a miner picks a transaction from the mempool to include it to a block?
Is it a greedy algorithm which just picks the ones with highest fees? Is the "age" of a transaction in the mempool also a factor? Or is it just a combination of fee and a random choice?
12  Economy / Trading Discussion / Re: Swapping BTC lightning for LTC on: March 23, 2023, 10:10:21 PM
Thank you both.
Which one of those has the lowest fees? (sometimes it is hard to find since they have a "hidden" fee with a crappy exchange rate)
13  Economy / Trading Discussion / Swapping BTC lightning for LTC on: March 23, 2023, 08:49:16 PM
Hello,
I'm looking for a DEX or non-KYC CEX that can swap BTC lightning <-> LTC.
I looked at changenow.io but not sure about its reputation.
Any other suggestions?
14  Local / Ελληνικά (Greek) / Κλείνει το Localbitcoins on: February 10, 2023, 04:11:28 PM
https://cointelegraph.com/news/localbitcoins-closes-down-the-p2p-crypto-exchange-service

Νομίζω βέβαια ότι πέρασε ο χρόνος του, αφού έτσι κι αλλιώς οι συναλλαγές που προσέφερε δεν ήταν "local" πλέον εδώ και πολλά χρόνια.
15  Bitcoin / Development & Technical Discussion / Re: Bitcoin transaction format and byte sizes on: January 17, 2023, 03:08:46 AM
Thanks for all those info, really useful.
So to sum up, a common P2PKH transaction with 1 input and 2 outputs w.r.t the hashes and signature needs the following:

Input ECDSA signature:  ~70 bytes (64 in taproot)
Input ECDSA public key: 33 bytes

For each output hash: 20 bytes
   
16  Bitcoin / Development & Technical Discussion / Re: Bitcoin transaction format and byte sizes on: January 16, 2023, 04:46:23 AM
And about the signature in the input, why does it take 70 bytes? Isn't it normally 64 bytes?
17  Bitcoin / Development & Technical Discussion / Re: Bitcoin transaction format and byte sizes on: January 16, 2023, 04:02:44 AM
Thanks all.

So to understand better:

1. In tx inputs, the size is dominated by scriptsig. I googled a bit and found this guide https://hackernoon.com/scriptsig-a-bitcoin-architecture-deep-dive-fs1i3zvy
which has an example of a scriptsig for one input, and says that it has 140 hex chars (=70 bytes) for the digital signature and 130 hex chars (=65 bytes) for the hashed public key. My question is a) why 70 bytes for an ECDSA signature? b) why 65 bytes for a RIPEMD160 hash? (unless this example is incorrect and I am missing something).

2. In tx outputs, the size is dominated by scriptpubkey. For 2 outputs, you need to have 2 Pay To Pubkey Hash correct? In this example https://learnmeabitcoin.com/technical/scriptPubKey I see Pay to Pubkey hash takes 40 hex each = 20 bytes?
18  Bitcoin / Development & Technical Discussion / Bitcoin transaction format and byte sizes on: January 12, 2023, 08:59:07 PM
I am doing some research on what is the potential impact of shorter public keys, hashes or signatures in Bitcoin transactions (leaving the security implications aside). So I basically want to see how a Bitcoin transaction exactly looks like in terms of bytes, basically a figure similar to the figures of IP packets which show that the first 4 bytes indicate the version, etc, then the source IP is 32 bytes as payload etc.
So far all I have found is this website for a bitcoin transaction calculator
https://bitcoinops.org/en/tools/calc-size/
However it just computes the final size and does not show clearly which part takes how much space.
Is there any better website/image that shows the elements of a bitcoin transaction in a byte level?
19  Bitcoin / Electrum / Re: Lightning payments fail all the time after many attempts on: September 22, 2022, 02:44:03 PM
I do have enough funds.
Anyway I will close and reopen the channel, and see if it makes any difference.
20  Bitcoin / Electrum / Lightning payments fail all the time after many attempts on: September 22, 2022, 01:55:09 PM
I have been using lightning payments for the last few months quite often, but now all of my payments seem to fail all the time.
After providing the deposit request, the payment does not go through and I get an error window "Payment failed Giving up after 25 (or sometimes more) attempts".
In the lightning network I am connected to 4 peers, 15K nodes and 83K channels.
I also tried trampoline routing with the same results.
Any ideas on how to make lightning payments work?
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!