Nope those are unrelated, and I haven't changed anything yet. This is
something I want to mull over and consider rather than making
reactionary changes.

This is more when you have an unconfirmed transaction where one of the
inputs is another unconfirmed transaction. Before libbitcoin only
confirmed transactions where the input's previous outputs where in the
blockchain. But I saw bitcoind allowed also input's from the mempool so
I added it >1 year ago. However I'm now considering whether adding that
compatibility wasn't a good idea.

On 17/02/14 09:24, Grazcoin wrote:
>
> 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
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>