OK yep, but I want to have a more saner policy first.

It's no point adding piecemeal things that restrict the freedom of
libbitcoin while improving nothing.

Take the fee rules for instance. They are incredibly stupid, hackish
and arcane. What is the problem? A limited memory pool and processing
of transactions. Why then don't we price the fee based on a node's
remaining available resources? As your memory pool gets filled, your
fee rules get tightened.

Also a nice way to calculate the amount of processing a transaction
will take. Verifying signatures and filesystem lookups are the slowest
ops. I want an elegant and mathematically based way to calculate a
transaction's cost.

fee = K * normalized_cost(tx) * availability(memory_pool)

On 09/09/13 21:18, Robert Williamson wrote:
> I'm not talking about workarounds specifically for nVersion, but
> for all the other stuff that is seen as non-standard by bitcoind,
> such as dust transactions, disabled op codes and other stuff,
> otherwise someone could send one transaction to a libbitcoin node
> which is accepted and other to the rest of the network which
> eventually gets confirmed, meaning the original to libbitcoin
> becomes invalid. (Proper precautions for race attacks should
> prevent against this though).
>
> The pull request here.
>
> https://github.com/bitcoin/bitcoin/pull/2982/files
>
> seems a bit of a big workaround when the main problem is that the
> value is being deserialized as a signed integer, rather than a
> uint32_t.
>
> https://github.com/bitcoin/bitcoin/blob/481d89979457d69da07edd99fba451fd42a47f5c/src/core.h#L184
>
> Maybe I'm missing something and they're not able to change the
> CTransaction nVersion though.
>
> I couldn't find any other documentation about the data type for
> nVersion other than here
> https://en.bitcoin.it/wiki/Protocol_specification#tx
>
> Thanks Bob
>
>
> On 9 September 2013 19:56, Amir Taaki <genjix@???
> <mailto:genjix@riseup.net>> wrote:
>
> No. The proper way is to investigate and see how nVersion affects
> libbitcoin. Not to add workarounds.
>
> On 09/09/13 19:21, Robert Williamson wrote:
>> Pretty scary, I always thought nVersion was uint32_t in the
>> protocol and any signed value would be cast to that before
>> IsStandard.
>
>> Also, is there any need to improve basic_checks() and
>> is_standard() to match the current bitcoind implementation at the
>> current time, or is it best to just allow bitcoind nodes in the
>> network to filter out non-standard transactions and only use
>> basic checks to ensure we never accept something invalid and
>> cause libbitcoin to follow a blockchain fork?
>
>
> https://github.com/spesmilo/libbitcoin/blob/master/src/validate.cpp#L53
>
>
>> I like
>
> https://github.com/spesmilo/libbitcoin/blob/master/src/validate.cpp#L78,
>
>
>
> even though it is never called, it has a very http://xkcd.com/221
> feel
>> to it.
>
>
>
>
>
>> On 9 September 2013 14:09, Amir Taaki <genjix@???
> <mailto:genjix@riseup.net>
>> <mailto:genjix@riseup.net <mailto:genjix@riseup.net>>> wrote:
>
>> my wallet crashed bitcoind!
>
>> https://github.com/bitcoin/bitcoin/pull/2982
>
>
> https://github.com/spesmilo/sx/commit/f5e3ca9485438adc5bea93eba34e3f56e606f151
>
>
>> -------- Original Message -------- Subject: Re: Strange
>> transactions Date: Mon, 09 Sep 2013 13:44:19 +0200 From: Amir
>> Taaki <genjix@??? <mailto:genjix@riseup.net>
> <mailto:genjix@riseup.net <mailto:genjix@riseup.net>>> To: Gregory
> Maxwell
>> <gmaxwell@??? <mailto:gmaxwell@gmail.com>
> <mailto:gmaxwell@gmail.com <mailto:gmaxwell@gmail.com>>>
>
>> ah I forgot to set it. Thanks.
>
>> On 09/09/13 13:42, Gregory Maxwell wrote:
>>> On Mon, Sep 9, 2013 at 4:38 AM, Amir Taaki <genjix@???
> <mailto:genjix@riseup.net>
>> <mailto:genjix@riseup.net <mailto:genjix@riseup.net>>>
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Both from here http://i.imgur.com/YUzk1cM.png
>
>>> Cool. Any idea why they have negative nversion?
>
>> _______________________________________________ unSYSTEM mailing
>> list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
>
>> _______________________________________________ unSYSTEM mailing
>> list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
> _______________________________________________ unSYSTEM mailing
> list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
>
> _______________________________________________ unSYSTEM mailing
> list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>