If there is the intent of hard forking within a year or two to allow for arbitrary precision amounts in transactions, I'm all for this change as preparation.
I personally will just do the thing that's best for me and stop relaying transactions below 1 or 2 coins. Less CPU usage, more memory available and nobody of my peers will find out about this anyways. If more and more people find out about the benefits of this solution, then centralized structures just like the one you suggested with this coalition of people will emerge to even be able to broadcast any transaction.
It is known for years that there is little to no incentive to relay any transaction at all. Making it hard but possible to change but at the same time setting it to a new default value that not everyone agrees with by far is at least risky.
Topic: Bitcoin Developers Adding Minimum Transaction Output Size! - to Gavin (Read 3409 times)
May 08, 2013, 12:07:39 AM
but I really don't understand why we have to implement transaction filtering in a way that is invisible to the user.
Becuase setting it sanely is not obvious. There is no NAK in the bitcoin protocol. If you go an set it to 1.0 or whatever you're effectively a 1/8th DOS attack on your peers, if a bunch of people set it to totally random value transactions will start randomly failing because they end up with peers that aren't forwarding the transactions. I explained that in the pull request thread linked to in this thread as well as in some of the other threads here on the subject."you should probably not touch this unless major Bitcoin ninjas that you trust are telling everyone to touch it".
True, there is a very strong bias to the status quo. If you are who I think you are then you'll get what I mean when I say that it's a lot like the old days at FPC.
People should stop saying that a billionth of a bitcoin which is 8 places from the decimal, also called a Satoshi, is the smallest unit possible now. That may be strictly true on a purely technical protocol level but if the Qt client and the main mining software is in effect limiting confirmations to a certain size then that essentially screws bitcoin over as a micro currency, especially if it skyrockets in value again.
If it sky rockets in value again the limit can be removed. There are no permanent changes being made. The protocol is not being changed only the software.
There is a certain amount of truth to that but then we get into the design point of view. Why have an arbitrary limit of 8 places on the protocol in the first place, when technically a much larger limit would have been possible, if only to circumvent it later on. I realize that this brings about the idea of an originalist design version adaptation argument but even if Satoshi couldn't foresee this being a problem, and I don't see how they couldn't, I'm not sure this breaks the system to the point where such a change is necessary, much less desireable.
May 08, 2013, 12:05:28 AM
People should stop saying that a billionth of a bitcoin which is 8 places from the decimal, also called a Satoshi, is the smallest unit possible now. That may be strictly true on a purely technical protocol level but if the Qt client and the main mining software is in effect limiting confirmations to a certain size then that essentially screws bitcoin over as a micro currency, especially if it skyrockets in value again.
If it sky rockets in value again the limit can be removed. There are no permanent changes being made. The protocol is not being changed only the software.
May 08, 2013, 12:04:48 AM
but I really don't understand why we have to implement transaction filtering in a way that is invisible to the user.
Becuase setting it sanely is not obvious. There is no NAK in the bitcoin protocol. If you go an set it to 1.0 or whatever you're effectively a 1/8th DOS attack on your peers, if a bunch of people set it to totally random value transactions will start randomly failing because they end up with peers that aren't forwarding the transactions. I explained that in the pull request thread linked to in this thread as well as in some of the other threads here on the subject."you should probably not touch this unless major Bitcoin ninjas that you trust are telling everyone to touch it".
But is there a way to penalize dust spam? Say, delay relay of dust spam transactions for 10 minutes.Who cares?! It's not a big deal if people can't send less than 5300 satoshis. Who actually sends that small an amount?
see:You're making the news Gavin, but not with something intelligent or innovative like you have us used to...
[...]
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice. What happened to that and why Gregory closed it like it did?
[...]
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice. What happened to that and why Gregory closed it like it did?
May 08, 2013, 12:03:53 AM
People should stop saying that a billionth of a bitcoin which is 8 places from the decimal, also called a Satoshi, is the smallest unit possible now. That may be strictly true on a purely technical protocol level but if the Qt client and the main mining software is in effect limiting confirmations to a certain size then that essentially screws bitcoin over as a micro currency, especially if it skyrockets in value again.
Blacklisting by address is idiotic by the way. Unless you are purposefully trying to block a site that can't or won't change up it's address because it has to keep a known public address, and why would you, it's utterly pointless and a waste of time to even propose because it serves no legitimate purpose and is trivial to get around.
Blacklisting by address is idiotic by the way. Unless you are purposefully trying to block a site that can't or won't change up it's address because it has to keep a known public address, and why would you, it's utterly pointless and a waste of time to even propose because it serves no legitimate purpose and is trivial to get around.
May 07, 2013, 11:35:34 PM
Who cares?! It's not a big deal if people can't send less than 5300 satoshis. Who actually sends that small an amount?
May 07, 2013, 11:13:47 PM
but I really don't understand why we have to implement transaction filtering in a way that is invisible to the user.
Becuase setting it sanely is not obvious. There is no NAK in the bitcoin protocol. If you go an set it to 1.0 or whatever you're effectively a 1/8th DOS attack on your peers, if a bunch of people set it to totally random value transactions will start randomly failing because they end up with peers that aren't forwarding the transactions. I explained that in the pull request thread linked to in this thread as well as in some of the other threads here on the subject."you should probably not touch this unless major Bitcoin ninjas that you trust are telling everyone to touch it".
May 07, 2013, 11:06:44 PM
LIKE: blocking dust spam
DISLIKE: default limit, undocumented options, invisible to user
the filtering part of jonls' patch may be controversial, but I really don't understand why we have to implement transaction filtering in a way that is invisible to the user.
DISLIKE: default limit, undocumented options, invisible to user
the filtering part of jonls' patch may be controversial, but I really don't understand why we have to implement transaction filtering in a way that is invisible to the user.
May 07, 2013, 10:13:34 PM
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice.
You're linking to a pull request that implements transaction blacklisting by address.The recent dust output stuff is configurable. I can only speculate why you would misrepresent things so…
Ah, so we get to configure the already famous patch?
I gave up on the address blacklisting, which I don't see elegant but rather desperate solution. Btw, you are not who decides on who I ignore in RL or the bitcoin network, and how would you know anyway? Can you guess my ignore list on this forum?
I can only read one entry on the list: bg002h. Retarded comments like your thoughtless dribble here wastes my time. Since I haven't got much time, I'm gonna extrapolate and presume you're existence on these forums is not worth my notice.
May 07, 2013, 09:43:52 PM
It's not a no-option/choice. It's not a change in the protocol. It's completely configurable. There are plenty of other transaction types that are "censored" and "blocked" and have been since early versions or even the first version. Why aren't we complaining about those?
If the devs never make another upgrade and keep it as it is, well, when one Gavin (5340 satoshis) becomes worth $500, miners/nodes can just change their conf files. It wouldn't be profitable to "block" dust transactions if they weren't actually dust.
This is a step towards pricing in tx fees and letting the free market decide. It'd be nice if we could instantaneously remove all magic numbers from the code but had we done that from the start, bitcoin would never have survived.
If they were changing the protocol I'd be concerned. But then there are other coins. If you're so concerned, simply use a different coin. Put your money where your mouth is; take action as a consumer.
Or, start a coalition of people and miners who will simply edit their conf file and thus it will be slightly harder to get tiny tx included in blocks, but it could still happen provided enough participate. This is a likely scenario. Get crackin!
If the devs never make another upgrade and keep it as it is, well, when one Gavin (5340 satoshis) becomes worth $500, miners/nodes can just change their conf files. It wouldn't be profitable to "block" dust transactions if they weren't actually dust.
This is a step towards pricing in tx fees and letting the free market decide. It'd be nice if we could instantaneously remove all magic numbers from the code but had we done that from the start, bitcoin would never have survived.
If they were changing the protocol I'd be concerned. But then there are other coins. If you're so concerned, simply use a different coin. Put your money where your mouth is; take action as a consumer.
Or, start a coalition of people and miners who will simply edit their conf file and thus it will be slightly harder to get tiny tx included in blocks, but it could still happen provided enough participate. This is a likely scenario. Get crackin!
May 07, 2013, 09:29:41 PM
Luke probably meant that they are still valid if they make it into blocks, I'm concerend with the fact that it might be very hard to even get them to accepting miners.
May 07, 2013, 09:26:59 PM
To be fair, 0.8.2 will be the one silently dropping transactions that were valid to all clients before that. Transaction relaying just became more of an issue...
It's not blocking them (they're still valid), just declining to participate in them.This isn't the first version to opt out of relaying spam, either: it's been done since 0.3.19 or so.
it would only be declining to participate in them if when trying to do a transaction of 0.00000001 the client says to the person using it "i decline to send this press override button below to override this option"
but having it built in as a no-option/choice for those that do upgrade the client. is called BLOCKING by definition
May 07, 2013, 09:20:45 PM
https://bitcointalksearch.org/topic/denominating-a-bitcent-as-a-gavin-198618
Maybe we can designate 5340 Satoshies as a Gavin.
May 07, 2013, 03:21:27 PM
To be fair, 0.8.2 will be the one silently dropping transactions that were valid to all clients before that. Transaction relaying just became more of an issue...
It's not blocking them (they're still valid), just declining to participate in them.This isn't the first version to opt out of relaying spam, either: it's been done since 0.3.19 or so.
May 07, 2013, 09:05:05 AM
To be fair, 0.8.2 will be the one silently dropping transactions that were valid to all clients before that. Transaction relaying just became more of an issue...
May 07, 2013, 08:58:54 AM
I, for one, welcome our new Bitcoin overlords.
May 07, 2013, 04:46:08 AM
Ah, so we get to configure the already famous patch?
It can be configured already, using -mintxfee / -minrelaytxfee command line arguments.If you want to add those to the GUI you're welcome.
BTW: please don't take it personal that another implementation for dust limiting was chosen, and not yours, it happens to all of us sometimes
May 06, 2013, 07:55:16 PM
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice.
You're linking to a pull request that implements transaction blacklisting by address.The recent dust output stuff is configurable. I can only speculate why you would misrepresent things so…
Ah, so we get to configure the already famous patch?
I gave up on the address blacklisting, which I don't see elegant but rather desperate solution. Btw, you are not who decides on who I ignore in RL or the bitcoin network, and how would you know anyway? Can you guess my ignore list on this forum?
May 06, 2013, 07:51:36 PM
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice.
You're linking to a pull request that implements transaction blacklisting by address.The recent dust output stuff is configurable. I can only speculate why you would misrepresent things so…
Quote
What happened to that and why Gregory closed it like it did?
I answered this in the pull request: "We won't be adding any blacklisting functionality at this time. There are some other active pull requests on dust relay limiting which should generally address the rest of the concerns here."Feel free to create your own censorcoin software if you believe blacklisting Bitcoin participants is in your interest. Make sure to identify your nodes in the version messages so that I can— in turn— blacklist them on my nodes so that I'm not wasting bandwidth on a bunch of peers that are going to silently blackhole transactions.
May 06, 2013, 07:45:54 PM
You're making the news Gavin, but not with something intelligent or innovative like you have us used to...
http://bitcoinmagazine.com/bitcoin-developers-adding-0-007-minimum-transaction-output-size
http://www.reddit.com/r/Bitcoin/comments/1drnvp/bitcoin_developers_adding_0007_minimum/
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice. What happened to that and why Gregory closed it like it did?
Please don't answer, I know you wont.Btw, you know what you can do with your patch, right, or I should explain... ? Was rude, sorry.
http://bitcoinmagazine.com/bitcoin-developers-adding-0-007-minimum-transaction-output-size
http://www.reddit.com/r/Bitcoin/comments/1drnvp/bitcoin_developers_adding_0007_minimum/
You guys continue refusing to implement solutions useful to all of us and then impose arbitrary limits in the client? Take for example the interface to limit "dust" by user choice. What happened to that and why Gregory closed it like it did?
Please don't answer, I know you wont.
Jump to: