[Fee logic] Don’t count txins for priority to encourage sweeping. #2945

1. 
   gmaxwell commented at 9:26 am on August 28, 2013: contributor

   This changes the priority calculation to not include the size of per-txin data including up to 109 bytes of scriptsig so that transactions which sweep up extra UTXO don’t lose priority relative to ones that don’t.

   I’d toyed with some other variations, but it seems like any formulation which results in an incentive stronger than making them not count will sometimes create incentives to add extra outputs so that you have extra inputs to consume later. The maximum credit is limited so that users don’t lose the disincentive to stuff random data in their transactions, the limit of 109 is based on the size of a P2SH redemption with a compressed public key.

   This shouldn’t need a staged deployment because the priority is not used as a relay criteria, only a mining criteria.

2. 
   gmaxwell commented at 9:29 am on August 28, 2013: contributor

   For some discussion. This is, I believe, a really modest change. Some may favor more extensive revamps, and I wouldn’t disagree— but I think we should do at least this much to stop some of the bad incentive bleeding.

   Making this change, or one like it, is an item on on my personal UTXO spring cleaning checklist: https://en.bitcoin.it/wiki/User:Gmaxwell/utxo_spring_cleaning and fits into a larger plan to help reduce the size and growth of the UTXO set.

3. 
   gavinandresen commented at 9:50 am on September 17, 2013: contributor

   I’ve been playing with variations of this for a couple hours, and wrote a unit test (I’ll email you the patch).

   ACK in general, with one nit:

   It looks like 109 isn’t the right number, I’m getting P2SH signatures that are 108-110 bytes big. @sipa : what is the maximum DER-encoded signature plus compress public key size?

4. 
   petertodd commented at 5:51 pm on September 17, 2013: contributor

   @gmaxwell @gavinandresen Signatures can be up to 73 bytes long,(1) so that gets you 73+1 for the signature, and (33+1)+1 for the scriptPubKey, and another byte for the length of the scriptPubKey, 110 bytes in total.

   1. https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm <- I wrote this after checking with @sipa
5. 
   sipa commented at 5:54 pm on September 17, 2013: member

   The average should be 109 though, and in fact, we could change the negate-S anti-malleability rule in a way that guarantees it’s at most 109, and on average 108.5.
6. [Fee logic] Don't count txins for priority to encourage sweeping.

   This changes the priority calculation to not include the size of per-txin
    data including up to 110 bytes of scriptsig so that transactions which
    sweep up extra UTXO don't lose priority relative to ones that don't.
   
   I'd toyed with some other variations, but it seems like any formulation
    which results in an incentive stronger than making them not count will
    sometimes create incentives to add extra outputs so that you have
    extra inputs to consume later.  The maximum credit is limited so that
    users don't lose the disincentive to stuff random data in their
    transactions, the limit of 110 is based on the size of a P2SH
    redemption with a compressed public key.
   
   This shouldn't need a staged deployment because the priority is not
    used as a relay criteria, only a mining criteria.

   d6eb259953
7. 
   BitcoinPullTester commented at 6:43 pm on September 17, 2013: none

   Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/d6eb259953699f5bea208ff41a0967d8ea513a70 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
8. 
   gmaxwell commented at 7:18 pm on September 17, 2013: contributor

   I think exact size doesn’t matter too much, so long as its not so big that people have no disincentive to start stashing a bunch of junk in their scriptsigs, and not so small that people shy away from cleaning up. 109 was entirely too prime, so I put in 110.
9. 
   petertodd commented at 8:35 pm on September 17, 2013: contributor

   Note that right now you can do the following:

   scriptPubKey: 1 (pubkeys) m CHECKMULTISIG scriptSig: (37 bytes of garbage) (73-byte signature)

   thus inserting ~37 bytes of garbage for free because we don’t actually check that the CHECKMULTISIG dummy PUSHDATA is equal to zero in IsStandard() - do we have agreement this should be fixed? I can write a patch; it’s a source of tx malleability too. Other than that I think we’ve stamped out any other way to put garbage in scriptSigs re: the IsStandard() rules already. (though of course if the limit was >110+33 bytes you could do so via invalid pubkeys in a P2SH CHECKMULTISIG)

10. 
    cozz commented at 8:50 pm on September 17, 2013: contributor

    From coin control, I know that the biggest txin is 149 bytes. To verify, I have printfed some ::GetSerializeSize(txin, SER_NETWORK, PROTOCOL_VERSION), the values are from 147 to 149. We have now 41 + 110 = 151. This is 2 bytes too much.

    I have printfed this: (unsigned int)txin.scriptSig.size() and it spits out values from 106 to 108. We already had 109 and 110 in the lottery, I would say the correct value should be 108.

11. 
    gmaxwell commented at 8:52 pm on September 17, 2013: contributor

    @cozz … you were testing P2SH?
12. 
    cozz commented at 9:00 pm on September 17, 2013: contributor

    @gmaxwell no, I am talking about a default tx, sorry for bothering.
13. gavinandresen referenced this in commit bd48a4fe49 on Oct 20, 2013
14. gavinandresen merged this on Oct 20, 2013
15. gavinandresen closed this on Oct 20, 2013

    ---

16. wtogami referenced this in commit 8b69377a08 on Oct 24, 2013
17. wtogami referenced this in commit 23fdcae07d on Oct 25, 2013
18. wtogami referenced this in commit a41ab59f44 on Oct 27, 2013
19. wtogami referenced this in commit 7684b23be0 on Oct 27, 2013
20. wtogami referenced this in commit 649b298487 on Oct 29, 2013
21. wtogami referenced this in commit b96ec1a29f on Oct 29, 2013
22. wtogami referenced this in commit 5e9587646d on Nov 2, 2013
23. wtogami referenced this in commit 9bec9feb87 on Nov 23, 2013
24. wtogami referenced this in commit 70373e4f22 on Nov 23, 2013
25. laudney referenced this in commit 59111a11a9 on Mar 19, 2014
26. destenson referenced this in commit 9d10b24d68 on Jun 26, 2016
27. Bushstar referenced this in commit 7c3fd254f4 on Apr 8, 2020
28. DrahtBot locked this on Sep 8, 2021

Contributors
gmaxwell gavinandresen petertodd sipa BitcoinPullTester cozz