Transaction b1a70de883080402cdd03be2f61f31cac91ac790443a7306583a71b900d4305f

1 Input
  • bf1f3bb9ea5cd9967888aa03c8b03480a66761f13ced801d282f7160a11801b8:495
    OP_DATA_32(32) e45b8a67289a32366307439fd169696bcaf39688c890b03b9073e74899a93865
    OP_CHECKSIG(172)
    OP_0(0)
    OP_IF(99)
    OP_DATA_3(3) ord
    OP_DATA_1(1) 
    OP_DATA_16(16) application/json
    OP_0(0)
    OP_PUSHDATA2(77) {"subject":"Re: Transaction / spam flood attack currently under way","content":{"format":"html","body":"\u003cdiv class=\"post\"\u003e\u003cdiv class=\"quoteheader\"\u003e\u003ca href=\"https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896\"\u003eQuote from: creighto on November 19, 2010, 08:29:12 PM\u003c/a\u003e\u003c/div\u003e\u003cdiv class=\"quote\"\u003ePerhaps in addition to the age priority rule recently implimented, there should be a minimum age rule \u003cspan style=\"text-decoration: underline;\
    OP_PUSHDATA2(77) "\u003ewithout\u003c/span\u003e a transaction fee. \u0026nbsp;Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. \u0026nbsp;This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. \u0026nbsp;I think that this would significantly inhibit the type of spamming attack that is currently underway.\u003cbr/\u
    OP_PUSHDATA2(77) 003e\u003c/div\u003eI'm doing something like that. \u0026nbsp;Priority is a more formalised version of the concept you're describing.\u003cbr/\u003e\u003cbr/\u003e\u003cdiv class=\"quoteheader\"\u003e\u003ca href=\"https://bitcointalk.org/index.php?topic=1842.msg22844#msg22844\"\u003eQuote from: FreeMoney on November 19, 2010, 05:39:44 PM\u003c/a\u003e\u003c/div\u003e\u003cdiv class=\"quote\"\u003eAs it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highes
    OP_PUSHDATA2(77) t [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] \u0026gt; C ?\u003cbr/\u003e\u003cbr/\u003eMaybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] \u0026lt; C to let in about a dozen transactions or so.\u003cbr/\u003e\u003c/div\u003eYes, like this. \u0026nbsp;And the no-priority-requireme
    OP_PUSHDATA2(77) nt area is 3K, about a dozen transactions per block.\u003cbr/\u003e\u003cbr/\u003eI just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. \u0026nbsp;Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. \u0026nbsp;0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.\u003cbr/\u003e\u003cbr/\u003eVersion 0.3.15 doesn't wr
    OP_PUSHDATA2(77) ite transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.\u003cbr/\u003e\u003cbr/\u003eI think this is a good compromise short of making the default fee 0.01. \u0026nbsp;It's not so much to ask that free transactions can only be used to turn coins over so often. \u0026nbsp;If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.\u003cbr/\u003e\u003cbr/\u003eWe'v
    OP_PUSHDATA2(77) e always said free transactions may be processed more slowly. \u0026nbsp;You can help ensure your transactions go through quickly by adding -paytxfee=0.01.\u003cbr/\u003e\u003c/div\u003e"},"source":{"name":"Bitcoin Forum","url":"https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952"},"date":"2010-11-19T23:50:24Z"}
    OP_ENDIF(104)
1 Outputs
  • b1a70de883080402cdd03be2f61f31cac91ac790443a7306583a71b900d4305f:0
  • value  546
    address  bc1par0s4uucpjhvgesastmsdyvna642gjhcmf7ge4t8khh4ddvp3kyscrxmwp