Re: [Bitcoin-development] Punishing empty blocks?
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::vectorunsigned 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: 5,
big_tx_fee: 1, // 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 m...@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,
[Bitcoin-development] Testnet reset for the 0.7 release
Testnet Mark III will be part of the 0.7 release, and is now in the master github branch. Mark III because this is the third genesis block for the testnet. The main reason for the reset is to get a more 'sane' test network; with the BIP16 and BIP30 and testnet difficulty blockchain rule changes the old testnet is a mess, with old clients serving up different, incompatible chains. The good news is the mess uncovered a couple of large-block-chain-reorganization bugs, but having a stable testnet to test new implementations or services is more important. Rules for tesnet3: + Minimum difficulty 1.0 (same as main net-- old testnet min difficulty was 0.125) + max-difficulty-protection rule that allows blocks to be mined at min difficulty if the block's timestamp is 20 minutes or more after the last block AND the block isn't on a difficulty-adjustment boundary. To make it easy to run either old code (using the old tesnet) and new code, the wallet and blockchain are stored in $DATADIR/testnet3 instead of $DATADIR/testnet. And to make it easy to find other testnet3-running nodes, the IRC channel used for bootstrapping is #bitcoinTEST3 (instead of #bitcoinTEST). The new testnet comes with a new blockchain that is full of interesting test cases. In particular, there are test cases for: + BIP16; early blocks were generated with a timestamp before the BIP16 switchover date, and there are transactions that test the BIP16 switchover rules + Most of the enabled Script opcodes. I created thousands of transactions that try to exercise edge cases in the Script interpreter. Missing are comprehensive tests for the signature opcodes and SIGHASH_ modes. + Block acceptance rules, including the rule on maximum block size, block times, etc (thanks to gmaxwell) If you're re-implementing Bitcoin then accepting the Mark III testnet blockchain is a good first test for compatibility. You'll still need to do a lot of work to make sure you reject the same set of invalid transactions or blocks as the original Bitcoin code. -- -- Gavin Andresen -- 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
Re: [Bitcoin-development] Punishing empty blocks?
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote: 1) Germane to the original conversation, anything hard to implement will not get implemented by miners. Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch, anything modifying the coinbase is hard to implement. 2) Coinbase is hard-limited to 100 bytes; this has to include space for voting as well as extra nonce, etc. So, I'm not sure that a full URL is a good plan. Rather, I would suggest a 20 byte keyhash, which allows the owner to broadcast a full URI out-of-band. 1) They shall prepend \mi: to the url to designate it as a url for miner info, and append a trailing \ to the url How about a simple prefix to the fixed-size keyhash? Perhaps MFR= (Mining Fee Rules) 2) The url given in the coinbase shall have http:// prepended to it before processing. I would recommend miners use https, with a specified SSL keyhash in the URI (so we don't need to pay for a proper SSL cert). 3) The destination may be a redirect (to allow short URLs), or may deliver content Clients should simply be required to follow the relevant HTTP specification. 4) The content-type returned by the final site post-redirect shall be either (preferred text/json) or text/plain or text/html text/plain and text/html are just wrong and don't make any sense here. Inre: Luke's complaint about JSON, it is the language of the web. There is no easier format for both computers and humans to read, and in this case, it includes extensibility, which is nice, since we have no idea how miners will wish to divvy up their services; I think one would need to make a strong case against JSON for a specific reason to not choose it by default. Bitcoin isn't the web, it's a complicated script-based cryptocurrency. Everything in the Bitcoin protocol requires a computer's interpretation for humans, and there's no reason to stray from this default. Also, JSON is not extensible in any of the ways needed for this specific purpose. 4) The text of the document delivered shall be a JSON format dictionary, and shall include at minimum the following fields: 'min_fee', 'pool_name', and 'last_modified' Optional fields can be determined over time as necessary by the mining community Last Modified and other caching rules are dealt with in the relevant HTTP specification... 5) The Service Level Agreement isn't binding, but miners who implement it are expected to make a best efforts attempt to follow it. While it doesn't make sense to give it the full legal force of a contract, I think it should be expressed as a MUST in the BIP. Generally a miner would occasionally publish the \mi:\ when they had updated their SLA, or just every so often, but the canonical location would be the final destination URL from the redirects. The coinbase advertisement MUST be part of every coinbase mined by the miner, or there's no reliable way to prove which blocks are theirs. -- 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
Re: [Bitcoin-development] Punishing empty blocks?
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote: I don't understand what the 20 byte keyhash is. Can you elucidate? 20 byte keyhashes are a fundamental building block of the Bitcoin protocol. ripemd160(sha256(ecdsaPubKey)) -- 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
Re: [Bitcoin-development] Punishing empty blocks?
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
3) I'm a little fuzzy on the details of BIP governance; but I'm happy to
write one up and get my thoughts down, or someone who's more familiar could
do it, I suppose.
I propose the following spec:
periodically a miner may choose to publish a url through their coinbase as
follows:
1) They shall prepend \mi: to the url to designate it as a url for miner
info, and append a trailing \ to the url
2) The url given in the coinbase shall have http:// prepended to it before
processing.
3) The destination may be a redirect (to allow short URLs), or may deliver
content
4) The content-type returned by the final site post-redirect shall be
either (preferred text/json) or text/plain or text/html
4) The text of the document delivered shall be a JSON format dictionary,
and shall include at minimum the following fields: 'min_fee', 'pool_name',
and 'last_modified' Optional fields can be determined over time as
necessary by the mining community
5) The Service Level Agreement isn't binding, but miners who implement it
are expected to make a best efforts attempt to follow it.
So a valid coinbase could be:
/P2SH/\mi:goo.gl/mr2D\extra_nonce:2110
Generally a miner would occasionally publish the \mi:\ when they had
updated their SLA, or just every so often, but the canonical location would
be the final destination URL from the redirects.
Inre: Luke's complaint about JSON, it is the language of the web. There is
no easier format for both computers and humans to read, and in this case,
it includes extensibility, which is nice, since we have no idea how miners
will wish to divvy up their services; I think one would need to make a
strong case against JSON for a specific reason to not choose it by default.
Thoughts welcome!
Best,
Peter
On Tue, May 29, 2012 at 10:47 AM, Luke-Jr l...@dashjr.org wrote:
On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
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: 5,
big_tx_fee: 1, // extra fee pr kb
}
I guess miners could work out a more suitable set of fees...
Please not JSON, and not hard-coded logic. Bitcoin already has a secure
scripting system - perhaps we can decide on an initial stack format and
run a
script retrieved from the URI?
--
Peter J. Vessenes
CEO, CoinLab
M: 206.595.9839
Skype: vessenes
Google+ https://plus.google.com/112885659993091300749
--
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
Re: [Bitcoin-development] Punishing empty blocks?
I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. Best, Peter On Tue, May 29, 2012 at 11:34 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote: I don't understand what the 20 byte keyhash is. Can you elucidate? 20 byte keyhashes are a fundamental building block of the Bitcoin protocol. ripemd160(sha256(ecdsaPubKey)) -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- 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
Re: [Bitcoin-development] Punishing empty blocks?
On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote: I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. A new message can be added to the p2p relay network, similar to tx and alert broadcasts, that allow miners to publish/update their policy URI signed by the key in question. Counter-DDoS rules could decline to relay or store URIs for keys that haven't been published in - or achieved statistical significance in - the last N blocks. -- 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
Re: [Bitcoin-development] Punishing empty blocks?
I see. That is undeniably more secure and bitcoin-y than my suggestion. It's also really a lot more work, especially in that it requires extra linkages between codebases that in my mind are largely separate. I'm just one voice, but I persist in believing that the 'lighter' solution, especially for something that may not be a particularly big problem in the bitcoin world is good -- it carries much less technical implementation debt going forward, and has a lower risk of sort of seizing up development with additional necessary code to worry about for those implementing to-spec clients. If that lighter solution turns out to be gameable, or has problems that require the full force of the bitcoin network and concepts, that would be the time to implement the improved version. That's just my approach, however. I worry that building in any additional requirements to the protocol or codebase adds significant cost to the network as a whole over the next 10 years. Peter On Tue, May 29, 2012 at 11:39 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote: I suppose I mean that I don't understand how to reverse that into a URL when one is presented only with a block, or perhaps a coinbase in a transaction. A new message can be added to the p2p relay network, similar to tx and alert broadcasts, that allow miners to publish/update their policy URI signed by the key in question. Counter-DDoS rules could decline to relay or store URIs for keys that haven't been published in - or achieved statistical significance in - the last N blocks. -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- 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
Re: [Bitcoin-development] Punishing empty blocks?
I disagree with a bunch of your points, but I'll wait on others to comment, except I will say that I don't understand what the 20 byte keyhash is. Can you elucidate? I am assuming major mining folks have written their own coinbasing facilities, but perhaps this is not the case -- if so, I agree that some work is necessary for such miners. Finally I will just comment that I am guided by the general perspective that many things about bitcoins are opt-in; therefore it makes sense to me put difficult work onto those who are motivated to do it, and keep things as easy as possible for the 'maybes' to participate -- hence small courtesies like allowing text/plain or text/html. Peter On Tue, May 29, 2012 at 11:18 AM, Luke-Jr l...@dashjr.org wrote: On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote: 1) Germane to the original conversation, anything hard to implement will not get implemented by miners. Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch, anything modifying the coinbase is hard to implement. 2) Coinbase is hard-limited to 100 bytes; this has to include space for voting as well as extra nonce, etc. So, I'm not sure that a full URL is a good plan. Rather, I would suggest a 20 byte keyhash, which allows the owner to broadcast a full URI out-of-band. 1) They shall prepend \mi: to the url to designate it as a url for miner info, and append a trailing \ to the url How about a simple prefix to the fixed-size keyhash? Perhaps MFR= (Mining Fee Rules) 2) The url given in the coinbase shall have http:// prepended to it before processing. I would recommend miners use https, with a specified SSL keyhash in the URI (so we don't need to pay for a proper SSL cert). 3) The destination may be a redirect (to allow short URLs), or may deliver content Clients should simply be required to follow the relevant HTTP specification. 4) The content-type returned by the final site post-redirect shall be either (preferred text/json) or text/plain or text/html text/plain and text/html are just wrong and don't make any sense here. Inre: Luke's complaint about JSON, it is the language of the web. There is no easier format for both computers and humans to read, and in this case, it includes extensibility, which is nice, since we have no idea how miners will wish to divvy up their services; I think one would need to make a strong case against JSON for a specific reason to not choose it by default. Bitcoin isn't the web, it's a complicated script-based cryptocurrency. Everything in the Bitcoin protocol requires a computer's interpretation for humans, and there's no reason to stray from this default. Also, JSON is not extensible in any of the ways needed for this specific purpose. 4) The text of the document delivered shall be a JSON format dictionary, and shall include at minimum the following fields: 'min_fee', 'pool_name', and 'last_modified' Optional fields can be determined over time as necessary by the mining community Last Modified and other caching rules are dealt with in the relevant HTTP specification... 5) The Service Level Agreement isn't binding, but miners who implement it are expected to make a best efforts attempt to follow it. While it doesn't make sense to give it the full legal force of a contract, I think it should be expressed as a MUST in the BIP. Generally a miner would occasionally publish the \mi:\ when they had updated their SLA, or just every so often, but the canonical location would be the final destination URL from the redirects. The coinbase advertisement MUST be part of every coinbase mined by the miner, or there's no reliable way to prove which blocks are theirs. -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ https://plus.google.com/112885659993091300749 -- 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
