Re: [Bitcoin-development] Public key and signature malleability
Any objections from other transaction-validating implementations? Sounds good to me. I think it's important to give people a chance to fix their software, but Pieter's proposal does that. On 10/21/2012 7:05 PM, Gavin Andresen wrote: Any objections from other transaction-validating implementations? I strongly support more precisely defining the transaction validity rules by changing the reference implementation. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? BitcoinJS will implement it, it's a useful feature and there is no reason not to support it. Two comments from my end: - This is just a thought, but I wouldn't mind using a new inv_type for this, e.g. MSG_MEMTX. I could conceivably see a future where broadcast and relay txs are stored in a very fast local cache whereas the general mempool is stored in a slower data structure. By being able to distinguish incoming getdata requests I can save a few milliseconds by querying the right storage right away. Might also help with things like telling apart broadcast/relayed transactions from the response to a mempool request for purposes like DoS scoring etc. Not a big deal by any means, but I also don't see a downside to it. inv_types are not a scarce resource, we have four billion of them available. For now clients would just treat MSG_TX and MSG_MEMTX interchangeably. - If a node doesn't have anything in it's mempool it sends back an empty inv message. This is either ambiguous (if other things also send empty inv messages in the future) or arbitrary (why should an empty inv be associated with a mempool request of all things.) Instead why not respond with an inv message that contains a single element of type MSG_MEMTX and hash 0. That would a very direct way to indicate that this response is associated with a mempool request. I'm not married to either suggestion, just trying to add my perspective. One thing you notice when reimplementing Bitcoin is that Bitcoin's protocol leaves out a lot of information not for space reasons, but because the reference client's implementation doesn't happen to need it. Sometimes however this locks other clients into doing things the same way. If we can make the protocol a bit richer, especially if this doesn't cost any extra bytes, then we should consider it as it might help some implementation down the road make a neat optimization. On 8/16/2012 7:56 PM, Pieter Wuille wrote: On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 I like the idea of being able to query the memory pool of a node; the implementation is straightforward, which is good. Maybe effectively using the command can be added? I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. 1) Upon receipt of a mempool message, the node will respond with an inv message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An inv message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? 3) Feature discovery is enabled by checking two version message attributes: a) Protocol version = 60002 b) NODE_NETWORK bit set in nServices This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? I would like to suggest to allocate an extra service bit for this. We still have 63 left, and this is a well-defined and useful extra service that was not yet provided by any earlier node. Doing that would also mean that mempool-providing survices may be discovered before connecting to them, as the service bits are carried around in addr messages. Any opinions about that? -- 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
[Bitcoin-development] BIP: Custom Services
Hey everyone, I was working on some custom protocol extensions for Bitcoin that I wanted to experiment with and I noticed that in order to enable nodes to announce these services the only mechanism the protocol currently provides is to use one of the 64 bits of the services field. This is obviously a resource that will run out quickly if we all just help ourselves, so I set out to come up with a standardized way to announce custom protocol extensions, without using up NODE_* flags. Please kindly review my solution: https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Services Thanks to Amir Taaki, Mike Hearn and Pieter Wuille who provided invaluable feedback while writing the draft. Note: Earlier drafts of this BIP contained a description of a mechanism for peer exchange for these custom services. However, since that part of the BIP was (1) just a recommendation and (2) rather complex, Amir and I agreed to split it off into a separate BIP [1] that will be refined some more and submitted later. Cheers, Stefan [1] https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery -- 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] BIP: Custom Services
More elaboration of the use cases might therefore be useful. I'm implementing a DHT, rather than storing the whole blockchain index locally, a future version of BitcoinJS will store only a user defined percentage (anywhere from 0-100%.) Any misses will be resolved by querying the network. Thanks to ultraprune, we no longer need a full index for verification. And for all the other use cases like lightweight server queries and block explorer queries a bit of latency is acceptable in exchange for scalability and decentralization. This feature will give people to option to run anywhere from a large BitcoinJS node (100% index) to a small one (20% index) to a lightweight one (0% index.) All of them are equally queryable, so if you're just trying out BitcoinJS you won't have to download the block chain just to run the block explorer example. Only when your block explorer's traffic grows will you need to contribute some query services back to the network in order not to get rate-limited. these capabilities are not advertised with CAddress, so how does one usefully discover and make use of them? Pieter brought up this very point when he reviewed an earlier draft. This prompted the creation of the second BIP I mentioned: https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery The basic principle is quite simple - prefix the standard addr message with a service-specific message to mark off service support. It's easy to implement and very efficient (without compression it's 1.288 bits per node, with compression it's quite possibly more efficient than the services field.) Because this stuff is a bit more complex and because it requires no changes to the Bitcoin protocol, Amir and I chose to split it off into a separate BIP and I want to work on it a little more. But if you are wondering how peer exchange might work for these custom services, please do take a look at it. you may as well just form an entirely independent network When I designed the DHT, I did just that. Later I was working on a concept for a decentralized pool and I noticed I was solving the same problems again. And with all three services running a node might be maintaining three separate TCP connections to the exact same peer. So then I considered making the DHT network extensible, so that the decentralized pool protocol could live in there. But, well if I'm doing that, why not just make the regular Bitcoin protocol extensible and let both extensions live in there. For a custom service you DO need the following: - service-specific DNS seeds - service announcement (BIP: CS) - service-specific messages (BIP: CS) - service-specific peer exchange (BIP: CSD) And those four things cover a lot of what Bitcoin does. But once you're thinking about n custom services it starts to look easier to add semantics for some nodes support some things in one network rather than instantiating n networks. On the opposite end of the spectrum there are very simple services. Consider a WebSocket transport. Some nodes might offer Bitcoin-over-WebSocket, for example to implement an SPV client in the browser. But they don't connect to each other via WebSocket, since they prefer plain TCP. So in this case you need peer exchange, but not much else. You could create a new P2P network for the sole purpose of exchanging peers, but again it seems much easier if there were ways to do this on the Bitcoin network. One final point: A major focus of this BIP is to make it easy to canonicalize custom services if we choose to do so. The idea is that custom services get to prove themselves in the wild - those that work well may be added to the standard protocol. That's a good reason to 1) encourage custom services to live in-band and 2) recommend compatibility with Bitcoin's standard mechanisms (12 byte command names, 1 bit service announcement, 1 bit peer exchange etc.) On 8/13/2012 3:15 PM, Mike Hearn wrote: I think it's pretty reasonable, although people will want to use node flags to get into the addr broadcasts anyway. That said, I suspect (based on previous discussions) that there would be quite some pushback against putting extra functionality into the core Bitcoin network. Most likely people will re-use the code with different peer discovery seeds and bootstrap similar but unrelated P2P networks for doing new applications. For instance, what if we want to do the language translation app I've talked about a few times before? You need a way to floodfill broadcast invalid transactions to interested parties. The pubsub mechanism in the Bitcoin protocol was an interesting way to do that, but I think it got removed. To broadcast to interested nodes now, you'd have to find them via addr broadcasts and then connect directly. And if you're going to do that, you may as well just form an entirely independent network. More elaboration of the use cases might therefore be useful.
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false. bool fValue = (bn2 = bn1 bn1 bn3); https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854 On 7/29/2012 6:31 PM, Amir Taaki wrote: Hi! Is this a valid script? [1 0 1, WITHIN NOT] The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of []. What am I missing here? Thanks -- 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 -- 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] script tests - invalid script in script_valid.json?
I was baffled by this exact script, too. :) Big props to Gavin for adding those data-driven test cases. I can't overstate how useful they are. Is there interest to port more tests (P2SH, checksig, checkmultisig, block verification, maybe even DoS rules) into data-driven format? It might be something that I'd like to help with if pull requests in that direction are welcome. On 7/29/2012 6:42 PM, Amir Taaki wrote: oh, bitcoin... Thanks justmoon :D - Original Message - From: Stefan Thomas m...@justmoon.de To: bitcoin-development@lists.sourceforge.net Cc: Sent: Sunday, July 29, 2012 1:33 PM Subject: Re: [Bitcoin-development] script tests - invalid script in script_valid.json? OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false. bool fValue = (bn2 = bn1 bn1 bn3); https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854 On 7/29/2012 6:31 PM, Amir Taaki wrote: Hi! Is this a valid script? [1 0 1, WITHIN NOT] The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of []. What am I missing here? Thanks -- 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 -- 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 -- 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 -- 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] Random order for clients page
I wouldn't expect any really important features which don't have complicated compromises attached to them to be omitted from all clients for all that long. True, it's those compromises that people should base their decision on. To make that easier was the motivation for me to suggest feature matrices in the first place. Right now if I read Electrum's description, it doesn't say anything about the tradeoffs with a lightweight client like the slightly weaker privacy guarantees. At best I could deduce that from the fact that unlike Bitcoin-Qt it doesn't explicitly list privacy as an advantage. So applying the same MyBitcoin test to the current Bitcoin Clients page and if you want to be fair, we'd have to assume that if it was indeed included it would also just be a short pitch listing only pros and no cons. So it would say something like: MyBitcoin starts instantly and is really easy to use and great for beginners. etc. Obviously if you compare a bad matrix to good short descriptions and vice versa you'll get the conclusion you're trying to get. I think Alan had the best idea - let's have the Clients page as it is and have it link to the wiki for those who want a more detailed comparison. On the wiki page we can then have explanations of the basic client types, separate matrices for features and for security/privacy and whatever else might be useful to know when choosing a client. Then users who don't really care aren't bothered by too much information and users who do can easily click through and find out about the different tradeoffs. On 7/10/2012 5:05 AM, Gregory Maxwell wrote: On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner etothe...@gmail.com wrote: What a feature matrix is good at though is it allows you to very quickly find the specific feature or general criteria you're looking for without reading through all of the text. So it might be a useful addition maybe not on Bitcoin.org, but certainly on the wiki. I'm generally not a fan of feature matrixes, they encourage checkbox decision making— which is seldom very good for the decider, though it's much loved by the marketing department that puts together the matrix. But just becase something is loved by marketing departments for its ability to set the agenda in variously biased ways doesn't mean its a great thing to emulate. Take the matrix Luke linked to for example[1]. Now imagine that we tunnel MyBitcoin from a year ago and drop it into that table. It would have every light green, except 'encryption' (which wouldn't have been green for bitcoin-qt then either). It would basically be the dominant option by the matrix comparison, and this is without any lobbying to get MyBitcoin specific features (like their shopping chart interface) added, not to mention the _vanishes with everyone's money_ feature. I don't think I'm being unreasonable to say that if you could drop in something that retrospectively cost people a lot into your decision matrix and it comes out on top you're doing something wrong. In tables like this significant differences like a remote hacker can rob you get reduced to equal comparison with chrome spoiler, and it further biases development motivations towards features that make nice bullets (even if they're seldom used) vs important infrastructure which may invisibly improve usage every day or keeps the network secure and worth having. Of course I want the fastest startup! Why would I choose anything else? What do you mean all my bitcoin is gone because the four remaining full nodes were taken over and reorged it all? I wouldn't expect any really important features which don't have complicated compromises attached to them to be omitted from all clients for all that long. Basically matrixes make bad decision making fast, and by making it fast it's more attractive than careful decision making that always takes time. The text is nice because it contextualizes the complete feature set and helps you understand why different clients exist, what problems they attempt to solve, and what compromises they make. ... without making the unrealistic demand of the user they they know how to fairly weigh the value of technical and sometimes subtle issues. [1] https://en.bitcoin.it/wiki/Clients -- 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 -- Live Security Virtual Conference
Re: [Bitcoin-development] Random order for clients page
You are not a developer of any alternative clients I am and I'm going to have to agree with Greg. Information about clients is bound to be transient and controversial. My relatively naive suggestion would be to move it to the Wiki. If it can handle the controversies involved with the Trade page, it should easily be able to handle the controversies involved with a Clients page like this one. A link to that page could be added under Bitcoin Wiki on Bitcoin.org. On the subject of randomization, I think that's a bad idea. Randomness does not equal fairness and more importantly it does not serve the users, which should be the overriding concern. As a user I don't want to be recommended a random client but the most sensible choice. As alternative client implementors we should not be overly concerned about Bitcoin.org recommending the wrong client, truly good clients will benefit from word-of-mouth and eventually rise to the top. If you want a fair ordering, then I'd order by number of downloads for downloadable clients and Alexa rank for any hosted / online services if it were decided that such should be listed at all. On 7/9/2012 6:09 PM, Amir Taaki wrote: JS randomisation is bad. People shouldn't need JS to view a webpage. Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is. You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards). If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website. Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now. - Original Message - From: Gregory Maxwell gmaxw...@gmail.com To: Amir Taaki zgen...@yahoo.com Cc: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Sent: Monday, July 9, 2012 5:04 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki zgen...@yahoo.com wrote: Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing it. -- 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 -- 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] Random order for clients page
I think by users you mean, geeks who understand wiki syntax. The point is to expand the circle of contributors. I'm pretty sure there are more people who can edit a wiki than people who know HTML and how to create a git pull request. :) Inability to agree on columns isn't why the page looks like that. My apologies, I vaguely remembered Luke's original proposal and that it got rejected, but you're correct, the reason wasn't a debate on the columns but that people didn't like the feature matrix at all. I didn't really mean to argue on the details of what the page should look like, but just to briefly respond to Mike's point: It looks like that because feature matrices aren't especially helpful for newbies to make a decision, especially when the features in question were often things like how they handled the block chain or which protocol standards they support, ie, things only of interest to developers. A well-designed feature matrix can quite useful and user-friendly. http://www.apple.com/ipod/compare-ipod-models/ Prose is better to get a sense of the philosophy and basic idea of a client. If it was between having only a feature matrix or only prose, I'd probably go for the prose as well. What a feature matrix is good at though is it allows you to very quickly find the specific feature or general criteria you're looking for without reading through all of the text. So it might be a useful addition maybe not on Bitcoin.org, but certainly on the wiki. On 7/10/2012 12:37 AM, Mike Hearn wrote: I strongly agree, but this is *why* I suggested moving it to the wiki. I recently had to choose an XMPP client and I looked on xmpp.org - after a frustrating experience with their listing [1] Probably because their listing is even more useless than any of the proposals that were presented here. Thank goodness it didn't end up like that. Their table doesn't even attempt to list features or differentiating aspects of each client. I think the XMPP guys have pretty much given up on directly marketing the system to end users. - more up-to-date (anyone can update them) Fortunately reasonable clients don't appear/disappear/change that often. - more in touch with users: I think by users you mean, geeks who understand wiki syntax. Because that's what it'll end up trending towards. I don't believe a wiki would reflect the needs of your average person. It's still better to have these arguments here and try to find a user-focussed consensus than hope one will converge from a wiki. If you want to see the result of internal politics, the current client page is a good example. We couldn't agree on the columns for a feature matrix, so now we just have walls of text. Inability to agree on columns isn't why the page looks like that. I know because I'm the one who argued for the current design. It looks like that because feature matrices aren't especially helpful for newbies to make a decision, especially when the features in question were often things like how they handled the block chain or which protocol standards they support, ie, things only of interest to developers. It's much easier to communicate the differences to people with a short piece of text, and maybe if there is no obvious way to explain why you'd want to use a given client, that's a good sign it's not worth listing there. Otherwise you end up like xmpp.org. Some of the options that are de-facto the most popular with users like BlockChain.info or just using your MtGox account are not mentioned at all. It's true that bitcoin.org needs to be conservative. That said, I'd like there to be sections for them too, actually. I agree that risk isn't purely about how it's implemented and that whilst we might like to push particular ideologies around protocols or code licensing, that isn't especially relevant to end users who have different priorities. Track record counts for a lot as well. -- 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] Enforcing inflation rules for SPV clients
Very interesting for you to bring this up. I had a similar idea for a totally different use case. Greg recently pointed out an interesting dilemma saying that (significantly) larger blocks would lead to centralization. So I've been working on a design for a decentralized pool that can handle gigabyte sized blocks by splitting up the work among its members. At the moment P2Pool nodes all verify all transactions in all blocks. But it seems feasible to create a system where miners who have over the last 1 blocks contributed to the pool's proof-of-work are allocated a proportional piece of verification work with redundancy and deterministic randomness that makes manipulation of the allocation extremely difficult. Such a pool would be very unlikely to accept an invalid block or transaction in practice. However, with these block sizes obviously non miners are going to have to be SPV, so even just a 0.0001% chance of an invalid block being accepted has profound implications for the network. If a decentralized pool like that had more than 50% of the hashing power and it accepted a single invalid block, that tainted chain would be forever regarded as valid by SPV clients. There needs to be some way to recover once an invalid block has been accidentally accepted by an imperfect miner. Based on that I also started to think about proofs of invalidity that would circulate. Basically you would add a new network message that would contain the proof that a specific signature and therefore the whole block is invalid. As long as the block's proof-of-work is valid and the block's parent is one of the last n = 5 blocks, the message is relayed (subject to a cooldown, warnings would be less frequently relayed the older the offending block is.) The mechanism works in exactly the way Mike mentions: It allows even SPV clients to punish any miner who is dishonest or negligent with their verification work. That gives miners a good reason not to be dishonest or negligent in the first place. (Motivation: Processing more transactions means that hashing is a smaller part of the overall cost for miners. For example, paying for 50 BTC worth of hashing per block costs 0.05 BTC per tx at 1000 tx/block, but only 0.0005 BTC at 10 tx/block. Number of transactions is a lever that lets us have lower fees and more network security at the same time. Like Greg correctly pointed out, this is not worth having if we have to sacrifice decentralization. But if we don't, it becomes a no-brainer. My IMTUO proposal [1] showed a way where miners don't need a copy of the set of unspent outputs at all. This means the minimum storage requirements per node no longer grow with the number of transactions. However, the price for this was about five times greater bandwidth usage per verified transaction. Since every miner still had to verify every transaction it looked like bandwidth would become an even bigger problem with IMTUO than storage would have been without. However, if a small miner can do less than 100% verifications and still contribute, suddenly IMTUO may become viable. That would accomplish the holy grail of Bitcoin scalability where the network successfully runs on trust-atomic entities all of which can choose to store only a small fraction of the block chain, verify a small fraction of transactions and perform a small fraction of the hashing.) [1] https://en.bitcoin.it/wiki/User:Justmoon/IMTUO On 6/24/2012 2:45 PM, Mike Hearn wrote: I've been having a discussion with d'aniel from the forums about how to handle the possibility of a majority-miner conspiracy to raise inflation, if most economic actors use SPV clients. Because of how blocks are formatted you cannot check the coinbase of a transaction without knowing the fees in the block, and the fees can only be calculated if you have all the input transactions for every transaction in that block. Because the attack scenario is an attempted takeover of the economy by miners, attempting to put hints into the blocks won't work - we have to assume the hardest chain is in fact wrong according to the rules signed up to by the Bitcoin user. The most obvious goal for a cartel of miners is to change the inflation formula, either for purely selfish reasons (they want more money than can be obtained by fees) or due to coercion by governments/central banks who still subscribe to the inflation is good idea. Whilst good nodes (still on the old ruleset) won't relay blocks that violate the rules no matter how hard they are, in a situation where an SPV client DOES hear about the bad best chain, it would switch to it automatically. And who knows how the network might look in future - perhaps most nodes would end up run by miners, or other entities that upgrade to the new ruleset for other reasons. d'aniel made a good proposal - having good nodes broadcast announcements when they detect a rule that breaks the rules, along with a proof that it did so. Checking the
Re: [Bitcoin-development] Berlin Bitcoin Hackathon
Flights booked. Mike Hearn and I will be there. :) On 6/22/2012 1:03 AM, Amir Taaki wrote: This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/ I am happy to host if space is needed. -- 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 -- 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] Near-term scalability
Thanks Mike for the writeup - I'm very sad to have missed the discussion on IRC since fee economics are probably my favorite topic, but I'll try to contribute to the email discussion instead. (4) Making the block size limit float is better than picking a new arbitrary threshold. Fees are a product of both real and artificial limits to transaction validation. The artificial limits like the block size limit are essentially putting a floor on prices by limiting supply beyond what it would otherwise be. E.g. the network could confirm more transactions theoretically, but the block size limit prevents it. The real limits are the bandwidth, computing and memory resources of participating nodes. For the sake of argument suppose a 1 TB block was released into the network right now and we'll also assume there was no block size limit of any kind. Many nodes would likely not be able to successfully download this block in under 10-30 minutes, so there is a very good chance that other miners will have generated two blocks before this block makes its way to them. What does this mean? The miner generating a 1 TB block knows this would happen. So in terms of economic self interest he will generate the largest possible block that he is still confident that other miners will accept and process. A miner who receives a block will also consider whether to build on it based on whether they think other miners will be able to download it. In other words, if I receive a large block I may decide not to mine on it, because I believe that the majority of mining power will not mine on it - because it is either too large for them to download or because their rules against large blocks reject it. It's important to understand that in practice economic actors tend to plan ahead. In other words, if there is no block size limit that doesn't mean that there will be constant forks and total chaos. Rather, no miner will ever want to have a block rejected due to size, there is plenty of incentive to be conservative with your limits. Even if there are forks, this simply means that miners have decided that they can make more money by including more transactions at the cost of the occasional dud. Therefore, from an economic perspective, we do not need a global block size limit of any kind. As guardians of the network the only thing we need to do is to let miners figure out what they wanna do. HOWEVER, the existing economic incentives won't manifest unless somebody translates them into code. We have to give our users (miners endusers) the tools to create a genuine fee-based verification market. On the miner side: I would make the block size limit configurable with a relatively high default. If the default is too low few people will bother changing it, which means that it is not worth changing (because a majority uses the default anyway), which means even fewer people will change it and so on. The block size limit should also be a soft rather than a hard limit - here are some ideas for this: - The default limit for accepting blocks from others should always be significantly greater than the default limit for blocks that the client itself will generate. - There should be different size limits for side chains that are longer than the currently active chain. In other words, I might reject a block for being slightly too large, but if everyone else accepts it I should eventually accept it too, and my client should also consider automatically raising my size limit if this happens a lot. The rationale for the soft limit is to allow for gradual upward adjustment. It needs to be risky for individual miners to raise the size of their blocks to new heights, but ideally there won't be one solid wall for them to run into. On the user side: I would display the fee on the Send Coins dialog and allow users to choose a different fee per transaction. We also talked about adding some UI feedback where the client tries to estimate how long a transaction will take to confirm given a certain fee, based on recent information about what it observed from the network. If the fee can be changed on the Send Coins tab, then this could be a red, yellow, green visual indication whether the fee is sufficient, adequate or dangerously low. A criticism one might raise is: The block size limit is not to protect miners, but to protect end users who may have less resources than miners and can't download gigantic block chains. - That's a viewpoint that is certainly valid. I believe that we will be able to do a lot just with efficiency improvements, pruning, compression and whatnot. But when it comes down to it, I'd prefer a large network with cheap microtransactions even if that means that consumer hardware can't operate as a standalone validating node anymore. Headers-only mode is already a much-requested feature anyway and there are many ways of improving the security of various header-only or lightweight protocols. (I just saw Greg's message advocating the opposite
Re: [Bitcoin-development] SatoshiDice and Near-term scalability
I do agree that changing/lifting the block size limit is a hard fork measure, but Mike raised the point and I do believe that whatever we decide to do now will be informed by our long term plan as well. So I think it is relevant to the discussion. Can someone please help quantify the situation? kthanks :) According to BlockChain.info we seem to have lots of small blocks of 0-50KB and some larger 200-300 KB blocks. So in terms of near term measure one thing I would like to know is why miners (i.e. no miners at all) are fully exhausting the available block size despite thousands of transactions in the memory pool. I'm not too familiar with the default inclusion rules, so that would certainly be interesting to understand. There are probably some low hanging fruit here. The fact that SatoshiDice is able to afford to pay 0.0005 BTC fees and fill up the memory pool means that either users who care about speedy confirmation have to pay higher fees, the average actual block size has to go up or prioritization has to get smarter. If load increases more then we need more of any of these three tendencies as well. (Note that the last one is only a very limited fix, because as the high priority transactions get confirmed faster, the low priority ones take even longer.) On 6/15/2012 7:17 PM, Jeff Garzik wrote: On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas m...@justmoon.de wrote: The artificial limits like the block size limit are essentially putting [...] Changing the block size is an item for the hard-fork list. The chance of the block size limit changing in the short term seems rather low... it is a nuclear option. Hard-fork requires a very high level of community buy-in, because it shuts out older clients who will simply refuse to consider 1MB blocks valid. Anything approaching that level of change would need some good, hard data indicating that SatoshiDice was shutting out the majority of other traffic. Does anyone measure mainnet normal tx confirmation times on a regular basis? Any other hard data? Clearly SatoshiDice is a heavy user of the network, but there is a vast difference between a good stress test and a network flood that is shutting out non-SD users. Can someone please help quantify the situation? kthanks :) -- 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] JSON-RPC is BIP territory or not?
Since several independent clients (I know at least libcoin https://github.com/ceptacle/libcoin/blob/master/src/coinHTTP/RequestHandler.cpp and BitcoinJS https://github.com/bitcoinjs/bitcoinjs-server/tree/master/lib/rpc) aim to implement JSON-RPC APIs which are either a superset of the original client's or have at least some compatible functions, I think you can make a case for including JSON-RPC API calls within the domain of BIPs. In this instance the BIP aims to create a common protocol between different clients, miners, mining proxies and pools. That's a lot of software, so standardization definitely seems like a good idea and I can't think of a reason not to use the BIP process. I have some comments on the content of the BIP, but since this thread is more of a meta-discussion I'll wait until the BIP is officially proposed. On 3/2/2012 7:51 PM, Amir Taaki wrote: Hi, I got sent this BIP: https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool What is your opinion on this? Is it BIP related? It is a implementation-specific non-bitcoin-protocol proposal. My understanding of BIPs is that they apply across bitcoin implementations and largely focus on the most generic use-cases (like the URIs) and the protocol. Things which affect all clients, and allow the system to function as a united whole. That BIPs especially focus on the protocol, and that something like this is outside the mandate of the BIP process. For instance, we could imagine a future scenario. Bitcoin-Qt is currently based off bitcoind's codebase. However wumpus built the client in mind with an abstraction layer to enable multiple backends (a good design). In our hypothetical situation, there are 3 different backend codebases using Bitcoin-Qt. I do not think a proposal to mandate a changing to Bitcoin-Qt's abstraction layer or a change in the UI placement would be appropriate BIP material. OTOH, many clients do need to make use of URIs and the BIP process is totally correct, as it standardises a behaviour which is needed for interoperability of the network and community. Thoughts? -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] getmemorypool BIP process
I've updated the draft to include long polling, and remove some assumptions of using HTTP for transport. Looks good to me. On 3/3/2012 4:44 PM, Luke-Jr wrote: On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote: HTTP and JSON-RPC are a client-server model; there is no way for the server to make calls to the client. It's not practical to expect clients to run their own JSON-RPC server - many cannot listen on WAN ports at all. You're doing that thing where either you say something before you've done adequate research, or you're being needlessly pedantic; I just copied and pasted this from section 2.1 of the JSON-RPC spec: I wasn't aware anyone was considering JSON-RPC over anything other than HTTP. I've updated the draft to include long polling, and remove some assumptions of using HTTP for transport. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] getmemorypool BIP process
Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S-C json-rpc, what (javascript) library do you use for this? As for an explicitly standard way, there is none. The JSON-RPC 1.0 spec http://json-rpc.org/wiki/specification says The specifications do not require a certain transport protocol. The use of TCP/IP socket streams is encouraged. The serialized request and response objects are sent to the peers through the byte streams. The JSON-RPC 2.0 spec http://jsonrpc.org/specification goes out of its way to say It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. The de-facto standard for bidirectional JSON-RPC is plain TCP sockets. BitcoinJS currently implements this - we detect whether an incoming connection is HTTP or raw JSON-RPC based on the first character. (HTTP must start with an uppercase letter, raw JSON-RPC must start with an opening curly bracket.) There are two things to watch out for with JSON-RPC over plain TCP: 1. Plain TCP sockets (unlike HTTP) have no standardized authentication mechanism, so I added an extra RPC call auth(username, password). 2. The TCP packets may or may not correspond to JSON-RPC messages. You can either use a streaming JSON parser (yajl in ANSI C, Jackson in Java, etc.), or you can just count (non-string-literal) curly braces to detect when a complete message has arrived. Many JSON-RPC libraries come with TCP socket support out of the box: http://json-rpc.org/wiki/implementations We're planning to add more features to our JSON-RPC API in the future, such as: - JSON-RPC over TLS sockets - Challenge-response authentication - TLS client handshake (certificate authentication) As for HTTP Keep-Alive: It works, but I don't think it's very widely supported among client libraries and HTTP isn't really made for this type of thing, so my gut instinct would be to avoid it. That said, it doesn't hurt to offer the option. On 3/3/2012 6:08 PM, Michael Grønager wrote: HTTP and JSON-RPC are a client-server model; there is no way for the server to make calls to the client. It's not practical to expect clients to run their own JSON-RPC server - many cannot listen on WAN ports at all. Well, I think what Stefan had in mind was http keep-alive combined with an event system. So similar to the way a web chat application work, just for json-rpc. BitcoinJS already uses this for realtime updating a webwallet. Libcoin is also prepared for this with a quite advanced, non-blocking, http server so I second Stefan that an update function could indeed be of relevance. Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S-C json-rpc, what (javascript) library do you use for this? Cheers, Michael -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
I'm firmly against a *blackout* - it would harm users' trust in Bitcoin since people looking to download the client or to get information about Bitcoin may end up in the wrong place. I constantly have to delete YouTube spam advertising this or that miracle GPU miner or secure Bitcoin client, which of course are all just the same trojan. As for making a statement or putting up a banner - that's ok with me. On 1/17/2012 7:15 AM, Gregory Maxwell wrote: On Mon, Jan 16, 2012 at 9:37 PM, Kyle Hendersonk...@old.school.nz wrote: For those that believe one particularly noisy country in the North America region with a policy called SOPA or PIPA directly affects Bitcoin - can you point out precisely where it does so? In addition to the concerns about internet freedom and domain name system filtering which are against the interests of bitcoin users and the bitcoin system generally, SOPA contains new requirements for payment networks which may adversely impact Bitcoin services businesses and limit their ability to do business in the US and other places where similar legislation is adopted. There are many millions of potential Bitcoin users in the US, so US law matters for our ecosystem even though far from all Bitcoin users are in the US themselves. (21) PAYMENT NETWORK PROVIDER- (A) IN GENERAL- The term `payment network provider' means an entity that directly or indirectly provides the proprietary services, infrastructure, and software to effect or facilitate a debit, credit, or other payment transaction. [...] (i) PREVENTING AFFILIATION- A payment network provider shall take technically feasible and reasonable measures, as expeditiously as possible, but in any case within 5 days after being served with a copy of the order, or within such time as the court may order, designed to prevent, prohibit, or suspend its service from completing payment transactions involving customers located within the United States or subject to the jurisdiction of the United States and the payment account-- (I) which is used by the foreign infringing site, or portion thereof, that is subject to the order; and (II) through which the payment network provider would complete such payment transactions. If you really want to go for the more extreme interpretation, it's not hard to conclude that the Bitcoin system itself is a payment network by the definition under the act, and if so in theory the AG's office could— without due process— order miners and mining pools located in the US to, for example, not process transactions containing the well known addresses of targeted infringing sites (e.g. The Wikileaks donation address). Though I personally think this is far out. I also think that other people will covered the SOPA/PIPA awareness (e.g. Wikipedia is shutting down for 24 hours) more than we could possibly do with our own resources. But this attitude of it being someone elses problem? I think thats nonsense. We live in _one world_, one world which is getting smaller every day. The value of a network—or of a economy— comes from the number of potential connections it can make. One reason Bitcoin is good is because it deconstructs some of the old barriers and anything that risks imposing new ones is a threat to us all. So, don't participate because bitcoin.org's help would be so small as to be pointless— sure. But because it doesn't matter? hardly. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternative to OP_EVAL
+1. I love this proposal. It's two less bytes than OP_EVAL even. It allows static analysis. It doesn't require any change to the script interpreter. (You can do a static replacement step between parsing and execution.) It allows all urgent use cases. It doesn't consume a NOP. If we ever want recursion or something else, we can still add OP_EVAL,... then. @roconnor: 1. make the script: OP_NOP1 HASH160 push-20-byte-hash EQUAL to make it extremely easy to see from the first byte that this is verly likely to be a special transaction (or more accurately if the first byte isn't OP_NOP1 then you immediately know it isn't a special script and can even disregard the token). I disagree. If people actually do mean HASH160 hash EQUAL, let *them* add a NOP. Or better to avoid NOP let them use HASH160 hash EQUALVERIFY 1. Point is, if you don't want code replacement you can easily break the pattern. But code replacement will be overwhelmingly more common, so it should be as small as possible. Every byte matters. On 1/2/2012 4:59 PM, Gavin Andresen wrote: Here are my latest thoughts on a safer OP_EVAL alternative, inspired by all the ideas and agitated IRC and email discussions of the last week or so: Goal: Let users publish a short funding address that is the hash of an arbitrary redemption Script revealed when they spend the funds, implemented in a backwards-compatible-in-the-blockchain way. Proposal: A new 'standard' transaction type, pay to Script hash: scriptPubKey: HASH160push-20-byte-hash EQUAL Redeemed with the same scriptSig as the OP_EVAL proposal: signatures serialized Script Old clients/miners will ignoresignatures and just validate that the hash ofserialized Script matches. New clients/miners will recognize the new type of transaction and will do the following additional validation: 1. Fail validation if there were any operations other than push data in the original scriptSig. 2. Deserialize the top (last) item on the scriptSig stack (fail validation if it fails to deserialize properly). 3. Run an additional validation on the deserialized script, using the remaining items on the scriptSig stack and the deserialized script as the scriptPubKey. --- As Amir said in IRC chat today, the idea is a hack but I like it. I like it, too-- it is cleaner than OP_EVAL, more straightforward to implement, and pretty much exactly matches the feature I care about (moving code from the scriptPubKey to the scriptSig). There are no special cases like CODESEPARATORS not allowed inserialized script. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent
Nice. I'll check with justmoon when I hopefully meet him at the conference. It's all fine with me. As soon as the original client switches to the new format, we will, too. On 11/13/2011 09:52 PM, Amir Taaki wrote: Nice. I'll check with justmoon when I hopefully meet him at the conference. If all is OK, hopefully 0.6 will be the last protocol version bump for a while. From: Mike Hearn m...@plan99.net To: Amir Taaki zgen...@yahoo.com Cc: "bitcoin-development@lists.sourceforge.net" bitcoin-development@lists.sourceforge.net Sent: Saturday, November 12, 2011 7:31 PM Subject: Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly. On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki zgen...@yahoo.com wrote: Hi, https://en.bitcoin.it/wiki/BIP_0014 Thanks to Gavin Andresen for proof reading and suggesting clarifications. Thanks to Patrick Strateman for suggesting the hierarchical format and pointing out some flaws of browser user-agents to me. The timeline is written in the past tense since BIPs are meant to be readable in the future for explaining why we took certain decisions with bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;) The next version 0.6 should be the protocol version which becomes peeled off from the current client. There are still some changes migrating into the protocol that need to be finished. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request review: drop misbehaving peers
A few thoughts: Should the DoS protection auto-disable if the node has less than a minimum number of connections? The idea being that if our node seems to be kicking /everybody /off the roster maybe there is something wrong with the protections. It would be nice if the node sent a message to the banned peer with a code indicating the reason for the ban, specifically the offense that put Bitcoin over the edge. Logging the reason is probably fine for most cases, but I wanted to put the idea out there, because it might make debugging easier if there are some weird bans happening in the wild and we can't figure out why. Should sending lots of messages that don't pass the protocol-level checksum test be a bannable offense? Or generally sending garbage data? The attacks I'm thinking of are cross-protocol attacks. So as rough example: The attacker puts an iframe on a website with a url like http://victim.com:8333 so lots of people's browsers connect to it. Maybe he could even use something like [magic-bytes]tx\0[...][valid orphan transaction] in the URL, so the browser would send GET /[magic-bytes] etc. and the Bitcoin node would interpret it. kjj wrote: A few non-standard transactions are probably legitimate. A whole bunch of them are probably not. I would think that assigning a point or two of badness to a peer sending one is pretty reasonable, with the understanding that we would need to adjust that as the network evolves. Strongly disagree. What is a non-standard transaction today may /be /a standard transaction tomorrow. On 9/15/2011 2:25 PM, Gavin Andresen wrote: Thanks Mike, that's exactly the kind of detailed review I was looking for. I think you're right an all points. I'll simplify: I'll add a -banscore option (default 100), and if a node accumulates more than -banscore misbehavior points it'll get dropped and banned for -bantime (default 60*60*24) seconds. I'll make bad signatures a banning offense, and I'll remove the number-of-sigops and non-standard-transaction penalties. I used a mutable field with const setter to avoid modifying a bunch of methods to take non-const blocks/transactions instead of const; I think it is appropriate because a block/transaction's DoS score is really meta-data and not part of it's state. I'll make GetTime() unit-test friendly as you suggest. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
