I agree miner do not care.

What pisses me off is that the 'reference' implementation yet again features a complex rule set with disastrous side effect if violated,
where a simple rule one would work better.

It is a serious blow to the reliability of the network that by missing some target fee with a few satoshi's confirmation does not get gradually slower, but just stops (in the subjective view of the user) working.

I am fully aware of the rules and wrote the program that created the transaction. Yes, the program did not round up to 0.0002 as it should have. Still the behavior of the network sucks. Here the transaction for your reference. It's not beginners stuff:

https://blockchain.info/tx/a423f46be27389e966b82254cdc8c264dac485be4f66f16f7a7ddf9029d59e21

Two transactions with zero fee and ten times the size of mine (20KB each) are confirmed, but not mine with a fee of 0.000139.
This sucks.

Yes, I think this is some case of premature optimization or socialist thinking. Transactions should be simply sorted by fee/KB and stuffed into the blocks until they fit.

I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.

iPhone user unhappy with Apple should simply sell their device.

Every used iPhone sold takes away a buyer of a new one. That hurts.

correct.

I worked in a few big banks and never met PHP.
C# was sometimes used on the desktop, but never on a backend. Have not seen IIS either.

Having a web interface is fine. Having bitcoins (the keys) stored on a the web site for thousands of user is exactly backward thinking of online banking that we want to leave behind.

Bitcoin should be owned by the user in secure devices like TREZOR and web applications should only help them to follow, prepare, report ... but not sign for them.

With BIP39 128 bits of random key can be conveniently encoded into 12 words.
 
Assuming the key is really random, is there a need for a KDF, or is it OK to use the 12 words as a kind of brain wallet?

I attempted a more formal description also adding new types Trade and Swap.

Abstract
Definition of the Coin Trace (CT) rule set to map lifecycle events of digital assets to Bitcoin transactions. The rules aim for simplicity and backward compatibility with Bitcoin wallets that can only deal with transfers between addresses.

Definitions
We trace nominal holding of a digital asset through CT compliant Bitcoin transactions, CTTs.

The trace of an address is the net of nominal trace credited and debited to it by CTTs.

A marker address is a Bitcoin address associated with the trace, it acts as the unique reference to the trace.

CTTs are a subset of valid Bitcoin transactions that match a definition in this document. Non-CTTs are ignored for the purposes of this protocol.

Digital asset lifecycle
CT supports following lifecycle events of the digital asset

• Funding the marker address
• Issue trace
• Transfer trace
• Trade a trace
• Swap traces
• Destroy trace

Funding
Any address can be a marker address. Transactions that credit the marker address are Funding CTTs until there is no Issue CTT observed on the marker address.

Issue
The Issue CTT is the first transaction with input only from the marker address. Outputs of the issue transaction that are not sending to the marker address credit nominal amounts of the trace to their target addresses. Subsequent spends of the marker address holding are not CTTs.

Transfer
A trace can be transferred to another addresses with Transfer CTTs.  A Transfer CTT has an output to the marker address and only input addresses having trace of the same marker address. A transaction is not a Transfer CTT if any of its inputs consumes more of an address than the trace of that address.

Trade
A Trade CTT exchanges a trace on an address for traceless Bitcoins. The Trade CTT has an output to the marker address and a matching pair of input and output addresses. Only one of the input addresses has the trace of the marker output in at least the amount of that input. Trade CTT output to a non marker address is not more than the amount of input on the other address.

Swap
A Swap CTT exchanges traces of a pair of addresses. The Swap CTT has two outputs to two marker addresses and a matching pair of input and output addresses. Input addresses have the trace of one of the marker addresses in at least the amount of that input. Swap CTT output to a non marker address is not more than the amount of input on the other address.

Destroy
A trace is destroyed if transferred to the marker address.

A problem with the current proposal, that in case of a transfer the transaction fee for mining and marking would be paid from the trace, that is eventually expensive if trace has value above its intrinsic satoshis.

I suggest to add a fourth type of transaction, the swap. This makes trading assets identified by traces atomic and observable.

Rule 4. Swap
A valid swap has two inputs and one or two marker payments to project address(es). The swap has two regular outputs with addresses matching the inputs but swapping the input quantities reduced by payments to project address(es).

A is an address having ALPHA (project address) trace, B has (optional) BETA trace. a is the quantity of ALPHA swapped for b amount of BETA.

Inputs  Outputs
A a      B a - marker
B b      A b - marker
          ALPHA marker
          BETA   marker

Interpretation:
Swap a(-marker) of ALPHA for b(-marker) of BETA

I found in the meanwhile on the other example, that transactions could be rejected because of:
"Insufficient funds at sending address" - this answers my 2nd and 3rd question.
The rule should however be on http://cointrace.net/about

Thanks, interesting proposal

In your traded Example (http://cointrace.net/1DpnYaMW1qPGd6bspzcz7vdi7NR782XWn7)

Funding phase:
investor 1Kug5MazR3c8VsBn61JZdvzdix49K7CCES sends 0.03 to project address, therefore should have 0.03/(0.03+0.034078)= 46.8% instead of 75%, isn't it?

In transfer phase:
What if https://blockchain.info/tx/48d7a411fe6fa67d562d8af8bd26e2b3c7fa6a5343fac60af71c2560b2a810ae would have spent more than 0.03 to 1LSmNv4kjh34AnnPHJ9s9NHQTymJ82HqnN ?

or if in https://blockchain.info/tx/ece810e8166f984787961febcc9b90fc01d644f9d8826097349296f573e47d31 the sum of outputs to 13XUuo2ieBBrjyRySst7pMyLtyovsH6Msc and 1P4bJN7u88dPee7hKN4mQh46RsR7J9exd9 would have exceeded 0.02 ?

Even open source is usually executed on hardware black boxes. I understand your concern, but believe that bitcoin mining with ASIC is one of the least concerning black boxes.

I am not sure that cuts it. A big stake gives access to deterministic yield enhancing strategies even more than a huge mining capacity in PoW. Just like playing no-limit poker against a huge stack is not fun.

Would you please point me to arguments supporting the need of ASIC resistance?

What is PoS good for as extending any number of forks simultaneously with it costs just as much as extending the trunk?

Circle, Coinbase and BitPay launch a KYC compliant overlay and get FinCEN approval for money transmitting.
A dark chain fork will emerge in answer.

In contrary. The monopoly of the core team is just breaking down, to be replaced by an oligopoly of those secure access to the team.

http://blog.coinbase.com/post/69775463031/coinbase-raises-25-million-from-andreessen-horowitz
"Separately, we’re also very pleased to share that Gavin Andresen has joined Coinbase as an advisor. "