Dust threshold changed without any mention in 0.11.1

[Hyena]

The same can be applied to Bitcoin; abusing the system because you can afford to pay the fines does not make it OK and should be discouraged.

There's a difference between a fine and a fee you know. Bitcoin has fees. University had fines. You can't compare these two.

Who are you to dictate what is proper and what is not anyway? With the university it is at least explicit that the girl was doing the wrong thing. Can't say the same about bitcoin.

By the way, all normal money transferring methods allow you to attach a message to the payment. Bitcoin failed to provide such capabilities as a built-in feature. It makes so much sense to encode payment details in the bitcoin transaction and it isn't even wrong. How on Earth can you call encoding payment details in bitcoin TX an abusive behaviour when ALL BANKS ALLOW THIS on their centralized ledgers. That's it. My last sentence just demolished all arguments of any opponent to encoding payment details in the BTC TXs.

[achow101]

By the way, all normal money transferring methods allow you to attach a message to the payment. Bitcoin failed to provide such capabilities as a built-in feature. It makes so much sense to encode payment details in the bitcoin transaction and it isn't even wrong. How on Earth can you call encoding payment details in bitcoin TX an abusive behaviour when ALL BANKS ALLOW THIS on their centralized ledgers. That's it. My last sentence just demolished all arguments of any opponent to encoding payment details in the BTC TXs.

BIP70 which is for payment requests, allows both the customer and the merchant to attach memos to payments, although I don't think that these memos will be stored in the blockchain. However, AFAIK those memos do stay where you really need them, in your wallet. You don't need (or want) everyone to know what you were spending your Bitcoin on, which is what encoding those memos into transactions in the blockcahin would do.

[Hyena]

By the way, all normal money transferring methods allow you to attach a message to the payment. Bitcoin failed to provide such capabilities as a built-in feature. It makes so much sense to encode payment details in the bitcoin transaction and it isn't even wrong. How on Earth can you call encoding payment details in bitcoin TX an abusive behaviour when ALL BANKS ALLOW THIS on their centralized ledgers. That's it. My last sentence just demolished all arguments of any opponent to encoding payment details in the BTC TXs.

BIP70 which is for payment requests, allows both the customer and the merchant to attach memos to payments, although I don't think that these memos will be stored in the blockchain. However, AFAIK those memos do stay where you really need them, in your wallet. You don't need (or want) everyone to know what you were spending your Bitcoin on, which is what encoding those memos into transactions in the blockcahin would do.

Ok that's cool, but are the memos cryptographically signed? Is it easy to verify that the text is written by the person who sent the bitcoins?

[achow101]

By the way, all normal money transferring methods allow you to attach a message to the payment. Bitcoin failed to provide such capabilities as a built-in feature. It makes so much sense to encode payment details in the bitcoin transaction and it isn't even wrong. How on Earth can you call encoding payment details in bitcoin TX an abusive behaviour when ALL BANKS ALLOW THIS on their centralized ledgers. That's it. My last sentence just demolished all arguments of any opponent to encoding payment details in the BTC TXs.

BIP70 which is for payment requests, allows both the customer and the merchant to attach memos to payments, although I don't think that these memos will be stored in the blockchain. However, AFAIK those memos do stay where you really need them, in your wallet. You don't need (or want) everyone to know what you were spending your Bitcoin on, which is what encoding those memos into transactions in the blockcahin would do.

Ok that's cool, but are the memos cryptographically signed? Is it easy to verify that the text is written by the person who sent the bitcoins?

The whole request can be cryptographically signed with a X.509 certificate, but are not required to be.

You can read the full details of the bip at https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

[Hyena]

The whole request can be cryptographically signed with a X.509 certificate, but are not required to be.

You can read the full details of the bip at https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

I think I remember when this was added and I was strongly against it since I don't think HTTPS should ever be relied on.

This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.

Everything in the above quote is utterly wrong and against my philosophy.

In my opinion, such messages should be exclusively deliver over the Bitcoin's own network, signed by the private keys of the sender's bitcoins, and perhaps encrypted using the message receiver's public key (PGP over Bitcoin). Is it technically possible? I don't know, but it should be, since Bitcoin utilizes PKI and PGP is based on that.

[onemorexmr]

The whole request can be cryptographically signed with a X.509 certificate, but are not required to be.

You can read the full details of the bip at https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

I think I remember when this was added and I was strongly against it since I don't think HTTPS should ever be relied on.

This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.

Everything in the above quote is utterly wrong and against my philosophy.

In my opinion, such messages should be exclusively deliver over the Bitcoin's own network, signed by the private keys of the sender's bitcoins, and perhaps encrypted using the message receiver's public key (PGP over Bitcoin). Is it technically possible? I don't know, but it should be, since Bitcoin utilizes PKI and PGP is based on that.

to cite yourself:

Who are you to dictate what is proper and what is not anyway?

IMHO creating unspendable outputs and bloating the UTXO is bad. it puts a burden for everyone and forever. no fee can cover that.

[Hyena]

to cite yourself:

Who are you to dictate what is proper and what is not anyway?

IMHO creating unspendable outputs and bloating the UTXO is bad. it puts a burden for everyone and forever. no fee can cover that.

good boy. That's why the acronym IMHO was invented now it's solely your opinion. You're no longer a dictator and thus I can respect your opinion since now we're equal.

[onemorexmr]

to cite yourself:

Who are you to dictate what is proper and what is not anyway?

IMHO creating unspendable outputs and bloating the UTXO is bad. it puts a burden for everyone and forever. no fee can cover that.

good boy. That's why the acronym IMHO was invented now it's solely your opinion. You're no longer a dictator and thus I can respect your opinion since now we're equal.

the difference is: i stated my opinion but you are acting according to your opinion and force it to everyone.

[Hyena]

the difference is: i stated my opinion but you are acting according to your opinion and force it to everyone.

aren't you acting according your opinion too? besides, I don't force anything on anyone. Feel free to not relay the TXs you don't like. Or perhaps, if you're a miner, feel free to not confirm them.

[achow101]

The whole request can be cryptographically signed with a X.509 certificate, but are not required to be.

You can read the full details of the bip at https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

I think I remember when this was added and I was strongly against it since I don't think HTTPS should ever be relied on.

This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.

Everything in the above quote is utterly wrong and against my philosophy.

In my opinion, such messages should be exclusively deliver over the Bitcoin's own network, signed by the private keys of the sender's bitcoins, and perhaps encrypted using the message receiver's public key (PGP over Bitcoin). Is it technically possible? I don't know, but it should be, since Bitcoin utilizes PKI and PGP is based on that.

I agree that all of the messages should be signed by the message sender's private key to ensure that the message isn't modified between the consumer and the merchant. E.g. the request from the merchant is signed by one of the addresses in the output section, the payment from the consumer is signed with one of the addresses used in the payment transaction, and the paymentACK from the merchant is signed with the same key as the first message.

Regarding the http/https, I think that was a good choice since that is an existing protocol which provides some privacy and direct connection between two computers instead of flooding the network like transactions do. Although the choice of X.509 certificates for signing is questionable, I can also understand that because those have names associated with them.

Perhaps you (or maybe I, if I have enough time) can write some code to add such things to the payment protocol and submit at PR.

[Hyena]

I agree that all of the messages should be signed by the message sender's private key to ensure that the message isn't modified between the consumer and the merchant. E.g. the request from the merchant is signed by one of the addresses in the output section, the payment from the consumer is signed with one of the addresses used in the payment transaction, and the paymentACK from the merchant is signed with the same key as the first message.

Regarding the http/https, I think that was a good choice since that is an existing protocol which provides some privacy and direct connection between two computers instead of flooding the network like transactions do. Although the choice of X.509 certificates for signing is questionable, I can also understand that because those have names associated with them.

Perhaps you (or maybe I, if I have enough time) can write some code to add such things to the payment protocol and submit at PR.

Why would we need HTTPS if bitcoin already has the concept of public and private keys in itself? Instead of a HTTPS certificate you would use the other party's public key and you would get it directly from the block chain, so its integrity is automatically guaranteed. What is more, currently the merchant has to have a static IP address. It's a remnant from the old and centralized way of internetting. We don't need this client<-->server concept any more. The nodes should be able to talk to each other directly, from behind ISP firewalls with their ports closed and what not.

[achow101]

I agree that all of the messages should be signed by the message sender's private key to ensure that the message isn't modified between the consumer and the merchant. E.g. the request from the merchant is signed by one of the addresses in the output section, the payment from the consumer is signed with one of the addresses used in the payment transaction, and the paymentACK from the merchant is signed with the same key as the first message.

Regarding the http/https, I think that was a good choice since that is an existing protocol which provides some privacy and direct connection between two computers instead of flooding the network like transactions do. Although the choice of X.509 certificates for signing is questionable, I can also understand that because those have names associated with them.

Perhaps you (or maybe I, if I have enough time) can write some code to add such things to the payment protocol and submit at PR.

Why would we need HTTPS if bitcoin already has the concept of public and private keys in itself? Instead of a HTTPS certificate you would use the other party's public key and you would get it directly from the block chain, so its integrity is automatically guaranteed. What is more, currently the merchant has to have a static IP address. It's a remnant from the old and centralized way of internetting. We don't need this client<-->server concept any more. The nodes should be able to talk to each other directly, from behind ISP firewalls with their ports closed and what not.

I was talking about https in regards to the method of transporting data, not the private keys. The X.509 certificates seems kinda silly and I agree with you. The only problem is verifying that that public key/certificate belongs to the right person.

While yes the merchant needs a static IP/Domain Name, how else would you get data to and from computers without rewriting the internet? How would nodes communicate without using this system.

[Nicolas Dorier]

Using Bitcoin for other than monetary purpose is not abuse if you are willing to pay the price. (may it be either in fees or in dust)
You can't abuse Bitcoin anyway. Some tried, did not worked so much.

Ah, this reminds me of a girl at the university who came from a very wealthy family and thought that some rules did not apply to her. There was a reserved parking area which she did not hold a permit for, but she parked there anyway. She would pay her fines and repeat the offense. This went on for quite some time before the university was fed up and made it a point to tow the vehicles of repeate offenders.

The purpose of the reserved lot wasn’t there to bring in additional revenue for the university from those who can afford to violate the rules and pay the fines. It was there to serve the needs of those who were designated to use it.

The same can be applied to Bitcoin; abusing the system because you can afford to pay the fines does not make it OK and should be discouraged.

No. It is not the same. The moral authority which define abuse in your parking lot is the law.
Every use of the Blockchain is valid as long as you can pay for it, if you don't want money to be the authority, then someone (or an oligarchy) will need to be the authority there is no other choice.

I would say, what I do with the blockchain is nobody's business. It should be noted that one can judge whether I'm "abusing or not" in their view, precisely because scripts and amount are not confidential. Which, we will agree, is more a bug than a feature. If I am abusing by what they judge a bad use case, then they should go ahead and lobbying the miners to not accept my transaction, not relay it, or rise required fees, in other words, made me pay more either by inconvenience or fees. Fee and not relaying are the most efficient way for you to make me feel the pain though.

[hhanh00]

No. It is not the same. The moral authority which define abuse in your parking lot is the law.
Every use of the Blockchain is valid as long as you can pay for it, if you don't want money to be the authority, then someone (or an oligarchy) will need to be the authority there is no other choice.

I would say, what I do with the blockchain is nobody's business. It should be noted that one can judge whether I'm "abusing or not" in their view, precisely because scripts and amount are not confidential. Which, we will agree, is more a bug than a feature. If I am abusing by what they judge a bad use case, then they should go ahead and lobbying the miners to not accept my transaction, not relay it, or rise required fees, in other words, made me pay more either by inconvenience or fees. Fee and not relaying are the most efficient way for you to make me feel the pain though.

It's simply not economical to do so. Look at the service that the OP offers. It adds a tiny overhead to the blockchain. In theory, it shouldn't be done but the effect is negligible. Now some coins want to piggy back their entire load on the blockchain, that's another story.
They probably think it's brilliant and great that they could build something out of the few opcodes offered by bitcoin. In my opinion, it is like building a cathedral out of
matches: Amazing yes, but not optimal. They should build their own system and have what they need baked in. Bitcoin should remain a distributed way to
transfer currency - not assets - not colored coins - not storage - etc. Not that they aren't valid applications, but because they use resources in a system that was not designed
to do that efficiently.

[Hyena]

While yes the merchant needs a static IP/Domain Name, how else would you get data to and from computers without rewriting the internet? How would nodes communicate without using this system.

Take I2P or Tor network for example. It's possible. From the merchant's point of view, a publicly accessible server is a huge security threat. I have developed all my bitcoin applications in a way that the most critical infrastructure is in my laptop behind a firewall and "hidden" from the public. Not to mention that domain hosting costs money and that your hosting provider could go rogue and hijack your service.

I would propose functionality to be added to the Bitcoin's protocol that allows storing payment details in the Bitcoin's block chain for a month (or some other period of time). When the payment details expire nodes can purge them from their copy of the block chain to save space. The merchant has 30 days to turn on their bitcoin node and fetch the payment details from the block chain. Those details should be signed by the payer's private key and encrypted with the payee's public key.

[achow101]

I would propose functionality to be added to the Bitcoin's protocol that allows storing payment details in the Bitcoin's block chain for a month (or some other period of time). When the payment details expire nodes can purge them from their copy of the block chain to save space. The merchant has 30 days to turn on their bitcoin node and fetch the payment details from the block chain. Those details should be signed by the payer's private key and encrypted with the payee's public key.

I think that is a good idea, but the problem is that in the initial payment request, the merchant has no way to know who (identity or bitcoin address) is sending them the bitcoin. They should definitely sign the request, but encrypting it is not possible without knowing the other party's public key, which is hard to know without knowing who is paying and public keys are not revealed until they sign a transaction.

[dexX7]

Hey Hyena,

to some degree the dust threshold is relevant for a meta protocol I'm contributing to, but we tackled this quite early by using the minRelayTxFee explicitly to determine the dust threshold on the fly (based on the user's "minrelaytxfee" setting and script size). The minRelayTxFee is exposed via the RPC "getnetworkinfo".

Here is a snippet, which may be useful:

Code:

/**
 * Determines the minimum output amount to be spent by an output, based on the
 * scriptPubKey size in relation to the minimum relay fee.
 *
 * @param scriptPubKey[in]  the scriptPubKey
 * @param minRelayTxFee[in] the minimum relay fee
 * @return the dust threshold value
 */
int64_t GetDustThreshold(const CScript& scriptPubKey, const CFeeRate& minRelayTxFee)
{
    // The total size is based on a typical scriptSig size of 148 byte,
    // 8 byte accounted for the size of output value and the serialized
    // size of scriptPubKey.
    size_t nSize = ::GetSerializeSize(scriptPubKey, SER_DISK, 0) + 156;

    // The minimum relay fee dictates a threshold value under which a
    // transaction won't be relayed.
    int64_t nRelayTxFee = minRelayTxFee.GetFee(nSize);

    // A transaction is considered as "dust", if less than 1/3 of the
    // minimum fee required to relay a transaction is spent by one of
    // it's outputs. The minimum relay fee is defined per 1000 byte.
    return nRelayTxFee * 3;
}

Or alternatively, check out GetDustThreshold() from Bitcoin Core.

In practise this means:

Code:

With minrelayfee=0.00001 (old default):

- Pay-to-pubkey-hash (34 byte): 0.00000546 BTC
- Multisig, two compressed public keys (80 byte): 0.00000684 BTC
- Multisig, one compressed, one uncompressed public key (112 byte): 0.00000780 BTC
- Multisig, three compressed public keys (114 byte): 0.00000786 BTC
- Multisig, one uncompressed, two compressed public keys (146 byte): 0.00000882 BTC

Code:

With minrelayfee=0.00005 (new, temporary default):

- Pay-to-pubkey-hash (34 byte): 0.00002730 BTC
- Multisig, two compressed public keys (80 byte): 0.00003420 BTC
- Multisig, one compressed, one uncompressed public key (112 byte): 0.00003900 BTC
- Multisig, three compressed public keys (114 byte): 0.00003930 BTC
- Multisig, one uncompressed, two compressed public keys (146 byte): 0.00004410 BTC

The already merged pull request Limit mempool by throwing away the cheapest txn and setting min relay fee to it #6722 (GitHub) resets the minRelayTxFee to the old default, and even though it introduces the notion of a floating relay fee, the dust threshold remains to be static. However, I wouldn't bet that this remains to be true in the future, and I could imagine the dust threshold becomes floating, too.

[Hyena]

Hey Hyena,

to some degree the dust threshold is relevant for a meta protocol I'm contributing to, but we tackled this quite early by using the minRelayTxFee explicitly to determine the dust threshold on the fly (based on the user's "minrelaytxfee" setting and script size). The minRelayTxFee is exposed via the RPC "getnetworkinfo".

...

The already merged pull request Limit mempool by throwing away the cheapest txn and setting min relay fee to it #6722 (GitHub) resets the minRelayTxFee to the old default, and even though it introduces the notion of a floating relay fee, the dust threshold remains to be static. However, I wouldn't bet that this remains to be true in the future, and I could imagine the dust threshold becomes floating, too.

Thanks for the info. getnetworkinfo RPC is probably the way to go for a bitcoin application that somehow depends on the minRelayTxFee parameter.

I like the idea of a floating tx fee. The dust threshold should be made irrelevant if the tx fee is calculated from the tx size. If the mempool gets full it makes sense to start throwing out the tx-s with cheapest fee-to-size ratio.

[Nicolas Dorier]

No. It is not the same. The moral authority which define abuse in your parking lot is the law.
Every use of the Blockchain is valid as long as you can pay for it, if you don't want money to be the authority, then someone (or an oligarchy) will need to be the authority there is no other choice.

I would say, what I do with the blockchain is nobody's business. It should be noted that one can judge whether I'm "abusing or not" in their view, precisely because scripts and amount are not confidential. Which, we will agree, is more a bug than a feature. If I am abusing by what they judge a bad use case, then they should go ahead and lobbying the miners to not accept my transaction, not relay it, or rise required fees, in other words, made me pay more either by inconvenience or fees. Fee and not relaying are the most efficient way for you to make me feel the pain though.

It's simply not economical to do so. Look at the service that the OP offers. It adds a tiny overhead to the blockchain. In theory, it shouldn't be done but the effect is negligible. Now some coins want to piggy back their entire load on the blockchain, that's another story.
They probably think it's brilliant and great that they could build something out of the few opcodes offered by bitcoin. In my opinion, it is like building a cathedral out of
matches: Amazing yes, but not optimal. They should build their own system and have what they need baked in. Bitcoin should remain a distributed way to
transfer currency - not assets - not colored coins - not storage - etc. Not that they aren't valid applications, but because they use resources in a system that was not designed
to do that efficiently.

How exactly do you make reasonable self enforcing contract (terms I prefer opposed to "smart contract") pegged on a fiat currency without bitcoin ? Another blockchain ? great, but not so sure it will be as self enforced, nor as well reviewed, nor with as good ecosystem, nor with as good documentation as Bitcoin.

Not that they aren't valid applications, but because they use resources in a system that was not designed to do that efficiently.

Analog phone system was not designed to service internet. The fact that it was not designed for it does not mean that there existed, at the time, any better alternative for it. We lived with it for a long time.
Sure better way of transferring fiat thant he blockchain are theorically possible, but we are resolving problem of today with solution of today. Not problem of today with solution of tomorrow.

If indeed, your judgment is right, then just look at the match cathedral scramble by the inevitable competition who will take out the least efficient one.
Or maybe colored coin company will just pivot to another blockchain, which is also fine. But right now there are use cases where bitcoin, even if not designed for it, is the best solution.

I hope that Blockstream's Elements will provide better way of doing things. But we can't build product on top of hypothetical solution of the future.

Once again, I understand what the Dust is about now, I am not bragging because it is not good to colored coin. I'm just bragging because changing the txMinRelayFee suddently broke everything, and not only colored coins, but every piece of software creating a transaction. Not to say it should not have been done. I just want more consideration about those actions. This had more impact than a hardfork for every services built on bitcoin.

[hhanh00]

The problem is that what one person sees as improvement (such as self enforcing contract, notes, etc.) another will consider undesirable.

If the system was centralized or if everyone involved was getting paid, it would be easier to regulate.
However, with Bitcoin only miners are paid. All the node relays are working for free, mostly because they want to be part of the movement (of course there are
other reasons but nowadays we have solutions that doesn't involve running a full node). These days, it's getting increasingly harder to do so and the number of
full nodes keep going down. I suppose that some will say that centralization towards miners is unavoidable and if accelerating it is the cost of having more features then so be it - but what if it ends up killing Bitcoin before better solutions come around?

Analog phone system was not designed to service internet. The fact that it was not designed for it does not mean that there existed, at the time, any better alternative for it. We lived with it for a long time.

What people do with their phone line is up to them since they pay for the charge and it doesn't really affect anyone. What we are talking about would be more like paying a bus fare and carrying a bicycle. It's not forbidden but if a lot of people were doing it, the other users would be unhappy.

Once again, I understand what the Dust is about now, I am not bragging because it is not good to colored coin. I'm just bragging because changing the txMinRelayFee suddently broke everything, and not only colored coins, but every piece of software creating a transaction. Not to say it should not have been done. I just want more consideration about those actions. This had more impact than a hardfork for every services built on bitcoin.

I agree. In general, I wish it was possible to have more implementations out there so that changing the behavior of Bitcoin Core would not have such impact.