Bitcoin Forum
April 25, 2024, 12:57:05 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Adding a feature to decline dust transactions  (Read 1460 times)
bigasic (OP)
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
October 02, 2014, 02:25:11 AM
 #1

I hate getting spammed with this dust. It would be great if I could put in my wallet a feature to say "dont accept anything less than 10 satoshis) or something like that.. I mean, 1 bitcoin would have to be worth like a million bucks to be worth a penny.  With spamming happening all the time, it would be a nice function. Let the user define what they will accept or reject, if its rejected it goes back to the sending address.
1714049825
Hero Member
*
Offline Offline

Posts: 1714049825

View Profile Personal Message (Offline)

Ignore
1714049825
Reply with quote  #2

1714049825
Report to moderator
If you see garbage posts (off-topic, trolling, spam, no point, etc.), use the "report to moderator" links. All reports are investigated, though you will rarely be contacted about your reports.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714049825
Hero Member
*
Offline Offline

Posts: 1714049825

View Profile Personal Message (Offline)

Ignore
1714049825
Reply with quote  #2

1714049825
Report to moderator
1714049825
Hero Member
*
Offline Offline

Posts: 1714049825

View Profile Personal Message (Offline)

Ignore
1714049825
Reply with quote  #2

1714049825
Report to moderator
1714049825
Hero Member
*
Offline Offline

Posts: 1714049825

View Profile Personal Message (Offline)

Ignore
1714049825
Reply with quote  #2

1714049825
Report to moderator
deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1025



View Profile WWW
October 03, 2014, 12:08:24 PM
 #2

The Bitcoin network doesn't know anything about the recipient of money. There is no way to set any persistent knowledge about recipients that would do something. A transaction cannot be made invalid or blocked because it has a pay-to address that is undesired.

That means it is up to the recipient to either ignore or deal with payments sent to them. The preference is that you deal with it so that the payment to your address doesn't remain unprunable in the blockchain.

You can include them in other transactions, and about 75% of the time doing so would have no additional cost. Coin control features in wallets let you select inputs to specifically include (or exclude) the dust in future payments.

A possible automated wallet solution would be to include a feature like Peter Todd's dust-b-gone, where a certain dust threshold can be set and the dust auto-swept to a community mining fee transaction. However, this currently transmits a desire to spend the dust directly to Peter's server. That's a fine feature for proprietary wallets to implement themselves. The broadcast transactions needed for this don't work with the relay rules of normal bitcoin though, and we must not create mandatory centralization or specialized nodes, so adding such a function to the p2p network or the reference client would be a good amount of brainwork to implement.
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1498
Merit: 1499


No I dont escrow anymore.


View Profile WWW
October 04, 2014, 03:04:45 PM
 #3

How about this: make a TX without fee and send the Satoshi back to the spammer. Its still blockchain bloat, but at least the spammers have to deal with it.

Im not really here, its just your imagination.
HELP.org
Hero Member
*****
Offline Offline

Activity: 510
Merit: 500



View Profile WWW
October 04, 2014, 03:09:26 PM
 #4

Most don't get confirmed so you just see the transaction sitting there. 

That could be a feature of the wallet:  do not to display any unconfirmed (or even confirmed) transaction less than x

Certified Bitcoin Professional
Bicoin.me - Bitcoin.me!
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2216


Chief Scientist


View Profile WWW
October 04, 2014, 05:00:07 PM
 #5

That could be a feature of the wallet:  do not to display any unconfirmed (or even confirmed) transaction less than x

That is a feature of Bitcoin-Qt. Unconfirmed dust transactions don't enter the memory pool, so they are not relayed, not included in blocks being mined, and not displayed by the wallet.

If I recall correctly, if they DO get mined into a block by somebody then they are displayed. Ignoring them and not adding them to the wallet in that case might be a nice feature, although today's dust might be tomorrow's treasure if prices rise another couple orders of magnitude.

How often do you get the chance to work on a potentially world-changing project?
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1075


Ian Knowles - CIYAM Lead Developer


View Profile WWW
October 04, 2014, 05:03:56 PM
 #6

Smart wallets won't even *display* the dust (let alone use it for a tx) so I don't think it is a big worry (in the end you might be able to *spend it* if BTC goes a lot higher in value).

I guess the only real issue here is that if people get sent many thousands of such *dust txs* then it might be a problem for the "listunspent" API.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
HELP.org
Hero Member
*****
Offline Offline

Activity: 510
Merit: 500



View Profile WWW
October 04, 2014, 11:16:44 PM
 #7

That could be a feature of the wallet:  do not to display any unconfirmed (or even confirmed) transaction less than x

That is a feature of Bitcoin-Qt. Unconfirmed dust transactions don't enter the memory pool, so they are not relayed, not included in blocks being mined, and not displayed by the wallet.

If I recall correctly, if they DO get mined into a block by somebody then they are displayed. Ignoring them and not adding them to the wallet in that case might be a nice feature, although today's dust might be tomorrow's treasure if prices rise another couple orders of magnitude.

I wasn't talking about any specific wallet, just that a wallet could just have parameters not to display things. I have always used Armory and it displays the unconfirmed dust transactions.  In fact I have 2 of them sitting there for a month.  Not sure if this means they are being rebroadcast because most of them drop off after a couple days. I haven't had a chance to investigate why.

Certified Bitcoin Professional
Bicoin.me - Bitcoin.me!
HELP.org
Hero Member
*****
Offline Offline

Activity: 510
Merit: 500



View Profile WWW
October 05, 2014, 01:24:12 AM
 #8

Apparently what happened was that the dust transactions got into Armory before I had upgraded QT.  Armory has its own memory pool and it stayed there until I manually cleared it.  With the current version of QT it should not show up all now.

Certified Bitcoin Professional
Bicoin.me - Bitcoin.me!
Fuish
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
October 05, 2014, 02:11:32 AM
 #9

I guess I am confused... What is the problem with someone sending you a million little bits of btc? Besides flooding your transaction history, I guess I fail to see the negative side.  Huh
dabura667
Sr. Member
****
Offline Offline

Activity: 475
Merit: 252


View Profile
October 05, 2014, 02:38:54 AM
 #10

I guess I am confused... What is the problem with someone sending you a million little bits of btc? Besides flooding your transaction history, I guess I fail to see the negative side.  Huh

You fail to understand how bitcoin works, then.

Every time you receive bitcoin, it's like receiving a "bill" in that amount.

So imagine I receive 1 BTC...

A. but in one situation I just receive 1 BTC over the span of 1 transaction.

B. In the other situation I receive the 1 BTC over the span of 100 transactions.


Now let's send the 1 BTC to a friend in each case.

A. There is 1 input, so the transaction is likely around 250 bytes, and does not require a fee if you wait a day after receiving it... or 0.00001 BTC if you want to send right away.

B. There are 100 inputs, so the transaction is likely around 14978 bytes to 18178 bytes ish... which disqualifies the amount for a free transaction, AND the fee will be about x15 to x19 times the previous fee. (0.00015 to 0.00019)

But more importantly... the transaction in B is so large that some miners will pass over it in order to save the block from getting too large.


If you have a ton of 1 satoshi inputs in your wallet, and the wallet is dumb... it will try to use those every time you try to send a few dollars out during normal usage, and the fees will become very large.

My Tip Address:
1DXcHTJS2DJ3xDoxw22wCt11FeAsgfzdBU
HELP.org
Hero Member
*****
Offline Offline

Activity: 510
Merit: 500



View Profile WWW
October 05, 2014, 02:40:29 AM
 #11

I guess I am confused... What is the problem with someone sending you a million little bits of btc? Besides flooding your transaction history, I guess I fail to see the negative side.  Huh

It would also fill up all the blocks with transactions and push out the regular transactions.  Block size is limited so it can only currently handle 7 transactions a second.  Also increase traffic for the nodes and increased storage space.  

Certified Bitcoin Professional
Bicoin.me - Bitcoin.me!
Fuish
Newbie
*
Offline Offline

Activity: 34
Merit: 0


View Profile
October 06, 2014, 07:18:23 AM
 #12

Oh, now I see. I did not consider re-sending the coins or the strain on the network. Thank you!
HELP.org
Hero Member
*****
Offline Offline

Activity: 510
Merit: 500



View Profile WWW
October 06, 2014, 01:36:33 PM
 #13

Oh, now I see. I did not consider re-sending the coins or the strain on the network. Thank you!

It's really a fairly complicated problem to keep the utility of Bitcoin because you want low fee transactions for "micropayments" (which may not be "micro" for some parts of the world) while protecting the system as it scales and keeping the incentives for miners via transaction fees.

Certified Bitcoin Professional
Bicoin.me - Bitcoin.me!
Pages: [1]
  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!