Bitcoin Forum
November 25, 2017, 12:20:13 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   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 57746 times)
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1778

Newbie


View Profile
May 06, 2013, 09:16:39 AM
 #261

Doesn't this update create one more way to cheat merchants with 0-confirmations?

1. Send a transaction with one of the outputs below the threshold.
2. If it's not relayed to the merchant then connect to other peers and repeat step #1.
3. Enjoy free goods because ur transaction will likely not be included into a block.
1511569213
Hero Member
*
Offline Offline

Posts: 1511569213

View Profile Personal Message (Offline)

Ignore
1511569213
Reply with quote  #2

1511569213
Report to moderator
1511569213
Hero Member
*
Offline Offline

Posts: 1511569213

View Profile Personal Message (Offline)

Ignore
1511569213
Reply with quote  #2

1511569213
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511569213
Hero Member
*
Offline Offline

Posts: 1511569213

View Profile Personal Message (Offline)

Ignore
1511569213
Reply with quote  #2

1511569213
Report to moderator
mollison
Full Member
***
Offline Offline

Activity: 157



View Profile
May 06, 2013, 09:22:10 AM
 #262

Why not just decide an acceptable rate of growth for the blockchain per annum (e.g. 10 GB), limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

This seems to directly address the fundamental issue (the concern about too much data in the block chain), which we will eventually face anyway if bitcoin is successful.
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
May 06, 2013, 09:23:59 AM
 #263

Why not just decide an acceptable rate of growth for the blockchain per annum, limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

This seems to directly address the fundamental issue (the concern about too much data in the block chain).
no that would be deflationary. we need to cut the block size in half every 8 years, its creates incentives for the miner to only include huge fee transactions.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
2D
Member
**
Offline Offline

Activity: 76


View Profile
May 06, 2013, 09:44:18 AM
 #264

So why even have 8 decimal places in the first place then?
muyuu
Donator
Legendary
*
Offline Offline

Activity: 966



View Profile
May 06, 2013, 10:02:17 AM
 #265

So why even have 8 decimal places in the first place then?

This is a configurable variable. If valuation is so high 1 Satoshi is a non-negligible amount, there won't be spam at all and this variable could be set to 0.

GPG ID: 7294199D - OTC ID: muyuu (470F97EB7294199D)
forum tea fund BTC 1Epv7KHbNjYzqYVhTCgXWYhGSkv7BuKGEU DOGE DF1eTJ2vsxjHpmmbKu9jpqsrg5uyQLWksM CAP F1MzvmmHwP2UhFq82NQT7qDU9NQ8oQbtkQ
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 06, 2013, 10:06:11 AM
 #266

So why even have 8 decimal places in the first place then?

Because some time in the future 1 BTC just might be worth $1,000,000.00 (i.e. 1 satoshi = 1 cent).
However, Bitcoin will not get to this truly excellent state if it is suffocated in infancy with transactions which existing fiat systems deem too stupid to bother with.

why the fuck would you send less than 5uBTC to ANYBODY?

Exactly! Can anyone detail any previous fiat transaction they had for an amount < 1 cent?


mollison
Full Member
***
Offline Offline

Activity: 157



View Profile
May 06, 2013, 10:07:47 AM
 #267

Why not just decide an acceptable rate of growth for the blockchain per annum (e.g. 10 GB), limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

I need to update my suggestion. I have been told on IRC that the real problem is considered to be that unspent transaction outputs have to be stored in every fully validing node's memory. As opposed to the problem being total block chain size.

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Advantages: Miners would optimize such that you need to pay a higher fee if you take up more of the unspent outputs in that block. Now, we let economic feedback kick in and we address the problem head on, rather than waiting for it to bite us as bitcoin usage grows and limiting dust transactions is not enough, since it only indirectly solves the problem.

Actually, you could do _both_ - set a safe upper limit on the block size to deal with storage issues and a safe upper limit on unspent outputs per block, too. Then you'd be totally safe.
ABitBack
Sr. Member
****
Offline Offline

Activity: 479



View Profile
May 06, 2013, 10:35:30 AM
 #268

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

ABitBack.com - Shutdown due to Shiftcode gross negligence Domain for sale PM if interested
Matthew N. Wright
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
May 06, 2013, 10:37:08 AM
 #269

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

That's exactly what Gavin referred to it as.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1778

Newbie


View Profile
May 06, 2013, 10:38:09 AM
 #270

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

My experience says that temporary fixes stay forever.
Bitcoin Oz
Hero Member
*****
Offline Offline

Activity: 700


Wat


View Profile WWW
May 06, 2013, 11:06:27 AM
 #271

When you have a communal asset like the blockchain it can lead to a tragedy of the commons situation unless you make services cover the cost of their transactions. Otherwise its like building roads and infrastructure funded by the taxpayer but the housing developers take all the profits.

tldr a land tax is a fair way to do things.

dutt
Member
**
Offline Offline

Activity: 111



View Profile
May 06, 2013, 11:18:54 AM
 #272

I guess this might have to happen if you want to keep the blockchain from getting spammed with useless transactions.
If the limit can be raised it can also be lowered, right?

mollison
Full Member
***
Offline Offline

Activity: 157



View Profile
May 06, 2013, 11:40:30 AM
 #273

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Actually, an improvement on the last suggestion.

Determine an acceptable (given technology) rate of growth of the total set of unspent outputs. Every 2 weeks, adjust the number of (new unspent outputs created - previous unspent outputs spent) allowed per block, based on how closely the maximum rate of growth is being tracked.

This makes the size of all unspent outputs a resource that is subject to an economic feedback loop, just as we already have (in theory) with the total size of each block. That minimizes transaction fees without ruling out legitimate transactions that look like dust (micropayments).

Miners could pay users to spend lots of dust outputs, since it allows them to include more unspent outputs (which they can charge for) in their block.
jonytk
Member
**
Offline Offline

Activity: 106



View Profile
May 06, 2013, 11:55:35 AM
 #274

People, i have a solution should look something like this:

Forbid transaction that includes output less than x for a output address with an actuall amount of less than y.

Where x is 100 times less than the transaction fee and y 100 times more than the transaction fee.
And,
the transaction fee IS the average of the transaction fee included in the last 4380 blocks.(1 month)
with a minimum hardcoded that will change, but could be 0.0001 for transactions of less than 0.01 btc amount (at the moment, but that last number could be 0.01% of the average transaction size, rounded downwards. according to blockchain.info average transaction size is 13.4btc; so you will have to pay a 0.000134 min fee for any transaction of less than 0.00134 / or for every output of less than 0.00134)

so for example if the currently average transaction is fee is 0.00054
you cannot send less than 0.0000054 to an address with less than 0.054 (it will bounce back as change?)

this will:
1- Encourage the consolidation of addresses for people that have little amounts of coins and many addreses.
2- Not prevent people from making satoshi-transactions (they will pay a fee but they will have to have some balance in the receiving address)
3- Not bloat the blockchain
4- Help in the eventually cleanup of the blockchain: then after an x period, we can cleanup all addresses with less than 100 times the transaction fee safely.(i'm not sure if this last one is possible, but we could alow the sending for free of this satoshis to a address with a minimum balance)

That should deal with the bloated blockchain problem...
people with small amounts of satoshis, and that care enought, can still recover them by sending some btc (over 0.01) to the address and then send it it back or by  alowing the sending for free of satoshis only if they leave the address with 0 balane and are send to a address with a minimum balance.

TL,DR:
Encourage consolidation of addreses, forbid sending satoshis to an empty address, allow sending satoshis (if paying fee) to an address with balance, helping cleanup of blockchain (addresess with 0 balance should be pruned)

And for the people complaining about the size of the blockchain, a miner/pool making 100$ a day cannot spend 100$ on a 1tb harddisk per year?

wolverine.ks
Sr. Member
****
Offline Offline

Activity: 375



View Profile
May 06, 2013, 12:05:33 PM
 #275

how is the any different than all miners using the standard client changing the minimum transaction size accepted to 5430 satoshis?

if it's identical, why haven't they done it already? why would a patch be necessary to implement the change? why not make a forum post with the suggestion?
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
May 06, 2013, 01:22:53 PM
 #276

It is not a data storage service. Bitcoin would be a very bad design for a storage service

That's your - and mine too - opinion.
Some people apparently see the blockchain as useful for data storage, or for message sending, whatever. Simply trying to censor them is dumb. It's the typical bureaucratic response to a perceived "problem": ban it!

The clever response is to imagine how could Bitcoin profit from it. And I can see no better way than to make them pay for such unconventional usage.

As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

Don't be ridiculous (or troll harder). There's consent in Bitcoin usage. Apart from botnets and alike, nobody forces you to install Bitcoin in your computer.

The costs of data storage are not just borne by the single miner that accepts the transaction and has arguably been paid for their trouble they are imposed on the entire network— all current and future users of Bitcoin— for all time.

They're not "imposed".

And yeah, that's part of the "game": the remuneration is diluted in this lottery-like thing popularly called mining. That's known in advance. You know you'll only get the fees of a transaction if you get to produce the block that contains it. As long as the remuneration you collect (inflation + fee) pays for the overall effort and costs you need to bear, you should be fine.
Although in general I'm for the internationalization of costs, you shouldn't get overly paranoid there. Sometimes it's more expensive to internalize a cost than to bear the free-rider. For example, have you ever seen a residential building trying to charge its inhabitants according to the amount of times they took the elevator?
(By the way, if UTXO ever becomes so huge that smaller miners can't bear to store it entirely - I honestly doubt it - they can choose to drop some transactions that they believe will never be spent. At the worst, some of these transactions get spent and these miners won't be able to fully validate the block in which they get included - if they get included by someone-, pretty much like SPV nodes. But they'll still be able to validate and mine all others, more "interesting" transactions. Another alternative would be to store these txs in slower and cheaper media, since they don't expect to access it. Anyway, I really doubt UTXO will ever get that big so this is likely a non-issue)

Quote
Will bitcoind also disconnect from nodes that don't respect this policy, à la FATCA style?
No, nodes relaying non-standard transactions are not disconnected. That would make it infeasible to have inconsistencies in policy. Part of the point of policy vs protocol rules is that policy isn't required to be completely consistent for correct operation.

Great, at least people can safely opt-out. I still think it should be an opt-in though.

I agree with you, but it's still sad to see biased behavior being embedded in the reference implementation. It's like bitcoin.org. Not a monopoly, but still, the "reference". I'd very much prefer if it remained the most unbiased possible.
Biased how?

By deciding which use cases are desirable and which are not, and attempting to censor those considered undesirable. That's a judgement of value.

I insist: banning like this is dumb. Charging for it is more reasonable, and much more use-case-neutral.

Discouraging the creation of transaction outputs that yield fewer Bitcoins than they cost to spend is pretty "value neutral".

I wouldn't call that "discouraging", I'd call that censoring them on bitcoind. Discouraging would be to make them pay.

As far as I'm aware a policy to restrict them doesn't discriminate against any kind of usage other than the "usage" of forcing hundreds of thousands of machines to archive non-bitcoin data against their operators consent.

It is not against their consent (botnets excluded, of course).

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
boonies4u
Hero Member
*****
Offline Offline

Activity: 826



View Profile
May 06, 2013, 01:35:57 PM
 #277

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.

This only changes the default behavior of pools so they block dust transactions. Some pools already block dust transactions and will continue to do so. Others haven't been blocking dust transactions and will accept them.

But others will just do whatever default behavior the devs set.
centove
Full Member
***
Offline Offline

Activity: 191


View Profile
May 06, 2013, 01:40:04 PM
 #278

After reading all 15 pages of this stuff.. It basically boils down to this.

There was a magic number in the code for the transaction fees, so if a user of the bitcoind software wanted to change this, one had to get the source, edit main.h find the magic constant, change it, compile, install and use the newly compiled binary.

Sooo rather then that.

It was made an run time configurable thing. A NEW magic number was chosen. OMG! You're censoring transactions!! Nazi! Fork the code!!

I mean see for yourself:

https://github.com/bitcoin/bitcoin/pull/2577/files

(hint the red lines are removed and the green lines are added)

For example:
---
-    // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
+    // To limit dust spam, require base fee if any output is less than 0.01
---

Notice the change from a CONSTANT to a variable?

Geeze...

Give me Btc: 1BRkf5bwSVdGCyvu4SyYBiJjEjbNiAQoYd Mine on my node: http://ask.gxsnmp.org:9332/
jonytk
Member
**
Offline Offline

Activity: 106



View Profile
May 06, 2013, 01:52:28 PM
 #279

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Actually, an improvement on the last suggestion.

Determine an acceptable (given technology) rate of growth of the total set of unspent outputs. Every 2 weeks, adjust the number of (new unspent outputs created - previous unspent outputs spent) allowed per block, based on how closely the maximum rate of growth is being tracked.

This makes the size of all unspent outputs a resource that is subject to an economic feedback loop, just as we already have (in theory) with the total size of each block. That minimizes transaction fees without ruling out legitimate transactions that look like dust (micropayments).

Miners could pay users to spend lots of dust outputs, since it allows them to include more unspent outputs (which they can charge for) in their block.

Yes and No, Yes there should be a high limit to prevent spam,
 but also there should be a lower limit on the amount of satoshis you could send to a EMPTY address,
 a spammer can use have infinite number of empty addresses to bloat the blockchain with 1 satoshi transactions
 but he can only have so many addresses with a balance in it!

thus forbid transactions that send less than x satoshis to a address with 0 satoshis.

If this transactions have multiple outputs, just look the one's that are empty and send the amount back as change.
This will make everyone want to have at least x btc in his/her address and not spamming the address space with almost empty addreses.


caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
May 06, 2013, 02:05:07 PM
 #280


As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

Don't be ridiculous (or troll harder). There's consent in Bitcoin usage. Apart from botnets and alike, nobody forces you to install Bitcoin in your computer.

This is plain disrespectful.

OK. And comparing it with drilling holes in people's heads was totally coherent, relevant and "respectful".

In the end of the day if you are not a significant miner you have no say whatsoever in how much to charge for any transaction and whether it is better to patch and recompile bitcoind to get what you want or to use some command line switches. All you can decide on is whether you prefer a higher fee for quicker transaction or not. This is so by design. It always was so. It always will be so.

I hope you're right on the last phrase.
And yes, in the end of the day significant miners get to tell what's accepted or not. So why embedding this particular policy in the default behavior anyway? (the particular dust-non-standard one, not the config options, which are obviously welcome)

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
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!