Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SZ2lb-00017V-0W for bitcoin-development@lists.sourceforge.net; Mon, 28 May 2012 16:25:59 +0000 X-ACL-Warn: Received: from nm27-vm1.bullet.mail.ne1.yahoo.com ([98.138.90.59]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1SZ2lZ-0006oB-Oi for bitcoin-development@lists.sourceforge.net; Mon, 28 May 2012 16:25:58 +0000 Received: from [98.138.90.50] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 28 May 2012 16:25:52 -0000 Received: from [98.138.89.232] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 28 May 2012 16:25:52 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 28 May 2012 16:25:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 25472.97058.bm@omp1047.mail.ne1.yahoo.com Received: (qmail 22820 invoked by uid 60001); 28 May 2012 16:25:51 -0000 X-YMail-OSG: A2ubXJkVM1mz5GO7_j5l5xpyp2efK3yHg5u8J9c7klXgsKj aRVxe8J0g8iwDFCHliiXSnKekSy1p.dvz0.Q1mvqaSbUUTkxW2lBq0ZvjuPE bYIzjILTG9exoibbe_wes2RHuygbkX_yHwiBAivuF_J4uoJ2Uc9qTVZ92jc7 SdcAmbxD08SGnyWYVjOWEZ3iQKwHQ7aZzznMu8AO9CDJIntdZX7dyFcJmHDY gYhqNSeftIu1ZmzrdXP_E8NybajSBjdq8vJNC5h8DPnp1onYQKnsAsHNblE6 gf5LIabDco5WYKfg7RwKkRU.kJQcY1P1026Pr917VriHU49ZRfjOBG1uXBA4 ZO7Aezy8.rAwf.ISghzWxyzrWxEHbgOkZIoPDsjnCBTYyf.DVAK2oN3YJ_.G _2kZbbV3xfkQvtuyj2NHwPx1i7Afr.RSoK4Bi60TMGUAp1waRbZGy8RxH90l gyD6.nJqvWl_CqXo65K9mKeqrVkRzC7pQypL1ZtbPziIzswRfzmTZT8OZcIc 1vNCxRO3EEkaVZ5zd86xriCPhvUMQXuTULw55uabcFFLbtFAz5f_b27yvQtY XTkwnHeg6HaHC0AdK3CH4cMVqmsExdZQ1Hu648WTYOdw- Received: from [178.8.73.166] by web121004.mail.ne1.yahoo.com via HTTP; Mon, 28 May 2012 09:25:51 PDT X-Mailer: YahooMailWebService/0.8.118.349524 References: <4FC0C401.1040600@justmoon.de> <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com> Message-ID: <1338222351.22426.YahooMailNeo@web121004.mail.ne1.yahoo.com> Date: Mon, 28 May 2012 09:25:51 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.90.59 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SZ2lZ-0006oB-Oi Subject: [Bitcoin-development] Fw: Punishing empty blocks? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 16:25:59 -0000 That's a cool idea. Very meta. ________________________________ From: Peter Vessenes To: Stefan Thomas Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, May 28, 2012 4:54 PM Subject: Re: [Bitcoin-development] Punishing empty blocks? 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. I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was. 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. We offered to host this before, and would still be willing to host such a service. Peter On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas wrote: Zooko is spot on - slower confirmations will give people a reason to set >higher fees. As soon as fees reach a level where they matter, even >botnet operators will be looking into ways of including transactions for >some extra profit. > >In the meantime slightly slower confirmations aren't a problem. Consider >that even if it takes four blocks to get your transaction included >instead of one, once it is included, you still benefit from every new >block in terms of security. So if you're looking for six confirmations >for example, even a three block delay will only be a 50% delay for you. >And of course there are techniques for instant transactions which >continue to be refined and improved. > >As for the proposed solutions: Punishing 1-tx blocks is complete and >utter nonsense. It's trivial to include a bogus second transaction. > >Any additional challenges towards miners like hashes of the previous >block are at best useless. If I was running a botnet, I'd just grab that >hash from a website (pretty good chance Blockchain.info will have it :P) >or mining pool or wherever and keep going undeterred. At worst they may >affect scalability one day. You might imagine a peer-to-peer network of >miners who for cost reasons don't download all blocks anymore, but >verify only a percentage of them at random. They might then exchange >messages about invalid blocks including a proof (invalid tx, merkle >branch) why the block is invalid. This is just one idea, the point is >that assumptions about what a legitimate miner looks like may not always >hold in the future. > >Finally, there is an ethical aspect as well. If a miner wishes not to >include my transaction that is his choice. He has no more an obligation >to sell his service to me than I have to buy it from him. If I really, >really want him to include my transaction I will have to offer to pay more. > >If we as developers think that confirmations are too slow or that more >blocks should include transactions, then the right measures would be: > >- Educating users about the relationship between confirmation speed and fees >- Raising the default transaction fee > >Every market has a supply curve, so it is economically to be expected >that there will be some miners who don't include transactions, simply >because they are at that end of the supply curve where it is not worth >it for them to sell their service. All markets must have a certain >tension - there must be miners who don't include transactions for there >to be users who want their transactions included more quickly. In other >words there must be somebody not confirming if confirmations are to have >value. If you interfere with that all you'll accomplish is keep >transaction fees below market level, which will make the transition from >inflation-financed hashing to transaction-financed hashing more painful >and disruptive. > >Cheers, > >Stefan > > >------------------------------------------------------------------------------ >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development