Adjust dust and fee value

novitski / bitcoinj

Automatically exported from code.google.com/p/bitcoinj

Apache License 2.0

0 stars 0 forks source link

Adjust dust and fee value #530

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

Bitcoin Core 0.9 will adjust down the minNonDustValue and default fees. We 
should match these changes in bitcoinj.

I think minNonDustValue should be adjusted first - possibly asap -, so that 
now-valid incoming transactions don't get rejected as spam.

Slashing fees can follow later when enough nodes have upgraded to the new rules.

I tried my luck at a patch, but currently minNonDustValue and default fee seem 
to be related somehow in the code. Its not clear to me how these relate.

Original issue reported on code.google.com by andreas....@gmail.com on 4 Mar 2014 at 12:31

GoogleCodeExporter commented 9 years ago

Also see https://github.com/bitcoin/bitcoin/pull/3305

Original comment by andreas....@gmail.com on 4 Mar 2014 at 12:33

GoogleCodeExporter commented 9 years ago

If the current upgrade rate holds, this will probably be safe to start rolling 
out in about 6 weeks.

Original comment by mh.in.en...@gmail.com on 1 Apr 2014 at 7:07

GoogleCodeExporter commented 9 years ago

Depending on the site used for measurement, 0.9 is now rolled out to 33% 
(bitnodes) or 7% (luke). I think we should get the patch ready so that it can 
be applied when needed. I tried my luck two times but somehow its much more 
difficult than I thought.

Original comment by andreas....@gmail.com on 3 May 2014 at 9:20

GoogleCodeExporter commented 9 years ago

Sure.

An app that does trial payments and measures how long they take to confirm 
would be useful.

Original comment by mh.in.en...@gmail.com on 4 May 2014 at 2:59

GoogleCodeExporter commented 9 years ago

0.9 is now at over 50% of nodes, apparently, but I tried sending a couple of 
transactions with the 1000 satoshi fee and they did not confirm yet after 14 
blocks and 5 blocks respectively. These were transactions with essentially no 
priority as they were respends of a tx that just confirmed.

My own 0.9 node does include them in getblocktemplate. So I conclude

1) Either most/big miners are not upgraded to 0.9 yet
2) The tx didn't propagate to all miners
3) Miners are upgraded and the tx did propagate, but they deliberately overrode 
the fee drop

Unfortunately there's no way to tell which it is.

I will leave this open for a while and we can try again in a month.

Original comment by mh.in.en...@gmail.com on 28 May 2014 at 3:20

GoogleCodeExporter commented 9 years ago

Thanks for testing this. Can you publish your fee patch nevertheless?

Original comment by andreas....@gmail.com on 28 May 2014 at 3:48

GoogleCodeExporter commented 9 years ago

No, because there is no patch. The app I wrote just overrides feePerKb in a 
SendRequest. It works fine.

Original comment by mh.in.en...@gmail.com on 28 May 2014 at 3:53

GoogleCodeExporter commented 9 years ago

OK, they finally confirmed. 23 blocks and 13 blocks, both in block 303049.  The 
coinbase says "KnCMinerB" so I guess that's who mined it.

Original comment by mh.in.en...@gmail.com on 28 May 2014 at 4:24

GoogleCodeExporter commented 9 years ago

They seem to be confirming immediately now, so we should do this. Andreas 
reported that there's something screwy about wallet emptying, when setting the 
new fee level. Should investigate.

Original comment by mh.in.en...@gmail.com on 21 Oct 2014 at 4:24

GoogleCodeExporter commented 9 years ago

See https://code.google.com/p/bitcoinj/issues/detail?id=579 for the screwy part.

When I checked 2 weeks ago, I got confirmation times of 1-3 blocks. Probably 
good enough to just lower the fee unconditionally and see if people complain 
about occasionally longer confirm times (in that case retrofit the app with a 
switch).

Original comment by andreas....@gmail.com on 21 Oct 2014 at 4:33