Print Page - Dust threshold changed without any mention in 0.11.1

Thanks a lot bitcoin developers for screwing my application by changing the minimum output amount YET AGAIN. You should have at least mentioned it in the changelog or under the notable changes section:
https://bitcoin.org/en/release/v0.11.1

That's right, instead of 540 satoshis the bitcoin-core now won't allow outputs smaller than 2730 satoshis. This is starting to piss me off because every time you change it I must also change my program logic. If you have to do it then at least make it possible to request the current minimal dust threshold with an RPC.

Since this is such a bullshit change, I hereby spawn a parallel conversation: should developers not upgrade their bitcoin-core to 0.11.1 because of this? So that we could still make smaller output transactions? OR perhaps I should modify the source code of bitcoin-core to deliberately allow smaller amounts. It's up to miners anyway, so stop putting this crap into bitcoin-core if it can be so easily evaded.

The code in question is here -> https://github.com/bitcoin/bitcoin/blob/ad57b310bac44a7e470cf66276421f2bbc61b1f0/src/primitives/transaction.h#L155

Code:

    CAmount GetDustThreshold(const CFeeRate &minRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::minRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical spendable txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend:
        // so dust is a spendable txout less than 546 satoshis
        // with default minRelayTxFee.
        if (scriptPubKey.IsUnspendable())
            return 0;

        size_t nSize = GetSerializeSize(SER_DISK,0)+148u;
        return 3*minRelayTxFee.GetFee(nSize);
    }

As knightdk said you can set the value yourself in your bitcoin.conf file.

Quote from: Hyena on October 20, 2015, 01:44:46 PM

Quote from: knightdk on October 20, 2015, 01:00:23 PM

The dust threshold is not hard coded. It is determined by the minrelaytxfee. The dust threshold changes with what is set as the minrelaytxfee, so you can set the minrelaytxfee in your own node to the original default of 0.00001 instead of the new default of 0.00005. That will change your dust threshold.

This seemed to provide a solution to my problem. Any ideas what the default minrelaytxfee was in 0.11.0 ? When I set it to 0.00000001 the minimal amount I was able to send was 3 satoshis. How to get 546 as it was in previous version?

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

Quote from: shorena on October 20, 2015, 01:50:39 PM

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

You're right. With that old default of 0.00001, the minimum output size is 0.00000546 satoshis. Now this leads to me a tough question -- how to determine the smallest possible value for that parameter that is still safe to use in a sense that neighbouring nodes will relay it. Is 0.00001 still safe to use? How long will it be safe to use? What's the best practice for developers when solving this problem?

Quote from: Hyena on October 20, 2015, 01:56:55 PM

Quote from: shorena on October 20, 2015, 01:50:39 PM

Old default is 0.00001 its given per 1000 bytes. The algorithm assumes a TX size of 182 bytes and multiplies by 3.

Code:

182 * 3 * 1000(Satoshi)/1000(byte) = 546 satoshi (dust)

with the modified default minrelaytxfee 0.00005 its

Code:

182 * 3 * 5000(Satoshi)/1000(byte) = 2730 satoshi (dust)

I would guess that for now 0.00005 is over the top. I had to increase it because the spam caused my node to crash, but its running fine with 0.00002 (twice the old default). Its also not very powerful (2GB single core VPS). I cant tell you for how long 0.00005 will work or even how many are running the default config.

0.11.1 is pretty common for the short time its out though, 12.8% according to -> https://bitnodes.21.co/dashboard/?days=365

Quote from: shorena on October 20, 2015, 02:12:02 PM

I guess it's a tough problem then. I need a programmatic solution. So that the program could detect and overcome the issue of nodes not relaying its transactions. For now 0.00001 should work but if it suddenly stops working in the future then I will get in trouble. How would you go about it? If the TX has not been confirmed in 60 minutes then somehow withdraw it, increase the fee and make a whole new TX? Actually I wouldn't be able to make a new TX because it will probably require more funds than initially planned. Has anyone else thought of this?

Quote from: Hyena on October 20, 2015, 03:02:33 PM

Quote from: shorena on October 20, 2015, 02:12:02 PM

Is it about the fee or do you need as small as possible outputs? IMHO the fee is best handled by core directory with

Quote

estimatefee nblocks

Estimates the approximate fee per kilobyte
needed for a transaction to begin confirmation
within nblocks blocks.

Arguments:
1. nblocks (numeric)

Result:
n : (numeric) estimated fee-per-kilobyte

-1.0 is returned if not enough transactions and
blocks have been observed to make an estimate.

Example:
> bitcoin-cli estimatefee 6

and

Quote

estimatepriority nblocks

Estimates the approximate priority
a zero-fee transaction needs to begin confirmation
within nblocks blocks.

Arguments:
1. nblocks (numeric)

Result:
n : (numeric) estimated priority

-1.0 is returned if not enough transactions and
blocks have been observed to make an estimate.

Example:
> bitcoin-cli estimatepriority 6

If you need as small as possible outputs I dont have a real solution, besides get in touch with a miner and see that you can pitch the TX directly to them.

Hyena, please be more vocal next time before the fact.

I whined alone about it before the drama happened : https://github.com/bitcoin/bitcoin/pull/6793 (https://github.com/bitcoin/bitcoin/pull/6793)
Quoting myself :

Quote

I'm just a bit down to be hit collaterally by a good idea to prevent spam. Especially when raising IsDust does not prevent spam at all. It is like we get hit, without benefit for any party, neither for spammers, you, us, or our deployed customers, pure pain without pleasure. :(

I proposed pegging dust on the fees : https://github.com/bitcoin/bitcoin/issues/6824 (https://github.com/bitcoin/bitcoin/issues/6824)

I agree with you that this is a bitch move and core devs don't care at all about it, nor about breaking stuff. (see the discussion)

Basically they tell you that you are wrong to hard code the value without giving a good way to find the dust amount without a centralized server to tell the correct value. (which is why I proposed pegging dust on the fee)

Sadly I don't code in C++ to implement my proposal, and no dev care about dust, so we'll have to handle this mess by ourselves either by using a centralized server for getting the right dust OR hard coding and redeploying everytime they change like that.
This freaking change broke every single piece of code which create a transaction... not only meta protocol, but normal wallet as well. (https://github.com/voisine/breadwallet/issues/291 (https://github.com/voisine/breadwallet/issues/291))

This suck but we'll have to live with it it seems.

Quote from: dserrano5 on October 20, 2015, 06:18:57 PM

So, worse than blow up.

That's one way to look at it. But it's still subjective. I've been in debate about it so many times. A really short counter argument would be that it's not "worse" until it increases the utility and thus the intrinsic value of bitcoin. It is worse when it is part of an attack on the bitcoin network.

Another really good point that was brought out in a previous discussion about the UTXO issue is that the Bitcoin network has to deal with it one way or another. Human moral cannot be relied on. If UTXOs are bitcoin's vulnerability then some day someone may want to exploit that vulnerability to bring the network to its knees. What is more, if I wanted to use that attack vector, I would generate the UTXO private keys deterministically so that in the end I could even get my attack money back.

Quote from: Nicolas Dorier on October 20, 2015, 04:55:18 PM

Hyena, please be more vocal next time before the fact.

What do you mean by being more vocal next time before the fact? I just discovered this mess-up yesterday the hard way. My customers lost their money because of that without getting any service. Next time I won't upgrade my bitcoin wallet, period. At least that's what I feel like doing. Obviously I will upgrade if I have to, for some really good reasons.

If you are not using the Bitcoin currency except incidentally but instead abusing the system to store data there are no promises that you're going to have a good time. It's not in the users of the system's general interest to accept an eternal data storage cost on your behalf.

As mentioned above, there is no explicit "dust threshold"-- it's determined by the minimum relay fee rate. In particular, the number "540" you were expecting was certainly never announced;-- and the change to the relay fee was absolutely release noted; and important for keeping nodes from blowing up in the short term-- yes, a somewhat lower value would have also worked but the relay fees were out of wack (adjusted predicatively down when the prices was at almost three times the current and going up) and the minimum bump might have been met immediately by the attackers (who can update their behavior much faster than people can upgrade software).

Above you write that you are creating unspendable outputs-- this is _specifically_ one abuse of the system dust threshold was intended to discourage; so it sounds like it's working as designed now.

But by all means, feel free to not upgrade your software or change its behavior... it's not the action of your own software that will inhibit you-- all it does it tell you quickly and cleanly so your transactions don't get stuck, it's the action of everyone else that inhibits the abuse. And it is quite effective, or else I suspect we wouldn't be enduring your vicious invective.

If someone is looking for a safe dust approximation without any relayfee intelligence, the original level of 5460 base units is probably a better expectation.

Quote from: gmaxwell on October 21, 2015, 07:32:57 AM

If you are not using the Bitcoin currency except incidentally but instead abusing the system to store data there are no promises that you're going to have a good time.

WTF are you talking about? What you might see as abusive is by no means an objective evaluation of the situation. Keep your petty feelings to yourself. As a core developer you should not allow yourself to give in to your emotions. It is your job to find a solution to the UTXOs because that number will increase EITHER WAY. With or without abuse.

Quote from: gmaxwell on October 21, 2015, 07:32:57 AM

and the change to the relay fee was absolutely release noted

FALSE. Stop lying in my face. When I searched the release notes there were no indication to the minrelaytxfee config parameter and the default value that might have changed as a result. It is pathetic to see you try to cover up this mess. Be an adult and admit that the release notes were lacking that info.

Quote from: gmaxwell on October 21, 2015, 07:32:57 AM

or else I suspect we wouldn't be enduring your vicious invective.

So now you're trying to put all the blame on me even though my activities have nothing to do with the fact that you missed an important part from the release notes. What is more, you fail to remain neutral and objective and again, give in to your petty childish emotions. Calling my activities vicious?! Be grateful to me for highlighting the UTXOs issue because when a malicious user starts to abuse this vulnerability you will not have a chance for a reasonable debate. I like bitcoin and I want it to evolve over time, I am willing to cooperate because I am at your side (in case you are on evolving Bitcoin's side, of course).

Quote from: knightdk on October 21, 2015, 11:04:41 AM

When the release was announced in the bitcoin-dev mailing list, the email included the information about the change of the minrelaytxfee. However, this was never mentioned in the website for some reason.

Ok fine. I'm not into pointing fingers anyway. Stuff like that happens, I'm a developer myself, I know. The monetary loss due to this was perhaps 0.5$ in my situation. And the idea of increasing the minimum acceptable output amount is also good, even though it was badly broadcast this time. I tried restarting my node with different minrelaytxfee values and the difference was humongous. With 0.00001 I had 20k unconfirmed TXs. I increased that number to 0.00003 and the number of unconfirmed TXs dropped below 10. This clearly eliminates the "stress test" attack vector on the Bitcoin's network. I hated it.

Quote from: Hyena on October 21, 2015, 10:07:32 AM

Data storage has a cost. The field you are putting bitcoin unrelated data is a public key field, it isn't Hyena's-file-sharing-field. It's used to set the rules for coins to be spent in the future. When you start cutting me a paycheck you can start dictating what my job is, but under no condition will it ever be to aid you in your quest in externalizing your data storage costs onto Bitcoin users.

Quote

Quote from: gmaxwell on October 21, 2015, 07:32:57 AM

and the change to the relay fee was absolutely release noted

Perhaps you should get control of your emotions before posting? It might help prevent you from making errors, I think release notes (https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.11.1.md) are clear on this, and it was also covered in the release candidate release notes (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011500.html).

For the avoidance of any residual confusion, let me quote from them here:

Notable changes =============== [...] Minimum relay fee default increase ------------------------------------ The default for the `-minrelaytxfee` setting has been increased from `0.00001` to `0.00005`. This is necessitated by the current transaction flooding, causing outrageous memory usage on nodes due to the mempool ballooning. This is a temporary measure, bridging the time until a dynamic method for determining this fee is merged (which will be in 0.12). (see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11 release notes, in which this value was suggested)

Not only was it covered in the 0.11.1 and 0.10.3 release notes, but the 0.11.0 notes recommend users make the same change for themselves manually.

Quote

you missed an important part from the release notes.

I await your apology with abated breath.

Quote

Quote from: gmaxwell on October 21, 2015, 07:32:57 AM

or else I suspect we wouldn't be enduring your vicious invective.

[...]
your petty childish emotions. Calling my activities vicious?!

invective (noun)
1. insulting, abusive, or highly critical language

Quote

Be grateful to me for highlighting the UTXOs issue because when a malicious user starts to abuse this vulnerability you will not have a chance for a reasonable debate.

You may be suffering confusion on this point, the dust limits are a fix and don't require having any debate with you (reasonable or otherwise); economic thresholds that discourage the creation of uneconomic to spend (or unspendable) txouts-- and were it not, you would have no cause to complain. And indeed, the protection it provides is not absolute, but it doesn't need to be. If you send hazardous materials through the post you might get caught, or you might not. But the odds are enough to provide all that is needed to keep you from harming the system. You will not be the first person to intentionally harm a shared resource to brag about how bold and brave you are for revealing issues, it's nonsense-- but also irrelevant, nodes can happily go on blocking your transactions regardless.

I suggest you take your "weakness demonstrations" to the local law enforcement office and helpfully show them how breakable their windows are... Be sure to tell them how grateful they should be for you highlighting their vulnerability. I think they are likely much more equipt to provide you with the education most suited to your current needs.

Quote from: gmaxwell on October 21, 2015, 09:59:16 PM

... long text, shit text ...

Boy what a bad loser you are. End users will read these notes:
https://bitcoin.org/en/release/v0.11.1

PERIOD, you lost the debate, now get back to work

BTW, you are barking at the wrong tree. I'm not complaining about dust threshold being too high. I am complaining about your incompetence of not being able to insert such an important change into the release notes meant for the end users.

Let me say it again if you still didn't get it --- I LIKE LARGE DUST THRESHOLD BECAUSE I HATE STRESS TESTS AND TX SPAM. So stop portraying me as the bad guy, I am not the stress tester, I am not abuser, I am not the enemy of Bitcoin.

You are misinterpreting (perhaps deliberately) my previous post and your answers only reflect your egomania. I don't think there will ever be a reasonable answer from you in this topic. People full of self-importance are always unable to admit their own flaws because they simply refuse to consider the possibility and it's not even their fault. It's how human mind operates. As species we collectively refuse to accept possibilities that turn our world upside down and thus shatter our egos. Your greatest enemy is inside of you. Be aware of its presence because only then you can sometimes be successful in defeating it.

Quote from: gmaxwell on October 21, 2015, 09:59:16 PM

I suggest you take your "weakness demonstrations" to the local law enforcement office and helpfully show them how breakable their windows are... Be sure to tell them how grateful they should be for you highlighting their vulnerability. I think they are likely much more equipt to provide you with the education most suited to your current needs.

This is just too good to be left unanswered. You are making me laugh and here's why. You are comparing Bitcoin to our archaic legal system and expect there to be an analogy. For such a world view you should be kicked out from the dev team immediately. You have failed to understand that the brilliance of Bitcoin is the fact that it does not need men with guns backing it up. It is designed to operate without relying on the assumption that its users have high moral standards and righteous intentions. The protocol has to deal with spammers, abusers and stress testers. There are programmatic ways to enforce it and you are just being a lazy programmer who thinks it would be easier to kindly ask anonymous bitcoin users not to generate massive amounts of UTXOs rather than to implement code that solves the issue on the protocol level. If you now say that dust threshold is meant to defend against UTXOs then stop complaining about people who make UTXOs and are willing to pay the price (whatever it is). It's free market.

Quote from: Hyena on October 22, 2015, 07:11:27 AM

Boy what a bad loser you are. End users will read these notes:

Don't look at me: I had no idea bitcoin.org mangled the release notes. Thanks. No one working on Bitcoin core has any control over bitcoin.org, but I'll report it (https://github.com/bitcoin-dot-org/bitcoin.org/issues/1099) now that you've brought it to my attention.

Quote

you are just being a lazy programmer who thinks it would be easier to kindly ask anonymous bitcoin users not to generate massive amounts of UTXOs rather than to implement code that solves the issue on the protocol level. If you now say that dust threshold is meant to defend against UTXOs then stop complaining about people who make UTXOs and are willing to pay the price (whatever it is).

I didn't contact you, you started this thread with a bunch of accusations and ranting, because -- apparently-- you weren't willing to "pay the price".

And no, just because there is a fine on something doesn't make it appropriate to do just because you're willing to pay the fine.

Quote

now get back to work

Please do not address anyone on this subforum in this manner. None of the developers of Bitcoin software owe you anything, and this sort of disrespect is most unwelcome.

Quote from: gmaxwell on October 22, 2015, 07:49:33 AM

Quote

now get back to work

Please do not address anyone on this subforum in this manner. None of the developers of Bitcoin software owe you anything, and this sort of disrespect is most unwelcome.

Ok now we're talking. Sorry if I hurt your feelings, it was a joke. I was ranting and raving not because I hate you but because that's how you get attention in the jungle (Internet).

And I still think that Bitcoin has the theoretical capabilities of dealing with UTXOs on the protocol level without relying on people's good will. For example, implement circular block chain so that older TXs would get thrown away no matter how much coins were left unspent. Also, I would advocate introducing a hybrid PoS/PoW model to bitcoin to boost the full node count and ease the abyss between stakeholders and miners. Right now miners have the ultimate power of writing whatever arbitrary data they want in block headers but I also want to have access to that power without owning an ASIC farm. I want to gain access to that power by holding a shit load of bitcoins. And that would be more fair because thanks to people like me (bitcoin hoarders) it has such a high value in the first place. Miners are bad for the price because they dump the coins but minters are good for the price because they hoard coins to mint more stakes.

Quote from: hhanh00 on October 22, 2015, 09:14:23 AM

I doubt we will see major modifications to Bitcoin, not because of a lack of interest but because the chances of a massive monetary loss make them a risk too great to take now. Hopefully, sidechains will change that.

Actually, I hope fees become so high that we will only use the Bitcoin as the "peg" and move all the other usages of the blockchain to sidechains. I know you feel entitled
to use the blockchain as a mean to store random stuff but at 2 GB of UTXO, I think Bitcoin isn't friendly towards full nodes anymore.

Maybe if enough people like you & amaclin abuse the system, there will be a change of the consensus rules but I don't think it's on the roadmap.

Hey just because I have my ways with the Bitcoin's block chain right now does not mean I want it to remain that way. There are tons of shitcoins whose block chain I can put into "good use" (should it become irrational with Bitcoin for whatever reason). And again, you're using the word "abuse" on me even though it is not an abuse. It is a very delicate and special form of steganography that I am involved in. And even then, it's pointless to argue about whether it is an abuse or not because all arguments for and against it will always remain subjective and very personal. So we might as well as drop the case. Fact is that bitcoin's block chain is most famous for being an immutable database guarded by the world's most powerful computing network. For that very reason it is an excellent place to store proof-of-existence hashes. Now you call it abusive. I call it ingenious. You want to fight to death over that?

Quote from: Kazimir on October 22, 2015, 10:54:45 AM

Quote from: Hyena on October 20, 2015, 12:28:12 PM

That's right, instead of 540 satoshis the bitcoin-core now won't allow outputs smaller than 2730 satoshis. This is starting to piss me off because every time you change it I must also change my program logic.

Just out of curiosity, what are you programming that depends on sending dust? (or at least very small, dust-alike txs)

Proof of existence on the block chain. And actually I consider the lion share of my project (see my signature) a decoder not the encoder. I have been monitoring the bitcoin's block chain for human readable text messages and JPG images for nearly 2 years now. The decoding service is not creating any UTXOs. Only the encoding service is creating them and this is up to each user's own moral standards. I am planning to switch to OP_RETURN soon, or at least have this as an alternative option for ~~moralfags~~ those who need it. (edit: since I received a warning from some moderator I don't no longer know what is allowed and what is not, I must admit it's getting Nazi down here but I think I can cooperate)

Quote from: hhanh00 on October 22, 2015, 10:08:48 AM

There would be no point in fighting you about this. It's a loophole of the system and you are using it. On one hand I don't really like it because I'm paying for storage (nodes work for free), on the other hand I hope that if there are enough of such users the blockchain size will grow
so large that:
- it will force into a change in the system,
- or full node numbers dwindle
Both ways, there will be a change.

You are right. In fact I am totally on your side in this. I also hate this loophole and I wish it got fixed somehow. I hate the idea of block chain growing into infinity. And with my actions I hope to draw enough attention on the issue that it actually gets resolved before a malicious entity finds a way to destroy bitcoin using the same loophole. Also, so far my services have not created any noticeable pollution. It's still just a fun educational experiment. For that reason I urge you not to be too mad at me. Also, satoshi nakamoto himself used the block chain in this "abusive" manner by embedding a message for the bankers in the first block. If satoshi didn't want the block chain to be used for other activities than purely monetary transactions then why on earth did he do it? That was a rhetorical question, no need to answer :P

Quote from: Hyena on October 22, 2015, 01:44:43 PM

Also, satoshi nakamoto himself used the block chain in this "abusive" manner by embedding a message for the bankers in the first block. If satoshi didn't want the block chain to be used for other activities than purely monetary transactions then why on earth did he do it?

I think it was probably a pity that Satoshi actually did that (of course you know it was to show that there was no premine) as unfortunately his approach has been used by others and then extended through other approaches (I even worked out how to encode information in the sigs themselves although I've never actually used it live - come to think of it that is actually perhaps a better approach as it is just reducing the signature entropy a little and doesn't actually waste space).

It is inevitable that such pollution is going to happen and limiting dust is (at least for now) about the only reasonable method to preventing the UTXO set getting too large.

Quote from: CIYAM on October 22, 2015, 02:01:44 PM

Quote from: Hyena on October 22, 2015, 01:44:43 PM

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.

Quote from: CIYAM on October 22, 2015, 02:01:44 PM

Quote from: Hyena on October 22, 2015, 01:44:43 PM

Since that is part of the coinbase script, it isn't related to creating normal transactions to put data on the blockchain. The coinbase script can have anything you want in there, that is its purpose. But encoding data into addresses or as part of OP_RETURN isn't really something that is condoned.

Quote from: Nicolas Dorier on October 26, 2015, 02:29:08 AM

So, if I start accepting fees for it... people can leave toxic waste in your yard? After all... they paid a fee.

Things are not so simple as you make them out to be. One user (drawn from a tiny subset of mostly a dozen people, currently) ... collects a fee then everyone else for all time in the future takes a bandwidth and storage cost.

Fees are a useful mechanism and, at times, an effective tool, but they do not themselves create moral authority or guarantee system survival because they do not and cannot pay the enormous externalities that dominate the system costs and they do not reflect a consensual interaction with all people they might impact.

Quote from: Nicolas Dorier on October 26, 2015, 06:48:21 AM

How do you define toxic waste exactly ? Any usage which does not use bitcoin as value transfer ? how arbitrary is that ?

I wasn't even speaking about bitcoin. I was speaking about traditional toxic waste and your yard. :) Uranium hexafluoride in alumnium cans, if we must name something specific... My point being that your argument was generic, "Using Nicolas Dorier's lawn for other purposes is not abuse if you are willing to pay the price". :)

In any case, going back to Bitcoin, no one is obligated to relay or mine any particular transaction; and might not do so if they think they're harmful by whatever criteria they're using. One need not define anything.

But to your question of "arbitrary", do you intend to insult me? I do not think it is arbitrary to say that Bitcoin, which was created, operated, maintained, and adopted with the express stated purpose of being an P2Pecash system ... has an intended purpose of being a P2P ecash system, and that use of that that is using the system outside of its stated purpose. By comparison there are alternative networks based on the Bitcoin code base which have stated purposes which explicitly include other things; and, as a point of history, when someone first proposed storing name registrations in the Bitcoin system the system's creator vigorously opposed this and recommended doing so in an alternative network.

Quote

That's sadly, the best impartial authority we can get, if you have a suggestion unbiased of personal view about what ought to be considered waste, I'm interested to know. (I'm talking solely about Blockchain use cases, not about technical decisions which help to keep properties of what make bitcoin unique)

Uses which are not related to Bitcoin ecash and instead just ride atop it as a communication/storage channel (or worse, try to explicitly compete with the Bitcoin currency and replace it in the market while using Bitcoin's own network) are a pretty good start. Case in point, we're in a thread where someone was upset because nodes were blocking transactions of theirs which were creating purposefully unspendable txouts (e.g. adding non-Bitcoin bloat to the UTXO set) in order to run a commercial service called "crypto graffiti" which does what it says on the tin. I think that this is indisputable abusive: It benefits nothing but it's operator/users to the cost of every current and future user of Bitcoin, it uses the system not as an ecash system (which is what virtually all of its users signed up for), but as a messaging and free perpetual data storage layer, this (data storage) usage potentially risks subjecting node operators to nuisances (e.g. DMCA notices), and even the name acknowledges its nature. ... but on the scale of abusive things it's not very interesting: something can be abusive without being worth worrying about, as the overall behavior of the system already confines the amount of damage to uninteresting levels. It's only worth mentioning that it's abusive by way of explanation as to why I do not expect this kind of use to be reliable.

Quote from: gmaxwell on October 26, 2015, 07:12:50 AM

Case in point, we're in a thread where someone was upset because nodes were blocking transactions of theirs which were creating purposefully unspendable txouts (e.g. adding non-Bitcoin bloat to the UTXO set)

This topic highlights the issue that even changing a seemingly harmless parameter can break software. Just because this time the software happened to be controversial does not justify what happened. Same thing could happen to any service that utilizes OP_RETURN somehow. This, for example: https://proofofexistence.com/

Quote from: gmaxwell on October 26, 2015, 07:12:50 AM

in order to run a commercial service called "crypto graffiti" which does what it says on the tin.

CryptoGraffiti is not a commercial service. By commercial service you probably mean paystamper.com which is an idea of a guy from the US who contacted me on this forum wishing to monetize cryptograffiti. Cryptograffiti only allows you to convert plaintext into bitcoin addresses (for free). You have to compile and broadcast the TX yourself.

Look at this TX:
https://blockchain.info/tx/828404780e2be4e95ea2d03239193e4b5f17a71998a78d42b4bf4897c4effbe6

Not only has it text embedded in the OP_RETURN (id:barbarbarba.usersusersuserstst8) but it also has 0.00092035 BTC
sent to 1111111111111111111114oLvT2 (unspendable output). So which one is worse? My service requires CAPTCHA to be solved so that real humans have to do work in order to generate unspendable outputs. However, there are systems out there that generate unspendable outputs automatically and potentially in much greater magnitudes than cryptograffiti.

What is more, I am willing to cooperate and help you find a reasonable solution to the problem. I could, for example, require much higher fees for using block chain as data storage and I could send part of the earned profits as donations for the development of bitcoin. So far I haven't earned shit and the bloat generated by my service is nothing in comparison to what satoshidice did. You can verify it yourself by observing the donations I have received:
https://blockchain.info/address/1MVpQJA7FtcDrwKC6zATkZvZcxqma4JixS

Having said all that, I hope to no longer receive unjustified acid from people who are desperate because of the unspendable outputs issue. There are bigger fish to fry than me.

Quote from: gmaxwell on October 26, 2015, 07:12:50 AM

But to your question of "arbitrary", do you intend to insult me?

Keep down on the caffeine, you are on fire ! I was not insulting you.
I say your way of deciding what is considered waste is arbitrary.

_{I am sure pissed off by the sudden Dust change which broke virtually every deployed piece of software responsible for creating a transaction (not only the ones you consider toxic), and the refusal to admit it (which mean it will bit everyone again), but that's another matter.}

That said, I'm not against it, just the pissed by the poor notice time we had for redeploying our customers.

Quote from: gmaxwell on October 26, 2015, 07:12:50 AM

I do not think it is arbitrary to say that Bitcoin, which was created, operated, maintained, and adopted with the express stated purpose of being an P2Pecash system ... has an intended purpose of being a P2P ecash system, and that use of that that is using the system outside of its stated purpose.

By comparison there are alternative networks based on the Bitcoin code base which have stated purposes which explicitly include other things; and, as a point of history, when someone first proposed storing name registrations in the Bitcoin system the system's creator vigorously opposed this and recommended doing so in an alternative network.

Bitcoin first use is P2Pecash system, then as long as you follow the rule of the consensus, and pay what miners ask, whether it is used as cash or not have no importance.
If the increased usage make fees go up, then the least important use case will be kicked out to other alternatives.
Would you pay 1$ for doing for a graffiti ? I won't.
Graffiti will be kicked out, as well as Satoshidice way before impacting P2Pecash use case. It will go away or transform by the fees and dust.
Sure they are nuisance, but as you said, inconsequential and it will be always inconsequential thanks to fees and dust.

This is why I say fee and dust are an impartial moral authority, no need of judge to punish them.
I'm impatient to see a better way of dealing with dust so we don't get bothered again. (I have seen bluematt PR which is promising)

Quote from: Nicolas Dorier on October 26, 2015, 02:29:08 AM

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.

Quote from: Supercomputing on October 26, 2015, 09:32:37 PM

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.

Quote from: Hyena on October 26, 2015, 10:00:58 PM

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.

Quote from: knightdk on October 26, 2015, 10:15:13 PM

Quote from: Hyena on October 26, 2015, 10:00:58 PM

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?

Quote from: Hyena on October 26, 2015, 10:20:44 PM

Quote from: knightdk on October 26, 2015, 10:15:13 PM

Quote from: Hyena on October 26, 2015, 10:00:58 PM

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

Quote from: knightdk on October 26, 2015, 10:28:45 PM

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.

Quote

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.

Quote from: Hyena on October 26, 2015, 10:36:40 PM

Quote from: knightdk on October 26, 2015, 10:28:45 PM

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.

Quote

to cite yourself:

Quote

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.

Quote from: Hyena on October 26, 2015, 10:36:40 PM

Quote from: knightdk on October 26, 2015, 10:28:45 PM

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.

Quote

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.

Quote from: knightdk on October 26, 2015, 11:14:53 PM

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.

Quote from: Hyena on October 26, 2015, 11:23:01 PM

Quote from: knightdk on October 26, 2015, 11:14:53 PM

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.

Quote from: Supercomputing on October 26, 2015, 09:32:37 PM

Quote from: Nicolas Dorier on October 26, 2015, 02:29:08 AM

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.

Quote from: Nicolas Dorier on October 27, 2015, 02:08:50 AM

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.

Quote from: knightdk on October 26, 2015, 11:41:01 PM

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.

Quote from: Hyena on October 27, 2015, 10:55:48 AM

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.

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() (https://github.com/bitcoin/bitcoin/blob/24ce77d775f48034ef0c42fa21017d145c790921/src/primitives/transaction.h#L138-L153) 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) (https://github.com/bitcoin/bitcoin/pull/6722) 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.

Quote from: dexX7 on October 27, 2015, 12:38:32 PM

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) (https://github.com/bitcoin/bitcoin/pull/6722) 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.

Quote from: hhanh00 on October 27, 2015, 04:50:11 AM

Quote from: Nicolas Dorier on October 27, 2015, 02:08:50 AM

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.

Quote

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.

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?

Quote

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.

Quote

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.

Quote

It's not forbidden but if a lot of people were doing it, the other users would be unhappy.

And how do you decide which kind of users should go ?
Take your choice :

* The dictator way (one or several oligarch decides)
* The constitutional way (what you call "original intent of bitcoin")
* The market way (those having the less valuable usage of bitcoin driven to alternative -calculated by paid fee-)

I am just saying it should be the market way.

Frankly, it is clear when bitcoin is not the right tool. But sometimes it is a tool that is good enough (better than legacy system) until we have better alternatives.

Take only the colored coin example, the fact that we can't have a SPV client for tracking his colored coin is a big problem. Even the fact that fees are paid in bitcoin is a bit of a problem for CC application.
Yes, there might be other solutions on other chain, but then you loose the ecosystem and the assurance of self-enforcing contracts that bitcoin provide out of the box.

Those usage to which bitcoin does not fit perfectly will surely migrate to other platform once the downside of going away are fixed (Element?). A bit like internet moved away from the phone to ADSL.
But we are just still not here. Right now, you are like asking to stop using internet because if the line is used by internet, then it can't be used for receiving the call.(which was its original purpose)

Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Hyena on October 20, 2015, 12:28:12 PM