Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
So let's play this out a little.. Let's call it Solomon's spend[1] Exchange gets hacked, bitcoins move. The exchange has a contract with an insurance company and miners for 'scorched earth' theft response that creates a double-spend of the original transaction. So now there's a 10,000 bitcoin incentive for miners to roll back the chain and start (re)mining the block where the theft occurred. The exchange gets an insurance payout, some miner wins the lottery, and the thief gets nothing. Seems like a good deal, what am I missing? [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote: I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Bitcoin was/is a disruptive technology for credit card payment processors, and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment processors. I think whether you call it scorched earth is a bit more of a reflection of whether you stand to make money, or lose money from the distruption. Personally, I think 'first-seen' is a dangerous scorched-earth policy that only benefits the people who own the internet routers that determine what is seen first. But from the standpoint of consensus, can we at least agree that it's a *node policy* decision, and the market particpants should be free to choose whichever policy works best for them? Otherwise, I think the only way to make 'first-seen' work is by adding a timestamp to CTransaction. On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote: scorched earth refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. All payment processors AFAIK process transactions through some scoring system, then accept 0-conf transactions for payments. This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth Without adequate decentralized solutions for instant payments, deploying replace-by-fee widely would simply push instant transactions even more into the realm of centralized, walled-garden services. On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach m...@friedenbach.org wrote: Thank you Jorge for the contribution of the Stag Hunt terminology. It is much better than a politically charged scorched earth. On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote: I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have preferred stag hunt since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies an attack to bitcoin because that's not how bitcoin used to work, then I guess minimum relay fee policies can also be considered an attack to bitcoin on the same grounds. Lastly, first-seen-wins was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be the end of bitcoin or will push the price of the btc miners are mining down, I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes ho...@hozed.org wrote: On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: Most money/payment systems include some method to reverse or undo payments made in error. In these systems, the longer settlement times you mention below are a feature, not a bug, and give more time for a human to react to errors and system failures. Settlement has to be final somewhere. That is the whole point of it. Transfer costs in current electronic payment systems are a direct consequence of their non-finality. That's the point Satoshi was making in the introduction to the whitepaper: With the possibility of reversal, the need for trust spreads. The problem with that statement is I trust a merchant that I went into a store and made a payment with personally more than I trust the firmware on my hard drive [1]. The attack surface of devices in your computer is huge. A motivated attacker just needs to get an intern into a company that makes some kind of component or system that's in your computer, cloud server, hardware wallet, or what have you that has firmware capable of reading your private keys. With the possibility of mass trojaned hardware, if we are going to trust the system, it must somehow allow reversal through a human
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
in future blocks. Quite possibly, to the point where those miners are then making a loss. Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. If enough miners do it they will simply break Bitcoin to the point where it's no longer an interesting payments system for lots of people. Then miners who have equipment to pay off will be really screwed, not to mention payment processors and all the investors in them. I'm sure you can confuse a few miners into thinking your ideas are a super-duper way to maximise their income, and in the process might facilitate a pile of payment fraud. But they aren't. This one is about as sensible as your let's never increase the block size and let's kill SPV clients crusades - badly thought out and bad for Bitcoin. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus. POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to. If a proprietary stack has problems with replace-by-fee then it's probably succeptible to malicious attack because an attacker could just broadcast one transaction to the network and then replace it when they are able to mine a block themselves. On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open development processes and reddit charms
Thank you Jeff. Having looked at a lot of linux code, and now a lot of bitcoin code, the biggest long-term systemic risk I see is that Bitcoin has is the lack of code janitors. The problem is that janitoring was *disruptive* for non-x86 linux architectures when it first got going, and it's going to be very disruptive for bitcoin as well, but it **needs** to happen. The code is too complex and hard to follow as it is now. (now, I could just be speaking because I haven't paid the social debt of looking at the latest bitcoin code, including libconsensus), but there really needs to be a focus on readability, maintainability, and (as much as I hate to say it) a rather hard-line policy on coding standards. I don't care which tabbing style or column width you pick, but **pick one**, and enforce it across the entire codebase. Maybe this should be bitcoin-stable, and bitcoin-devel, with a 6-9 month social expectation of minimal cosmetic changes in -stable, with a 1 month 'merge window' where -devel turns into -stable. On Tue, Dec 16, 2014 at 12:59:06PM -0500, Jeff Garzik wrote: It can be useful to review open source development processes from time to time. This reddit thread[1] serves use both as a case study, and also a moment of OSS process introduction for newbies. [1] http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/ *Dirty Laundry* When building businesses or commercial software projects, outsiders typically hear little about the internals of project development. The public only hears what the companies release, which is prepped and polished. Internal disagreements, schedule slips, engineer fistfights are all unseen. Open source development is the opposite. The goal is radical transparency. Inevitably there is private chatter (0day bugs etc.), but the default is openness. This means that is it normal practice to air dirty laundry in public. Engineers will disagree, sometimes quietly, sometimes loudly, sometimes rudely and with ad hominem attacks. On the Internet, there is a pile-on effect, where informed and uninformed supporters add their 0.02 BTC. Competing interests cloud the issues further. Engineers are typically employed by an organization, as a technology matures. Those organizations have different strategies and motivations. These organizations will sponsor work they find beneficial. Sometimes those orgs are non-profit foundations, sometimes for-profit corporations. Sometimes that work is maintenance (keep it running), sometimes that work is developing new, competitive features that company feels will give it a better market position. In a transparent development environment, all parties are hyperaware of these competing interests. Internet natterers painstakingly document and repeat every conspiracy theory about Bitcoin Foundation, Blockstream, BitPay, various altcoin developers, and more as a result of these competing interests. Bitcoin and altcoin development adds an interesting new dimension. Sometimes engineers have a more direct conflict of interest, in that the technology they are developing is also potentially their road to instant $millions. Investors, amateur and professional, have direct stakes in a certain coin or coin technology. Engineers also have an emotional stake in technology they design and nurture. This results in incentives where supporters of a non-bitcoin technology work very hard to thump bitcoin. And vice versa. Even inside bitcoin, you see tree chains vs. side chains threads of a similar stripe. This can lead to a very skewed debate. That should not distract from the engineering discussion. Starting from first principles, Assume Good Faith[2]. Most engineers in open source tend to mean what they say. Typically they speak for themselves first, and their employers value that engineer's freedom of opinion. Pay attention to the engineers actually working on the technology, and less attention to the noise bubbling around the Internet like the kindergarten game of grapevine. [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith Being open and transparent means engineering disagreements happen in public. This is normal. Open source engineers live an aquarium life[3]. [3] https://www.youtube.com/watch?v=QKe-aO44R7k *What the fork?* In this case, a tweet suggests consensus bug risks, which reddit account treeorsidechains hyperbolizes into a dramatic headline[1]. However, the headline would seem to be the opposite of the truth. Several changes were merged during 0.10 development which move snippets of source code into new files and new sub-directories. The general direction of this work is creating a libconsensus library that carefully encapsulates consensus code in a manner usable by external projects. This is a good thing. The development was performed quite responsible: Multiple developers would verify
Re: [Bitcoin-development] Reconsidering github
On Wed, Aug 20, 2014 at 08:24:33AM +0200, Wladimir wrote: On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes ho...@hozed.org wrote: If bitcoin wants to become irrelevant, then by all means, continue to depend on github and all the unknown attack surface it exposes. Those of us that do run our own servers will migrate to higher quality alternatives. So that means you're volunteering to run a web-accessible mirror of the bitcoin repositories? Wladimir http://bitspjoule.org/hg/upstream/bitcoin I guess I should update it more than every 6 months and then the updates won't take so long. It would also go a lot faster if I had a couple of dedicated servers, but that won't happen until I sell someone a support contract for crypto-commodities trading. I figure a bitcoin a month should support the hardware, 24x7 monitoring, and maybe a couple of full nodes running on the servers as well. And to pick up from another comment on this thread if you don't understand some of the differences between git and mercurial, or how to set up servers that pull from git and mirror to mercurial, you will have a lot harder time tracking down and removing malicous code that could get injected if someone gets root on a Github server. It is also a very usefull excercise in distributed systems design to understand how distributed revision control systems in theory converge to a coherent global state, and what is similiar or different to Bitcoin's global consensus model of what the balance of every bitcoin address is. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
Gerrit is free if you can afford the admin(s) to maintain it. http://code.google.com/p/gerrit/wiki/ShowCases And yes, I'm volunteering to get paid to be the admin, especially if you want a 'painless' log in with a github account feature, because it will be very painful for me to unroll the damage if github is compromised. My preference would be that we use the same ECDSA keys we secure our bitcoins with to secure our access to the code review and source control systems. On Wed, Aug 20, 2014 at 04:16:11PM +0200, Mike Hearn wrote: If github were to be abandoned for anything, it'd make sense to move code review and bug tracking elsewhere. GitHub does a reasonably good job of hosting git repositories. It kind of sucks at code review and the issue tracker is rudimentary at best. These days you can do log in with my github account so if done well, it'd not have to be very painful. JetBrains make great stuff and they have a code review and repository exploration tool called Upsource in development, which should come out soon. I think it's proprietary but that would be no different to github, and it's designed for self hosting. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote: On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote: It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as github, nice and convenient as it is. Assuming there is a problem with that usually is caused by using Git the wrong way or not knowing its capabilities. Nobody can modify / insert a commit before a GnuPG signed commit / tag without breaking the signature. More detail at the bottom at [1], I am sparing you this here because I suspect you already know it and there is something more important I want to stress: Bitcoin has currently 4132 forks on Github. This means that you can get contributions by pull requests from 4132 developers. That is a HUGE amount, and you shouldn't ditch that due to not using all features of git :) To get a grasp of how much that is: When you search projects with more than 4100 forks, there are only 32 of them! You are one of the top open source projects, and you should be grateful for that and keep Github up so the other people can send you pull requests with their improvements :) Volunteer contributions need to be honored and made as easy as possible, for people are investing their personal time. Greetings and thanks for your work, xor, one developer of https://freenetproject.org [1] If you GPG-sign a commit / tag, you sign its hash, including the hash of the previous commit. So is a chain of hashes and thus of trust from all commits up to what is signed. It's pretty similar to the blockchain actually :) So Github cannot modify anything. If they did, the head of the hash-chain would change, and thus the signature would break. Git would notify people about that when they pull. Of course people can still ignore that warning and let Github rewrite their Git history. But people who aren't educated about this shouldn't be release managers. They should not even have push access to your main repository, they should only be sending pull requests. Thats is where the decentralization of Git is: In the pull-requests. The people who deal with them should verify tag and possibly even commit signatures carefully, and not accept anything which is not signed. Also, before deploying a binary, the very same commit which is going to become a binary has to be given a signed tag by the release manager, and by everyone who reviews the code. The person who deploys the actual binary needs to verify that signature. There is an article which elaborates on some of the ways you have to ensure Github doesn't insert malicious code - but please read it with care, some of its recommendations are bad, especially the part where its about rebasing because that DOES rewrite history which is what you want to prevent: http://mikegerwitz.com/papers/git-horror-story This is why I clone git to mercurial, which is generally designed around the assumption that history is immutable. You can't rewrite blockchain history, and we should not be re-writing (rebasing) commit history either. The problem with github is it's too tempting to look at the *web page*, which is NOT pgp-signed, and hit the 'approve' button when you might have someone in the middle approving an unsigned changeset because you're in a hurry to get the latest new critical OpenSSL 0day security patch build released. We need multiple redundant 'master' repositories run by different people in different jurisdictions that get updated on different schedules, and have all of these people pay attention to operational security, and not just outsource it all to github because it's convenient. There's no reason to *stop* using github, cause it *is* easy... but you want to have multiple review of *the actual code*, not just signatures and see if the changes really do make sense. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
I think it's a little disingenuous to talk about encrypting the P2P protocol as a security improvement, when all the organized crime agencies need to do is borrow a Fedex/UPS truck and deliver some laptops to Github employees and they can insert whatever monitoring/0-day they want. Encryption is complicated stuff to actually **get right**, and the more stuff you throw crypto around, the more likely it is you'll get a Heartbleed 0-day If you want to increase security, make it simpler. I'm not even sure it can be easily simplified... how could you separate the P2P network transport from the core blockchain functionality? On Wed, Aug 20, 2014 at 04:37:24PM +0200, Mike Hearn wrote: I would be very happy if we upgraded the P2P protocol with MAC keys and a simple home grown encryption layer, because: 1. It's practically guaranteed that 5-eyes intelligence agencies are either systematically deanonymising Bitcoin users already (linking transactions to real world identities) or close to succeeding. Peter is correct. Given the way their infrastructure works, encrypting link level traffic would significantly raise the bar to such attacks. Quite possibly to the level where it's deemed unprofitable to continue. 2. Tor is not a complete solution. The most interesting links to monitor are those from SPV clients connecting to Core nodes. Whilst Java SPV clients have the nice option of an easy bundled Tor client (er, once we fix the last bugs) clients that are not based on bitcoinj would have to use the full-blown Tor client, which is not only a PITA to bundle as Tor is not at all library-fied, but is a giant pile of C which is almost certainly exploitable. Even if it runs in a separate address space, for many platforms this is insufficient as a compromised Tor client could then go ahead and compromise your wallet app too. Implementing a full Tor client is not a reasonable thing to ask of a wallet developer, but doing HMAC checks and a simple ECDH exchange + AES would be quite realistic. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
On Sat, Aug 23, 2014 at 10:32:15AM -0400, Peter Todd wrote: On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote: This is why I clone git to mercurial, which is generally designed around the assumption that history is immutable. You can't rewrite blockchain history, and we should not be re-writing (rebasing) commit history either. Git commits serve two purposes: recording public history and communication. While for the purpose of recording history immutable commits make sense, for the purpose of communicating to other developers what changes should be added to that history you *do* want the mutable commits that git's rebase functionality supports. Much like how university math classes essentially never teach calculus in the order it was developed, it is rare indeed for the way you happened to develop some functionality to be the best sequence of changes for other developers to understand why and what is being changed. Anyway, just because mercurial is designed around the assumption that commit history is immutable doesn't mean it actually is; an attacker can fake a series of mercurial commits just as easily as they can git commits. The only thing that protects against history rewriting is signed commits and timestamps. What I would really like is a frontend and/or integration to Git/Mercurial that uses Bitcoin transactions *as* the signature, which has the nice side effect of providing timestamps backed by the full faith and credit of a billion dollar blockchain. So what is the best way for me to stick both a git *and* a mercurial identity hash into a bitcoin transaction? (which leads to point 2 below) The problem with github is it's too tempting to look at the *web page*, which is NOT pgp-signed, and hit the 'approve' button when you might have someone in the middle approving an unsigned changeset because you're in a hurry to get the latest new critical OpenSSL 0day security patch build released. We need multiple redundant 'master' repositories run by different people in different jurisdictions that get updated on different schedules, and have all of these people pay attention to operational security, and not just outsource it all to github because it's convenient. The easiest and most useful way to achieve that would be to have a formal program of code review, perhaps on a per-release basis, that reviewed the diffs between the previous release and the new one. Master repos in this scenario are simply copies of the master master repo that someone has manually verified and signed-off on, with of course a PGP signature. If you feel like volunteering to maintain one of these repos, you may find my Litecoin v0.8.3.7 audit report to be a useful template: https://bitcointalk.org/index.php?topic=265582.0 I'm not interested in volunteer, I'm interested in getting paid, and the best way I believe I can accomplish that is use *my* bitcoin address in a signature-transaction of the code I've reviewed. What is the advantage of PGP? Far more people have ECDSA public-private keys than PGP keys. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
On Sat, Aug 23, 2014 at 04:50:30PM +, Justus Ranvier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/23/2014 04:17 PM, xor wrote: On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote: Encryption is of little value if you may deduce the same information by observing packet sizes and timings. Instead of spawning a discussion whether this aspect is a reason to NOT encrypt, you should do the obvious: Fix that as well. X being broken is not a reason for not fixing Y. Pad the then encrypted packets with random bytes. The fact that they are encrypted makes them look like random data already, so the padding will not be distinguishable from the rest. Also, add some random bias to their timing. The packet size and timing issue will become less of an issue as the network grows anyway. One transaction inserted into a 3 transaction-per-second encrypted stream is more obvious than the same transaction inserted into a 100 or 1000 TPS stream. The requirement for anonymity and privacy is lawyers and a Bitlicense. If you want privacy and anonymity, then do high-frequency trading on a centralized exchange, and if you want to go over-the-top, run some arbitrage bots as well, and hide in the millions of transactions per second that go on. But make sure you get a Bitlicense and have a good securities lawyer. Trying to solve a legal/legislative/social problem with more crypto is only going to serve the people who created the legal/legislative/social problem in the first place, because they can hire a hacker who will find a misplaced (} in your crypto code, and all the work you did to encrypt wire protocols becomes silently worthless. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering github
On Tue, Aug 19, 2014 at 04:58:48PM +0200, Wladimir wrote: On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote: It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as github, nice and convenient as it is. Despite my complaining about github, I don't like the idea of moving somewhere else. The current way of working - to use github for storing the tree, and use a custom script for signing+merging - is fine with me. Github has a low barrier to contribution. Almost every open source developer already has a github account. Switching to something self-hosted makes it more difficult for people to contribute. Plus if we have to take the hosting upon ourselves, we have to handle sysadmin work ourselves as well. That's not a good use of the limited manpower available. Also it will be a lot of work to migrate over all the current issues and pulls. I don't look forward to that. I don't see the point of this, sorry. Wladimir If a project cannot be organized enough to run its own hosting/web presense/ counterintelligence/security that starts with installing an OS and patching kernels, then it is really not wise for me to trust my financial future to software written by such a group. There is a great deal of 'work' that is really quite pointless, particularly in regards to claims I see about security that are irrelevant unless you have the understanding that comes from operating and running your own servers. This includes running DDOS protection, so no cloudflare. If bitcoin wants to become irrelevant, then by all means, continue to depend on github and all the unknown attack surface it exposes. Those of us that do run our own servers will migrate to higher quality alternatives. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
On Thu, Aug 07, 2014 at 11:45:44PM +, Luke Dashjr wrote: On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote: Hi there, I was wondering if you guys have come across this article: http://www.wired.com/2014/08/isp-bitcoin-theft/ The TL;DR is that somebody is abusing the BGP protocol to be in a position where they can intercept the miner traffic. The concerning point is that they seem to be having some degree of success in their endeavour and earning profits from it. I do not understand the impact of this (I don't know much about BGP, the mining protocol nor anything else, really), but I thought it might be worth putting it up here. This is old news; both BFGMiner and Eloipool were hardened against it a long time ago (although no Bitcoin pools have deployed it so far). I'm not aware of any actual case of it being used against Bitcoin, though - the target has always been scamcoins. That statement right there is all the evidence I need to convince myself that Bitcoin is under continuous and active BGP feed manipulation by organized crime elements. Just the phrase of referring to !bitcoin as 'scamcoins' is a signal of an organized marketing/psychological operations effort to marginalize other competitors, and the documented altcoin BGP highjacks were most likely testing of the system to confirm both a) that it works b) how to hide it below the detection threshhold -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
On Fri, Aug 08, 2014 at 11:42:52AM +0200, Mike Hearn wrote: AFAIK the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... Why would miners need updates? If they implement the standard SSL infrastructure you can change certificates and keys without needing to update miners. Besides, when it comes to financial services SSL is essential, I'm kind of surprised it wasn't already used everywhere. I wouldn't use an online bank that didn't support SSL, I would see it as a a sign of serious problems. Heck I wouldn't even use webmail that didn't support SSL these days. Because turning on SSL gives pool operators a way to hack your miners. http://www.symantec.com/connect/blogs/openssl-patches-critical-vulnerabilities-two-months-after-heartbleed Just because SSL is the answer for financial services regulated security theatre, where fraud means you just roll-back the transaction, it does not mean it is actually a good cryptographic solution. There are far better mechanisms that could be implemented using ECDSA keys (aka bitcoin addresses) to authenticate both miners and pools, but the problem is there zero economic incentive to do so. As long as the BGP/SSL/zero-day-of-the-week man-in-the middle fraud cost is lower than the engineering cost to do some real cryptography and code audits, we'll keep having new 'security patches' every couple of months. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
On Fri, Jul 25, 2014 at 12:30:11PM +0200, Mike Hearn wrote: Ok... 'time' on the blockchain could be 'gamed' ... but with great difficulty. Unfortunately not: miners have in the past routinely gamed the timestamp in order to use it as an extra nonce and squeeze some more gigahashes out of their hardware/pool. Also remember that currently the chain could be dominated by a coalition of just two pools. There's a solution to both of these problems.. https://github.com/CatcoinOfficial/CatcoinRelease/commit/0d03a5b3d8bb7bc3c935e7196c5d807da997cf9c If you want a really reliable time source, use at least three block chains and make sure they all agree within an hour. An application presented with a fake blockchain can use quite a few heuristics to test the 'validity' of the block chain. The app cannot tell if it was given a truncated chain. You could keep such an app stuck in the past forever. This is often a problem. Reliable 'time' has been impossible up until now - because you need to trust the time source, and that can always be faked. Using the blockchain as an approximate time source gives you a world wide consensus without direct trust of any player. Much though I hate to be a party pooper, you could currently get Bitcoin-level trusted time by just polling at least two or three independent servers e.g. google.com, baidu.cn, yandex.ru(they all serve time via HTTPS headers). Well, being as how I don't trust Bitcoin anyway because it includes SSL, yes, you could get 'bitcoin-level' trust. If we crack the mining decentralisation problem then this argument becomes a lot stronger, but for now .. But if you actually want something secure, you look at the altcoin space which solved the mining decentralization problem when Litecoin came out, and this also solves the having to trust a single source code base. There is lots of code diversity out there in altcoins, and what appears to me to be a really strong cryptographically sound time source, but only if you use multiple diverse sources. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote: On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof-of-Stake branch?
Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
I understand the theoretical benefits of multi-sig. But if you want to make this mind-numbingly simple, do it on the *existing* single-sig. But why in the world do we not have a *business* that offers bitcoin wallet insurance? The bitcoin world (and this list) ran around blaming MtGox and users for being 'stupid' to trust mtgox. So start a multi-level marketing business that offers *insurance* so if your bitcoin wallet gets hacked/stolen/whatever, your 'upstream' or whomever sold you the wallet comes to your house with a new computer or installs the new wallet software, or whatever, or just makes it good. Now, if the **insurance underwriter** decides that multisig will reduce fraud, and **tests it**, then I'd say we do multi-sig. But right now we are just a bunch of technology wizards trying to force our own opinions about what's right and 'simple' for end users without ever asking the damn end-users. And then we call the end-users idiots because some scammer calls them and says I'm calling from Microsoft and your computer is broke, please download this software to fix it. Multi-sig is more magical moon-math that scammers will exploit to con your grandma out of bitcoin, and then your friends will call her a stupid luddite for falling for it. Fix the cultural victim-blaming bullshit and you'll fix the node bleeding problem. On Mon, Apr 07, 2014 at 10:15:15AM -0400, Eric Martindale wrote: We need to make it so mind-numbingly simple to run Bitcoin correctly that the average user doesn't find reasons to do so in the course of normal use. Right now, Coinbase and Bitstamp are winning in the user experience battle, which technically endanger the user, and by proxy the Bitcoin network. Multi-sig as a default is a start. It won't succeed unless the user experience is simply better than trusted third parties, but we need to start the education process with the very basic fundamental: trusting a third-party with full access to your Bitcoin is just replacing one centralized banking system with another. Eric Martindale Developer Evangelist, BitPay +1 (919) 374-2020 On Apr 7, 2014 7:05 AM, Mike Hearn m...@plan99.net wrote: My guess is that a large number of users have lost interest after they lost their money in MtGox. The 24th of February coincides with the final shutdown Sigh. It would not be surprising if MtGox has indeed dealt the community a critical blow in this regard. TX traffic is down since then too: https://blockchain.info/charts/n-transactions-excluding-popular?timespan=60daysshowDataPoints=falsedaysAverageString=1show_header=truescale=0address= Judging from comments and the leaked user db, it seems a lot of well known people lost money there (not me fortunately). I wish I could say people have learned but from the size of the deposit base at Bitstamp they clearly have not. A lot of Bitcoin users don't seem to be ready to be their own bank, yet still want to own some on the assumption everyone else either is or soon will be. So it's really only a matter of time until something goes wrong with some large bitbank again, either Bitstamp or Coinbase. Some days I wonder if Bitcoin will be killed off by people who just refuse to use it properly before it ever gets a chance to shine. The general public doesn't distinguish between Bitcoin users who deposit with a third party and the real Bitcoin users who don't. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration
Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address
with public key cryptography. The problem is that it theoretically offloads a lot of complexity and responsibility on the user. Managing private keys securely is complex. However this complexity is already being addressed in the Bitcoin ecosystem. So doing public key authentication is practically a free lunch to bitcoiners. I've formatted the protocol description as a BIP because this is the only way to have all major wallets implementing it, and because it completely fits in my opinion the BIP process category. Please read it and let me know your thoughts and comments so we can improve on this draft. Eric Larcheveque ela...@gmail.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
Anyway the particular situation in which a single entity controls 40% of the hashing power should be rare. That's potentially dangerous for bitcoin and although changing the hashing algorithm would be painful and risky, I would be terribly scared of that happening if I was that entity. Letting my percentage of hash rate dilute as others grow would definitely be part of my plan. I think *your* plan is an ecologically and socially rational plan. My observations of irrational responses on this list lead me to believe there is a single entity (which may be a cartel) which *effectively* controls between 30% and 50% of the sha-256 hashing power and is quite terrified of any alternative, and attempts to purchase, consume, or eliminate any entities that might dilute it's controlled hash rate or pose a risk of switching to a new algorithm. We must have a system in which 1 to 10% of the hashrate can provide a reasonable check-and-balance and competitive pressure to 90% of the hash rate, or it's going to be fundamentally unstable, and we will just re-create 'to big to fail' all over again. Although this is again completely orthogonal to the merged mining or not discussion, hashing algorithms are often mixed in the discussions against merged mining. If you had to introduce that hashing algorithm hardfork change you will probably chose something with similar properties than those of SHA256, like being easy to implement specialized hardware for it. You could even chose a memory-hard algorithm if you want to promote ASIC production centralization, but you can't chose an anti-ASIC algorithm because those don't exist. It is well known that any information machine that can be built with software can also be built with specialized hardware and viceversa. Sadly that kind of fallacy is often used to justify the ecological crime that starting a new chain with no plans of doing merged mining represents. You speak of ecological crime without proposing any mechanism in which the ecologically correct thing is also the economically rational thing. If I could get real-time MISO market pricing for wind energy, I could do this http://grid.coop/smartgridcmp-long.png and run a mining farm on my farm. I would like to propose we collaborate on developing secure mechanism to audit energy sources for miners on a new chain called 'Ecocoin' in which the block reward is proportional to how much energy the owner of the newly generated block reward personally harvested from renewable sources. The reward curve will have to be calibrated and adjusted to minimize the over all costs and fraud risk of auditing the energy input sources. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Thu, Mar 27, 2014 at 02:49:32PM +0100, Thomas Voegtlin wrote: Le 27/03/2014 13:49, Mike Hearn a écrit : Ah, BIP32 allows for a range of entropy sizes and it so happens that they picked 256 bits instead of 128 bits. I'd have thought that there is a right answer for this. 2^128 should not be brute forceable, and longer sizes have a cost in terms of making the seeds harder to write down on paper. So should this be a degree of freedom? Here is what I understand: 2^128 iterations is not brute forcable today, and will not be for the foreseeable future. I foresee 2^128 being brute forceable in 20-25 years. See below. An EC pubkey of length n can be forced in approximately 2^(n/2) iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which are 256 bits, would require 2^128 iterations. This is why unused addresses (160 bits hash) are better protected than already used ones. However, people tend to believe that a public key of size n requires 2^n iterations. This belief might have been spread by this popular image: https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146 So I assume this image is using the Landauer principle for minimum energy ( http://en.wikipedia.org/wiki/Landauer%27s_principle ), however it is unknown (to me at least) if a reversible computing ecdsa forcing algorithm could be implemented. (this may or may not be a quantum computing device) Let's suppose for a moment you could, and get a million times better than the Landauer pinciple limit of 2.85 zJ per bit, so we have total energy to cycle through 128 bits of address space of: units 2**128 * 2.85zJ / 1e6 megawatt*hours * 269.39021 An attacker with a sub-Landauer limit/1e6 cracker would need a lot of silicon area, and a couple of hours energy from a large wind farm, and could siphon that energy out in a rural area without anyone noticing anything other than a few shipping containers and that the wind turbines are running more on windy days. If we go back to just Landauer limit, and assume a 10MW system that runs 24x7 (much like the NCSA Blue Waters Cray machine), we need: (please check my math, or point out any stupid assumptions I've made) units 2**128 * 2.85zJ / 10 megawatts years * 3073.1914 Or 3000 years. Well that still sounds pretty safe. How about 250MW? units 2**128 * 2.85zJ / 250 megawatts years * 122.92766 Now I'm starting to get worried, because when I started computing, it was on an 8-bit CPU that was measured in thousand operations-per-second. In 1996 the largest supercomputer in the world was ASCII Red, with an amazing 1 trillion floating-point operations per second. This morning I have a 1-2 Teraflop water-cooled graphics processor sitting next to me warming the room. I expect in 5-10 years we'll have silicon with 256 bit registers that may be able to do thousands or millions of ECDSA calculations per second per computation unit. So if you stop hearing from me here, it's because I found a better mailing list, or a got a contract to develop and ECDSA cracker, in which case you probably won't hear from me again until I have a talk at DEFCON showing it off. -- Troy Benjegerdes -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wed, Mar 26, 2014 at 09:49:39PM +0100, Mike Hearn wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: - cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. Using the same keys across different altcoins seems like an exceedingly bad opsec practice. Cointype is critical, as well as having a predictable and deterministic mapping of alt coins to Cointype. What should I be using for Catcoin, for instance? the CAT symbol all the exchanges use, or do we set up a 'registry', or some other mechanism? I'd venture to guess the altcoin market is, or soon will be larger in US dollar value trade volume than Bitcoin, so *some* of us are quite bothered by the wailing and gnashing of teeth that occurs on this list at mere thought of such heresy. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFQBAEBCAA6BQJTMd1DMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhb89B/98Tb0Xncho+1cbja1K R9xYOKPhWU5EIuPr7zbpuQxufuM8hZsyFSo/ptnQnJ8EAJ2GvUUEnE2vDDjvqqJm vy5URtOwKc6ztBDrjtWToKCgBwpJTektWrJMu2FQaO5CV/4sHhVM4By8BoDvCNLt xeN7BccjvlDZ+2ggRaYt4P/QKctEyt9qZrdDmIsNxUa+bLzplHoqdoQMjQ2CUcUA T+/Lq7MH+vROJXqx7d3JSsZAQ59evQDyorvCrxNgfVbB7j10t1zr5r5viWUEDtZ5 /9DAP92vpSCokmKWfSlysHbC4KEqWglWka7aSBLXmAVrJeFxJRojsLQbCKUUFrG0 IigO =91oy -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
On Tue, Mar 25, 2014 at 08:40:40PM +, Ricardo Filipe wrote: 2014-03-25 13:49 GMT+00:00 Peter Todd p...@petertodd.org: On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote: On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote: Bitcoin doesn't scale. There's a lot of issues at hand here, but the most fundemental of them is that to create a block you need to update the state of the UTXO set, and the way Bitcoin is designed means that updating that state requires bandwidth equal to all the transaction volume to keep up with the changes to what set. Long story short, we get O(n^2) scaling, which is just plain infeasible. We have a fundamental disagreement here. If you go back and read Satoshi's original thoughts on scaling, it is clear that he imagined tens of thousands of mining nodes and hundreds of millions of lightweight SPV users. Yeah, about that... https://blockchain.info/pools On-topic: This argument is quite the fallacy. The only reason we have that few pools is because each of their miners doesn't find it feasible to mine on their own. if you count the individual miners on those pools you will get to the scale Gavin was trying to point out. Nevertheless i think that is just a minor disagreement, since tree chains help decentralization. I think is actually a major fundamental disagreement, and opinions tend to correlate strongly with salary considerations. It is difficult to get a man to understand something, when his salary depends upon his not understanding it! -- Upton Sinclair Let us either agree to disagree, or get on with moderating this list so that only sensible salaried discussions can take place. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Mon, Mar 24, 2014 at 01:57:14PM -0700, Mark Friedenbach wrote: On 03/24/2014 01:34 PM, Troy Benjegerdes wrote: I'm here because I want to sell corn for bitcoin, and I believe it will be more profitable for me to do that with a bitcoin-blockchain-based system in which I have the capability to audit the code that executes the trade. A discussion over such a system would be on-topic. Indeed I have made my own proposals for systems with that capability in the past: http://sourceforge.net/p/bitcoin/mailman/message/31322676/ There's no reason to invoke alts however. There are ways where this can be done within the bitcoin ecosystem, using bitcoins: http://sourceforge.net/p/bitcoin/mailman/message/32108143/ I think that's fair, so long as we limit bitcoin-development discussion to issues that are relevant to the owners of the hashrate and companies that pay developer salaries. What I'm asking for is some honesty that Bitcoin is a centralized system and to stop arguing technical points on the altar of distributed/decentralized whatever. It's pretty clear if you want decentralized you should go with altchains. Bitcoin is not a centralized system, and neither is its development. I don't even know how to respond to that. Bringing up altchains is a total red herring. This is *bitcoin*-development. Please don't make it have to become a moderated mailing list. When I can pick up a miner at Best Buy and pay it off in 9 months I'll agree with you that bitcoin *might* be decentralized. Maybe there's a chance this *will* happen eventually, but right now we have a couple of mining cartels that control most of the hashrate. There are plenty of interesting alt-hash-chains for which mass produced, general purpose (or gpgpu-purpose) hardware exists and is in high volume mass production. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
I think that's fair, so long as we limit bitcoin-development discussion to issues that are relevant to the owners of the hashrate and companies that pay developer salaries. What I'm asking for is some honesty that Bitcoin is a centralized system and to stop arguing technical points on the altar of distributed/decentralized whatever. It's pretty clear if you want decentralized you should go with altchains. I'm here because I want to sell corn for bitcoin, and I believe it will be more profitable for me to do that with a bitcoin-blockchain-based system in which I have the capability to audit the code that executes the trade. On Sun, Mar 23, 2014 at 04:53:48PM -0700, Mark Friedenbach wrote: This isn't distributed-systems-development, it is bitcoin-development. Discussion over chain parameters is a fine thing to have among people who are interested in that sort of thing. But not here. On 03/23/2014 04:17 PM, Troy Benjegerdes wrote: I find it very irresponsible for Bitcoiners to on one hand extol the virtues of distributed systems and then in the same message claim any discussion about alternate chains as 'off-topic'. If bitcoin-core is for *distributed systems*, then all the different altcoins with different hash algorithms should be viable topics for discussion. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fake PGP key for Gavin
On Sat, Mar 22, 2014 at 06:03:03PM +0100, Mike Hearn wrote: In case you didn't see this yet, http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html If you're using PGP to verify Bitcoin downloads, it's very important that you check you are using the right key. Someone seems to be creating fake PGP keys that are used to sign popular pieces of crypto software, probably to make a MITM attack (e.g. from an intelligence agency) seem more legitimate. I find it more likely that fake PGP keys are from corporate industrial espionage and/or organized crime outfits. Intelligence agencies will stick to compromised X509, network cards, and binary code blobs. Besides, why would an intelligence agency want your bitcoin when they can just intercept ASIC miners and make their own? I think the Mac DMG's of Core are signed for Gatekeeper, but do we codesign the Windows binaries? If not it'd be a good idea, if only because AV scanners learn key reputations to reduce false positives. Of course this is not a panacea, and Linux unfortunately does not support X.509 code signing, but having extra signing can't really hurt. Uhhmm, real operating system use package managers with PGP instead of pre- compromised X.509 nonsense. https://wiki.debian.org/SecureApt -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Sat, Mar 22, 2014 at 03:08:25PM -0400, Peter Todd wrote: On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote: On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. Lol! Granted, I guess I should disclose that I'm working on tree chains, which just improve the scalability of blockchains directly. I'm think tree-chains could be implemented as a soft-fork; if applied to Bitcoin the datacoin 1% might face market risk. :P Soft-fork tree chains with reasonable data/memo/annotation storage would be extremely interesting. The important question, however, is how does one build a *business* around such a thing, including getting paid as a developer. What I find extremely relevant to the **bitcoin-dev** list are discussions about how to motivate the people who own the hashrate and bulk of the coins (aka, the bitcoin 1%) to PAY DEVELOPERS, and thus it is good marketing FOR BITCOIN DEVELOPERS to remind the people who profit from our efforts they need to make it profitable for developers to work on bitcoin. If it's more profitable for innovative developers to premine and release $NEWCOIN-blockchain than it is to work on Bitcoin-blockchain, is that a valid discussion for this list? Or do you just want to stick your heads in the sand while VC's look to disrupt Bitcoin? -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On Thu, Mar 13, 2014 at 04:50:14PM +0100, Mike Hearn wrote: On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik jgar...@bitpay.com wrote: Such hand-wavy, data-free logic is precisely why community coordination is preferred to random apps making random decisions in this manner. That ship sailed months ago. If you wanted a big push for uBTC, then would have been the time. Though given that it'd have made lots of normal balances incredibly huge, perhaps it's a good thing that didn't happen. Also milli is a unit people encounter in daily life whereas micro isn't. Is it milli / micro / nano or milli / nano / micro? I bet a lot of people would get that wrong. I think the ship of hand-wavy, data-free logic sailed with 'money supply == 21 million', so why not enjoy the ride? If we care about real people and real use cases, then let's talk about indexing the money supply to some blockchain-observable value and add demurrage instead of of bikeshedding the color of the latest coat of paint. If you have to export to financial packages that can't handle fractional pennies, then by all means represent prices in whatever units you like for that purpose, but in software designed for ordinary people in everyday life mBTC is a pretty good fit. Besides, fractional pennies crop up in existing currencies too (the famous Verizon Math episode showed this), so if a financial package insists on rounding to 2dp then I guess it may sometimes do the wrong thing in some business cases already. Fundamentally, more than two decimal places tends to violate the Principle Of Least Astonishment with many humans, and as a result, popular software systems have been written with that assumption. Lots of people use currencies that don't have any fractional components at all ! So perhaps all prices should be denominated in satoshis to ensure that they're not surprised :) I'm surprised every time I pull up to a gas pump and the price is 3.24 per gallon. But I don't really care what the price is, as long as there's an e85 pump. If I could pay at the pump with bitcoin, I wouldn't even look at the price, I'd only care if my tank got filled up or if I have to drive slower to get better mileage. Hell, I'd have an app that would tell me what gas station to go to that got me the best miles per bitcoin based on where I actually wanted to go. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
cynic hat: on Every volatility bump messes up expectations of what a bitcoin is worth, so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC now, and plan uBTC for just after the next price spike to $10KUSD or whatever, and then plan on rolling back to mBTC when the price crashes from altcoin money supply inflation competition. On Thu, Mar 13, 2014 at 09:45:54AM -0400, Jeff Garzik wrote: vendor hat: on Based on this seeming consensus, BitPay was headed towards uBTC internally, and hoped to coordinate messaging and rollout with others in the community. Ah well, proceed apace, and Bitcoin Wallet will catch up, I suppose. Multiple unit changes negatively impact users, but we are already there :/ On Thu, Mar 13, 2014 at 9:34 AM, Wladimir laa...@gmail.com wrote: On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik jgar...@bitpay.com wrote: Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. I've kind of given up getting any consensus about this, or even getting people to care. Everyone agrees that a decimal shift would be good, but it's the same boring shed painting discussion every time on how many decimals. In the end nothing happens. I can't really blame Andreas for finally taking action and making the change to mBTC. People in the community are familiar with mBTC because some exchanges and price sites used mBTC (at least for a while when $1000), also mBTC seems to be catching on on reddit etc. Moving to muBTC (which in itself would be better because it is the final unit change ever needed without hardfork) would require more coordinated education effort. Wladimir -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
I'm asking for how to DEVELOP THE CODE so I can trade between two block chains, and then I'm going to start trading cats and dogs and bits. Somewhere in trying to figure out the design spec we got caught up in existential concern about 'globally knowable and accurate price history', and I'm telling you it doesn't matter. I'm the customer and the developer, someone give me a clear design document to trade between two chains and I can write it, and then we can debate improvements. On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote: This is not bitcoin-philosophy, it's bitcoin-development. Existential philosophy belongs on IRC or the forums. On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io wrote: Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote: You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1 I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1 I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote: So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. It's not. Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. Well, if your investors take money with market manipulating news stories, this is absolutely the responsible thing to do to increase shareholder value with a future opportunity to cause a crash-on-demand. Besides, if you really want microtransactions, you should be using an altcoin with faster block times, smaller market cap, and larger 'human' readable currency supply. That being said, I'd say include the change, we all know about it. What would be nice would be some exploits and attack signatures for what the DOS will look like when it hits so that those of us paying attention can make some money trading in anticipation of the market crash instead of just the guys paying for the attack. The real killer feature of Bitcoin is that we can learn from it's mistakes (and bitcoin can learn from the copycatcoins), instead of one-size-fits all fiat. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
To each his own, but if I say Please don't charge me for YOUR privacy by putting junk like stealth addresses in the blockchain, I think I'd get laughed out of most rooms. Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. On Mon, Feb 24, 2014 at 09:23:12AM -0800, Mark Friedenbach wrote: Given our standardization on 128-bit security / 256-bit primitives, I can't think of any crypto related data payload which requires more than 40 bytes. Even DER encoded compressed public keys will fit in there. A signature won't fit, but why would you need one in there? There's no need to design for 64-byte hashes, and the 80-char line length comparison is a good point. As an Engineer I'd want to have a little more room as a 32-byte hash or EC point + 8 bytes identifying prefix data is the bare minimum, but it is also very important that we send a message: This is for payment related applications like stealth addresses only. Don't burden everybody by putting your junk on the block chain. On 02/24/2014 08:39 AM, Wladimir wrote: On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: A common IRC proposal seems to lean towards reducing that from 80. I'll leave it to the crowd to argue about size from there. I do think regular transactions should have the ability to include some metadata. I'd be in favor of bringing it down to 40 for 0.9. That'd be enough for 8 byte header/identifier32 byte hash. 80, as the standard line length, is almost asking for insert your graffiti message here. I also see no need for 64 bytes hashes such as SHA512 in the context of bitcoin, as that only offers 256-bit security (at most) in the first place. And if this is not abused, these kind of transactions become popular, and more space is really needed, the limit can always be increased in a future version. Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
On Fri, Feb 14, 2014 at 12:21:59AM -0500, Peter Todd wrote: On Tue, Feb 11, 2014 at 11:59:19AM -0600, Troy Benjegerdes wrote: Is there any code that does this? I would like to develop a multicoin-qt wallet that runs on two blockchains from one binary, and allows trading using this mechanism between the two chains. Cross-chain trading is a different thing entirely; it doesn't allow for the clever 2-party-trade trick. (as far as I know) Is there a simple way to do cross-chain trades that doesn't need a third chain to somehow facilitate things? -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Is there any code that does this? I would like to develop a multicoin-qt wallet that runs on two blockchains from one binary, and allows trading using this mechanism between the two chains. On Mon, Feb 10, 2014 at 02:32:47PM -0500, Peter Todd wrote: On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote: On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote: Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE that allows colored coins and similar embedded consensus system assets to be securely transferred to another party in exchange for Bitcoins atomically. In summary his p2p 2-step-trade mechanism operates as follows: I'm told there's probably at least one if not more earlier attributions/reinventions for the 2-step-trade protocol using SIGHASH_SINGLE. Please reply with them if you have them so we can give credit where credit is due. Got this: Message-ID: 52418eba.3080...@monetize.io Date: Tue, 24 Sep 2013 06:08:10 -0700 From: Mark Friedenbach m...@monetize.io Organization: Monetize.io Inc. To: Meni Rosenfeld m...@bitcoil.co.il Subject: Re: Freimarkets and investment If assets were tagged you could do a very limited form of pre-signed offers: in: 10 btc SINGLE|ANYONECANPAY out: 1 AAA These are composable, in that you can append the inputs and outputs of multiple offers together and result in a valid transaction. However this is pretty much the limit of what is possible without adding new SIGHASH modes, and if you're going to hard-fork to add tagging, then you might as well go the whole distance with explicit hierarchical sub-transactions as we did with Freimarkets. Cheers, Mark On 9/24/13 5:44 AM, Meni Rosenfeld wrote: Hi Jorge, The video was sent to me by Amos Meiri, I think eToro funded its production. Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the transaction, there will be an output of 1 my stock to an initially unknown address. Can I provide a signature for my input of 1 my stock that will be valid even with the output details provided later? In any case, I think that's out of scope for the presentation. Meni On 24/09/2013 13:10, Jorge Timón wrote: Yes, it's a nice presentation. I love the video with the chameleons that you link at the end !! As a little sugestion, I think the biggest advantage of tagging is not inflatable assets, it's open binding orders. Even without granular subtransactions as freimarket has, you could sign your input (say, representing 1 My stock) and only the output you're interested in (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. Without tagging, you need to know where the inputs come from to check they're really bitstampUSD, because the network won't enforce the 100 bistampUSD in your output, any uncolored coins filling the btc quantity you wanted to represent those 100 usd will be ok, for miners. Goog luck with the talk, I'm eager to hear it. By the way, Mark, the explanation of the blockchain image sounds a little bit like hashcasttle, no? well, just merged mining every new asset, sounds like jaromil's freecoin too. On 9/24/13, Meni Rosenfeld m...@bitcoil.co.il wrote: Hi Mark, We currently have a more general mathematical framework for the concept of colored coins - a color is a combination of initial state and a kernel function that maps input colors to output colors. Order-based coloring is one such kernel function, tagging is another. As long as you can point at an output and say what its color is, we call it a colored coin system. The blockchain image is a stand-in for using a new block chain for each asset. Meni On 24/09/2013 00:42, Mark Friedenbach wrote: Hi Meni, I did call Freimarkets colored coins in the early days, but the term colored coin itself within the community seems to have become identified with the specific proposal of assigning value to specific satoshis, and running an order based coloring algorithm to determine asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely new assets and has explicit tagging of outputs, so we decided to avoid the phrase colored coin so as to keep from confusing people. But as an academic, yes you are correct. You presentation looks great. BTW, what's the first logo for the Alternative token systems slide? Or is that just a stand-in for the block chain? Mark On 9/23/13 12:24 PM, Meni Rosenfeld wrote: Hi, As you might know I'm giving a talk about Colored Coins in Amsterdam. My presentation is available at https://bitcoil.co.il/files/Colored Coins.pptx (I'm not posting this link publicly until after the talk). I'll be happy for any feedback. I'm listing Freimarkets as an implementation of Colored Coins. It doesn't look like you're identifying with the term, but it does fit the definition (and though it
Re: [Bitcoin-development] Malleability and MtGox's announcement
Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs to be solved at the layer above - the infrastructure building on the Bitcoin system. Despite that, I do think that we (as a community, not just developers) can benefit from defining a standard way to identify transactions unambiguously. This is something Mark Karpeles suggested a few days ago, and my proposal is this: We define the normalized transaction id as SHA256^2(normalized_tx + 0x0100), where normalized_tx is the transaction with all input scripts replaced by empty scripts. This is exactly what would be signed inside transaction signatures using SIGHASH_ALL (except not substituting the previous scriptPubKey to be signed, and not dealing with the input being signed specially). An implementation is here: https://github.com/sipa/bitcoin/commits/normtxid. Note that this is not a solution for all problems related to malleability, but maybe it can make people more aware of it, in tangible way. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper.
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 03:40:03PM +0100, Isidor Zeuner wrote: What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. I'm not a core developer, but I would certainly hope that those who have commit access to the Bitcoin repository don't let themselves be pressured by a company holding back user funds in order to get a patch included into the Bitcoin source code. This isn't about developers. This is about venture capitalists taking lots of money from unsuspecting investors, and MtGox is in a psy-ops PR-war with multiple other exchanges and lots of places that would like to take their market share and money. Why do you want the 'official' PR-spin-war response approved by the official bitcoin developer PR-firm, who's probably being paid by competitors to MtGox? Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. Fortunately for the rest of us, any dumb farmer can create a copycatcoin Hell, if MtGox hosted their *own* fork of bitcoin I'd run that in a heartbeat. And for full disclosure, I am available for consulting if anyone would like assistance setting up and hosting an independent source code repository that includes good automated regression tests. -- Troy -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleability and MtGox's announcement
I cannot judge the competence of code I've never seen, so I have no position on that. What I HAVE seen quite clearly is both overt and covert market manipulation under cover of blame for 'the developers', or 'the exchange' You're doing it yourself with the phrase 'incompetence'. When you run an exchange of that volume, then maybe you might be in a position to say so, but if you were *invested* in a competitor to MtGox you'd make a lot of money calling them incompetent, wouldn't you? I'm looking to drum up some consulting business by making my observations about market manipulation public, and if I can't drum up any business, at least I can speak my mind free of any non-disclsosure agreements. What do you stand to gain from your statements on this list? On another note, is there any third-party archive of bitcointalk.org? I much prefer mailing lists because *I* have an archive. On Mon, Feb 10, 2014 at 11:39:19AM -0500, Christophe Biocca wrote: The bug MtGox is blaming has been documented on the wiki for years. Mark Karpeles was on IRC publicly discussing the topic https://bitcointalk.org/index.php?topic=458076.msg5052255#msg5052255 MtGox's incompetence has been on public display since day 1. I'm not sure what critical information you think secret cabals are keeping from you. On Mon, Feb 10, 2014 at 11:14 AM, Troy Benjegerdes ho...@hozed.org wrote: Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version
Re: [Bitcoin-development] Malleability and MtGox's announcement
A bitcoin problem is not really my problem, and if MtGox's investors can't seem to understand the value of publishing their code, I'll be happy to take their money as it leaves bitcoin for more distributed and transparent cryptocurrency ecosystems. I feel some sort of moral obligation to point out to this community when something stupid is going on, and if you think a MtGox problem is not a Bitcoin problem then I can't really help you, all I can do is point out my observations and facts as I see them, and then execute trades to relieve those who choose to ignore these facts of their money. Happy trading On Mon, Feb 10, 2014 at 10:57:03AM -0600, Nick Simpson wrote: You must be new here. MtGox very rarely comments on things like this publicly, outside of irc or their website. Second, MtGox problem is a MtGox problem. You have no right to demand access to their private code. If you feel wronged as a customer, sue them. Otherwise, they have no obligation to you. I believe you are barking up the wrong tree. Respectfully, Nick On February 10, 2014 10:14:02 AM CST, Troy Benjegerdes ho...@hozed.org wrote: Okay, why the everloving FUCK is there not someone on this list with a @mtgox.com address talking about this? I started using bitcoin because I could audit the code, and when the developer cabal does stuff 'off-list' what you do is hand over market manipulation power to the selected cabal of company insiders who are discussing things 'off-list'. The people having a 'private' discussion about how to solve this are TAKING MONEY from everyone else, by having access to insider information. I don't think any of the developers actually have a clue this is the result, because a good chunk of them are employed by for-profit companies funded by venture capital, and VC lawyers are very good at writing employment contracts that provide plausible deniability of insider trading. The press MAKES MONEY (okay, takes money) by manipulating markets, and venture capitalists pay lots of money to ensure the market is manipulated in ways they can profit from. Private market manipulation is one of the costs of anonymity and privacy, and I don't really like paying for some off-list discussion of what appears to be a serious scalability and usability problem. Bitcoin is such a powerful tool because it broadcasts transactions to the network for everyone to see. Can we please broadcast some more technical details to this mailing list, including exactly what MtGox is doing, and how they wish to resolve it? If you gave me the entire code stack that MtGox runs on under an AGPLv3 license, I'm pretty sure I, along with everyone else here could come up with a workable solution. I think a code release would be a huge win for MtGox as well, and would cement their position as market leader in transparent cryptocurrency trading. Otherwise we are just a bunch of dinghys getting capsized one by one in a sea of market-manipulating white whales. Isn't the closed door market manipulation of the big banks one of the reasons we all started using Bitcoin in the first place? Why do revolutions always put the same old bullshit back in power? What we need is some transparent code evolution. On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote: Hi all, I was a bit surprised to see MtGox's announcement. The malleability of transactions was known for years already (see for example the wiki article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it, or mails on this list from 2012 and 2013). I don't consider it a very big problem, but it does make it harder for infrastructure to interact with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to avoid it altogether to make life easier for everyone. But we can't just change all infrastructure that exists today. We're slowly working towards making malleability harder (and hopefully impossible someday), but this will take a long time. For example, 0.8 not supporting non-DER encoded signatures was a step in that direction (and ironically, the trigger that caused MtGox's initial problems here). In any case, this will take years, and nobody should wait for this. There seem to be two more direct problems here. * Wallets which deal badly with modified txids. * Services that use the transaction id to detect unconfirming transactions. The first is something that needs to be done correctly in software - it just needs to be aware of malleability. The second is something I was unaware of and would have advised against. If you plan on reissuing a transaction because on old version doesn't confirm, make sure to make it a double spend of the first one - so that not both can confirm. I certainly don't like press making this sound like a problem in the Bitcoin protocol or clients. I think this is an issue that needs
Re: [Bitcoin-development] MtGox blames bitcoin
On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote: On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
If you've got any ideas for a better forum, let me know. MtGox is one of the largest public faces of the code being developed here. If the public perception is that this is a bitcoin protocol flaw, then we need some damned strong and compelling public arguments about why it ain't so. But after some thought, that's not the critical issue I want to raise on this list. If something about the implementation, the protocol, of bitcoin-qt or bitcoind makes it easy for an attacker to mutate transactions and hard for an 'end-user' such as MtGox to confirm payments, then we've got a fundamental user-interface flaw. We can get all indignant about RTFM or telling the users they are idiots, but that's not really going to be good for long-term adoption and use. My opinion is part of the development process should be to react to public perceptions of how the code is being used (and mis-used), and how the market is being manipulated, and try to improve it so the whole system is stable, predictable, and friendly to users. On Mon, Feb 10, 2014 at 01:45:58PM -0500, Jameson Lopp wrote: You have plenty of good points, but they are not relevant to this mailing list. I suggest you take them elsewhere. -- Jameson Lopp Software Engineer Bronto Software, Inc On 02/10/2014 01:25 PM, Troy Benjegerdes wrote: On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote: On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote: On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: We have an embedded consensus system and we want to be able to upgrade it with new rules. This asserts a central authority and gives developers too much power. I don't quite see how, There is nothing that 'forces' me to upgrade, unless I have chosen to run an operating system (MacOS, Windows, Android) that have automatic don't-ask-the-user update mechanisms. The bigger problem with 'asset transfer' of assets which do not exist soley in the blockchain is including the consensus of relevant local and distributed legal jurisdictions. For example, just because the 'colored coin' and blockchain consensus is that I 'electronically' signed a mortgage document giving some random internet company the rights to foreclose on my home does not mean that my local county Judge or Sheriff are going to do anything if the internet company cannot produce the original paper document with ink signature. The only 'assertion' of central authority here is people who download and run the code and submit to whatever the code asserts they are supposed to do. At least with the 'central authority' of the big-business bitcoin developer cabal I can read the code before I submit to it's central authority, and this is a significant improvement over amgibuous legislation or proprietary high-frequency trading algorithms. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
The only 'assertion' of central authority here is people who download and run the code and submit to whatever the code asserts they are supposed to do. At least with the 'central authority' of the big-business bitcoin developer cabal I can read the code before I submit to it's central authority, and this is a significant improvement over amgibuous legislation or proprietary high-frequency trading algorithms. Standard Disclaimer: Digital asset transfer systems are fundementally fancy accounting systems; no amount of code can, by itself, make data represent a physical or legal entity. Only consensus and/or authorities in the real world can do that. Crypto-currencies are only a partial exception to that rule, and only because a scarce asset that can be transferred digitally appears to have potential to be broadly useful. How do I document in the embedded consensus system what the ruling in a small-claims court about the ownership of a contested asset was? Good accounting systems (such as mercurial, and proper double-entry financial accounting tools) allow reverting a bad commit, or bad data entry, while maintaining records of the history. Not as good accounting systems (like git) allow you to re-write history. What's the equivalent user interface, process, and wire protocol for reversing a fraudulent transaction while maintaining a full audit trail? Courts can't legislate our code, and we can't expect them to download and trust our 'distributed de-centralized' digital asset tracking system that will be downloaded from a single centralized developer website unless we meet them at least halfway, and probably need to propose model municipal and county ordinances that go along with our code releases. Those considering investing in or otherwise devoting resources to the creation of digital asset transfer systems should be warned that their value in general remains unproven and losing some or all of your investment is very possible, even probable. I myself have doubts that these systems serve real-world business needs, but the only way to find out is to build them and see. I would agree 100% that we need to build them, test the code, use them, and then *try them in court*, and make sure we can explain in very simple plain language what an 'embedded consensus system' is to the distributed de-centralized local court systems. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote: Choosing how many bits to put in the prefix may be difficult, particularly if transaction load changes dramatically over time. 0 or 1 bits may be just fine for a single user running their own node, whereas a central service might want 4 or 5 bits to keep their computation costs scalable. Ignoring prefixes the cost for each reusable address is only a small percentage of the full node cost (rational: each transaction has one or more ECDSA signatures, and the derivation is no more expensive), so I would only expect computation to be an issue for large centralized services. (non-full nodes suffer more from just the bandwidth impact). I have not seen anyone address my high-level question to (somewhat) complicated mechanisms to keep coin flows private. Who pays for it? From what I see it's going to double the amount of data needed per address, further centralizing 'full' nodes. I'm fine if the NSA is paying for privacy (I actually trust them more than banks and advertisers), but let's just be honest, okay? If socializing the cost of privacy is Bitcoin's goal, and giving the benefits to a few that understand it and/or have the resources to determine privacy providers that won't scam them, then say so, so I can get on with launching a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses addresses, and has miners and pools that charge more for addresses they have never seen before. I bet it will be more distributed and have about half the average transaction cost of Bitcoin, because most people *just don't care* about privacy if they get cheap and/or free services. -- Troy, transparency advocate who is quite transparent that if you buy me farmland, I'll shut up about transparency, because I'll be too busy growing food and giving part of it away. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)
But I think it's great people can choose how to trade privacy for computation/bandwidth however they want, and services can compete to offer monitoring for 0+ bit prefixes. Its not a decision with user localised effect. If most users use it with parameters giving high elimination probability, that affects everyone else's privacy also. Also statistical effects are accumulative as more plausibly related addresses are eliminated at each potentially linked transaction. I think once the network flow analysis guys are done with incorporating it, and if reusable addresses saw significant use, my prediction is the result will be pretty close to privacy game over and it will undo most if not all of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only adding a bit or two of entropy per join, this elimination effect could easily undo more than that). You've got a major social engineering problem here. 1) who is marketing privacy 2) how do you validate 'privacy providers' Just like all the scamcoins, there will be scamprivacy providers, which will drive the market price of privacy down to zero. Who's paying the network/development/bandwidth/etc cost for privacy? I'd guess 85% of real users don't really care about some abstract 'privacy' ideal, they just want payments to work and to download cat pictures. If you say 'regular address re-use is deprecated, and the top 1% in bitcoin weatlh who own 95% of the miners want privacy', well fine. But you just opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain old regular address re-use and transparency. Does this stuff still work if regular address re-use is a transparency feature and not a bug? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Payment processors that support testnet?
Are there any bitcoin to fiat currency processors (like bitpay, coinbase, etc) that allow testing using the bitcoin testnet? It seems most of the credit card payment processor apis have features to allow developers to do testing without 'real money', what's the equivalent of this for bitcoin when you need to do end-to-end testing that goes from BTC to a USD or EU denominated bank accound? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other crypto-currencies? Let's suppose that me and my friends get 'islanded' from the rest of the internet for a week, but we still want to trade bitcoin. It would work if there are local miners, until we reconnect. Suppose we have the main chain (Alice), while bob is on a boat, trading with some friends, but has no network connectivity. When bob reconnects with Alice, a 'Merge' transaction happens where a miner looks at bob's forked blockchain, sees no double-spends, and includes BOTH chains. Now suppose someone on bob's boat has a buggy client, or sent a transaction before disconnect that results in a double-spend on the merge. So we have a merge conflict, which generally requires human interaction, so bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, AND incentivize a miner to do some extra work to merge. Thoughts everyone? -- Troy -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
On Tue, Dec 17, 2013 at 02:48:14PM -0800, Gregory Maxwell wrote: On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. We already automatically merge forks that we become aware of simply by pulling in all the novel non-conflicting transactions the fork contains and including them in our next blocks. Now maybe this is a fatal flaw with Bitcoin's hard upper limit for number of coins, but any miners that with good faith tried to support an islanded bitcoin network now have generate transactions that get clobbered when the network reconnects. I can imagine a way to do this with some freicoin-like demurrage, which would only impact new coinbase based on the percentage of the hashing power that was on the other side of the fork. So if you are with the 95% of hashing power, you keep 95% of the new coins when the other 5% shows back up from being islanded. And this is also way more complicated than what I had first imagined to do securely and reliably. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
