Bitcoin Forum
November 12, 2024, 07:27:07 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Poll
Question: Community says:
Yay
Nay

Pages: « 1 [2]  All
  Print  
Author Topic: Add user interface to set dust limit and filtered addresses  (Read 3730 times)
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1452



View Profile
March 20, 2013, 02:43:43 PM
 #21

I'm so glad I found Bitcoin, to give me the freedom to use my money as I see fit. It saddens me to see people who think they know what Bitcoin is "meant to be". Just another group of control freaks I need to watch out for.
This also applies to MY computing resources: I can use MY processor as I see fit.

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
paraipan (OP)
In memoriam
Legendary
*
Offline Offline

Activity: 924
Merit: 1004


Firstbits: 1pirata


View Profile WWW
March 22, 2013, 03:04:56 PM
 #22

I'm so glad I found Bitcoin, to give me the freedom to use my money as I see fit. It saddens me to see people who think they know what Bitcoin is "meant to be". Just another group of control freaks I need to watch out for.
This also applies to MY computing resources: I can use MY processor as I see fit.

+1 this^

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1452



View Profile
March 23, 2013, 11:17:35 PM
 #23

is it possible for someone to make a windows build? (like with the "no forced fee" or "coin control" releases)

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
March 24, 2013, 02:03:10 AM
 #24

Would people who support this also support an alternative which strongly de-prioritized repeated address use? e.g. only relaying one to a few transactions per address in the mempool.

Blacklisting has some enormous systemic risks for the community— but if people behave in ways which make blacklisting effective then it is inevitable, if not because of this this user than eventually some other user.  Since privacy and fungibility are in all of our interests the system should operate in a way that gives people incentives to not behave in ways that damage those (e.g. use fresh addresses).  Plus it creates more fair load-balancing of the available resources: if someone voluntarily discloses that two transactions are theirs, why shouldn't we prevent them from using more than their share of the available capacity?

I ran a patch like this on my own nodes for some time— long before SD existed, though it has since bitrotted due to other changes.  I haven't promoted it because I believed that people who didn't understand it would think I was trying to single out a particular user... which is not the case, the purpose of such a change would be to protect everyone from the damage to the system being caused by singling out people by making singling out less effective against common behavior.

deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1036



View Profile WWW
March 24, 2013, 02:28:12 AM
 #25

To me, the motivation for this patch is not to affect what gets relayed or included in the blockchain, but instead to be able to easily ignore dust that may be sent to your own wallet addresses or to be able to ignore abandoned addresses filled with dust, dust that is too expensive to spend because it would cost more in transaction fees per KB to send it than the value of the payment.

We all know where this comes from - the "loser dust" of SatoshiDice, where they fill up user's wallets with payments of 0.0000001 - 0.00005000, simply as messages to say "you lost".

These payments-as-messages are bad for Bitcoin. This patch is also bad for Bitcoin. Future clients can and will allow the recovering of disk space and the removal of spent transactions. However, if you play SatoshiDice and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".
paraipan (OP)
In memoriam
Legendary
*
Offline Offline

Activity: 924
Merit: 1004


Firstbits: 1pirata


View Profile WWW
March 24, 2013, 04:08:16 AM
Last edit: March 24, 2013, 03:42:16 PM by paraipan
 #26

Would people who support this also support an alternative which strongly de-prioritized repeated address use? e.g. only relaying one to a few transactions per address in the mempool.

...

Yes, it looks reasonable and way more elegant.


However, if you play SatoshiDice and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".

I think most people here want Bitcoin to be a huge success. An enormous success even. If it does happen, at some point, these "dust" transactions will no longer be dust.

...

Hope we pass the growing pains and "satoshis" get passed around like full bitcoins today.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
March 24, 2013, 03:39:48 PM
 #27

these "dust" transactions will no longer be dust.
Are you really anticipating an increase in valuation of 2000x (thats whats required to make a 1e-8 output worth what $0.01 is today) before people have long since lost the relevant keys?
Quote
I've considered asking many times, but haven't bothered, does anyone have a figure on the theoretical maximum size of a pruned block chain?
Infinite, unless we add a rule to reject 0 value outputs. If we do the theoretical maximum size is about 44 petabytes.

and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".
The ignoring in this patch, fwiw, doesn't appear to change wallet behavior. Once those txn are mined they'll show up in the wallet. Litecoin carries a patch that ignores things in the wallet.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1120
Merit: 1160


View Profile
March 24, 2013, 08:16:10 PM
 #28

I didn't know 0 value outputs exist. What purpose do they serve?

There are only two legit use for them that I know of. The first is if you want to make a transaction that pays 100% of the funds going in to the transaction to fees. Although such a transaction output should use the OP_RETURN provably unspendable scriptPubKey, because spending the zero-value output makes no sense. The second is if you need to attach some data to a transaction, and don't want to pollute the UTXO set with that data; for that you use the scriptPubKey "OP_RETURN <data>"

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
March 26, 2013, 07:38:02 AM
 #29

That's 2200TB. Which is 37 of the best 2016 HDDs.
[...]
Would it be outlandish to say that in 2016, using improved technology which exists today, a node will require less than $10000 [...] Is dust as really as big of a problem as people make it out to be?
Uh. Your 2200TB of storage would, using the most cost effective hardware currently available, cost $130,992 today.  No doubt this will improve substantially in a few years 2016... but "less than $10,000" sounds a bit ambitious (even relative to past storage scaling)... and you've not justified your random division by 20.

But hey, just take that and run with it—   At $10,000-and-growing in hardware costs just to store the data needed to check the validity of blocks efficiently, costs that have no direct income generation, would Bitcoin be a decenteralized system?  I don't believe that it would be.  It would be a distributed system, yes, but one with some dozen of major players and large mining pools in complete control of the system, subject to easy influence by regulators and organized crime, and with everyone else is stuck with them.

That might be the eventual outcome of Bitcoin— just as it seems the eventual outcome of originally-asset-backed government promissory notes was to become today's current unbacked currencies. But even if it is inevitable I'd like to see that outcome forestalled: A Bitcoin who's only selling part is a different set of cronies-in-charge is not especially attractive to the systems of central banks, and not especially attractive compared to payment systems with lower hardware cost and faster confirmations.

Quote
Do we need the 0 value outputs? Will pruning exist in the next few years? Will the size of the block chain realistically grow fast enough to reach some of the numbers I've had fun with in this post?
We have pruning now now just no way for nodes to find sources for blocks in order to sync up if real full nodes become sparse, so there is as of yet no knob to delete the old history. It's not used at all now except for reorgs, syncing up new peers, and rescanning restored wallet backups. Validation is against the pruned data.

Quote
How long will 13 year old computers be able to run a full node?
You're not talking about excluding just old systems, you're talking about excluding everything that isn't a commercial-scale price-of-a-cheap-car capital investment in dedicated-to-bitcoin hardware-that-doesn't-even-exist-yet. Requiring reasonably modern, even reasonably high end conventional hardware, is probably not great for decentralization but probably doesn't preclude it, but I think that going beyond that does. Fortunately the same scaling laws your arguing will turn $130k  into $10k will also grant the same capabilities inexpensive systems in suitable time. Maybe.  And when it does we should make use of it. What we shouldn't do is set ourselves up so our only choice is to toss the decentralization that made the system worth having because we let it bloat faster than the technology could keep up with.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!