Bitcoin Forum
September 25, 2017, 07:05:15 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
Author Topic: WARNING! Bitcoin will soon block small transaction outputs  (Read 56743 times)
Crystallas
Member
**
Offline Offline

Activity: 106



View Profile
May 06, 2013, 05:19:05 AM
 #221


The next stage of enlightenment happens when you read Gavin's posts about how having a default value at all is temporary until the code for automatically calculating one based on a market mechanism between users and miners is ready.

I can't wait for the next implementations that fix the problem of decentralized market TX rates. But related, while different, the blockchain needs to smart-purge obsolete blocks(transactions that have been both max confirmed and transfered completely from the block of origin.)

I remember this annoying issue with a dust-wallet I have. Its only purpose is for dust transactions. While I try to use my own concept of minimizing dust by using a dedicated dust-wallet, everyone has to realize that many BTC users have this very same problem. Many of them are newbies who are learning the complexities of the whole BitCoin world. Newbies are an important part of growing the BitCoin adoption.



I'm going to continue collecting dust transactions, others will also continue collecting dust transactions. So lets push for better solutions than centrally planned solutions, even if temporary(and right now, the word temporary is merely a promise as of 0.8.2, not the fact of the situation.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506366315
Hero Member
*
Offline Offline

Posts: 1506366315

View Profile Personal Message (Offline)

Ignore
1506366315
Reply with quote  #2

1506366315
Report to moderator
1506366315
Hero Member
*
Offline Offline

Posts: 1506366315

View Profile Personal Message (Offline)

Ignore
1506366315
Reply with quote  #2

1506366315
Report to moderator
1506366315
Hero Member
*
Offline Offline

Posts: 1506366315

View Profile Personal Message (Offline)

Ignore
1506366315
Reply with quote  #2

1506366315
Report to moderator
SgtSpike
Legendary
*
Offline Offline

Activity: 1358



View Profile
May 06, 2013, 05:34:59 AM
 #222


The next stage of enlightenment happens when you read Gavin's posts about how having a default value at all is temporary until the code for automatically calculating one based on a market mechanism between users and miners is ready.

I can't wait for the next implementations that fix the problem of decentralized market TX rates. But related, while different, the blockchain needs to smart-purge obsolete blocks(transactions that have been both max confirmed and transfered completely from the block of origin.)

I remember this annoying issue with a dust-wallet I have. Its only purpose is for dust transactions. While I try to use my own concept of minimizing dust by using a dedicated dust-wallet, everyone has to realize that many BTC users have this very same problem. Many of them are newbies who are learning the complexities of the whole BitCoin world. Newbies are an important part of growing the BitCoin adoption.



I'm going to continue collecting dust transactions, others will also continue collecting dust transactions. So lets push for better solutions than centrally planned solutions, even if temporary(and right now, the word temporary is merely a promise as of 0.8.2, not the fact of the situation.)
The best way to purge dust is to include the dust addresses in with your normal use wallet.  I've had plenty of dust go to my mainly used address, some as small as 3 satoshis, but they've all been spent at one time or another with larger BTC outputs, automatically.  At one time, I looked at the unspent transactions, and had a dozen or two, but now, I only have 3 unspent outputs.  And I've never paid more than a 0.0005 BTC fee, either.
Crystallas
Member
**
Offline Offline

Activity: 106



View Profile
May 06, 2013, 05:38:42 AM
 #223


The best way to purge dust is to include the dust addresses in with your normal use wallet.  I've had plenty of dust go to my mainly used address, some as small as 3 satoshis, but they've all been spent at one time or another with larger BTC outputs, automatically.  At one time, I looked at the unspent transactions, and had a dozen or two, but now, I only have 3 unspent outputs.  And I've never paid more than a 0.0005 BTC fee, either.

That is one way to do it, but only for those who make enough big transactions to cover it.
Matthew N. Wright
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
May 06, 2013, 05:51:09 AM
 #224

Before commenting on this, I wanted to make sure I read the development discussion (the one that matters most).

Having read it, I am of the opinion that people here are brave enough to abandon working systems in the real world to hype up an experimental one with numerous flaws, yet aren't brave enough to accept compromise and would rather everyone else suffer.

Gavin admits that this is only a temporary patch and further work needs be done to uncover the true nature of the problems. His patch does seem to fix some problems, for now. When those problems are no longer problems the patch can be undone. Wait until Gavin refuses to remove the patch later when it's no longer needed before crying fork.

"ACK"

Realpra
Hero Member
*****
Offline Offline

Activity: 819


View Profile
May 06, 2013, 05:51:44 AM
 #225

This must be blocked.

Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
Matthew N. Wright
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
May 06, 2013, 05:53:15 AM
 #226

This must be blocked.

Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

HTML is a design protocol and is referenced client-side only. Bitcoin is a distributed transaction protocol requiring databases. In relation, HTML has never had a minimum content limit, but websites have. Look up HTTP HEADERS or TCP/IP stack and you'll understand. There are minimum requirements for data to be considered data, and maximums for all real world solutions to storage.

Would you also be against changing the TCP/IP protocol from the ground up to fix, once and for all, IP spoofing, DDoSing, etc? Change is only a bad thing when it's bad.

If IBM creates a new quantum storage drive that can hold all the information in the universe and Google makes FTTH a standard down to every village on the planet, this won't be such a problem anymore.

gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2296



View Profile
May 06, 2013, 06:00:31 AM
 #227

This must be blocked.
Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!
... Bitcoin _is_ limits, without limits it would be worthless.

Bitcoin will not be compromised
noedaRDH
Full Member
***
Offline Offline

Activity: 182


Finding Satoshi


View Profile
May 06, 2013, 06:06:56 AM
 #228

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?

And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

1NwGKiLcAngD1KiCCivxT6EDJmyXMGqM9q

Ask not what Bitcoin can do for you - ask what you can do for Bitcoin.
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
May 06, 2013, 06:08:10 AM
 #229

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?

And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

Short you have no control, cause it is really a mining thing. So if the majority of miners hashing power like the change, it then sticks. The only way to break revert is to get the miners to revert.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2296



View Profile
May 06, 2013, 06:17:36 AM
 #230

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?
And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?
Short you have no control, cause it is really a mining thing. So if the majority of miners hashing power like the change, it then sticks. The only way to break revert is to get the miners to revert.
GAH. Will you f@#$@# stop with the constant stream of misinformation?!

No "majority of miners hashing power" comes into this at all: It's not enforced against blocks.

Miners running with the defaults won't mine transactions with outputs of 54µBTC but will happily accept blocks that do and nodes running with defaults won't relay them.  Anyone can change their own defaults and presumably would if the value of Bitcoin changed dramatically.  Likewise new versions could have different defaults.  There is no dividing bitcoin issue at all, this is just node implementation behavior not a blockchain-protocol rule, and everything remains totally compatible.

Bitcoin will not be compromised
Daily Anarchist
Hero Member
*****
Offline Offline

Activity: 615



View Profile WWW
May 06, 2013, 06:19:38 AM
 #231

I have trouble understanding all this; what's the rationale behind this new patch? What would be the problem of continuing things as they are now?

And if users end up not liking the changes, can they revert back? Can the next client after 0.82 reverse these changes without dividing Bitcoin?

Short you have no control, cause it is really a mining thing. So if the majority of miners hashing power like the change, it then sticks. The only way to break revert is to get the miners to revert.

I don't think this is true. If miners refuse to upgrade it won't cause a fork. It just means that if somebody DOES send a 1 satoshi transaction that it won't get into the blockchain until a miner who allows it mines a block. I don't think this is a winner take all scenario.

Don't get me wrong, I think it's a terrible idea to raise the minimum tx amount, but that's strictly a miner's choice. It's not either/or, it's both.

Discover anarcho-capitalism today!
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
May 06, 2013, 06:21:14 AM
 #232

Miners running with the defaults won't mine transactions with outputs of 54µBTC but will happily accept blocks that do and nodes running with defaults won't relay them.

I basically said the same thing, I don't know where my mis-information is?

I don't think this is true. If miners refuse to upgrade it won't cause a fork. It just means that if somebody DOES send a 1 satoshi transaction that it won't get into the blockchain until a miner who allows it mines a block. I don't think this is a winner take all scenario.

I didn't say it would cause a fork

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2296



View Profile
May 06, 2013, 06:29:16 AM
 #233

I basically said the same thing, I don't know where my mis-information is?
Quote from: gweedo
So if the majority of miners hashing power like the change, it then sticks.
^ right there.

Has nothing to do with a majority of hashing power. If, for example, 10% of hashing power were under the old rules (or some alternative anti-spam rules that still allowed very small outputs under some conditions) then you'd expect 1:10 blocks to include transactions paying the small amounts.

Bitcoin will not be compromised
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
May 06, 2013, 06:34:14 AM
 #234

I basically said the same thing, I don't know where my mis-information is?
Quote from: gweedo
So if the majority of miners hashing power like the change, it then sticks.
^ right there.

Has nothing to do with a majority of hashing power. If, for example, 10% of hashing power were under the old rules (or some alternative anti-spam rules that still allowed very small outputs under some conditions) then you'd expect 1:10 blocks to include transactions paying the small amounts.

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
May 06, 2013, 06:34:18 AM
 #235

1) I note the distinct lack of discussion surrounding https://bitcointalk.org/index.php?topic=130450.0 and its pull request.

2) This issue certainly deserves better communication, but think the trolling (reddit/bitcointalk) by @johndillon was premature and exaggerated, because there is still plenty of time and opportunity in the release cycle for comments.  Usually the time prior to -rc1 release is used to write the communications that appear in -rc1.  The -rc1 release announcement then describes the changes, including rationale and impact.

-rc1 release initiates a phase of public testing and comment.  If the community really dislikes a particular change, this testing phase is yet another opportunity to make that known.

3) Most importantly...

The vast majority of remote workers (miners) do not seem to care at all about mining policies, in practice.  Pools' mining policies are incredibly opaque, few miners show deep interest in mining policy, and few pool operators show much interest in deep thinking about mining policies, transaction selection, and various economic incentives.  Even a lot of smart, engaged pool operators wind up preferring unmodified (or close to it) bitcoind for reasons of reduced complexity.

Therefore, just wanting -- quite rationally -- to get paid for mining, it is the sad reality that the block subsidy (currently 25.0 BTC) reduces transaction fees to the economic equivalent of statistical noise.  The long term cost of generating and storing economically worthless transaction outputs is simply not transmitted to users or miners.  Nor, really, is the short term cost.  The economic signalling of the block subsidy drowns the rest out.

The cost is currently borne entirely by "the cloud", the all-volunteer P2P network of full nodes.  The only modicum of behavior signalling we see there is a decreasing number of full nodes, and an increasing amount of P2P traffic.

What does all this add up to?  The answer is lies in the free market.  Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners.

These hardcoded anti-spam limits have existed for years, originally starting out at 0.01 BTC.  Transactions have always been filtered.  Anything outside a small set of "standard" transactions are deemed "non-standard", and will be filtered (not relayed).  Again, policy has been in place for years.

The fee limits were lowered over time, but still hardcoded.  This latest change makes this limit configurable, moving one step closer to the goal of users being able to react rapidly to changes in miner policy or bitcoin value.  One step closer to a freer market.

Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it.  This rule self-adjusts over time, as the "tx fee required to send" changes over time.  In a dynamic fee market, it might change a lot.

It is unavoidable that tiny transactions worth fractions-of-a-penny may be easily abused for data transmission and storage.  We have already been burdened with megabytes worth of wikileaks data, GPG encrypted data, and the PGP fingerprint strong set, so this is not a theoretical problem.  These files are stored as bitcoin transactions with values around 0.00000001.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1232


GetMonero.org / MyMonero.com


View Profile WWW
May 06, 2013, 06:38:25 AM
 #236

This must be blocked.

Ever heard of the HTML protocol limiting web pages to a certain maximum or minimum size? No? Because its ridiculous for what is supposed to be a universal protocol!

No, but HTTPds always implement limits. My nginx config has size limits on the request header and size limits on the body. There are security concerns around unmitigated data - why should my HTTPd accept a 256kb GET? HTML is not a communications methodology, it's merely a way of syntactically representing something visual. Limits would never be inherent in the HTML language constructs, but rather in the communications protocol. Incidentally, HTML does have many implied limits in the DOM - nesting levels and maximum JavaScript stack sizes and so on - based on the average user running with only a few hundred MB of free RAM and a relatively slow processor. Just because a poorly designed website with overly complex markup works on your core i7 with 16gb of RAM doesn't mean it'll work on my grandmother's Celeron with 2gb of RAM.

tl;dr - your analogy is flawed

Dougie
Full Member
***
Offline Offline

Activity: 211


You are not special.


View Profile
May 06, 2013, 06:40:26 AM
 #237

I don't understand this. This could ruin bitcoin for a lot of people.

Lurking since 2011...
1J4DhU3q6RxxCTfAAcg5ExVK6FfxkmzkTH
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2296



View Profile
May 06, 2013, 06:41:42 AM
 #238

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

HUH?  Let me try to break this down:

> If a big mining pool

OKAY, I follow.

> changes to that

0.8.2 with this change, I assume, okay

> and starts getting a lot of blocks

Okay, well finding blocks is just a product of hash power and luck

> then obvious there

Where?!

> choosing to use that method of blocking dust

HUH?! Running this code has nothing to do with finding blocks.  I understand the words you are using but the way you are stringing them together is virtuoso rutabaga.

Bitcoin will not be compromised
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2296



View Profile
May 06, 2013, 06:42:36 AM
 #239

I don't understand this. This could ruin bitcoin for a lot of people.
Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

Bitcoin will not be compromised
gweedo
Legendary
*
Offline Offline

Activity: 1246


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
May 06, 2013, 06:45:32 AM
 #240

but we all know that hashing power == power here. What I was trying to say, is if a big mining pool changes to that and starts getting a lot of blocks then obviously there choosing to use that method of blocking dust.

HUH?  Let me try to break this down:

> If a big mining pool

OKAY, I follow.

> changes to that

0.8.2 with this change, I assume, okay

> and starts getting a lot of blocks

Okay, well finding blocks is just a product of hash power and luck

> then obvious there

Where?!

> choosing to use that method of blocking dust

HUH?! Running this code has nothing to do with finding blocks.  I understand the words you are using but the way you are stringing them together is virtuoso rutabaga.


if you understand that is it, that is all I care, I am sorry my public schooling education has failed you.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!