Re: [Bitcoin-development] Multisignature transations
On Fri, Sep 30, 2011 at 1:21 PM, Gavin Andresen gavinandre...@gmail.com wrote: Accepting this does not preclude adding more 'standard' transaction types in the future. I think 2 of 3 is a _far_ more useful example than (a or b), it is the prototype for a normal escrow transaction., and still only results in three address and at most two signatures like the (A and B) or C case. You can also replicate the functionality of (a or b) in a hashish and inefficient sort of way with two of three by simply using a public known key as one of the roles. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote: You give the hash to whoever is paying you, and store the hash -- script mapping when you do that (assuming you're not using a deterministic wallet; if you are, you probably just increment a counter in the wallet). If anyone finds that solution unsatisfying, consider— It's already the case that I could take one of your disclosed public keys and create an infinite series of secondary keys out of it for which only you could decode, and the only way for you to find them in the blockchain would be to have performed the same procedure and made a note of the addresses you're watching for. ... or really, more simply I could generate a private key on your behalf and send funds there. (What do you mean you didn't get the funds? I sent them to the private key defined by the cryptographic hash of the lyrics of your favorite song!) So it's already the case that if I didn't get your address from you (or through a negotiation with you), I can't expect you to receive them. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote: I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping: The additional material _IS_ then part of the private key. It's not something seperate. Its something you need to know in order to author the address. This was fundamentally my argument. Not that you could hide information, but that information was already hidden. Right now under conventional uses I can't identify all the transactions that land in your wallet, because I don't know the keys it contains. With the proposal it's the same situation. This possibility is used today in: * blockexplorer * bitcoin-js * my own tiered implementation for thin clients [snip] So, if we introduce a standard (multikey) payment that hides the address (or makes it overly complicated to extract it) it will be a major problem for the projects that I listed above. These projects will be able to use the _same_ procedure to extract the identifying information. Except now instead of ripemd160(sha256(pubkey)) it will be more like ripemd160(sha256([some extra bytes generated by the wallet holder]||pubkey)) that you extract. If the former is not a problem for these applications, why is the latter? -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell tyrell.el...@gmail.com wrote: On 2012-01-02 05:31:19 -0800, Christian Decker said: Later full blocks would be required to detect usable inputs for future outgoing transactions. Er, yes, this is what I meant; I guess I should have been more specific. So, a paranoid client cannot confirm reciept of coins until it has an unstubbed copy of the entire chain. It can do other things (like send coins) using a stubbed chain, but it needs the whole unstubbed chain in order to be sure that incoming coins haven't already been spent. Thanks for confirming this. Er, no— if a node controls the private keys for a transaction, and that transaction makes it into the chain then it can safely assume that its unspent (at least once its buried a few blocks into the chain). This is the essence of a SPV node. What it can't do is perform this function for txn which aren't its own. Though the system could be extended in a compatible manner to make this possible: https://bitcointalk.org/index.php?topic=21995.0 -- 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] bitcoin.org SOPA/PIPA blackout
On Mon, Jan 16, 2012 at 9:37 PM, Kyle Henderson k...@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
Re: [Bitcoin-development] Quote on BIP 16
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki zgen...@yahoo.com wrote: How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? ... No it's not a mistake. P2SH _prevents_ needing long addresses. Lets unpack the acronym pay to script _hash_. Hashes only need to be 128-256 bits in size or so to have acceptable security, so you don't need something longer than that for paying to a hash. Note that gavin is saying 70 characters, not bytes. Without some form of P2SH then only way for you to make a personal choice of asking people to pay to a two-factor protected account or two a multiparty trust that manages the finances of an organization is using some form of P2S, pay-to-script. In other words, you'd have to have an address that encodes a full script specification for the sender to pay to, instead of just encoding its hash. As a result these addresses would be much longer (and potentially very long). The minimum size of a two address involving encoded script would be on that order, but they get bigger quite quickly if you add more options to the script (actually 70 sounds quite small, it should be more like 100 for a minimum two pubkey script). In addition to the unworkability of very long addresses as described by gavin (amusingly I am unable to copy and paste the quoted example in one go) a P2S solution has several problems which you might consider more or less important: (1) They are highly vulnerable to invisible substitution. E.g. I can trivially take a P2S address, change one or two characters and get a script which is redeemable by anyone. With P2SH you have to do computation which is exponential in the number of unchanged digits to get a look alike address. (2) The sender is fully responsible for fees related to the enlarged transactions. Even if _you're_ willing to take the txn-processing time and fee burden of a 30 person joint trust address, random e-commerce sites will not be and will randomly reject your addresses. (3) They create another input vector for non-trivial data which must be inspected and validated, potentially presenting an attack surface. (4) They leave the complicated (long) release rules in the transaction outputs. When a transaction is mined we can't be sure if it will ever be redeemed. The outputs are unprunable. In a future world where many nodes prune output space is far more important than input space and it would make sense to require more fees for it because we're never sure how long it would need to be stored (making it an attractive target for someone who wants to make Bitcoin unusable by spamming it with worthless data). P2SH reduces output sizes to the absolute minimum without inflating the total data size. -- Try before you buy = See our experts in action! 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-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: I've also been wondering if it is time to remove the IRC bootstrapping mechanism; it would remove a fair bit of code and we'd stop getting reports that various ISPs tag bitcoin as malware. When testing the list of built-in bootstrapping IP addresses I always connect fairly quickly, and the DNS seeding hosts seems to be working nicely, too. Sο— would we remove it or leave it deactivated as a fallback users can turn on? I have two different thoughts about IRC depending on the answer. I think it's important that we have more mechanisms then just DNS and hardcoded seednodes. This is important because the mechanisms we have are all pretty subject to blocking. Now— before you say it— Bitcoin isn't intended to be blocking resistant (combine it with Tor and Tor anti-censorship tools) but by making blocking a bit harder we discourage people from even trying, even if we're not seriously in the anti-blocking business— and it gives bitcoin users more confidence because there is a bit less FUD What if your ISP blocks it?? It uses DNS! Someone might take away the domains! SOPA PIPI ACTA CIPA Alakazam. Is the fact that users can addnodes / addr.txt enough of an alternative to address this? _If so_, then removing it is a good idea. I volunteer to maintain a multi-channel joining node for the foreseeable future to avoid letting old clients get partitioned (several people need to do this). An area where I think our mechanisms are inadequate absent IRC is announcing new nodes. I had a new listener up for over a week recently and was basically getting no inbound until I enabled IRC. I volunteer to do some measurement of this (e.g. bring up some nodes with no irc and find out how long until sipa hears about them). If DNS seeds are slow to learn about new nodes we may need to add a simple UDP announcement feature. In any case, I hadn't been thinking that we would completely remove IRC— I was expecting us to keep IRC around but turned off. In particular I think it may be a little risky to turn off IRC at the same time as deploying addrman, because if addrman has unexpected bad behavior IRC is what may keep things going. Obviously it should be well tested enough to feel confident, but belt-and-suspenders is the way to go. If we do keep in the long run I think it's important to _fix_ IRC. Right now it has some really stupid behavior which is highly pro-partitioning. */who only returns a few nodes, and because most idlers aren't actually working (no port forward) it's usually for there to be only a few that work. (I've never seen zero, but I've seen 1). *Other than who we only learn about nodes when they join. But the stable long lived nodes we need to hear about seldom rejoin. Nonuseful windows boxes go up and down a lot. *Nodes sit in a single channel forever. There are 100 of them. Especially with fewer clients on line nodes may be sitting alone with no correctly working nodes with them. *Nodes recently seen on IRC are highly promoted in the peer selection. So, here is an updated irc.cpp which I've been running (in various versions) for a while: http://people.xiph.org/~greg/irc.cpp It does the following things: * Only stays connected for a half hour * If its sure its not listening it uses a random nick so people won't try to connect * Reconnects if it needs more connections * If the node is actually listening (evidence by actual incoming connections) it reconnects on its own every 1-2 hours and joins two channels at random rather than one. (it doesn't change peer selection— It's hard to be confident of the impact of that change. I think addrman makes it less of an issue) I've only not submitted it as a pull request because I haven't had a chance to test to my standards, and because I felt unsure about the future of IRC. I feel strongly that if we're going to keep IRC as a backup we should fix it. If we're not going to bother then thats fine— but I think we need to think carefully if we're doing enough for bootstraping (with the points I made) without it. Certainly getting it off by default would be a good move. The botnet allegations are horrible. -- 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] BIP 20 Rejected, process for BIP 21N
On Tue, Jan 31, 2012 at 9:33 AM, slush sl...@centrum.cz wrote: excuse me if it was already discussed, but maybe using satoshis instead of decimal bitcoin would be better choice? We all know about pains with proper handling decimal numbers across of all implementations - and it's not only about json-rpc. Mixed bag of worms there, even ignoring what people have already implemented— if you make it use satoshis people who are working with things at COIN scale are inevitably going to end up multiplying numbers stored as radix-2 floating point to get satoshis and then are going to be confused when it comes out wrong. Using decimal numbers at least lets them treat the values as strings and avoid arithmetic that will end up confusing them. -- 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] BIP16/17 replacement
On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins andypark...@gmail.com wrote: Hello, Gulp. Am a little nervous about wading into this swamp. However, it seems to me that the debate has veered into the personal and away from the I think you've been deceived by people who have some interest in promoting this as some sort of big controversy, or perhaps just confused by the general level of noise. The differences between BIP16/BIP17 are technically obscure, everyone who is well versed in the issue (with the potential exception of Luke). There is broad consensus among the involved technically minded parties over just about all of it. Luke has been maintaining an opinion tracker page: https://en.bitcoin.it/wiki/P2SH_Votes reflecting the views of core developers and people who've been technically involved enough to have an informed opinion. Surely if there are objections to both suggestions, that another solution might be better? There is always a different color that the shed could be painted. Expecting absolute consensus on the _best_ way forward is an unreasonable standard, especially if you're going to invite the opinions of many people. Depending on how you count we have considered a good two dozen options in this space— Starting with the OP_CAT key combinations many months back, and including many variants of the current ideas. The BIPs only represent the final surviving ideas. In particular, BIP16 was the isolated consensus path forward that came out of the discussions about the concerns that BIP12 was too computationally powerful— I don't think I can identify any particular person as the author of the BIP16 idea. At the the time BIP16 became a BIP only Luke was actively objecting to it. Though his hard work and tireless (...unstoppable dogmatic) promotion he's managed to build a workable alternative, and it now has some support other than himself. This, however, doesn't constitute a material schism. this idea up for my traditional mailing-list roasting but with the hope that As always, asbestos underwear is required. If the change is going to be a big one anyway and will require a client upgrade why not... It does not, in fact— Yes, it requires a client update to make use of the new functionality, but old nodes will happily continue to validate things. It's hard to express how critical this is distinctly. Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that things were done right, the validate them for themselves. A breaking change of the kind you suggest is not something that would be considered lightly, and this is certainly not justified for this. - Increase the version number in transactions to make a new transaction structure - Dump the scriptPubKey field completely. Everything will be pay-to- script-hash in version2 transactions - Replace it with hashOfClaimingScript - Add an unsignedParameters array. If we ever were to scrap the system, I think we very much would do something like what you describe here... and as much has been documented: https://en.bitcoin.it/wiki/Hardfork_Wishlist (see Elimination of output scripts) But, to be clear, this stuff is pretty much fantasy. I'm doubtful that it will ever happen, doubtful that we can get the kind of development resources required to pull off a true breaking change in a way that people would actually trust upgrading to— at least not before a time that the system is simply too big to make that kind of change. -- 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] Announcement: libcoin
On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager grona...@ceptacle.com wrote: The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop! Very interesting. Do you know where this speedup came from? It's not typical for straight refactors that don't change datastructures and the like to see such big speedups. I see you have commented out code that disables fsync, which was my first guess since I get big speedups from doing similar things. -- 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] Announcement: libcoin
On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote: sync, libbitcoin only made it to height 138k (of course, because the time is mostly spent late in the chain 138k is not very far along— I'm guessing it's going to take libbitcoin 3x-4x longer all said) It ended up taking almost exactly twice as long, FWIW. -- 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] Announcement: libcoin
On Thu, Feb 2, 2012 at 12:36 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote: sync, libbitcoin only made it to height 138k (of course, because the time is mostly spent late in the chain 138k is not very far along— I'm guessing it's going to take libbitcoin 3x-4x longer all said) It ended up taking almost exactly twice as long, FWIW. (and Gah: forgive the autocompletion of my fingers: I'm apparently unable to type the word coin without prefacing it with bit) *libcoin* not libbitcoin. -- 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] Duplicate transactions vulnerability
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves supp...@pi.uk.com wrote: One more thing to add. The implementation in the reference patch fixes the blockchain forking issue however by still allowing spent coinbases to be disconnected patched clients are still vulnerable to blockchain corruption. While not an immediate issue it would mean LoadBlockIndex() would error on restart and could cause problems for new clients during the initial blockchain download. I am not following you here, can you explain what you're thinking? Is there a reason not to disallow duplicate coinbases entirely? Because this would make it impossible for nodes to prune the vaules. They'd all forever have to keep a set of all the coinbase hashes in order to perform the test. The height-in-coinbase BIP will make duplicates effectively impossible to create, which is a much more clean behavior. -- 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] Fwd: Proposal for a new opcode
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd w...@uchicago.edu wrote: Dear all, I am proposing a new opcode for the purposes of anonymous transactions. This new opcode enables scripts to be given proof that the receiver can carry out or has carried out a previous transaction. I'm currently working on a paper that discusses using this opcode for anonymous transactions. Here is an alternative protocol: N parties wish to purchase equal amounts of Bitcoin without the exchange being able to link their future transactions, they each put the relevant amount of gold/whatever up at the exchange. The exchange provides the exchanges public key, and the user provides a public key for signing. Externally the N participants agree on a collection of non-cooperating mixers (the mixers may actually just be the participants themselves, independent third parties, etc). Each participant generates a new bitcoin address, and encrypts it with the the public keys of the the exchange and all the mixers using an appropriate communicative homorophic scheme (or just a layers stack of regular encryption keys). The participants then combine their encrypted addresess into a block and hand it off to the mixing chain. Each mixer randomizes the order and decrypts all the messages with its key. At the end of the chain the exchange does the final decryption and presents a list of addresses to the involved users. Users validate that their address is in the set and sign the entire set. Once all involved users have signed, the exchange pays. This requires no changes to the Bitcoin system and could be trivially implemented by anyone interested. It provides anonymity which is strong so long as any one of the mixers is uncompromised. It has very low overhead. It is not directly resistant to disruption, but if participation in an identified round requires a key provided by the exchange, abusive users can be detected and excluded. Have I explained this clearly enough? I could probably implement the whole system it if its unclear. Can you contrast this with your proposal for me? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for a new opcode
On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd w...@uchicago.edu wrote: -My protocol works, your's doesn't. It's not enough to have a mix, the mix needs to be verifiable to avoid one of the mixers inserting their own key and removing a key that should be in there. That doesn't mean you can't make your protocol work with some more magic, but magic is required. If the final step fails (someone says their address is missing) you challenge the mixes to disclose half of their correspondences. You can then prove which (if any) mixes defected. Why I didn't bother elaborating is ... I think you can even avoid the fancy protocol where you must take care to only disclose alternating halves at each mix because the addresses are throwaway: If the it fails in the final stage everyone publishes _everything_ and the cheater is instantly and provably identified and can be excluded from the next attempt which is then performed using totally new addresses and the disclosed addresses are never used. Care would need to be taken to avoid fake-failures (e.g. the exchange says 'it fails' triggering disclosure then sending anyways— but the participants could prove this cheating and stop using the exchange), I think there isn't much risk there if the participants are themselves the mixes. I need to think this through a bit more. [snip] On a related note, private keys and signatures have better proofs of knowledge then hashes. Has this been considered in the P2SH conversation? There might be ways to use this to make even better methods for enhancing anonymity. It's not something I thought about— In general the P2SH tends to be a superset of other schemes, e.g. you can do a signature to prove you access to a private key, then you can show someone a script using that key to show control of a P2SH address. There are lot of interesting things you can do with bitcoin if you can construct (potentially interactive) proofs for knowing the preimages of hashes. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bootstrapping full nodes post-pruning
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn m...@plan99.net wrote: I remember some people, Greg in particular, who were not a fan of approach (2) at all, though it has the benefit of speeding startup for new users as there's no indexing overhead. I'm not a fan of anything which introduces unauditable single source material. Trust us is a bad place to be because it would greatly increase the attractiveness of compromising developers. If we wanted to go the route of shipping pruned chains I'd prefer to have a deterministic process to produce archival chains and then start introducing commitments to them in the blockchain or something like that. Then a client doing a reverse header sync[1] would bump into a commitment for an archival chain that they have and would simply stop syncing and use the archival chain for points before that. This would leave it so that the distribution of the software could still be audited. More generally we should start doing something with the service announcements so that full nodes that don't have enough bandwidth to support a lot of syncing from new nodes can do so without turning off listening. [1] https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync -- 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] Near-term scalability
[I originally sent an earlier version of this message to Mike off list, but I figure it's worth adding to the public discussion] On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn m...@plan99.net wrote: (4) Making the block size limit float is better than picking a new arbitrary threshold. On the forums Matt stated that block chain pruning was a no-go because it makes bitcoin more centralized. I think we've thrashed this one out sufficiently well by now that there should be a united opinion on it. By itself letting the size float has non-trivial existential risk. A Bitcoin with expensive transactions due to competition for space in blocks can be front-ended with fast payment systems and still provide the promised decentralized currency. Bitcoin with a very large blockchain and blocks does not. It would do the bitcoin users no good to increase the transaction volume while concurrently making Bitcoin more or less pointless over the alternatives. Scalability must be improved, we can unite on that opinion. But scalability can't come at the expense of what made Bitcoin worth having in the first place. Fortunately it appear to be possible to greatly increase the scalability without compromising on keeping the costs of operating a fully validating node very low, for example Pieter's experimentation with txout+txid indexing (for the 'flip the chain' proposals) indicates that the data required right now to validate further transactions is only about 85MiB— and that would be somewhat smaller with compression and with clients which intentionally try to reduce the set of unspent transactions. Commitments to these indexes in the chain would allow almost-full validating nodes with fairly limited resources. (Almost-full meaning they would not validate the history long before they started, they'd trusted header difficulty for that. They could still mine and otherwise act as full nodes). Achieving scalability improvements without breaking the radical decentralization will be a lot harder than just improving scalability but it's effort that is justified if the scalability is actually needed. How much decentralization is needed in the end? That isn't clear— As much as possible should generally be the goal. Modern currencies aren't controlled by single parties but by tens of thousands of parties locked in economic, legal, and political compromise that limits their control. In Bitcoin the traditional controls that keep parties honest are non-existent and if they were just directly applied we'd potentially lose the properties that make Bitcoin distinct and useful (e.g. make all miners mine only with FED permission and you just have a really bandwidth inefficient interface to the dollar). Instead we have aggressive decentralization and autonomous rule enforcement. Mike pointed out that Before he left Satoshi made a comment saying he used to think Bitcoin would need millions of nodes if it became really popular, but in the end he thought it could do fine with just tens of thousandsI'm not so sure— and I think the truth is in between. Tens of thousands of nodes— run by a self-selecting bunch of people who reap the greatest rewards from controlling the validation of Bitcoin, who by that criteria necessarily have a lot in common with each other and perhaps not with the regular users— could easily be an outcome where control is _less_ publicly vested than popular government controlled currencies. We probably don't need the raw numbers of nodes, but we need a distribution of ownership and a distribution of interest (e.g. not a system by bankers for bankers) of those nodes which I think can only be achieved by making them cheap to operate and having a lot more than we actually need. — though not so much that it has to run on every laptop. The core challenge is that the only obvious ways to justify the cost of maintaining expensive validation infrastructure is because you intend to manipulate the currency using it or because you intend to prevent other people from manipulating the currency. The latter motivation is potentially subject to a tragedy of the commons— you don't need to run a full validating node as long as 'enough' other people do, and enough is a nice slippery slope to zero. Right now just the random computers I— some random geek— had at home prior to Bitcoin could store over a hundred years of max size blocks and process the maximum rate of transactions. With the costs so low there isn't any real question about a consolidation of validation making Bitcoin pointless. You could probably increase the scale 10x without breaking that analysis but beyond that unless the cost-per-scale goes down a highly consolidated future seems likely. 40 years from now why would people use Bitcoin over centralized private banknotes like paypal or democratic government controlled currencies? Perhaps Bitcoin transaction could transition to being more of the same— controlled by a consortium of banks, exchanging
Re: [Bitcoin-development] Near-term scalability
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki zgen...@yahoo.com wrote: Part of the problem is that Satoshi didn't totally anticipate the growth of the network. The block reward (the subsidy) is too high, which is why transactions can afford to be so cheap. What would happen if blocks required a cumulative fee of XN BTC for N transactions before being accepted? I would take the last block I solved and use it to write a transaction to nowhere which which gave all 50 BTC out in fee. This pays for as many transactions in the block as I like for any value of X you want to choose. You should read the bitcointalk forums more often: variants on that idea are frequently suggested and dismantled. There is a lot of noise there but also a lot of ideas and knowing what doesn't work is good too. -- 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] After compressed pubkeys: hybrid pubkeys
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote: RE: 0x06/0x07 'hybrid' public keys: Any opinions? Forbidding it certainly makes alternative implementation slightly easier in the future, but I'm not sure the hassle of a network rule change is worth it. I say treat any transactions that use them as 'non-standard' -- don't relay/mine them by default, but accept blocks that happen to contain them. I agree that a rule change isn't worth it right now, but making them non-standard now is easy and should make a rule change in the future easier. ACK. Hopefully no one will mine these before we can merge denying them into another rule change. But if they do, oh 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] 0.6.x - detachdb in wrong place
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp grarp...@gmail.com wrote: Well, detachdb doesn't appear in the -\? help because it's stuffed under pnp, which is not set in my build. please fix for people, tx :) It isn't inside the ifdef in bitcoin git master. (For future reference this sort of request is probably best opened as an issue in the github issue tracker instead of posted to the list). -- 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] 0.6.x - detachdb in wrong place
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp grarp...@gmail.com wrote: It isn't inside the ifdef in bitcoin git master. Oh, hmm, well then, what is the difference or usage between these two repositories in regards to the project? Which one are the formal releases tagged (tbz's cut) in? Which one has the branches with the commits that will make it into the next formal release? ie: tracking along 0.5.x, 0.6.x, HEAD/master (to be branched for 0.7.x). https://github.com/bitcoin/bitcoin https://git.gitorious.org/bitcoin/bitcoind-stable The latter is Luke's backports of security and stability fixes to otherwise unmaintained old versions. -- 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] 0.6.x - detachdb in wrong place
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp grarp...@gmail.com wrote: Presumably the github/0.6.2 branch is safe for production? 0.6.2 is very widely used, more so than the other acceptably updated backports. What degree of caution about wallet eating should be made for those using github/master? I can't speak for anyone but myself: I don't run master on wallets with large amounts of (non-testnet) coin in them, except for a few times when I needed access to this feature or that or just in a isolated capacity for testing. In any use with real wallets I'd be sure to have good backups that never touched the new code. We have at various times had bugs in master that would corrupt wallets (though IIRC not too severely) and have bugs that would burn coin both in mining and in transactions (though again, I think not too severely). My caution is not due to the risk being exceptionally great but just because there is probably no remedy if things go wrong, this caution is magnified by the fact that we don't currently have enough testing activity on master. Testnet exists so that people can test without fear of losing a lot of funds and with the 0.7.0(git master) testnet reboot it should be more usable than it has been. It would be very helpful if anyone offering bitcoin services would setup parallel toy versions of your sites on testnet— it would bring more attention to your real services, it would give you an opportunity to get more testing done of your real services, it would show some more commitment to software quality, and it would let you take a more active role in advancing bitcoin development by doing a little testing yourself that you couldn't do on your production systems. -- 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] Ultimate Blockchain Compression w/ trust-free lite node
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner etothe...@gmail.com wrote: One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct root. Not only would that be disruptive, it would be a disaster to track down. This is why good comprehensive tests and a well specified algorithim are important. The tree update algorithm would be normative in that scheme. Worrying that implementers might get it wrong would be like worrying that they'd get SHA256 wrong. A PATRICIA tree/trie would be ideal, in my mind, as it also has a completely deterministic structure, and is an order-of-magnitude more Provable libJudy trees. Oh boy. -- 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
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn m...@plan99.net wrote: 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 proof might be very Link? I also proposed this on this list (see the response in the tree datastructures thread) along with more elaboration on IRC. If multiple people are coming up with it thats a good sign that it it might actually be viable. :) I was going for a slightly different angle and pointing out that the proofs would mean that a node doing validation with TxOUT tree which hasn't personally wittnessed the complete history of Bitcoin actually has basically the same security— including resistance to miners creating fake coin in the past— as a full node today because in order to get away with a lie every single node must conspire: It's adequate that only one honest node wittness the lie because once it has the proof information is hard to suppress. To save people from having to dig through the public IRC logs for what I wrote there: --- Day changed Thu Jun 21 2012 15:10 gmaxwell etotheipi_: amiller: an interesting point with all this txout tree stuff is that if you join the network late and just trust that the history is correct based on the headers, any other node who has witnessed a rule violation in the past can prepare a small message which you would take to be conclusive proof of a rule violation and then ignore that chain. 15:11 gmaxwell e.g. if someone doublespends I just take the conflicting transactions out and the segments connecting them to the chain... and show them to you. And without trusting me you can now ignore the entire child chain past that point. 15:13 gmaxwell This fits nicely with the Satoshi comment It takes advantage of the nature of information being easy to spread but hard to stifle ... it would be safe to late-join a txout tree chain, because if there is only a single other honest node in the world who was around long enough to wittness the cheating, he could still tell you and it would be as good as if you saw it yourself. 15:17 gmaxwell (this is akin to the provable doublespend alert stuff we talked about before, but applied to 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] Tor hidden service support
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp grarp...@gmail.com wrote: You are going to want to include the block of the Phatom project as well: https://code.google.com/p/phantom/ fd00:2522:3493::/48 Perhaps some argument to add blocks to the IsRoutable check is in order? Then people who use overlay networks that are actually routable but which use otherwise private space can just add the relevant blocks. Note that while these blocks are not expected to be routable, that people may in fact have interfaces, routing tables and packet filters on their machines configured with up to all three of those networks for the purposes therein. Note that while the hidden service support in bitcoin uses a compatible IPv6 mapping with onioncat, it is _not_ onioncat, does not use onioncat, does not need onioncat, and wouldn't benefit from onioncat. The onioncat style advertisement is used because our protocol already relays IPv6 addresses. The connections are regular tor hidden service connections, not the more-risky and low performance ip in tcp onioncat stuff. -- 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] Pruning in the reference client: ultraprune mode
Pieter's performance numbers are a bit conservative if anything— profiles on ultraprune[1] show that the reference client's wasting of a lot of time in redundant serialization and hashing operations is the major time sink. Once thats cleared up it should be quite a bit faster [1] https://people.xiph.org/~greg/ultraprune_profile.png On Fri, Jul 6, 2012 at 12:52 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Also note that this is not directly related to the recent pruning proposals that use an alt chain with an index of unspent coins (and addresses), merged mined with the main chain. This could be a step towards such a system, however. In particular, if the BDB indexing in ultraprune is replaced with a hash committed tree structure who's root is committed in the blockchain you then have a txout commitment scheme. Ultraprune is most of the messy structural work for that. The rest is mostly storage differences. -- 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 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote: But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a transaction hash, output index refers to the first such pair that is not already spent. No? Yes, that is essentially what BIP 30 did. It's important to note that bip 30 doesn't prevent duplication, it just prevents the identified really evil outcome of the duplication. There was discussion on doing the height _before_ that, but the realization that the rewrites were a real vulnerability made it urgent and rolling out the height will require time while the bip30 change could be deployed more quickly. -- 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] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón timon.elvi...@gmail.com wrote: Didn't even know that they were proprietary software bitcoin clients. Should people trust them? Should the web promote them? After all, you can't know what they do. What if one of them contains a back door or something? I would say it's better not risk to apologize later. I agree too. Not that being open is _any_ guarantee, ideally we'd want standards of review and testing, but thats a bit much to ask for right now. -- 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] Bitcoin Wallet for Android
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I've reverted these additions to the page, nothing personal but— Er, to be clear, I left the android software in because the source is available (And I'm told its had some review). I removed the proprietary software section the plug for the blockchain.info webservices, and the demotion of the armory client. As far as criteria goes, I don't think we should list anything with a security model weaker than SPV unless users can practically operate their own servers. …and even that I'm a little uneasy with, because most people will use the defaults. Ideally even thin clients would have a near SPV security model, just without the bandwidth. But since the alternative for thin clients is centralized web services the lower standard will probably have better net results for now. Nor do I think we should list anything which can't currently be subjected to independent review of the whole stack (e.g. including the server components in thinclients, unless the server is untrusted). In the future this should be raised to there existing actual evidence of third party review. -- 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
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote: JS randomisation is bad. People shouldn't need JS to view a webpage. JS randomization doesn't imply needing JS to view the page. It implies needing JS to see it in random order. You could also combine it with the server-side randomization if you care about non-js being non random, though I don't think it matters. As others have pointed out I don't generally think the randomization is good in principle, but if its done it should at least achieve its goals. 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. I'll let other people speak for themselves, but I did consult others before reverting your last batch of changes. More generally, we have pull requests in order to get some peer review of changes. Everyone should use them except for changes which are urgent or trivially safe. (Presumably everyone with access knows how to tell if their changes are likely to be risky or controversial) 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). I'm strongly supportive diversity in the Bitcoin network, and some alt client developers can speak to the positive prodding I've given them towards becoming more complete software. If I've said anything that suggests otherwise I'd love to be pointed to it in order to clarify my position. Unfortunately none of the primary alternatives are yet complete, the network would be non-function if it consisted entirely of multibit or electrum nodes (and as you've noted armory uses a local reference client as its 'server'). The distinction between multiple kinds of clients in terms of security and network health are subtle and can be difficult to explain even to technical users and so until something changes there the reference client needs to be the option we lead with. People should us it unless their use-case doesn't match. When it does they'll know it and they'll be looking. We don't need to make one of those recommendations a primary option. I like the proposals of moving this stuff to the Wiki as the wiki already contains tons of questionable (and sometimes contradictory) advice and so there is less expectation that placement there implies any vetting. -- 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] Scalability issues
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp grarp...@gmail.com wrote: It already takes a month to build a new blockchain, let alone keep up with new incoming blocks. Please fix your software stack. Something is wrong with your system and I doubt it has much to do with bitcoin. A full sync here takes something like an hour. There are certainly lots of scalability things going on, but there is no cause for concern for regular hardware being unable to _keep up_ without a hardforking change to the protocol first. -- 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] Scalability issues
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp grarp...@gmail.com wrote: Update: this class of machine just became useless for bitcoin. When blk0002.dat was created to store more blocks, all forward progress processing blocks turned into losing ground by 20 or so a day. Guessing both datfiles were being accessed at once resulting in disk based overload. I've not seen any other mentions of crypto in this thread so I'm not sure how well new hardware would perform. Going shopping I guess. I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync the chain, but it was less than two days as that was the span between when I checked on it. It's staying current just fine. Again, I encourage you to investigate your software configuration. -- 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] Scalability issues
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp grarp...@gmail.com wrote: I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync the chain, but it was less than two days as that was the span between when I checked on it. It's staying current Well, are you running bitcoin on, say, an FS with sha256 integrity trees for all bits and AES-128-XTS/CBC disk encryption? If not, we're not comparing the same apples, let alone the same OS. The file system is using twofish-cbc-essiv:sha256, apparently. (I went and dug up a mothballed machine of mine because of your post). And I agree, encrypting everything is a good practice— I once got a disk back from RMA where only the first sectors were zeroed and the rest had someone elses data, since then I've encrypted everything because you can't wipe a dead drive. I'd love to know precisely what Bitcoin is doing thats making your machine so unhappy... but your configuration is uncommon for bitcoin nodes in many distinct ways so it's not clear where to start. -- 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 22 - getmemorypool
On Mon, Jul 30, 2012 at 4:26 PM, Amir Taaki zgen...@yahoo.com wrote: Hi, luke-jr wants me to split this BIP into 3 separate BIPs because he says that other devs felt it was too unfocused and covered too many topics. However this discussion took place on IRC, a It actually took place on this list: http://sourceforge.net/mailarchive/forum.php?thread_name=20120612105038.GA29784%40vps7135.xlshosting.netforum_name=bitcoin-development It just took some IRC prodding to get Luke to move in the direction of breaking it up to get the optional parts that Pieter objected to out of the spec. Perhaps other people missed it too... so discussing it more sounds fine if anyone objects. -- 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
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik jgar...@exmulti.com wrote: My only response is a weak one: inevitability. It seems likely that -somebody- will implement their own P2P commands for their own client subset, even if only a simple use 'getstatus' with strSubVer matching /FooClient/ Therefore, if it is inevitable, we might as well make some basic rules about how to extended your P2P command set. I'm not opposed to that logic. But for cases where an introduction mechanism will be needed... it would be awfully good to have one, and I do think that there is harm in making people think that simple services negotiation will actually work for their needs for cases where a separate p2p network 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
Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are. https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal Why does this focus on actually sending the hash tree? The block header + transaction list + transactions a node doesn't already know (often just the coinbase) is enough. -- 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] Segmented Block Relaying BIP draft.
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: For some reason sourceforge is not sending me updates anymore but I can see the replies online… There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then download the transactions separately. However there are two problems: 1. Downloading all the transactions individually might be inefficient. My proposal will allow nodes to request multiple transactions at once. Someone can do that just by pipelining the one at a time requests. How much bandwidth do you think you could save over that? 2. Why not add a few additional components to the protocol to allow requests for any level of the merkle tree? It's not very complicated at all and protects against the future. I don't see what value this provides. For protecting against the future you might as well suggest uploading x86 code which gets executed to select transactions. Protects against the future. Can you clarify some more about exactly how you think it would help? It's sometimes desirable to be more general rather than more special case when it's costless... but having couple extra p2p protocol messages to implement, test for interop, guard against vulnerability, etc. isn't costless... and should be justified with concrete benefits. it's not clear to me how your proposal is really all that useful for very large blocks: I looks like it would lot of bytes sending redundant tree data. The block sizes at the moment are about 0.1MB but what if the bitcoin demand starts pushing that into megabytes? And what if? _Bitcoin_ blocksizes can't be any larger. Some future incompatible system? well perhaps. But we're working on the protocol for bitcoin now. And yes the ~0.95MB limit needs to be changed in order for bitcoin to grow that far. Why would the limit not be lifted? How will bitcoin demand be satisfied other than having large fees to deter transactions, hoping the fees are large enough to balance the demand with the block size limits to prevent many transactions being unconfirmed and annoying users? That limit has got to go eventually. And then it could be that block sizes do become large enough to worry about the performance in relaying. The finite size— and ultimately the contention for space it causes— is the only thing will creates non-trivial fees. Without the fees there is no honest economic motivation to mine with adequate computing power to provide security (lots of dishonest motivations— e.g. applying control over the currency exist), you'd just have a race to the bottom, given unbounded block sizes it is always rational for decentralized to include any transaction with a fee even if it is very small— otherwise the next rational solver is just going to include it. Bitcoin gets its value through scarcity. There are two kinds of scarcity that are economically important, scarcity of the coins— there will never be more than 21 million— and scarcity of the block space which, as the protocol is defined and enforced by every node can not be more than 1MB. The latter scarcity is what makes the security model economically sane. Fortunately, its perfectly possible to make transactions denominated in bitcoin outside of the blockchain, and in a secure and distributed manner that respects the principles that make bitcoin attractive, but with information hiding that improves privacy, transaction speed, and scalability. See, e.g. the good work being done by Open transactions to create distributed cryptographic banks. So blockchain scarcity itself doesn't prevent Bitcoin from being a one world currency (something which isn't at all sane no matter how big you make the blocks if you don't allow for other modes of transaction processing— who the heck wants to possibly wait an hour to get a 1 confirm sodapop??). From the beginning it was obvious that confirmations would eventually be slower (or expensive to make merely slow; Bitcoin is incapable of reliable fast confirmations)— thats the nature the stochastic consensus and the fee based security support. You could instead imagine a future where bitcoin's security came by collusion by major financial cartels and governments, and where fees aren't important But I reject that future, it's a perfectly viable one, but why bother with Bitcoins in the first place? To make some early adopters a little bit of money starting off the next big centrally controlled fiat? Boring. I can't say for sure if the 1MB limit will stay exactly as is forever, as I expect the economics work with any limit out of a fairly broad range that is low enough to both make the space seriously scarce and low enough that 'inexpensive' (e.g. privately owned) hardware can continue to audit it to preserve the decentralized security, and the economic importance of the size limit is more subtle than the inflation resistance... but I know that changing it is precisely as
Re: [Bitcoin-development] Large backlog of transactions building up?
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik jgar...@exmulti.com wrote: Yeah, my public nodes currently have 2200+ Over time, it gets cluttered naturally due to the disconnect between what miners mine and what relayers relay. Right, this disconnect is why simple scalar measures of mempool size aren't terribly informative. There are bursts of weird transactions (e.g. someone was flooding zero value txn a few weeks ago; before that there were some enormous series of double-spend induced orphans), and other sustained loads that quite a few miners are intentionally excluding. No one has strenuously argued against this, so I suppose it is down to writing a patch, and coming up with a good number we (as a network) can agree upon. Sounds good— my only concern is that nodes will repeat their own transactions but not the unconfirmed parents. So being more aggressive can turn otherwise valid transactions into orphans. Would there be value in an archive-mempool which is only checked when you receive an orphan transaction? I would point out that you can't _KNOW_ a txn will disappear. Someone else could happily reannounce it. (I know you know this; but it's good to be clear on that point when we talk about it!) -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large backlog of transactions building up?
On Tue, Sep 25, 2012 at 1:34 PM, Jorge Timón timon.elvi...@gmail.com wrote: On 9/23/12, Jeff Garzik jgar...@exmulti.com wrote: - provides a deterministic lifetime for a TX; if you KNOW a TX will disappear 144 blocks (24 hours) after you stop transmitting, then it is probably safe to initiate recovery procedures and perhaps revise the transaction - prevents zombie TXs from littering memory... they hang around, wasting resources, but never get confirmed I don't understand. Can the chain enforce this number? Why can't clients delete all those transactions right now? This is discussion about transactions which are not in the chain yet. On 9/23/12, Gregory Maxwell gmaxw...@gmail.com wrote: There are bursts of weird transactions (e.g. someone was flooding zero value txn a few weeks ago; before that there were some enormous series of double-spend induced orphans), and other sustained loads that quite a few miners are intentionally excluding. Why clients store transactions that don't obey the current rules of the chain at all? The double spending transaction is not stored— which is, in fact, the problem which creates these huge chain. When a transaction depending on the doublespend is received we do not know its parent (because we dropped it because it was a rule violation) so we keep it around as an orphan hoping its parent arrives. The software could maintain a cache of rejected txids to consult for orphan txn's parents, but it would need to be dropped any time there is a reorg so I don't know how useful it would be. -- 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] Draft BIP for Bloom filtering
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn m...@plan99.net wrote: If you just want to waste bandwidth of nodes you can connect to nodes and repeatedly download blocks, or fill the network with fake nodes that spam random generated transactions to whoever connects. I don't see how to avoid that so it seems odd to worry about a much more complicated attack. Because I can potentially waste bandwidth of all nodes forever (well as long as users are still scanning blocks with my transactions in them) with O(1) work. Though I'm not sure how much of a threat is vs just paying 1e-8 btc to lots of addresses which would only be less bad by some constant factor as worse. I guess I should try to attack it and see how bad the pollution I can construct should be. (offline, of course) -- 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] Draft BIP for Bloom filtering
On Fri, Oct 26, 2012 at 10:21 AM, Mike Hearn m...@plan99.net wrote: Anyway, it's trivial to DoS the entire Bitcoin network today. It hasn't ever happened. Maybe one day it will, but the only rationale people can come up with for such an attack beyond random griefing is Which happens and is a concern. Altcoins have been attacked on things we fixed. For example, litecoin nodes were being run out of disk space through addr.dat flooding. I think we've been generally fortunate that the level of griefing is low (though not non-existent). But part of the reason its been low is that it's probably harder to DOS attack bitcoin than you believe. In the reference client a lot of work has gone in to removing attacks with sublinear cost for the attackers. That people aren't attacking much now is not an argument to accept a new vulnerability much less a _normative_ vulnerability in the protocol. That it's no big deal even attacked would be a fine argument to me, so I'll go try to convince myself of that. governments, Please don't put that kind of black helicopter junk in my mouth. I agree with you the point that these aren't a source of concern for me. -- 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] Electrum security model concerns
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I'm concerned about how the particular security model of electrum is being described; or rather— not being described. Just to close the loop on this: I finally got in touch with Thomas on IRC and walked over the security issues I brought up here, plus a number of other ones. He took the concerns seriously and rapidly redesigned big swaths of electrum to eliminate the issues structurally. Electrum no longer a classical thin client it is now a slightly watered down simplified-payment-validation node with generally the same security properties as other SPV nodes. Its network behavior leaves it somewhat more vulnerable to isolation and compromise by a high hash power attacker, because it does not (yet) make an effort to make sure it's really on the longest chain. It is also more vulnerable to transaction hiding (a DOS attack) for similar reasons. But this is still a massive improvement. The UI was also changed and the confirmation status of payments is no longer hidden. There are still things to improve— both in the client and the security communication to users. But I wanted to leave a note that it's come a long way and that I now feel confident that any remaining issues will be resolved. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote: On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has, otherwise your invoice would appear in the UI as unverified and is subject to manipulation by viruses, etc. That's expected behaviour - except it's mainly be manipulated by *users*, not viruses (which can just as easily manipulate whatever custom cert store we use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no matter who Joe is or what connections he has. So using the OS cert store would effectively restrict merchants to the intersection of what ships in all the operating systems their users use, which could be unnecessarily restrictive. As far as I know, every browser has its own cert store for that reason. Browsers with this bug are not relevant IMO. This is messy. It's important to people to know that their cert will be accepted by ~everyone because non-acceptance looks like malice. If the cert system is actually to provide value then false positives need to be low enough that people can start calling in law enforcement, computer investigators, etc.. every time a cert failure happens. Otherwise there is little incentive for an attacker to not _try_. Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. Would you find it acceptable if something supported a static whitelist plus a OS provided list minus a user configured blacklist and the ability for sophisticated users to disable the whitelist? This way people could trust that if their cert is signed via one on the whitelist they'll work for ALL normal users.. and the UI can have very strong behavior that protects people (e.g. no 'click here to disable all security because tldr' button)... but advanced users who can deal with sorting out failure can still have complete control including OS based control. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for which has more overlap with the discussion here? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote: Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will likely be accepted quite fast - especially now when the bounty was just halved... I also fear that there is a lot of BTCs that is effectively un-owned and it could even drive Satoshi to use some of his BTCs ;) Pieter already commented on this, but it's so important it must be said twice because everyone developing software for Bitcoin must understand and internalize it: Bitcoin is not a democracy, it's certainly not a democracy of miners. Every full node independently and autonomously validates the rules of the system without the influence of other participants. Unfortunately, there is no universally consistent way to evaluate the temporal ordering of transactions independently known— and none likely to ever exist— and a digital currency requires ordering to resolve double spends. Because of this Bitcoin must compromise the autonomy of its validation slightly: It uses a computational majority to determine transaction ordering. But only ordering! This is essential because if all the rules were subject to the whim of a computing majority the system would be far less trustworthy. The economic incentives which keep the mining participants honest depend on the value of defection being as limited as possible. So, no— you can't achieve by what you want with miners. Any miner which applied your rules would instantly stop mining from the perspective of Bitcoin users. As a miner myself, I welcome my competition adopting your proposal :P. You're looking for a hard fork of the system. Such a change must be supported by ~all users, and so it must be something which has near universal consensus that it is essential. I think it's not essential— though I agree that better UTXO set size management would have been a useful component if it had been in the origin economic promise of the system— and I already know that some participants take a principled position that views changes to the mere spendability of outputs as _theft_. Your proposal is also more economically hazardous than necessary: By paying unmoved coins to miners you create a substantial incentive for miners to delay processing transactions in the hopes that they expire first. There is also some risk that the return of large coins from the past after the currency has substantially deflated would be extremely economically disruptive. As far as your concern— as opposed to the mechanism— I share it. But it's important to note that the source of most of the problem transactions is a single source, and a rather unusual one that defies the normal anti-spamming economic incentives by attracting mentally ill people to subsidize pay for the bloating transactions, which are already penalized. I believe this specific issue can be adequately addressed primarily through a three fold process: (1) Make client software aggressive about sweeping up dust inputs: Any time a transaction is created that has change keep adding in extra inputs— smallest to largest— until an additional one would increase the cost of the transaction by 0.0001 BTC or more — the only major complication is doing this without concurrently harming privacy which is why it's not done yet in the reference client. (2) Change the default relay and mining rules to further penalize transactions with very small outputs. Making sure that its practically possible to create inexpensive transactions right now is very important for the long term success of the system while the small size of the system makes it unattractive to use, but I don't believe that applies for dust outputs. (3) Change the default relay and mining rules to further incentive reductions in the UTXO set size. This would make the actions of (1) save the participants funds instead of just being an altruistic behavior that most do because its a default. It might also be useful for client software to incorporate a destroy wallet button for people with wallets that only have dust remaining to send the private keys off to something of community benefit (e.g. bitcoin foundation, the faucet, or the developers of that that client) for recovery so that they don't perpetually bloat the UTXO set. I expect that these actions would substantially address your concerns, and even if they do not I believe that they would be the most basic prerequisites for any kind of argument that something more drastic (especially something that some would could consider theft!) is essential. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote: The main source for these 1 Satoshi payouts is Sahtoshi Dice. Because people are making 1 satoshi bets, or is this part of their messaging system? It's part of their messaging system. Every losing play results in a new 1e-8 output being created. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote: These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies minimize fees,max privacy,defragmentation,i don't care and even switch between them for individual sends. While thats a fine thing— and a feature that I'd personally use— its not one that I expect to have a real measurable impact on the overall network behavior. For this kind of minutia especially, defaults are all powerful and must be the best they can be. :) -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote: 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement where users pay fees, getting transactions into the chain has a cost. In cases where you trust the sender to not double spend on you, you may keep a fee-less transaction around in your pocket. Then when it's your turn to pay, you use some unconfirmed transactions to do so. This brings up an additional point. If we're mutually trusting parties (or secured by some kind of external mechanism), and you've given me a payment which I haven't broadcast for confirmation— and later we make another transactions I should be able to offer you the original unconfirmed txn and ask if you'd instead be willing to write a replacement that combines both payments. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn m...@plan99.net wrote:
The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
not convinced this is the best use of time, but if somebody steps up
to do it, that could also work.
I strongly believe that if community leads with client software which
is not a full _capable_ node (e.g. which can begin life as a SPV node
but at least eventually become full if the system resources permit)
then Bitcoin will fail, or at least fail to be anything but the
world's most inefficient centralized payment system. Obviously SPV
nodes are excellent tools for getting bitcoin into less capable
systems, but they aren't a general replacement for the software the
participants in Bitcoin run.
— Because the properties promised by the system can not be upheld if
there is only a fairly small number of self selecting nodes enforcing
the rules. If we wanted a system where its security against theft,
denial of service, and non-inflation were governed by the consensus of
{mtgox,blockchain.info, deepbit, bitpay, slush, btcguild, bitminter}
we could have something infinitely more scalable by just using
something OT like with a simple O(N) consensus between these parties.
No disrespect intended to any of these services— but a system whos
rules were only enforced at the good graces of a small number of
interested parties is not what the users of bitcoin signed up for.
People obviously care about supporting the goals and security of a the
system they use but actions speak louder than words. If a
non-validating node is promoted then we're telling people that it's
not important that many people run them. If running a full node
requires using different software (with a different interface) or a
much more painful initialization than another promoted option then it
will be correctly perceived as costly. If people perceive it to be
both costly and not important then rational participants will not run
it. The result will be fragile to non-existent security, where
dishonest or exploitative parties benefit from running all the full
nodes until they start ripping people off and shift the equilibrium
just a little towards running costly nodes.
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
There is no set timeline for the adoption of Bitcoin— man has survived
eons without Bitcoin just fine— and there are many practical reasons
why slow adoption is beneficial, including reducing the harm users
experience from growing pains. By allowing things to mature at their
own pace we can preserve the principles that make the system valuable.
If the new user experience is sufficiently bad (and I agree it's bad,
esp with the current release versions of Bitcoin-Qt) then that should
justify more support of work that improves it without compromising the
system. If it's not bad enough to apply those resources, then it's not
bad enough to justify compromising it: as this sort of change is hard
to reverse.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote: Alan's :( UTxO meta-chain proposal becomes vastly easier to do now that ultraprune is merged. No, not really. Somewhat easier due to some structural changes, but it still needs to invent and get consensus on a normative data structure and people need to write implementations of the required operations on it (implementations probably required to prove performance for consensus). We still have to sort through the tradeoff of making a _single_ data structure the normative merkle tree representation for the UTxO set to the preclusion of other implementations— including ones which are asymptotically faster, such as a straight hash table. There are also issues that need to be sorted out like key structure— the most useful index for validation is txid:vout keyed, but Alan wanted 'address' prefixed, which is not friendly for validation but enables robust query by address— a query that the referce normal bitcoin software doesn't even optionally support right now. Any disagreements on this point must be hammed out because the structure would be normative. That would allow the Satoshi client to know it's wallet balance and operate with a =SPV level of security during the initial block download, and keep them on the path of becoming a full node. If users can see their balances, send and receive transactions, and otherwise go about their business (except for mining) during the initial block download, would that not address your concerns? The above said, that is all good stuff too. And I do thing starting fast with reduced security (be it to SPV+ or SPV) is a good idea. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote: It sounds to me that you're insisting that you're asking people who oppose degrading our recommendations to commit to a costly rushed development timeline. I think this is a false choice. Hardly. I don't have any particular timeline in mind. But I disagree we have forever. New ideas have a certain time window to take off and become credible. Marketing initiatives have limited windows. This matters, perhaps, when you're some VC pumping cash into a startup with the hopes of being the next stockmarket pump and dump darling. Outside of that people use whatever they use because it works for them. And by the numbers Linux desktops are more common than they've ever been— and certainly Linux kernel _systems_ half the people I know have one in their pocket and its hard to go more than a few hours without touching one. To some extent the Year of the Linux desktop is a bit like the Year of being able to turn lead into gold ... we can turn lead into gold now, but the particle accelerators, atomic power, and atomic weapons enabled by the same technology are far more interesting due to the particle realities of this. So we didn't get the ubiquitous Linux desktop: We got the ubiquitious Linux server, the ubiquitous Linux-kernel smart phone, the ubiquitous Linux television, media player, HVAC controller, etc. instead. Desktops— well, that didn't meet people's hopes though I think not for the lack of marketing on the part of Linux, but because Apple stepped up and produced middle ground products that attracted a larger audience. Especially as MSFT dropped the ball. They did some things better, had a running start, and had a non open source software business model which made reaping rewards easier. But I don't see how any of this has anything to do with Bitcoin... Except for the point that if Bitcoin doesn't become the money system everyone uses and instead becomes the money system infrastructure all the systems people use depend on— just as Linux has with the desktop, where it might not be on the desktop but its in router firmware, cloud servers, and just about everything else— I wouldn't consider that much of a loss. time window, eventually people just give up and move on. Does anyone take desktop Linux seriously anymore? No. The year of desktop Linux is a joke. People took it seriously in 2001 but despite great progress since, the excitement and attention has gone. There were steady improvements over the last 10 years but nobody is creating desktop Linux startups anymore Bitcoin already missed its first— and perhaps only— fad window in any case. Today people say Bitcoin? Thats still around? I thought it got hacked. ... thanks to compromised centralized services. It's unclear we need to have every man and his dog run a full node. Every man and his dog? Perhaps not. But as many as can— probably so. If we depend on the organic need for full nodes to overcome cost and effort to run one there will always be major incentives to let someone else do that, and the system would have its equilibrium right on the brink of insecurity. Perhaps worse, since insecurity is most obvious retrospectively. Security doesn't make for a good market force. Tor is a successful P2P network where the number of users vastly outstrips the number of nodes, and exit nodes in particular are a scarce resource run by people who know what they're doing and commit to it. Tor is a distributed but controlled, by a small number of directory authority operators, system. It is a good system. But it has a trust model which is categorically weaker than the one in Bitcoin. If you want something where a majority of a dozen signing keys— hopefully in the hands of trusted parties— can decide the state of the system you can produce someting far superior to Bitcoin— something that gives near instant non-reversable transactions, something that gives good client security without the complexity of a SPV node, etc. But that isn't Bitcoin. Even with no incentives, they were able to obtain the resources they need. And yet every tor user— if the have the bandwidth available can be a full internal relay and the software nags them to do it (and also nags them to act as invisible bridges for blocking avoidance), and every user is technically able to run an exit (though they don't bludgeon users to do that, because of the legal/political/technical issues involved). To do any of this doesn't require a user to switch to different software, and the tor project has previously opposed client only software. So why should Bitcoin be different? It's less different than you make it out to be— but it _is_ different. Bitcoin is a distributed currency. The value of bitcoin comes from the soundness of its properties and from the persistence of its security. If the integrity of the distributed ledger is disrupted the damage produced, both in funds stolen and in undermining the
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote: Greg's point looks like it's veering towards we don't want to grow the network unless we're going to get more full nodes out of it. No… There is no fundamental completion between taking what actions we can to maximize the decentralization of the network and making the software maximally friendly and painless to get started with and use. It's possible— not even deep rocket science— to create software that accommodates both. And because of this, I don't think it's acceptable to promote solutions which may endanger the decentralization that makes the system worthwhile in the first place. If the current experience is so poor that you'd even consider talking about promoting directions which reduce its robustness then thats evidence that it would be worth finding more resources to make the experience better without doing anything the that reduces the model, even if you've got an argument that maybe we can get away with it. If there isn't interest in putting in more resources to make these improvements then maybe the issue isn't as bad as we think it is? I think it is very much in everyone's interest here to encourage new users to start using Bitcoin, even if they don't support it. Absolutely— and yet that has nothing to do with promoting software to users which only consumes without directly contributing and which doesn't even have the capability to do so even if the user wants to (or much less, is indifferent). -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote: Our divergence is on two points (personal opinions): (1) I don't think there is any real risk to the centralization of the network by promoting a SPV (purely-consuming) node to brand-new users. In my opinion (but I'm not as familiar with the networking as you), as long as all full nodes are full-validation, the bottleneck will be computation and bandwidth, long before a constant 10k nodes would be insufficient to support propagating data through the network. Not so— a moderately fast multicore desktop machine can keep up with the maximum possible validation rate of the Bitcoin network and the bandwidth has a long term maximum rate of about 14kbit/sec— though you'll want at least ten times that for convergence stability and the ability feed multiple peers. Here are the worst blocks testnet3 (which has some intentionally constructed maximum sized blocks),E31230 : (with the new parallel validation code) - Verify 2166 txins: 250.29ms (0.116ms/txin) - Verify 3386 txins: 1454.25ms (0.429ms/txin) - Verify 5801 txins: 575.46ms (0.099ms/txin) - Verify 6314 txins: 625.05ms (0.099ms/txin) Even the slowest one _validates_ at 400x realtime. (these measurements are probably a bit noisy— but the point is that its fast). (the connecting is fast too, but thats obvious with such a small database) Although I haven't tested leveldb+ultraprune with a really enormous txout set or generally with sustained maximum load— so there may be other gaffs in the software that get exposed with sustained load, but they'd all be correctable. Sounds like some interesting stuff to test with on testnet fork that has the POW test disabled. While syncing up a behind node can take a while— keep in mind that you're expecting to sync up weeks of network work in hours. Even 'slow' is quite fast. In fact, I was under the impression that connectedness was the real metric of concern (and resilience of that connectedness to large percentage of users disappearing suddenly). If that's true, above a certain number of nodes, the connectedness isn't really going to get any better (I know it's not really that simple, but I feel like it is up to 10x the current network size). Thats not generally concern for me. There are a number of DOS attack risks... But attacker linear DOS attacks aren't generally avoidable and they don't persist. Of the class of connectedness concerns I have is that a sybil attacker could spin up enormous numbers of nodes and then use them to partition large miners. So, e.g. find BitTaco's node(s) and the nodes for miners covering 25% hashpower and get them into a separate partition from the rest of the network. Then they give double spends to that partition and use them to purchase an unlimited supply of digitally delivered tacos— allowing their captured miners to build an ill fated fork— and drop the partition once the goods are delivered. But there is no amount of full nodes that removes this concern, especially if you allow for attackers which have compromised ISPs. It can be adequately addressed by a healthy darknet of private authenticated peerings between miners and other likely targets. I've also thrown out some ideas on using merged mined node IDs to make some kinds of sybil attacks harder ... but it'll be interesting to see how the deployment of ASICs influences the concentration of hashpower— it seems like there has already been a substantial move away from the largest pools. Less hashpower consolidation makes attacks like this less worrisome. (2) I think the current experience *is* really poor. Yes, I said so specifically. But the fact that people are flapping their lips here instead of testing the bitcoin-qt git master which is an 1-2 order of magnitude improvement suggests that perhaps I'm wrong about that. Certainly the dearth of people testing and making bug reports suggests people don't actually care that much. You seem to suggest that the question for these new users is whether they will use full-node-or-lite-node, but I believe it will be a decision between lite-node-or-nothing-at-all (losing interest altogether). No. The question that I'm concerned with is do we promote lite nodes as equally good option— even for high end systems— remove the incentive for people to create, improve, and adopt more useful full node software and forever degrade the security of the system. Waiting a day for the full node to synchronize, and then run into issues like blkindex.dat corruption when their system crashes for some unrelated reason and they have to resync for another day... they'll be gone in a heartbeat. The current software patches plus parallelism can sync on a fast system with luck network access (or a local copy of the data) in under an hour. This is no replacement for start as SPV, but nor are handicapped client programs a replacement for making fully capable ones acceptably performing. Users need to
Re: [Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote: I've implemented an alternative to the BIP 32 proposal. I wanted a system based on a hierarchical string representation (rather than hierarchy of integers as BIP 32 proposes). For example I name keys like this: [hd1.7549].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy [hd1.7549].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1 [hd1.7549].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn [hd1.7549].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn First draft of proposal: https://gist.github.com/4211704 As Pieter pointed out recently— it's not (realistically) possible to blindly iterate through strings. This means your proposal loses the backup recoverablity property which is part the point of a deterministic wallet: If you have a backup prior to a new string name being established you must also have a reliable backup of the string as well. Of course, if you're backing up the strings then you can also backup a map equating the hdwallet indexes to your strings, and in the event of a catastrophic loss where you are only left with the original ultimate root you lose no coins (only metadata) with the BIP32 scheme. If, instead, we have your scheme and the backup of strings is incomplete then some or all assigned coin may be lost forever. Your extended hierarchy of multiplers also makes me uncomfortable. BIP32 uses a HMAC in its construction to obtain strongly unstructured points. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd w...@uchicago.edu wrote: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme. If you have the the full extended secret there then you can spend along the chain— but just the plain ecdsa secret by itself is not enough to spend anything but that address itself. Or have I misunderstood you here? The easiest deterministic wallet construction is simply to use a stream cipher to generate random bytes used as the private keys in a wallet. Hierarchical constructions do not seem to me to add more, other then distinguishing transactions by sending to unique addresses, which could be done by other means. Sadly that construction has no ability to separate address generation from spending— an important element for merchant applications. Not just for their own own distinguishing of transactions but because the use of fresh addresses is essential to the limited privacy properties of the Bitcoin system. I called that a type-1 deterministic wallet in some old forum post where I wrote about the different derivation schemes as opposed to the point combining type-2 construction. The hope in BIP32 was that we could get away just using a single one. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blockchain as root CA for payment protocol
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke timo.ha...@web.de wrote: It's not about technical differences, but about the different use or purpose, which can result in different security demands. I argue that DNS has a lower demand in this respect than payment ids have. So DNS data can be in a chain with a hashrate lower than bitcoin's hashrate but payment ids _for_ bitcoin have to be in a chain with equal hashrate. It seems you're not very well informed about what namecoin does— it's a multiple namespace key-value store. And, as Peter pointed out— a non-parasitic system can have exactly the same POW hashpower. Namecoin chose a model which made it so that namecoin could survive even if Bitcoin failed, but you don't have to. I strongly recommend you listen to Peter and Luke— externalizing the costs of your services onto people who do not care about them is not going to produce good results for anyone. It's possible to accomplish what you want to accomplish without taking resources from the users of the Bitcoin currency without their consent— and you have people here who are willing to help you figure out how. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank raph...@gmail.com wrote: Has this been considered? If made sufficiently general, older clients could support any extension of the rules. Various hard parameters within the protocol are defined in main.h of the official client. In BIP-34, there is a suggested way to make changes, based on consensus. https://en.bitcoin.it/wiki/BIP_0034 You misunderstand what BIP_0034 is doing— it's not gauging consensus, it's making sure that the change is safe to enforce. This is a subtle but important difference. The mechanism happens to be the same, but we're not asking for anyone's approval there— the change is needed to make Bitcoin as secure as people previously believed it to be, there have been no serious alternatives tendered. As far as I can tell the proposal has always had universal agreement from anyone who's thought about it. The only open question was if it was safe to deploy, and thats what that process solves. Bitcoin is not a democracy— it quite intentionally uses the consensus mechanism _only_ the one thing that nodes can not autonomously and interdependently validate (the ordering of transactions). This protects the users of Bitcoin by making most of the system largely nonvolatile constitutional rules instead of being controlled by popular whim where 'two wolves may vote to have the one sheep for dinner'. If it were possible to run the whole thing autonomously it would be, but alas... Even if you accept the premise that voting is a just way of making decisions (it isn't; it's just often the least unjust when something must be done), mining is not a particularly just way of voting: 'Hashpower isn't people', and currently the authority to control the majority of the hashpower is vested in a only a half dozen people. Moreover, the incentives to abuse hashpower are sharply curtailed by its limited authority (all one can do with it is reorder transactions... which is powerful but still finite) and allowing arbitrary rule changes would vastly increase that power. There are some more subtle issues— if the acceptance of chain B depends on if you've seen orthogonal chains A or A' first then there can be a carefully timed announcement of A and A' which forever prevents global convergence (thanks to a finite speed of light an attacker can make sure some nodes see A first, some A'). If a rule change can be reorged out, then it's not really a rule— any actual rule prohibits otherwise valid blocks that violate it (and without this distinction you might as well implement the 'rule' as miner preferences). Additionally there is the very hard software engineering QA problem for a sufficiently complex rule language— script isn't turing complete and look at all the issues it has had. In summary— this sort of thing, which has come up before, is technically interesting and fun to think about but it would make for substantial engineering challenges and would not be obviously compatible with the economic motivations which make Bitcoin secure nor would it be morally compatible with the social contract embedded in the system today. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank raph...@gmail.com wrote: Bitcoin is not a democracy— it quite intentionally uses the consensus mechanism _only_ the one thing that nodes can not autonomously and interdependently validate (the ordering of transactions). So, how is max block size to be decided then? In one sense it already is decided— there is a protocol rule implementing a hard maximum, and soft rules for lower targets. If it's to be changed it would only be by it being obvious to almost everyone that it should _and_ must be. Since, in the long run, Bitcoin can't meet its security and decenteralization promises without blockspace scarcity to drive non-trivial fees and without scaling limits to keep it decenteralized— it's not a change that could be made more lightly than changing the supply of coin. I hope that should it become necessary to do so that correct path will be obvious to everyone, otherwise there is a grave risk of undermining the justification for the confidence in the immutability of any of the rules of the system. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair step...@bitpay.com wrote: If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive? Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather it's the costs associated with the validation and propagation of the transactions themselves...which is the way it should be. The cost to whom? This is important because the cost of validating blocks is borne by all the participants in Bitcoin— or at least all the participants who haven't given up on the decenteralized trustless stuff and are simply trusting someone else. Even a small cost becomes large when hundreds of thousands. And perhaps you don't lament people delegating their trust to large entities— but keep in mind: Bitcoin was created for the express purpose of creating a money system which didn't require trust because it was based on cryptographic proof— mathematical law— instead of politics and human law. Take that away and you have a really poorly understood inefficient system operated by entities which are less trustworthy and rightfully entitled to authority than the ones operating the established major currencies. When I think about issues like this, I like to remind myself that the mesh network isn't really an essential part of Bitcoin. Thats absolutely true— but I don't know that it's relevant in this case. Nodes can at some point start to charge fees to collect and distribute transactions and blocks. They can— but doing so would radically undermine Bitcoin. A refresher: If you combine digital signatures with simple transaction rules you can have a purely autonomous monetary system based entirely on math. It would be perfect, anonymous, scalable ... except for the problem of double spending. To solve double spending the participants must agree on which of a set of duplicated payments is one the authoritative one. Coming to this agreement is fundamentally hard just at the basics of physics— a result of relativity is that observers will perceive events in different orders depending on the observer's and the events relative locations. If no observer is privileged (a decenteralized system) you have to have a way of reaching a consensus. This kind of efficient consensus we need— which which participants can join or enter at any time, which doesn't require exponential communication, and which is robust against sock-puppet participants— was long believed to be practically impossible. Bitcoin solved the problem by using hashcash to vote— because real resources were forever expended in the process the sock-puppet problem is solved. But the vote only works if everyone can see the results of it: We assume that the majority of hashpower isn't a dishonest party, and that honest nodes can't be prevented from hearing the honest history. Nodes choose then rules-valid history that has the most work (votes) expended on it... but they can only choose among what they know of. As Satoshi, wrote: [Bitcoin] takes advantage of the nature of information being easy to spread but hard to stifle. The requirement for everyone to hear the history doesn't get talked about much— at least with reasonably sized blocks and today's technical and common political climates the assumption that information is easy to spread but hard to stifle is a very sound one. It's a good thing, because this assumption is even more important than the hash-power honesty assumption (a malicious party with a simple majority of hashpower is much weaker than one who can partition the network). ... but that all goes out the window if communicating blocks is costly enough that the only way to sustain it is to jealously guard and charge for access/forwarding. The consequence of such a change is that the Bitcoin consensus algorithm would be handicapped. How long must you wait before you know that the history you have won't get replaced by a more authoritative one? Today an hour or two seems relatively solid. In a world with non-uniform block forwarding perhaps it takes days— if ever— before any participant is confident that there isn't a better history lurking. All doubly so if the bookkeeping required for this payment ends up necessitating additional transactions and adds to the load. [This is also the flaw in the 'Red Balloons' paper, making transactions a dozen times longer just to attach credit for forwarding doesn't seem wise compared to keep transactions so cheap to transmit that even a small number of altruists make the equilibrium state be liberally-forwarding] They would also charge for the propagation of blocks based on the work required to validate them. Large miners would obviously locate and connect to each other. Even enormous blocks are no problems for big industrial players. Don't want to pay the cost to get their big blocks from them? Your loss: If you don't take their blocks and they constitute
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I hope that should it become necessary to do so that correct path will be obvious to everyone, otherwise there is a grave risk of undermining the justification for the confidence in the immutability of any of the rules of the system. With all I wrote on the gloom side— I thought I should elaborate how I think that would work, assuming that my gloom isn't convincingly disproven. It's the year 2043— the Y2038 problem is behind us and everyone is beginning to forget how terrible it turned out to be— By some amazing chance Bitcoin still exists and is widely used. Off-chain system like fidelity bonded banks are vibrant and widely used providing scalable instant and completely private transactions to millions of people. Someone posts to the infrequently used IETF Bitcoin working group with a new draft— It points out that the transaction load is high enough that even with a 100x increase in block size completion for fees would hardly be impacted and that— because computers are 2^20 times faster per unit cost than they were in 2013— and networks had made similar gains, so even a common wristwatch (the personal computer embedded in everyone's wrist at birth) could easily keep up with 100 megabyte blocks so the size should be increased as of block 2,047,500. The only objections are filed by some bearded hippy at the museum of internet trolling (their authentic reconstruction of Diablo-D3's desktop exhibit couldn't keep up), and by some dictatorship who again insists that their communist PeoplesCoin should be used instead— the usual suspects. And so, after a couple years of upgrades, it is so. Or perhaps more likely— it would get revised along side a hardforking cryptosystem upgrade (e.g. replacing sha256 in the hash trees with SHA-4-512), thus amortizing out all the migration costs... The trickiness and risk of changing it— of economic problems, of the risk of undermining trust in the immutability of the system's rules— only exists if there is genuine, considered, and honest controversy about the parameters. At the moment any increase would be sure to be controversial: common hardware and networks would not obviously keep up with our current maximum size, and our current transaction load doesn't produce a usable fees market. This cannot remain true forever. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote: One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that others find. There will not be an issue with blocks being jealously guarded Then perhaps I totally misunderstood what you were suggesting. I believed you were saying blocksize would be controlled by people having to pay to receive and pay to have blocks forwarded. (by which I mean the fee or cost associated with the bandwidth and validation that a transaction requires) with some amount of profit. This means that the relay node will not fetch and propagate those transactions whose fee is too small (unless there was some other fee structure outside the miners fee). The only fee-or-cost they're worrying about is their own marginal costs. This says nothing about the externalized cost of the hundreds of thousands of other nodes which also must validate the block they produce, many of which are not miners— if we are well distributed— and thus don't have any way to monetize fees. And even if they are all miners for some reason, if these fees are paying the ever growing validation/storage costs what expenditure is left for the proof of work that makes Bitcoin resistant to reversal? If the cost is soaked up by validation/forwarding then the capacity to run a validating node ends up being the barrier to entry and difficulty would be very low... which sounds fine until you realize that an attacker doesn't have validation costs, and that selfish (optimally rational) miners could just eschew validation (who cares if you lose some blocks to invalidity if you're producing them so much cheaper than the honest players?). It is good to be wary of these potential issues, but I don't see how the economics are likely to yield the outcome you fear. And, really, there's not a lot that can be done to prevent economics from dictating the ultimate outcome. In fact, what I write above is not so much about what I think *should* be built, it's more about what I *predict* will be built. What I want is for economics to dictate a positive outcome. They can do this how the system is currently constructed where the economics of using the system are clearly aligned with securing it. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Secure download
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami r...@gnomon.org.uk wrote: Would be nice to have a secure page at bitcoin.org, though, rathar than having to go to github - certs from somewhere like Namecheap should cost you next to nothing. For those of us too lazy (not paranoid enough) to bother with GPG, a (secure) page on bitoin.org with the MD5 hashes of the binaries would be awesome... While I think that it's silly that we don't have a HTTPS (only!) page, it should be noted that an HTTPS page is in no way a replacement for GPG, sadly: Anyone who can MITM the server to the whole internet can trivially obtain a fraudulent cert with only moderate cost and time. (The reason for this is that (many? most? all?) CAs verify authority by having you place a file at some HTTP path on the domain in question. Effectively the current CA model only prevents those from intercepting who cannot intercept the traffic generally. Basically only helps with the evil hotspot/tor_exit problem.) -- 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_d2d_feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote: The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared. I believe you are confusing disjoint things. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn m...@plan99.net wrote: BDB ran out of locks. However, only on some 0.7 nodes. Others, perhaps nodes using different flags, managed it. We have processed 1mb sized blocks on the testnet. Therefore it isn't presently clear why that particular block caused lock exhaustion when other larger blocks have not. Locks are only mostly related to block size, once I heard what was happening I was unsurprised the max sized test blocks hadn't triggered it. Therefore it is possible that we have a very limited amount of time until nodes start dying en-masse. Scaremongering much? Egads. On Tue, Mar 12, 2013 at 5:27 AM, Michael Gronager grona...@ceptacle.com wrote: Forks are caused by rejection criteria, hence: 1. If you introduce new rejection criteria in an upgrade miners should upgrade _first_. 2. If you loosen some rejection criteria miners should upgrade _last_. 3. If you keep the same criteria assume 2. And ... if you aren't aware that you're making a change ??? -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote: I don't want to misrepresent what happened, but how much of that was really a risk? The block was rejected, but the transactions were not. Some but not much. If someone flooded a bunch of duplicate concurrently announcing both spends to as many nodes as they could reach they would almost certainly gotten some conflicts into both chains. Then both chains would have gotten 6 confirms. Then one chain would pop and anyone on the popped side would see 6 confirm transactions undo. This attack would not require any particular resources, and only enough technical sophistication to run something like pynode to give raw txn to nodes at random. The biggest barriers against it were people being uninterested in attacking (as usual for all things) and there not being many (any?) good targets who hadn't shut down their deposits. They would have to have accepted deposits with 12 confirms and let you withdraw. During the event an attacker could have gotten of their deposit-able funds. On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. There were circulating double-spends during the fork (as were visible on blockchain.info). I don't know if any conflicts made it into the losing chain, however. It's not too hard to check to see what inputs were consumed in the losing fork and see if any have been consumed by different transactions now. I agree it would be good to confirm no one was ripped off, even though we can't say there weren't any attempts. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about that publicly. [snip] I agree it would be good to confirm no one was ripped off, even though we can't say there weren't any attempts. https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747 -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell matthewmitch...@thelibertyportal.com wrote: Why would it be a difficulty in getting people to update away from 0.7 and earlier? How long would that roughly take? If people are hesitant to update, imagine if a more serious vulnerability is found. It could be disastrous. The development community backports critical fixes which makes updating instead of upgrading possible, but that still is not free. Many people are carrying patches against Bitcoin which require integration and time for testing— even if its just an update. Small behavior changes can still break things for the users. For example, a major mining pool lost well over 1000 BTC when upgrading to 0.8 because the reindex interacted poorly with their pool server software and caused them to pay people 25 BTC per share, an update or upgrade is just a risky even whos risk can be minimized if its done at your own pace. Sometimes when there is a vulnerability what people will do is isolate their production nodes from the internet using upgraded nodes, so they avoid touching the production systems. Other times the vulnerability is only a DOS attack so they ignore it unless the attack happens, or only applies to something else they don't care about. Another point is that if everyone instantly upgrades in response to developers claim that an urgent is needed (as opposed to implementing other workarounds) then the security of the system much more obviously reduces to the ability to compromise a developer— something no one should want. When roll outs take time there is more time for review to catch things, fewer nodes harmed by an introduced flaw, etc. -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] On fork awareness Was: 0.8.1 ideas
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the client) that their transactions The development of two chains was maximally bad because the state was irreconcilable without the manual intervention. The only reason you're saying that it was only the false confirms that were bad is because manual intervention resolved the worse badness. :) A whole bunch of people spending coins that can only exist in the different exclusive chains would have been very bad indeed. Is it possible to change the definition of 6 confirmations so that it's something like: six confirmations clear of any other chain. While there are two competing chains, it's possible that one will go pop at any moment. That makes the confirmation count of any transaction on one of those chains, zero. Not reliably, you will only hear of a competing chain if some of your peers have accepted it. If your peers were all pre-0.8 or all 0.8 you only would have heard of one chain. Relaying non-primary chains has some obvious and subtle challenges— Obviously you need some way of preventing it from being a DOS vector, but thats not a fundamental issue— you could rate limit by only relaying chains which are close to the current best in sum difficulty— just a software engineering one. A more subtle issue is it that it's not in a node's self-interest to tell peers about a chain it thinks is invalid: it wants its peers on _its_ view of the consensus, not some other one. Though perhaps this could be addressed by only relaying headers for non-primary chains. -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn— if its heard the fork and its on the lower difficulty side. Extending that to also alert if its on the winning side and the fork is long enough might be wise, though I have a little concern that it'll be mistaken to be more dependable than it would be. -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner b...@benlabs.net wrote: This. Software behavior which is not described by the source code should not be considered an integral part of the rule set. Any influence of external libraries on the consensus mechanism is unacceptable. No one thinks its controversial to remove it or that it's a good thing to have— only that its technically somewhat complicated and risky to remove it. -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension
On Sat, Mar 23, 2013 at 5:57 PM, Jay F j...@outlook.com wrote: My first concern was that I and about everyone else only has TCP/UDP port forwarding, You tunnel it! http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00 You could do worse to have a data stream that looks like WEBRTC traffic… In some ways SCTP is a pretty optimal transport for Bitcoin like messaging. -- 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_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote: I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally implemented by clients. That is quite drastic enough, as it requires adding more perpetual data that must remain in fast lookup for all validating nodes (the set of revoked 'addresses'). Keep in mind that this is only improvement for what is a usually inadvisable usage of Bitcoin to begin with... you should not be reusing addresses. -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A mining pool at 46%
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho melvincarva...@gmail.com wrote: There was some chat on IRC about a mining pool reaching 46% http://blockchain.info/pools The estimates on there may be a bit lossy. What's the risk of a 51% attack. The whole fixation on 51 as a magic number is a bit confused— I'll say more below. I suggested that the pool itself is decentralized so you could not launch one None of the pools listed there are meaningfully decentralized— before Luke whines, in theory the ones supporting GBT could be if used in a way that no one actually uses them. P2Pool is decentralized based on the same technology as Bitcoin itself, but it's certainly not as point and click easy as a centralized pool. On IRC people were saying that the pool owner gets to choose what goes in the block That is correct. Though I'd point out— the major pool ops all seem to be great folks who care about the future of Bitcoin— and the continued success of their very profitable businesses: a 50% mining pool with a 3% fee rakes in 54 BTC per _day_. The more likely threat isn't that pool owners do something bad: It's that their stuff gets hacked (again) or that they're subjected to coercion. ... and the attacker either wants to watch the (Bitcoin) world burn, or after raiding the pool wallet can't exploit it further except via blockchain attacks. Surely with random non colliding nonces, it would be almost impossible to coordinate a 51% even by the owner That makes no sense. A centralized pool is the miner, the remote workers are just doing whatever computation it tells them to do. Certainly these remote workers might switch to another pool if they knew something bad was happening... but evidence suggests that this takes days even when the pool is overtly losing money. Miners have freely dumped all their hashpower on questionable parties (like the infamous pirate40) with nary a question as to what it would be used for when they were paid a premium for doing so. It seems even those with large hardware investments are not aware of or thinking carefully about the risks. It would be great to know if this is a threat or a non issue It's important to know exactly what kind of threat you're talking about— someone with a large amount of hash-power can replace confirmed blocks with an alternative chain that contains different transactions. This allows them to effectively reverse and respend their own transactions— clawing back funds that perhaps had already triggered irreversible actions. This doesn't require some magic 51%— its just that when a miner has 50% the attack would always be successful if they kept it up long enough (long enough might be years if you're talking really close to 50% and he gets unlucky). Likewise, someone with a sustained supermajority could deny all other blocks— but that attack's damage stops when they lose the supermajority or go away. More interesting is this: An attacker with only 40% of the hashpower can reverse six confirmations with a success rate of ~50%. There is source for computing this at the end of the Bitcoin paper. I did a quick and really lame conversion of his code JS so you can play with it in a browser: https://people.xiph.org/~greg/attack_success.html -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A mining pool at 46%
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn m...@plan99.net wrote: but I think p2pool still has a lot of problems dealing with FPGA/ASIC hardware and it hasn't been growing for a long time. As an aside and a clarification— P2pool works great with FPGAs, and one of the largest FPGA farms I've heard of uses it. But it doesn't work well the old BFL FPGA miners— because they have insane latency. Likewise it doesn't currently work well with Avalon, again because of insane latency. P2pool uses a 10 second sharechain in order to give miners low variance but that means that if you have a several second miner you'll end up subsidizing all the faster p2pool users somewhat. It was basically stable with the network until ASICminer came online mining on BTCguild mostly and the first avalons started to ship, and then the network went up 10TH in a couple weeks (and now 15TH) while P2Pool stayed mostly constant. ForrestV (the author and maintainer of the P2pool software) would love to work on making Avalon and other higher latency devices first class supported on P2Pool, but he doesn't have one— and frankly, all the people who have them aren't super eager to fuss around with a 5BTC/day revenue stream, especially since the avalon firmware (and its internal copy of cgminer) itself has a bunch of quirks and bugs that are still getting worked out... and I do believe that p2pool helps reduce concerns around mining pool centralization. ... but I think as a community we don't always do a great job at supporting people who work on infrastructure— even just making sure to get them what they need to keep giving us free stuff—, we just assume they're super rich Bitcoin old hands, but that often isn't true. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Integration testing for BitCoin
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter arit...@gmail.com wrote: Hey guys, I just bought some BitCoins after being lazy to do it for the last few years, but also looked at the client code and the messages that are going on this mailing list. I saw that there are quite some unit tests, but I didn't find integration test for BitCoin, and I believe that it's quite important for the future of BitCoin (making the current code more stable, testing attack scenarios, refactoring and extending code). [...] Tests that simulate multiple bitcoin users and can verify that the whole network of bitcoin clients work together to achieve the goals of Bitcoin. Also maybe [System testing](http://en.wikipedia.org/wiki/System_testing) would be a better name for the tests, but I'm not sure. I prefer to call them system tests. We use a system called blocktester that Matt Corallo wrote, https://code.google.com/r/bluemattme-bitcoinj/source/browse/core/src/test/java/com/google/bitcoin/core/FullBlockTestGenerator.java?name=fullverifr=874c5904b12d1fcec5b556429cf208f63cd4e1bc It's based on BitcoinJ and works by simulating a peer against a slightly instrumented copy of Bitcoin(d/-qt) (modified to avoid computationally expensive mining). The tests simulates many complicated network scenarios and tests the boundaries of many (hopefully all) the particular rules of the blockchain validation protocol. We can use these tests to compare different versions of the reference software to each other and to bitcoinj (or other full node implementations) as well as comparing them to our abstract understanding of what we believe the rules of the protocol to be. These tests are run as part of the automated tests on every proposed patch to the reference software. Via a robot called pulltester which comments on github requests and produces logs like this: http://jenkins.bluematt.me/pull-tester/92a129980fb9b506da6c7f876aa8adb405c88e17/. Pulltester also performs automatic code coverage measurements. Additionally, we run a public secondary test bitcoin network called 'testnet', which can be accessed by anyone by starting the reference software with testnet=1. Testnet operates the same as the production network except it allows mining low difficulty blocks to prevent it going for long times without blocks, and some of the protective relaying rules against non standard transaction types are disabled. Most of this testing work has been centered around validating the blockchain behavior because thats what has serious systemic risk. Measuring the json rpc behavior is strictly less interesting, though interesting too. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a signature on. I stuffed the testnet chain full of the EICAR test string and it hasn't triggered for anyone— it seems that (most?) AV tools do not scan big binary files of unknown type.. apparently. If we encounter a case where they do we can implement storage scrambling: E.g. every node picks a random word and all their stored data is xored with it. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
(1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by hashing it. (2a) If we find that miners mine P2SH^2 addresses where the P2SH wasn't relayed (e.g. they want the fees) we introduce a block discouragement rule where a block is discouraged if you receive it without receiving the P2SH^2 pre-images for it. With this minor change there is _no_ non-prunable location for users to cram data into except values. (and the inefficiency of cramming data into values is a strong deterrent in any case) The same thing could also be done for OP_RETURN PUSH value outputs used to link transactions to data. Make the data be a hash, outside of the txn include the preimage of the hash. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote: Of course, either way you have the odd side-effect that it's now difficult to pay further funds to a random txout seen on the blockchain... strange, although possibly not a bad thing. Oh wow, thats actually a quite good thing— it's a property I know I've lamented before that I didn't know how to get. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Who is creating non-DER signatures?
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Actual network rules will need to come later. However, even just not accepting them into memory pools will it make very hard (if not impossible) for the buggy clients that create transactions to get any confirmations. I'm not sure... 0.6% isn't much, but 9600 transactions is. Without knowing how they're getting created it's hard to say what the damage is... are they being created by people using old cached JS transaction generators? If so— the harm is insignificant. Are they being created by hardware wallets with the keys baked inside that can't be changed? If so— the harm would be more significant. I think the latter is unlikely right now— but if the network doesn't stop relaying these transactions it seems inevitable. In all cases these transactions can be currently be mutated to an acceptable form— the malleability being one of the arguments for removing support for non-canonical encodings. So we could easily post a transaction normalizer tool that someone with unrelayable transactions could pass their transactions through to fix them, even without coming to the developers for help. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net wrote: I'd imagined that nodes would be able to pick their own ranges to keep rather than have fixed chosen intervals. Everything or two weeks is rather X most recent is special for two reasons: It meshes well with actual demand, and the data is required for reorganization. So whatever we do for historic data, N most recent should be treated specially. But I also agree that its important that everything be splittable into ranges because otherwise when having to choose between serving historic data and— say— 40 GB storage, a great many are going to choose not to serve historic data... and so nodes may be willing to contribute 4-39 GB storage to the network there will be no good way for them to do so and we may end up with too few copies of the historic data available. As can be seen in the graph, once you get past the most recent 4000 blocks the probability is fairly uniform... so N most recent is not a good way to divide load for the older blocks. But simple ranges— perhaps quantized to groups of 100 or 1000 blocks or something— would work fine. This doesn't have to come in the first cut, however— and it needs new addr messages in any case. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon john.dillon...@googlemail.com wrote: Have we considered just leaving that problem to a different protocol such as BitTorrent? Offering up a few GB of storage capacity is a nice idea but it means we would soon have to add structure to the network to allow nodes to find each other to actually get that data. BitTorrent already has that issue thought through carefully with it's DHT support. I think this is not a great idea on a couple levels— Least importantly, our own experience with tracker-less torrents on the bootstrap files that they don't work very well in practice— and thats without someone trying to DOS attack it. More importantly, I think it's very important that the process of offering up more storage not take any more steps. The software could have user overridable defaults based on free disk space to make contributing painless. This isn't possible if it takes extra software, requires opening additional ports.. etc. Also means that someone would have to be constantly creating new torrents, there would be issues with people only seeding the old ones, etc. It's also the case that bittorrent is blocked on many networks and is confused with illicit copying. We would have the same problems with that that we had with IRC being confused with botnets. We already have to worry about nodes finding each other just for basic operation. The only addition this requires is being able to advertise what parts of the chain they have. What are the logistics of either integrating a DHT capable BitTorrent client, or just calling out to some library? We could still use the Bitcoin network to bootstrap the BitTorrent DHT. Using Bitcoin to bootstrap the Bittorrent DHT would probably make it more reliable, but then again it might cause commercial services that are in the business of poisoning the bittorrent DHT to target the Bitcoin network. Integration also brings up the question of network exposed attack surface. Seems like it would be more work than just adding the ability to add ranges to address messages. I think we already want to revise the address message format in order to have signed flags and to support I2P peers. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote: running hash of all messages sent on a connection so far. Add a new protocol message that asks the node to sign the current accumulated hash. We already depend on OpenSSL, why not just use standard SSL? SSL doesn't actually provide non-repudiation. We actually want non-repudiation. I want to be able to prove to others that some node deceived me. (there are a number of other arguments I could make against SSL, but that one is probably sufficient— or rather, it's an argument that we should have some way of cheaply getting non-reputable signatures regardless of the transport) Last time I looked, Tor wasn't really usable in library form and connecting to hidden services is really slow. So it'd be an issue to just re-use it out of the box, I think. For phone stuff you should work with The Guardian Project - they've implemented Tor on Android among other things and want to find easier ways for apps to use it. Also look into torchat, which bundles a special tor build and runs a hidden service. Because of services like Blockchain.info attacking the casual privacy users not using their webwallet service I've been thinking that even for clients that don't normally use tor their own transaction announcements should probably be made by bringing up a connection over tor and announcing. But thats another matter... I've switched to running on tor exclusively for my personal node (yay dogfooding) and I've found it to connect and sync up very fast most of the time. The biggest slowdown appears to be the our timeout on the tor connections is very high and so if it gets unlucky on the first couple attempts it can be minutes before it gets a connection. We're short on onion peers and I sometimes get inbound connections before I manage to get an outbound. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote: We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure you're connection isn't being tampered with and is encrypted. Because if you just want bitcoin p2p over SSL... just start up stunnel on another port. Done. You've still solved nothing about the problem of discovery issue. 1) Non-repudiation is only useful with fraud proofs, and they will have to be thought out for everything the node might claim. That isn't so. If a node is reliably rogue I can go manually gather evidence and people can manually take action against it. Consider the DNSseeds, right now fraud proofs really wouldn't matter— the limited amount of trust put in those things is based not on oh no, nodes will ignore you in the future if you're bad, it's based on the ability of misconduct to sully the operator's reputation. But without non-repudiation the ability to tie reputation to good behavior is fairly limited especially if they perform targeted attacks. Wasn't me Instead— I'd argue that non-repudiation is always useful when there is trust. It's things like fidelity bonds— a trust generator that depend on automatic enforcement— that are only useful with fraud proofs. Anyway, the concept of a per-node identity keypair is the first step towards non-repudiation, and implementing SSL transport. Yea, indeed, per-node keys are useful for a bunch of things. Care is needed to avoid problems like deanonymizing use over tor with them. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote: Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. Or you can just let it mine honestly and take the Bitcoins. This is fast (doesn't require weeks of them somehow not noticing that they're isolated), and yields the values I listed as 'costs' if you would have otherwise been able to use it to mine the difficulty down to 1. Cost is just as much foregone income from the alternative attack you could have done instead. nor even topological, nor even particularly long-lived. At least for attacks that drive the difficulty down it does. If you want to talk about abusing a pool or creating a partition in order to create short reorgs— I agree, those don't have to be long lived and you can find many messages where I've written on that subject. It's inconsiderate to propose one attack and when I respond to it changing the attack out from under me. :( I would have responded entirely differently if you'd proposed people segmenting the network and creating short reorgs instead of mining the difficulty down. Do you know if there is any downwards limit on difficulty? I know it takes going slow for a long and noticeable time, but I am just curious on the theoretical limit. Every 2016 blocks can at most lower the difficulty by a factor of 4, thats where the log4 (number of 2016 groups needed) and 4^n (factor in cost reduction for each group) come from in the formulas I gave previously. I dont see the signatures. http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/SHA256SUMS.asc/download The signatures can't be inside the tarball because they sign the tarball. Seems like the website redesign managed to hide the signatures pretty good. They're in the release announcements in any case, but that should be fixed. Even when they were prominently placed, practically no one checked them. As a result they are mostly security theater in practice :(, — so— unfortunately, is SSL: there are many CA's who will give anyone a cert with your name on it who can give them a couple hundred bucks and MITM HTTP (not HTTPS!) between the CA's authentication server and your webserver. Bitcoin.org is hosted by github, even if it had SSL and even if the CA infrastructure weren't a joke, the number of ways to compromise that hosting enviroment would IMO make SSL mostly a false sense of security. The gpg signatures and gitian downloader signatures provide good security if actually used, solving the getting people to use them problem is an open question. And I agree, this stuff is a bigger issue than many other things like mining the difficulty down. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote: Busy with pre-conference stuff, not following details of this conversation... ... but it sounds a lot like the guy fawkes protocol Zooko was thinking about a year or so ago. Sort of, but in a guy fawkes signature you use the commitment to hide the preimage that proves you had authority to spend a coin. Adam proposes you do this in order to hide _which coin you're spending_. This has obvious anti-DOS complications, but Adam deftly dodged my initial attempts to shoot him down on these grounds by pointing out that you could mix blinded and blinded inputs and have priority and transaction fees come from only the unblinded ones. Effectively, it means that so long as you could convince the network to let you spend some coins, you could also spend other ones along for the ride and the network wouldn't know which ones those were until it was too late for it to pretend it never saw them. I think there are all kinds of weird economic implications to this— a blinded payment would seem to have a different utility level to an unblinded one: you can't use it for fees— except you can unblind it at any time. And the discontinuousness (two types of inputs) and that it would enable mining gibberish (though perhaps not data storage, if you see my preimage solution to that) seems awkward and I think I have to spend some time internalizing it before I can really think through the implications. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin, depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication creates quadratic costs in evaluating a private clique's claims so instead an implementation would make the identities public but only once they're burred a bit. Perhaps an extreme version of the idea is easier to understand. Ignore DOS attacks for a moment and pretend there is never any address reuse: Everyone creates txouts paying a P2SH addresses that have a OP_PUSH nonce in them and tell you recipient the nonce out of band. When the recipients spend those coins they provide the script but not the nonce. The recipient knows what coins he's spending, but the public does not. The public can tell there is no double spend though, because they'd see the same script twice. The person he's paying may be skeptical that he actually has any coin and didn't just mine some gibberish, but our spender tells that their receiver the nonce, and that person can see the coin available for spending in the chain and also see that there are no double spends. This could actually go on forever with no ambiguity over who owns what, but the out of band proofs that you have to give people when you spend coins would grow with the history of the coins. Since there wouldn't be much privacy once a transaction was sufficiently split up in any case, you instead just publish the unblindings once transactions are sufficiently buried. Thus bounding the growth of the proofs. The reason I say I need to internalize this more is mostly that I need to think about attacks on the publication for 'tained' transactions being more or less isomorphic to just refusing to allow spending of the 'tainted' coins in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Double Spend Notification
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote: So the decision has been made to make 0-conf double spends trivial, so no one will ever trust 0-confs. If a later transaction appears with a larger fee, it will be considered to be the valid one, and the first one dropped, as long as the first one has not been confirmed. This makes undoing a mistaken transaction possible. This has been suggested, but I know of no such decision having been made. Indeed. I've argued against it pretty aggressively, but I am starting to find arguments for and against pure fee-based replacement more equally persuasive. Regardless of the eventual outcome, fees today aren't a major motivator vs subsidy and overall network health— and even if some protection isn't 100% there are plenty of cases where the risk is averaged across many small transactions and any reduction of risk is a reduction in operating cost. (No one is going to double spend your soda machine at high speed— so you can like increase your prices by the amount of successful double spends you experience and call it done) On the other hand, it's well established that people underestimate the costs of unlikely risks. More deterministic behavior can result in safer interactions more than _better_ behavior. If we believe that in the long term self-interest will result in pure-fee based replacement being wide spread then it is also good to not build a dependency on behavior that will not last. One point that was only recently exposed to me is that replacement combined with child-pays-for-parent creates a new kind of double spend _defense_: If someone double spends a payment to an online key of yours, you can instantly produce a child transaction that pays 100% of the double spend to fees... so a double spender can hurt you but not profit from it. (and if your side of the transaction is potentially/partially reversible he will lose)... But then again, a race to burn more money is kinda ... odd and even if the benefit of resisting the double spends is only a short term benefit, a short term benefit can be greatly important in encouraging Bitcoin adoption. ... and the long term behavior is far from certain. So at least from my position it's far from clear what should be done here. I've noticed a number of people who seem to be swayed by replace by fee— or at least its inevitability if not value. So even ignoring developers there may evolve a community consensus here regardless of what I think about it. My SO pointed that that the transaction burning race described above sounds like an economists wet dream: it's one of those silly cases they use in experiments to probe human behavior... except it sounds like a possible eventual outcome in systems used by people. Perhaps it would be useful to point some graduate students at this question and see what they can come up with about it. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais arthur.gerv...@inf.ethz.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin developers, We would like to report a vulnerability which might lead, under some assumptions, to a double-spending attack in a fast payment scenario. The vulnerability has been introduced due to signature encoding incompatibilities between versions 0.8.2 (or 0.8.3) and earlier Bitcoin versions. Please find at the following link a detailed description of this vulnerability: ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf It would be kind if your paper cited the one of the prior discussions of this transaction pattern: E.g. https://bitcointalk.org/index.php?topic=196990.msg2048297#msg2048297 (I think there are a couple others) The family of transaction patterns you describe is one of the ones I specifically cite as an example of why taking non-reversible actions on unconfirmed transactions is unsafe (and why most of the Bitcoin community resources) council the same. You can get similar patterns absent changes in the IsStandard rule through a number of other means. One obvious one is through concurrent announcement: You announce conflicting transactions at the same time to many nodes and one excludes another. By performing this many times and using chains of unconfirmed transactions and seeing which family your victim observes you can create input mixes that are only accepted by very specific subsets of the network. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? Without validation listening isn't currently very useful. :( Maybe it could be somewhat more with some protocol additions. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote: Is the repeatable build infrastructure portable (to any reasonable mostly-POSIX-compliant system, with gcc or clang)? I have the vague It's portable to anything that can run the relevant VMs. Uh provided you don't mind cross compiling everything from an unbuntu VM. It certainly would be nice if the trusted-computing-base for gitian were a bit smaller, thats an area for long term improvement for sure. It may need some massaging. The tor project is beginning to use the same infrastructure, so this could be usefully conserved work. Likewise expanding the supported output targets would be great— though in the case of Bitcoin this is bounded by resources to adequately QA builds on alternative targets. Requiring precise library depdendencies is quite awkward. Certainly requiring new enough to avoid known bugs is understandable, but that should be caught at configure time and fail. In some cases packages solving bugs is problematic for Bitcoin. This is something that it seems to take a whiteboard to explain, so I apologize for the opacity of simple email here. From a technical perspective Bitcoin's whole purpose is getting a whole bunch of computers world wide to reach a bit identical agreement on the content of a database, subject to a whole pile of rules, in the face of potentially malicious input, without any trusted parties at all (even the guy you got the software from, assuming you have the resources to audit it). I'll walk through a simple example: Say Bitcoin used a backing database which had an unknown a bug where any item with a key that begins with 0xDEADBEEF returns not found when queried, even if its in the DB. Once discovered, any database library would want to fix that quickly and they'd fix it in a point release without reservation. They might not even release note that particular fix it if went along with some others, it could even be fixed accidentally. Now say that we have a state where half the Bitcoin network is running the old buggy version, and half is running the fixed version. Someone creates a transaction with ID 0xDEADBEEF... and then subsequently spends the output of that transaction. This could be by pure chance or it could be a malicious act. To half the network that spending transaction looks like someone spending coin from nowhere, a violation of the rules. The consensus would then fork, effectively partitioning the network. On each fork any coin could be spent twice, and the fork will only be resolvable by one side or the other abandoning their state (generally the more permissive side would need to be abandoned because the permissive one is tolerant of the restrictive one's behavior) by manually downgrading or patching software. As a result of this parties who believed some of their transactions were safely settled would find them reversed by people who exploited the inconsistent consensus. To deploy such a fix in Bitcoin without creating a risk for participants we need to make a staged revision of the network protocol rules: There would be a protocol update that fixed the database bug _and_ explicitly rejected 0xDEADBEEF transactions until either some far out future date or until triggered by quorum sensing (or both). The users of Bitcoin would all be advised that they had to apply fixes/workaround by the switchover point or be left out of service or vulnerable. At designated time / quorum nodes would simultaneously switch to the new behavior. (Or in some cases, we'd just move the 'bug' into the Bitcoin code so that it can be fixed in the database, and we'd then just keep it forever, depending on how harmful it was to Bitcoin, a one if 4 billion chance of having to rewrite a transaction wouldn't be a big deal) We've done these organized updates to solve problems (as various flaws in Bitcoin itself can present similar consensus risks) several times with great success, typical time horizons spanning for months to years. But it cannot work if the behavior is changed out from under the software. Fortunately, if the number of users running with an uncontrolled consensus relevant inconsistent behavior is small the danger is only to themselves (and, perhaps, their customers). I'm not happy to see anyone get harmed, but it's better if its few people than many. This is part of the reason that it's a linux packaging letter, since for Bitcoin the combination of uncoordinated patching and non-trivial userbases appears to be currently unique to GNU/Linux systems. Though indeed, the concerns do apply more broadly. multiple packages is difficult, and runs into A wants only n of C, while B wants only m. My understanding is that gentoo is actually able to handle this (and does, for Bitcoin)— and really I presume just about everything else could with enough effort. I certainly wouldn't ask anyone else to do that. If you're really getting into the rathole of building separate libraries
Re: [Bitcoin-development] Endianness (was: Linux packaging letter)
On Tue, Jul 23, 2013 at 8:54 PM, Wendell w...@grabhive.com wrote: Forking for curiosity's sake: Is there a substantial barrier to endian independence in the Bitcoin codebase? Not really. The software was originally written to write out memory order to and from the wire, which is part of why the protocol is LE everywhere, so fixing that much is pretty typical endianness fixes. There is an extra kink in that almost everything Bitcoin sends and receives is an authenticated data structure— the stuff gets hashed for authentication. So that simply swizzling the byte order on immediately on input isn't enough because sometimes you'll go on to hash that data and it can't be in memory order for that. Luke gave an initial crack at it a long time ago: http://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/endian But it wasn't enough yet. Seems like its just enough of an undertaking that absent a really good reason to care about it no real progress in fixing it is happening. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Endianness (was: Linux packaging letter)
On Tue, Jul 23, 2013 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote: order to and from the wire, which is part of why the protocol is LE everywhere, *before someone corrects me, it's not LE everywhere (I meant manywhere :P)— there is just enough BE to keep you on your toes. :P -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BitMail - p2p Email 0.1. beta
On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. rdohm...@gmail.com wrote: Secure P2P Email from Friend to Friend without relying on a central server. Key- / Repleo-Exchange. Full decentral Email-Network using the Echo Protocol. Store Email for Offline-Friends in the P2P Network. Chat and Instant Messaging is build in. Define Add your friends. Strong e2e Multi-Encryption (PGP-kind/AES over SSL: using libgcrypt). Libspoton Integration. Additional Security Layer with the GB-Feature for Emails. Preventing Data Retention (VDS). WoT-less. HTTP HTTPS Connections. Open Source. BSD License. anyone with a Server? Key? Keep safe everyone: A number of apparent sock accounts has been posting about what appears to be the same software under the name goldbug for a couple days now: e.g. https://lists.torproject.org/pipermail/tor-talk/2013-July/029107.html https://lists.torproject.org/pipermail/tor-talk/2013-July/029125.html http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Preparing for the Cryptopocalypse
On Sun, Aug 4, 2013 at 8:30 PM, Peter Vessenes pe...@coinlab.com wrote: I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He told me recently NTRU, which is lattice based, is one of the few (only?) NIST-recommended QC-resistant algorithms. Lamport signatures (and merkle tree variants that allow reuse) are simpler, faster, trivially implemented, and intuitively secure under both classical and quantum computation (plus unlikely some proposed QC strong techniques they're patent clear). They happen to be the only digital signature scheme that you really can successfully explain to grandma (even for values of grandma which are not cryptographers). They have poor space/bandwidth usage properties, which is one reason why Bitcoin doesn't use them today, but as far as I know the same is so for all post-QC schemes. Though I question the validity of the claim that ECC is so much more secure than RSA (with appropriate keysizes). The problems are intimately related, but under the best understanding ECC (with suitable parameters) ends up being the maximally hard case of that problem class. I do sometimes worry about breakthroughs that give index-calculus level performance for general elliptic curves, this still wouldn't leave it any weaker than RSA but ECC is typically used with smaller keys. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. wtog...@gmail.com wrote: If you disallow the same IP and/or subnet from establishing too many TCP connections with your node, [...] has almost zero drawbacks, There are whole countries who access the internet from single IP addresses. There are major institution with hundreds or even thousands of hosts that could be running Bitcoin who are visible to the public internet as a single IP address (/single subnet). Most tor traffic exits to the internet from a dozen of the largest exits, common local-network configurations have people addnode-ing local hosts from many systems on a subnet, etc. Prioritizing the availability of inbound slots based on source IP is reasonable and prudent, but it does not have almost zero drawbacks. Outright limiting is even worse. As a protective measure its also neigh useless for IPv6 connected hosts and hidden service hosts. It's also ineffective at attacks which exhaust your memory, cpu, IO, or bandwidth without trying to exhaust your sockets. So I am not opposed to prioritizing based on it (e.g. when full pick an inbound connection to drop based on criteria which includes network mask commonality), but I would not want to block completely based on this. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] CoinWitness: Really Really ultimate blockchain compression
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some here might find interesting: https://bitcointalk.org/index.php?topic=277389.0 -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Mon, Aug 19, 2013 at 1:09 PM, Frank F frank...@gmail.com wrote: If there are technical problems with getwork, maybe they should be addressed and fixed instead of outright abandoned. They have been, resulting in a replacement called getblocktemplate which (presumably) almost everyone talking to bitcoin(d|-qt) has been using for a long time. I think removing the ability to mine in the stock package would be regrettable, but to be honest we already don't have it for the mainnet. I think we should do as Jeff suggests and remove getwork. But I think we should also package along a proper getblocktemplate miner to remove any doubt that we're providing a full network node here. (I note that the choice of miner is also easy: Regardless of people's preferences which way or another, AFAIK only luke's bfgminer stuff can mine directly against bitcoin getblocktemplate with no pool in the middle. It also supports a huge variety of hardware, and a superset of our target platforms) -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 32.5
On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I am wondering if we shouldn't have a BIP32 addendum which makes the following signing related recommendations: Looks like we're in the midst of another DSA duplicated K disaster. (Now, blockchain.info mywallet) I talked to Pieter about this some earlier today and he sounded pretty positive. I'll go ahead and start on an actual BIP document for it. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
