I agree with you about the current fee policy, preventing mass outputs of 1
satoshi might be a good idea, but the damage is already done, blockchain
size is huge due to satoshidice transactions and people storing actual data
encoded into tx outputs.

The problem is we've moved way past the point where practically every node
is also mining and attempting to gain the transaction fees, a node might
have an expense when it transmits a large 10kb transaction to multiple
peers, but it will never have a chance to gain the reward from whatever
transaction fees might be in the tx.

You might be able to calculate a value based on the system resources used
when validating and broadcasting the transaction, but now ASICs always win
the fees, while we keep the dsha256 proof-of-work (I'm not in favour of
changing it).

Any per-node fee will have great discrepancies and will lead to some nodes
accepting and rejecting, potentially creating a vector for race-type
attacks when accepting 0-confirmation transactions.

I guess you're right about leaving it, since there is no well written
documentation for which types of transactions are standard or not. Most
nodes are running bitcoind and it's up to those to filter and decide on
what is standard or not.

Thanks
Bob


On 9 September 2013 20:26, Amir Taaki <genjix@???> wrote:

> > 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
> >
> > _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>