One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data.<div><br></div><div>I had started a thread about this on <a href="http://bitcoin.org">bitcoin.org</a> some time ago, and I don't recall what the general outcome was.</div>
<div><br></div><div>I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees.</div>
<div><br></div><div>We offered to host this before, and would still be willing to host such a service.</div><div><br></div><div>Peter<br><br><div class="gmail_quote">On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas <span dir="ltr"><<a href="mailto:moon@justmoon.de" target="_blank">moon@justmoon.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zooko is spot on - slower confirmations will give people a reason to set<br>
higher fees. As soon as fees reach a level where they matter, even<br>
botnet operators will be looking into ways of including transactions for<br>
some extra profit.<br>
<br>
In the meantime slightly slower confirmations aren't a problem. Consider<br>
that even if it takes four blocks to get your transaction included<br>
instead of one, once it is included, you still benefit from every new<br>
block in terms of security. So if you're looking for six confirmations<br>
for example, even a three block delay will only be a 50% delay for you.<br>
And of course there are techniques for instant transactions which<br>
continue to be refined and improved.<br>
<br>
As for the proposed solutions: Punishing 1-tx blocks is complete and<br>
utter nonsense. It's trivial to include a bogus second transaction.<br>
<br>
Any additional challenges towards miners like hashes of the previous<br>
block are at best useless. If I was running a botnet, I'd just grab that<br>
hash from a website (pretty good chance Blockchain.info will have it :P)<br>
or mining pool or wherever and keep going undeterred. At worst they may<br>
affect scalability one day. You might imagine a peer-to-peer network of<br>
miners who for cost reasons don't download all blocks anymore, but<br>
verify only a percentage of them at random. They might then exchange<br>
messages about invalid blocks including a proof (invalid tx, merkle<br>
branch) why the block is invalid. This is just one idea, the point is<br>
that assumptions about what a legitimate miner looks like may not always<br>
hold in the future.<br>
<br>
Finally, there is an ethical aspect as well. If a miner wishes not to<br>
include my transaction that is his choice. He has no more an obligation<br>
to sell his service to me than I have to buy it from him. If I really,<br>
really want him to include my transaction I will have to offer to pay more.<br>
<br>
If we as developers think that confirmations are too slow or that more<br>
blocks should include transactions, then the right measures would be:<br>
<br>
- Educating users about the relationship between confirmation speed and fees<br>
- Raising the default transaction fee<br>
<br>
Every market has a supply curve, so it is economically to be expected<br>
that there will be some miners who don't include transactions, simply<br>
because they are at that end of the supply curve where it is not worth<br>
it for them to sell their service. All markets must have a certain<br>
tension - there must be miners who don't include transactions for there<br>
to be users who want their transactions included more quickly. In other<br>
words there must be somebody not confirming if confirmations are to have<br>
value. If you interfere with that all you'll accomplish is keep<br>
transaction fees below market level, which will make the transition from<br>
inflation-financed hashing to transaction-financed hashing more painful<br>
and disruptive.<br>
<br>
Cheers,<br>
<br>
Stefan<br>
<div class="HOEnZb"><div class="h5"><br>
------------------------------------------------------------------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<br>
will include endpoint security, mobile security and the latest in malware<br>
threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><table style="font-family:Times"><tbody><tr><td><img src="http://coinlab.com/images/coinlab-logo.png"></td><td valign="bottom"><div style="font-family:RobotoLight,'Lucida Grande',Helmet,Freesans,sans-serif;font-size:16px;line-height:20px">
Peter J. Vessenes<br>CEO, CoinLab<br>M: 206.595.9839<br>Skype: vessenes<br><a href="https://plus.google.com/112885659993091300749" target="_blank">Google+</a></div></td></tr></tbody></table><br>
</div>