Hi Amir,

I remind you that adding the unconfirmed inputs was due to my request on
email from 15.1.2014:
[Libbitcoin] sx get-utxo without pending

my question from that email was:
Is there a way to either ask for utxo without pending outputs, or get an
unconfirmed raw transaction?

You chose at first to enable the retrieval of the unconfirmed new
transactions (mempool), and now you reverted that change. That's fine
and probably the right thing to do. Is there a way to ask for utxo
without pending outputs then? (I don't want to to try and spend
unconfirmed outputs that may soon change due to the malleability issue).

As for the HashCanonicalPushes - it is part of fighting the
malleability. Just grep on "push" at:
https://gist.github.com/sipa/8907691

Grazcoin


On 2014-02-15 00:01, Amir Taaki wrote:
> ok, those proposals sound reasonable.
>
> can you explain the reasoning behind HasCanonicalPushes()?
>
> about accepting txs with unconfirmed inputs: originally I didn't have
> this but I only added it for compatibility with bitcoind:
> https://github.com/spesmilo/libbitcoin/commit/6ab8340a
> I didn't like this at the time, so now I'm going to remove that code.
> simplifies everything & much better IMO.
>
> that's the 'unconfirmed' parameter for when you store a tx:
>
https://github.com/spesmilo/libbitcoin/blob/master/include/bitcoin/transaction_pool.hpp#L152
>
> On 14/02/14 11:50, Grazcoin wrote:
>> The latest modification on the reference client that should fight the
>> DDoS could be also implemented on libbitcoin:
>>
>> Add HasCanonicalPushes(), and use it in IsStandardTx
>>
https://github.com/bitcoin/bitcoin/commit/87fe71e1fc810ee120a10063fdd26c3245686d54
>>
>> Add option to avoid spending unconfirmed change
>>
https://github.com/bitcoin/bitcoin/commit/1bbca249b202c4802cc2c4d4de4a26e6392b4d92
>>
>> Grazcoin
>>
>> On 02/14/2014 09:34 AM, Grazcoin wrote:
>>> How about ignoring all non-standard transaction (e.g. with outputs
>>> smaller than dust limit 5430 satohis)?
>>> We could still keep an option to enable the non-standard transactions
>>> using a command line argument.
>>>
>>> On reference implementation since 0.8.2:
>>>
>>> https://bitcointalk.org/index.php?topic=219504.0
>>>
>>> Payments (transaction outputs) of 0.543 times the minimum relay fee
>>> (0.00005430 BTC) are now considered 'non-standard', because storing them
>>> costs the network more than they are worth and spending them will
>>> usually cost their owner more in transaction fees than they are worth.
>>>
>>> Non-standard transactions are not relayed across the network, are not
>>> included in blocks by most miners, and will not show up in your wallet
>>> until they are included in a block.
>>>
>>>
>>> On 02/14/2014 07:57 AM, Amir Taaki wrote:
>>>> Hey, you're right. What rules do you propose that are elegant that we
>>>> can use to prioritise transactions and filter spam? I don't believe the
>>>> mempool rules in Satoshi bitcoind are well designed.
>>>>
>>>> On 13/02/14 22:41, Grazcoin wrote:
>>>>>
>>>>> The transaction:
>>>>> c5e2814507f49b5370f70c4477b02854a34c16af2c301cf097d1a634c4721ee6
>>>>> is an example for a spam transaction (part of the attack on bitcoin
>>>>> network).
>>>>>

>>>>> $ sx fetch-transaction
>>>>> c5e2814507f49b5370f70c4477b02854a34c16af2c301cf097d1a634c4721ee6 | wc
>>>>>       1       1   51317

>>>>>
>>>>> $ sx fetch-transaction
>>>>> c5e2814507f49b5370f70c4477b02854a34c16af2c301cf097d1a634c4721ee6 | sx
>>>>> showtx | head -n 20
>>>>> hash: c5e2814507f49b5370f70c4477b02854a34c16af2c301cf097d1a634c4721ee6
>>>>> version: 1
>>>>> locktime: 0
>>>>> Input:
>>>>> previous output:
>>>>> 9d9dd3402bb4ad7c409f3b5cf1b695a2d7815a58ef12982d0aeaa6a6a6880aee:0
>>>>> script: [
>>>>>
30450221008eb4a4a7d91468fa1ec083dd72868dd0ccb314df580e0a84e76b51df43c58ae402205d07ddf588ee43bd4780ba9241c7075ec46cc1e83c9d21e4c49e3a01aefa516701
>>>>> ] [
>>>>>
045cce731a4d6308e5baf7d73ad2fcab298563bbc86404905d84e2b0ec314946a6d0e8076bd9db8e85ca0e7e5bd33f2adc629d48ac26f10e6ee459fc64efb5b8f5
>>>>> ]
>>>>> sequence: 4294967295
>>>>> address: 1SochiWwFFySPjQoi2biVftXn8NRPCSQC
>>>>> Output:
>>>>> value: 1
>>>>> script: dup hash160 [ addd9328c13df98785d28be84ea8b93af1777969 ]
>>>>> equalverify checksig
>>>>> address: 1GrKLUduDbS5WM8zMJ4qzPCZ7UMpxj9AMo
>>>>> Output:
>>>>> value: 1
>>>>> script: dup hash160 [ 5754bc1d08e76b8c021d7e04c7448ab751df5dad ]
>>>>> equalverify checksig
>>>>> address: 18xmJAisJ1GBLVpuyFmqaA7LNmj8d6NE73
>>>>> Output:
>>>>> value: 1
>>>>> script: dup hash160 [ ad731d73d79a753ae71d64aa80c7697ee7cd603f ]
>>>>> equalverify checksig
>>>>> address: 1Gp7oXBtT2V5a4gqGcDVetw2aPw7vFPx1D
>>>>>
>>>>> It just sends 1 satoshi to a long list of addresses, and it is clear
>>>>> that it will never get included in a block.
>>>>> Shouldn't we just ignore the tx (not keep it in the memory pool
and not
>>>>> forward it)?
>>>>> blockchain.info does.
>>>>>
>>>>> If for some reason it does enter a block, we'll get it anyway.
>>>>> Grazcoin
>>>>>
>>>>>
>>> _______________________________________________
>>> Libbitcoin mailing list
>>> Libbitcoin@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>>
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin