<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-04-23&#xA;📝 Original message:On Wed, Apr 23, 2014 at 06:04:00PM +0300, Alex Mizrahi wrote:&#xA;&gt; This is outright ridiculous.&#xA;&gt; &#xA;&gt; Zero-confirmation double-spending is a small problem, and possible&#xA;&gt; solutions are known. (E.g. trusted third party + multi-sig addresses for&#xA;&gt; small-value transactions.)&#xA;&#xA;Also replace-by-fee scorched earth.&#xA;&#xA;&gt; On the other hand, protocol changes like described above might have&#xA;&gt; game-theoretical implications which are non-trivial and hard to understand.&#xA;&#xA;To put it mildly. :) Beyond the obvious issues with adding mechanisms&#xA;for miners to vote on what blacklists they wish to apply, it&#39;s&#xA;interesting to consider how trying to make zeroconf transactions secure&#xA;directly is quite close to changing the block interval. Like the&#xA;blocksize that&#39;s a fundemental economic parameter of the system - how&#xA;low-latency and well connected you must be to be allowed to mine. Even&#xA;in a scheme where the punishment for allowing a double-spend was somehow&#xA;applied perfectly fairly, you&#39;d still be favoring large well-connected&#xA;miners in a very similar way to reducing the block interval.&#xA;&#xA;&gt; The above approach works as long as the majority of hashpower is honest,&#xA;&gt; &gt; defined to mean, working to stop double spending. This is the same security&#xA;&gt; &gt; property as described in the white paper, thus this introduces no new&#xA;&gt; &gt; security assumptions.&#xA;&gt; &gt;&#xA;&gt; &#xA;&gt; No. Bitcoin should work if miners are merely individually rational, i.e.&#xA;&gt; they try to maximize their pay-offs without colluding with others.&#xA;&#xA;It&#39;s worth noting that the academic efforts studying Bitcoin are&#xA;spending quite a bit of effort focused on the incentive compatibility of&#xA;various mechanisms in the protocol: https://github.com/citp/bitcoin-sok/issues/5&#xA;&#xA;There&#39;s solid consensus in the academic community that Bitcoin can&#39;t&#xA;just depend on notions of &#34;honesty&#34; to work.&#xA;&#xA;&gt; I guess word &#34;honest&#34; might have different meanings, that can be a source&#xA;&gt; of confusing.&#xA;&gt; 1. Honest -- not trying to destroy bitcoin&#xA;&gt; 2. Honest -- following rules which are not required by the protocol&#xA;&#xA;What exactly those rules are is up for debate too. Right now if, say,&#xA;just 5% of Bitcoin miners were willing to accept Colored Coin&#xA;transactions you could still use Colored Coins. The other 95% may want&#xA;to block said transactions, but there&#39;s huge practical difficulties in&#xA;organizing a reorg and ensuring that everyone co-operates; miners have&#xA;strong incentives to defect if the consensus isn&#39;t assured as any miners&#xA;attempting to reorg are wasting their hashing power if it doesn&#39;t&#xA;succeed.&#xA;&#xA;OTOH with a voting scheme the cost to propose that a specific block or a&#xA;transaction be blacklisted is much lower. In Mike&#39;s proposed scheme to&#xA;not just blacklist, but actually take coinbases it&#39;s downright&#xA;profitable. Rather than being a last resort option, it&#39;ll be easy for&#xA;miners to propose various things be blacklisted, if the vote goes&#xA;through, great, if it doesn&#39;t, no harm done. Obviously that makes&#xA;blacklists into a much more useful tool and greatly changes the&#xA;political landscape around them.&#xA;&#xA;Remember, if you&#39;re operating a publicly known pool, and there&#39;s a&#xA;voting mechanism available to you to blacklist specific blocks, how are&#xA;you going to resist pressure from your local authorities to do just when&#xA;there&#39;s no cost to you to do so?&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;0000000000000000278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 685 bytes&#xA;Desc: Digital signature&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/50cd1cfa/attachment.sig&gt;</html></oembed>