Skip to content

Instantly share code, notes, and snippets.

Created Feb 5, 2016
What would you like to do?

On being a cypherpunk: "I've never considered myself a cypherpunk"

On where to keep your Bitcoin: "As I understand it, every client receives every transaction in the system, so it can check later if transactions are valid. What happens when the number of transactions gets very large? When that happens, I think most people using bitcoin will not be running always-connected-to-the-bitcoin-network software. I think there will be at least three different sets of people: 1. People who trust a web site to keep their wallet safe more than they trust themselves. They'll use sites like MyBitcoin or MtGox, which give them an online wallet."

On Luke-Jr: "I think Luke Dashjr fits the definition of a poisonous person, and I think Bitcoin would be better without him"

On Peter Todd describing problems with bigger blocks: "Stop with the false info, Peter."

On core dev Mark Friedenbach describing problems and being lazy: "Not if you do it right, and you know it. Stop being such a negative nelly. If you spent more time working on solutions......,"

On waiting for scaling problems to appear before fixing them: "Don't worry much about it until just before it becomes a problem. Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant."

On the future of Bitcoin scaling: "Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something). And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network. And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction."

On another implementation of Bitcoin: "Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network"

On the security of Bitcoin: "So the short answer is that BC is backed by mathematics/cryptography and the "wisdom of crowds"; assuming there's no flaw in the algorithms, and assuming that there is no grand conspiracy of more than half of the nodes, it is impossible to inflate the currency or make fraudulent payments. I don't believe in grand conspiracies, so that doesn't worry me. "

On the possibility of two chains: "There will NOT be two active chains, that is just FUD."

On the advice to run a full node: "You really like telling people what they ought to do, don't you?"

On timing of a hard fork: "Consensus-critical code needs time for testing, review, rollout, etc. So I'm starting the process; we'll have 9 months for the testing/review/rollout process, and maybe we'll even reach 95% consensus before the earliest possible date I'm coding into the fork (March 1, 2016)."

On presenting hard fork risks the same as soft fork risks: "It doesn't matter if the software is obsolete because of hard or soft fork, the difference in risks between those two cases will not be understood by the typical full node or SPV node user."

On Greg's lack of a scaling roadmap: " I wish you'd either trust my judgement on this a little more or spend the time to present a coherent alternative that we could all get behind (or tear apart or both)."

On Developers: "I mean, if the current set of developers can't create a secure bitcoin network that can't handle the equivalent of 4 web pages every 10 minutes, then they should be fired."

On SPV Mode: " I am willing to run SPV mode because I trust that my customers aren't going to double spend against me."

On BIP 101: "BIP101 would still be fine as a protocol limit... except Peter Todd and others have managed to put enough fear into the miners of some aint-never-gonna-happen-because-nobody-makes-money "attack scenario" to make them reject a protocol limit higher than whatever the current (crappy) network protocol can support."

On the proper block size: "I think 2MB is absurdly small."

On running a full node: "it might be time to fork into two projects: one that targets the needs of companies, and another that targets geeky I-wanna-run-a-full-node users."

On character: "But character matters. 'This person is (blah)' can be useful information"

On suggesting a hard fork: "I won't suggest a hard fork unless I am convinced all major miners and merchants and exchanges will agree."

On time for a hard fork: "And a few months before the fork was scheduled alert messages would go out to old versions."

On scammers in the Bitcoin Foundation: "What scammers and dodgy companies are you talking about? A hard fact of life is 'most startups fail.' MANY Foundation member companies will fail-- if you have a way of telling in advance which are dodgy/scammy and which are just unlucky, a bad business idea, or poorly run I would love to hear it. (Besides obvious scams like the recent MMMglobal membership that was just revoked)."

On Peter Todd: "Peter is hung up on the decentralization/privacy aspects of Bitcoin"

On treating Core: "Do not treat the core development team as if we were a commercial company that sold you a software library. That is not how open source works;"

On using Bitcoins as a store of value: "I don't plan on saving a significant number of Bitcoins as a store of value. I like to invest in people who are doing productive things that grow our economy and make the world a better place, so when Bitcoins replace dollars Wink I'll lend them to people by buying bonds or stocks."

On SPV mining: "I should bang out udp broadcast of block headers and validationless mining so we can stop talking about propagation time...." - classic slack /

On SPV mining: "Well, I suppose they COULD, but it would be a very bad idea-- they must validate the block before building on top of it. The reference implementation certainly won't build empty blocks after just getting a block header, that is bad for the network."

On not mixing fees funding the network and the block limit: "Please don't continue to muddle the maximum blocksize issue with whether or not transaction fees will be sufficient to secure the network in the future. They are mostly orthogonal issues that should be discussed separately."

On no block limit: "In my heart of hearts I still believe that going back to "no hard-coded maximum block size" would work out just fine."

On who should run a node: "Miners and merchants and wallet services and a small fraction of super-security-conscious people are more than enough for a robust, stable network; I don't think we need more incentives to run full nodes."

On Peter Todd: "Peter Todd is a very large part of the "Bitcoin Core moves forward too slowly" problem."

On being the center of Bitcoin: " before the Foundation I was becoming the center of Bitcoin. That would have been even more centralized and dangerous." -

On Luke-Jr: "Have fun wrestling with Luke; some bitcoiners gave up years ago."

On Peter Vesseness (who ran Bitcoin foundation and stole 5 million ) "Peter is trustworthy."

On nodes in data centers: "Most ordinary folks should NOT be running a full node. We need full nodes that are always on, have more than 8 connections (if you have only 8 then you are part of the problem, not part of the solution), and have a high-bandwidth connection to the Internet. So: if you've got an extra virtual machine with enough memory in a data center, then yes, please, run a full node."

On Peter Todd: "Maybe I don't communicate clearly enough, but much of the fear, uncertainty, and doubt about the block size issue comes from people like Peter who want to know exactly how technical problems that MIGHT come up three years from now will be solved TODAY."

On IBLT: "The block size must rise, but there are a couple of technical things that have to get done first:

  1. Fees have to float. That's what I've been working on. 2) Broadcasting large blocks has to get more efficient. We know how, "we" just have to write the code ("use full bloom filters")."

On respect: "Mmm. If you want my respect, write some code."

On eliminating the block limit: "That orphan cost is what puts a floor on transaction fees, and is why I still think eliminating the block size is the correct thing to do in the long term."

On changing the currency: "If you want to change the currency.... Then you first need to convince the geeks, then you need to convince everybody else. "

On coin blacklists: "I'll play devil's advocate a little bit: maybe the "slippery slope" argument is wrong-- maybe "dirty" coin tracking from competing non-governmental organizations would be a good thing for the world. Maybe supporting a free-market of organizations performing those services will make it less likely that governments decide they must step in and mandate a solution that they create."

On Luke-Jr: "I expect that edit to be reverted as soon as Luke-Jr notices..."

On the block size: "I would like to let the market decide the block size, too, but that is a whole 'nother debate."

On Peter Todd: "@BraveTheWorld Yeah, Todd's ego is definitely a problem."

On running a full node behind TOR: "Well, in that case the simplest solution is to pay $10 per month to a hosting provider in a country that is NOT oppressive. Run a full node there, and if you have mining equipment in your house, connect to it over an encrypted connection (an ssh tunnel would work nicely). Again, bandwidth from your oppressive internet service provider will be the same no matter how busy the Bitcoin network gets." -

High Fees would be a great problem to have: "Do you think that there will SO much load on the bitcoin network, that we'll start seeing the ball in the miner's court's? where they demand extra fees, or alternative payment structures like monthly subscriptions for the vendors who use them. "That would be a great problem to have!"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment