That is to say, you should always be able to send at least $.01 using L1. So if a sustained price raise keeps the minimum dust as a couple dimes for a while, that's when I think they will take an action to lower the dust limit with a soft fork.
Dust limit is not a consensus rule to need any kind of fork. It is a "client based preference" that the devs should let the user set in a Settings window so that they can change it based on the market situation on their own without needing to upgrade to the new version to change it. 
Topic: [TESTED IT] Minimum transaction value (Read 478 times)
Interesting. At current fiat prices, that's about 8 cents. (BTC @ $29,500-ish) ... So if the price goes up to low 6 digits (around $295,000) then minimum dust is still worth below $1.
On L1, on-chain, I usually don't bother sending such small amounts anymore anyway. Maybe the core devs will lower the dust limit or the default dust limit in the future, they did it before when the "reasonable" small transaction was 0.01 BTC, then it became 0.001 BTC.
On L1, on-chain, I usually don't bother sending such small amounts anymore anyway. Maybe the core devs will lower the dust limit or the default dust limit in the future, they did it before when the "reasonable" small transaction was 0.01 BTC, then it became 0.001 BTC.
I think Core devs would at least keep the minimum dust representable in cents.
That is to say, you should always be able to send at least $.01 using L1. So if a sustained price raise keeps the minimum dust as a couple dimes for a while, that's when I think they will take an action to lower the dust limit with a soft fork.
Interesting. At current fiat prices, that's about 8 cents. (BTC @ $29,500-ish) ... So if the price goes up to low 6 digits (around $295,000) then minimum dust is still worth below $1.
On L1, on-chain, I usually don't bother sending such small amounts anymore anyway. Maybe the core devs will lower the dust limit or the default dust limit in the future, they did it before when the "reasonable" small transaction was 0.01 BTC, then it became 0.001 BTC.
People do pay $5 in order to send $100 to other countries using whatever traditional fiat remittance service they can find but only because they don't know there are cheaper or more efficient ways now. Western Union or whatever bank is what they know.
On L1, on-chain, I usually don't bother sending such small amounts anymore anyway. Maybe the core devs will lower the dust limit or the default dust limit in the future, they did it before when the "reasonable" small transaction was 0.01 BTC, then it became 0.001 BTC.
People do pay $5 in order to send $100 to other countries using whatever traditional fiat remittance service they can find but only because they don't know there are cheaper or more efficient ways now. Western Union or whatever bank is what they know.
I don't really expect it to happen if the block size stays the same.
Depends on how widespread adoption you imagine in the future, I suppose.I just don't see many people investing reserving $18,000 to buy coffee for the next 10 years.
An analogy. I'm not suggesting I have a "coffee only" channel, but rather a channel I can open, close, rebalance, etc., a couple of times a year and use for daily spending. While regular on-chain transactions need to be cheap for small value transactions to still be viable, on-chain Lightning channel transactions don't need to be that cheap because they can scale. $5 for 1 transaction is too much; $5 for 1000 transactions is absolutely fine. 
but the question would be what to do if / when the minimum transaction size will be too large for everyday transactions or the minimum transaction fee of 1sat/vB will be in the dozens of dollars or something like that.
1 sat/vB limitation only enforced by node, not by Bitcoin protocol. It can be solved easily by changing default minimum relay fee on Bitcoin full node implementation. But if 1 sat is deemed expensive for transaction fee, a fork will be needed.
I miss those days when I could broadcast up to 1000 byte with 0 fee, as long as one of the inputs was "mature" enough to qualify. I think it was called "medium priority" in Bitcoin Core, when destroying a certain number of coin days.
At that time, people are lucky since miner still following Bitcoin Qt behavior to include fee-less transaction under certain condition. These days, miner simply prioritize profit.
LN can't really work if opening and closing a channel is very expensive, unless most people accept custodial wallets.
That's of little matter, in my opinion. What's making Lightning difficult is liquidity issues. First off, you can't just have one channel; routing will fail often. So, you need bunch of channels to lower those chances. How much money in each? The more the better. Open channels with who? Preferably with a large entity to lower the chances of routing fails and of insufficient liquidity. If you receive your salary on the same channel, that could work indeed. I just don't see many people investing $18,000 to buy coffee for the next 10 years.
If you don't want coffee, close the channel. If you don't want to close the channel, buy something else instead of coffee. You don't invest into anything neither literally nor figuratively. 
I'm sure it will happen eventually, but there is no need for it at the moment.
I don't really expect it to happen if the block size stays the same. I miss those days when I could broadcast up to 1000 byte with 0 fee, as long as one of the inputs was "mature" enough to qualify. I think it was called "medium priority" in Bitcoin Core, when destroying a certain number of coin days.Quote
Also, a good reply from Pieter Wuille about this here: https://bitcoin.stackexchange.com/a/100862
It's the first time I read about fees being spam protection against using the Bitcoin network as "cheap global broadcast system". I always thought it's only related to on-chain spam.Quote
Sure, but while I wouldn't be willing to pay $5 as a fee to buy a $5 coffee with an on-chain transaction, I'd be happy enough to spend $5 on a fee to open a Lightning channel which would let me buy a $5 coffee every day for the next 10 years.
If you receive your salary on the same channel, that could work indeed. I just don't see many people A couple of years ago I read about the plan to lower the minimum fee to 0.1 sat/vbyte, but then fees went up again and it didn't happen.
Yeah, it's been discussed before: https://github.com/bitcoin/bitcoin/pull/13922I'm sure it will happen eventually, but there is no need for it at the moment.
Also, a good reply from Pieter Wuille about this here: https://bitcoin.stackexchange.com/a/100862
LN can't really work if opening and closing a channel is very expensive, unless most people accept custodial wallets.
Sure, but while I wouldn't be willing to pay $5 as a fee to buy a $5 coffee with an on-chain transaction, I'd be happy enough to spend $5 on a fee to open a Lightning channel which would let me buy a $5 coffee every day for the next 10 years. This is another topic, but it's an interesting one. I'm sure we have a dedicated thread for this, but the question would be what to do if / when the minimum transaction size will be too large for everyday transactions or the minimum transaction fee of 1sat/vB will be in the dozens of dollars or something like that.
A couple of years ago I read about the plan to lower the minimum fee to 0.1 sat/vbyte, but then fees went up again and it didn't happen.Quote
An easy answer would be that most transactions will be on some sort of off-chain network like Lightning or a sidechain of Bitcoin, but maybe there will be a softfork which allows to send smaller amounts and use lower fees (maybe in mSat denomination). But nobody knows yet; we can only discuss and introduce our ideas and suggestions to the developers whenever the topic / issue gets tangible.
LN can't really work if opening and closing a channel is very expensive, unless most people accept custodial wallets. This is another topic, but it's an interesting one. I'm sure we have a dedicated thread for this, but the question would be what to do if / when the minimum transaction size will be too large for everyday transactions or the minimum transaction fee of 1sat/vB will be in the dozens of dollars or something like that.
An easy answer would be that most transactions will be on some sort of off-chain network like Lightning or a sidechain of Bitcoin, but maybe there will be a softfork which allows to send smaller amounts and use lower fees (maybe in mSat denomination). But nobody knows yet; we can only discuss and introduce our ideas and suggestions to the developers whenever the topic / issue gets tangible.
The thing about fees is that they is set partly based on the price. For example in early days when the price was less than a dollar the fees were super high and at a fixed amount like 0.01BTC. Then suddenly it decreased a couple of times as the price went up and people were paying fixed 10k satoshis. As blocks were filled we started calculating them based on the size (sat/vb). It is reasonable to think in the future with drastic price rises we are going to decrease it further and start paying fraction of a satoshi per vbyte.An easy answer would be that most transactions will be on some sort of off-chain network like Lightning or a sidechain of Bitcoin, but maybe there will be a softfork which allows to send smaller amounts and use lower fees (maybe in mSat denomination). But nobody knows yet; we can only discuss and introduce our ideas and suggestions to the developers whenever the topic / issue gets tangible.
Keep in mind that with or without LN the on-chain fees are always going to be an important factor and they need to remain reasonable otherwise it will hurt bitcoin's utility.
'Ten years ago dust, now a fortune'
And half the fortune will be spend on fees.An easy answer would be that most transactions will be on some sort of off-chain network like Lightning or a sidechain of Bitcoin, but maybe there will be a softfork which allows to send smaller amounts and use lower fees (maybe in mSat denomination). But nobody knows yet; we can only discuss and introduce our ideas and suggestions to the developers whenever the topic / issue gets tangible.
And half the fortune will be spend on fees.
Maybe. Or maybe in the future the minimum fee rate is 1 sat/kvB rather than 1 sat/vB. Who knows? 
294 sats is the lowest transaction that the Bitcoin Core software can accept and less of it is considered a dust transaction, but does not mean that it is the lowest transaction that can be broadcast in the network?! 
294 sats is the smallest segwit output which Bitcoin Core will accept by default. It is defined here, in sats/kvB: https://github.com/bitcoin/bitcoin/blob/623745ca74cf3f54b474dac106f5802b7929503f/src/policy/policy.h#L54Code:
static const unsigned int DUST_RELAY_TX_FEE = 3000;
Given an average segwit output could be spent in a minimum of 98 vbytes, then 98*3 = 294 sats.
However, nodes are free to change this limit if they want, and accept transactions which create much smaller outputs. They probably wouldn't be able to broadcast that transaction to other nodes (the majority of which use the default limit), but any miner using such a node to build a block would see such a transaction and would be free to include it. As I said above, such transaction are non-standard but are still perfectly valid.
but does not mean that it is the lowest transaction that can be broadcast in the network?!
It could happen, but it's not very likely. Even if you connect to a node that accepts a lower dust limit, that node will also have the same problem so it can't propagate it to other nodes. 
Now we know that the lowest accepted value for segwit addresses is 294 sats.
I don't know, but since the term "dust TX" is client-specific and not network protocol, the statement above cannot be accurate.
294 sats is the lowest transaction that the Bitcoin Core software can accept and less of it is considered a dust transaction, but does not mean that it is the lowest transaction that can be broadcast in the network?!
Overall, thanks for proving that such tx can be broadcast.
'Ten years ago dust, now a fortune'
And half the fortune will be spend on fees.Quote
But I support the 'half a day VPN' idea.
Quote
I tested if 17 segwit dusts can be sent together, it worked.
Do the same to your legacy dust Quote
Think of it as the 18 dusts from the legacy addresses, sent as segwit dusts.
That is what I expected, but it hasn't moved yet. I thought c7298be8c111422fd0bc3915d67451ea24fba9b3529126e4bf39ca5db94370ba was from you, but now I'm not sure anymore.
@LoyceV
I wanted to repeat the same test in 10 years and want to use these addresses. And the title of the test will be:
'Ten years ago dust, now a fortune'
But I support the 'half a day VPN' idea. One segwit dust was sent to bc1qwpc320c70sz7mf7v6vyu5v7lzjv3hlsa23d8ew, now I tested if 17 segwit dusts can be sent together, it worked. Think of it as the 18 dusts from the legacy addresses, sent as segwit dusts.
I wanted to repeat the same test in 10 years and want to use these addresses. And the title of the test will be:
'Ten years ago dust, now a fortune'
But I support the 'half a day VPN' idea. One segwit dust was sent to bc1qwpc320c70sz7mf7v6vyu5v7lzjv3hlsa23d8ew, now I tested if 17 segwit dusts can be sent together, it worked. Think of it as the 18 dusts from the legacy addresses, sent as segwit dusts.
EDIT (2):
)
Lol, I thought the dust transaction would have been related to this topic. If I get another dust inputs, I can use them to buy half a day VPN To complete the test, you should do the same to a Bech32 address...
Tested it with a TX to the address bc1qwpc320c70sz7mf7v6vyu5v7lzjv3hlsa23d8ew (from a nice bitcointalk user ) 
I recall from an earlier post though, that had Bitcoin source code in it that the 294-byte minimum segwit size applied at a 3000 sats/KB fee rate (i.e. 3 sats/byte). I am curious to figure out whether this minimum size would be even smaller if the fee sent was just 1 sat/byte (ditto for the legacy transactions).
It has nothing to do with the fee rates of a transaction.The fees as stated in the code is actually referring to the dust relay fee instead of the actual transaction fee. This is a user-configurable parameter but the standard is kept at 3sat/byte to maintain the 546sat dust limit that was before the introduction of this dust relay fee. But yes, if the user changes the dust relay fee, then their node would see a different dust limit.
Interesting!
This made me think of Muun, since they support lightning through submarine swaps, and in theory all your sats are on-chain:
I tested with a 293 sats invoice and it went through perfectly fine.
I'm not really sure what is actually happening behind the scenes though.
This made me think of Muun, since they support lightning through submarine swaps, and in theory all your sats are on-chain:
Regarding the lightning aspect of the recovery process, Muun uses super optimized submarine swaps to execute the lightning payments, both incoming and outgoing. This means that your funds are on-chain and thus recoverable by the mechanism I just described.
I tested with a 293 sats invoice and it went through perfectly fine.
I'm not really sure what is actually happening behind the scenes though.
Most likely, the Lightning node is combining the final amount in the contract (your invoice) with its own sats to at least meet the minimum L1 tx size.
I recall from an earlier post though, that had Bitcoin source code in it that the 294-byte minimum segwit size applied at a 3000 sats/KB fee rate (i.e. 3 sats/byte). I am curious to figure out whether this minimum size would be even smaller if the fee sent was just 1 sat/byte (ditto for the legacy transactions).
~snip~
Now we know that the lowest accepted value for segwit addresses is 294 sats.
Now we know that the lowest accepted value for segwit addresses is 294 sats.
Interesting!
This made me think of Muun, since they support lightning through submarine swaps, and in theory all your sats are on-chain:
Regarding the lightning aspect of the recovery process, Muun uses super optimized submarine swaps to execute the lightning payments, both incoming and outgoing. This means that your funds are on-chain and thus recoverable by the mechanism I just described.
I tested with a 293 sats invoice and it went through perfectly fine.
I'm not really sure what is actually happening behind the scenes though.
Jump to: