The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction.  In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway.  The tip would be below the amount that would allow said user to “rebroadcast” their transmit fee.  So you don’t get recursive transmit fees.

Say I want to send .001 BTC to Fred.   The cluster is operating at 1billion k/hash/second, then I need to distribute my transactions to enough nodes so that the k/hash/second % of the total is acceptably high for the transaction to get logged within the next N blocks.

So generating nodes A, B, and C each price their transmit fee proportional to their khash rate.  (how do they prove their khash rate?  total blocks generated over time?)

So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.   I send a different one to B and C.

Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.

The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it’s still small, it’s nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won’t matter much anymore.

There’s more work to do on transaction fees.  In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.  However, I haven’t had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.

52,146 total views, 25 views today