Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of mac.com
	designates 17.172.81.0 as permitted sender)
	client-ip=17.172.81.0; envelope-from=gronager@mac.com;
	helo=st11p00mm-asmtpout001.mac.com; 
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@mac.com>
In-reply-to: <CAMGNxUv3jX+bdEyF8p-y3i93yLySxyT=7Qy336dPw9vgDKG51w@mail.gmail.com>
Date: Tue, 29 May 2012 10:52:49 +0200
Message-id: <5C824F0D-6025-4630-965B-E6C685588250@mac.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
	<CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com>
	<4FC0C401.1040600@justmoon.de>
	<CAMGNxUv3jX+bdEyF8p-y3i93yLySxyT=7Qy336dPw9vgDKG51w@mail.gmail.com>
To: Peter Vessenes <peter@coinlab.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Precedence: list

Peter, I like the idea of being able to know what fees to expect from different miners (it is like a service description / SLA for their service), but I would prefer a more distributed discovery mechanism for the information on the fees (Spent 10 years on Grid Computing...).

Miners could e.g. include a pointer to a webpage (or even their min fee) in the coinbase (encoded properly, like the "/P2SH/" string for BIP0016). That way clients could look it up them selves or you could create sites accumulating this information from the chain it self.

So something like :
        const char* service_sla = "|https://my_ubercool_asic_mining_pool/sla.php|";
        COINBASE_FLAGS << std::vector<unsigned char>(service_sla, service_sla+strlen(service_sla));
 
The format of the sla.php page should then be specified too - but it could be a json-rpc call returning a json object like (as result):
{ 
    sla_version: "0.1",
    accept_no_fee_tx: false,
    min_fee: 50000,
    big_tx_fee: 10000, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...

Seems like this calls for a BIP ?

/M



On 28/05/2012, at 16:54, Peter Vessenes wrote:

> 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 <moon@justmoon.de> 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

Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle.com
Web: http://www.ceptacle.com/