Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMa<div class="post">The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction.&nbsp; In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway.&nbsp; The tip would be below the amount that would allow said user to "rebroadcast" their transmit fee.&nbsp; So you don't get recursive transmit fees.&nbsp; <br/><br/>Say I want to send .001 BTC to Fred.&nbsp; &nbsp;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.&nbsp; &nbsp;<br/><br/>So generating nodes A, B, and C each price their transmit fee proportional to their khash rate.&nbsp; (how do they prove their khash rate?&nbsp; total blocks generated over time?) <br/><br/>So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.&nbsp; &nbsp;I send a different one to B and C.&nbsp; &nbsp;<br/><br/>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.<br/><br/>The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.<br/><br/><br/><br/></div> text/html