Re: [Bitcoin-development] Tree-chains preliminary summary
Peter I was curious if you could detail what specific concerns Adam Back brought up with the current iteration of the tree-chains idea? It's been alluded to a few times yet I have not read the specific problem. Greg -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
How does this system handle problems with the lower chains after they have been locked-in? The rule is that if a block in the child chain is pointed to by its parent, then it effectively has infinite POW? The point of the system is that a node monitoring the parent chain only has to watch the header chain for its 2 children. A parent block header could point to an invalid block in one of the child chains. That parent block could end up built on top of before the problem was discovered. This would mean that a child chain problem could cause a roll-back of a parent chain. This violates the principle that parents are dominant over child chains. Alternatively, the child chain could discard the infinite POW blocks, since they are illegal. P1 - C1 P2 - --- P3 - C3 P4 - C5 It turns out C4 (or C5) was an invalid block P5 - C4' P6 - --- P7 - C8' This is a valid sequence. Once P7 points at C8, the alternative chain displaces C5. This displacement could require a compact fraud proof to show that C4 was an illegal block and that C5 was built on it. This shouldn't happen if the miner was actually watching the log(N) chains, but can't be guaranteed against. I wonder if the proof of stake nothing is at stake principle applies here. Miners aren't putting anything at stake by merge mining the lower chains. At minimum, they should get tx-fees for the lower chains that they merge mine. The rule could require that the minting reward is divided over the merge mined chains. -- 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/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
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] Tree-chains preliminary summary
I'll make sure I understand your proposal better before commenting much on it, but at a first glance, I don't see how it is incompatible with 2 way peg and merged mining itself. Why wouldn't you want merged mining for the root of your tree? A miner could only chose a leaf block at a time, but it could merged mine with other leafs in other independent trees. Anyway, I'll better comment on the 2 way peg and merged mining issues raised so far. On 3/25/14, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io wrote: More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I don't think it would be entirely unfair to describe one of the possible ways a secondary coin becoming unbacked can play out as inflation-- after all, people have described altcoins as inflation. In the worst case its no _worse_ inflation, I think, than an altcoin is-- however. I think that's an obscure corner case that is not likely going to ever be implemented. If you produce real inflation there will likely be a bank run. If you're going to implement something equivalent to demurrage you should call it demurrage instead of inflation. And that's only for the pegged coin in the side chain: BITCOINS IN THE MAIN CHAIN WILL NEVER BE INFLATED USING 2P2. So I think it's less confusing if we just say that 2-way peg can't produce inflation in general, and leave unless you explicitly introduce an inflation mechanism as a probably unnecessary clarification. I see your point, but gmaxwell accurately guesses below that when I'm talking about inflation, I'm including the inflation of the alt too. You don't need inflation on the side chain. You don't need to create another currency to create another chain with different and maybe experimental features, that's the whole point. With merged mining, you're adding up the different created seigniorage subsidies to the same fire to share the heat. With 2-way peg, you don't even need to create a new p2p currency with a seigniorage to burn on hashes or be accused of pre-mining as the more ecological alternative in existence. Your chain can secure itself on fees, just like bitcoin in the future. Merged mining will help, but it's not the panacea and you will need to reward miners because that's what your security ultimately depends on. This is mostly about not burning the world, it may not be as interesting to you as improving bitcoin's scalability but you're not doing anyone a favor by presenting both concepts as being incompatible, not even yourself. With tree-chains that's particularly obvious as the scheme doesn't try to privilege one chain over another beyond parent-child relationships. If I understand it correctly, all the utxo nodes in the tree implement the same rules so doesn't seem suitable to solve the same problems. I understand that merged mining IS NOT a solution to scalability on its own, having 10 independent 1MB blocks is no worse than 1 10MB block in terms of performance vs centralization. But maybe it's possible to have a 10 GB sharded side-chain (your proposal) that it's merged mined with the main chain and where the currency of the side-chain comes from. So merged mining could help solve the scalability problem indirectly. And 2-way peg could be a useful previous step for your proposal to be deployed on production, with real bitcoins without forcing all bitcoin users to take the associated risks, only the people who opt in. Incidentally, I understand that the pegged chains are meant to be merge-mined. 2 way peg doesn't require merged mining but it is assumed that merged mining will be used since it provides more security than independent mining. I thought you agreed with this and your claim was just that merged mining is less secure than embedded consensus, something I have never denied, my complain against embedded consensus is that it doesn't seem to scale (with Bitcoin as it is today) and can't offer many features that a hardfork merged mined chain could offer (like those explained on our freimarkets proposal). But since you're implying again that merged mining is superior to independent mining is generally false, I invite you again to dismantle my example http://sourceforge.net/p/bitcoin/mailman/message/31806950/ or to prove your hypothesis that is free to attack merged mining chains by attacking namecoin for free. Either one will serve, my you're not responding to any of the suggestions. Instead, you're saying that people defending merged mining assume that attackers are economically rational. I think you're referring to me and it's false. Of course the attacker doesn't need to be economically rational. For some unknown reason he's attacking a chain, without questioning the rationality of the attack, I just sum costs,
Re: [Bitcoin-development] Tree-chains preliminary summary
On Sat, Mar 22, 2014 at 12:43:34PM -0700, Mark Friedenbach wrote: Btw, any chance we could get a summary description of tree-chains posted to bitcoin-development? Sure: Introduction 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. So let's split up the transaction volume so every individual miner only needs to keep up with some portion. In a rough sense that's what alt-coins do - all the tipping microtransactions on Doge never have to hit the Bitcoin blockchain for instance, reducing pressure on the latter. But moving value between chains is inconvenient; right now moving value requires trusted third parties. Two-way atomic chain transfers does help here, but as recent discussions on the topic showed there's all sorts of edge cases with reorganizations that are tricky to handle; at worst they could lead to inflation. So what's the underlying issue there? The chains are too independent. Even with merge-mining there's no real link between one chain and another with regard to the order of transactions. Secondly merge-mining suffers from 51% attacks if the chain being merge-mined doesn't have a majority of total hashing power... which kinda defeats the point if we're worried about miner scalability. Blocks and the TXO set as a binary radix tree = So how can we do better? Start with the big picture idea and take the linear blockchain and turn it into a tree: ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ Obviously if we could somehow split up the UTXO set such that individual miners/full nodes only had to deal with subsets of this tree we could significantly reduce the bandwidth that any one miner would need to process. Every transaction output would get a unique identifier, say txoutid=H(txout) and we put those outputs in blocks appropriately. We can't just wave a magic wand and say that every block has the above structure and all miners co-ordinate to generate all blocks in one go. Instead we'll do something akin to merge mining. Start with a linear blockchain with ten blocks. Arrows indicate hashing: a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ⇽ a9 The following data structure could be the block header in this scheme. We'll simplify things a bit and make up our own; obviously with some more effort the standard Satoshi structures can be used too: struct BlockHeader: uint256 prevBlockHash uint256 blockContentsHash uint256 target uint256 nonce uint time For now we'll say this is a pure-proof-of-publication chain, so our block contents are very simple: struct BlockContents: uint256 merkleRoot As usual the PoW is valid if H(blockHeader) blockHeader.target. Every block creates new txouts, and the union of all such txouts is the txout set. As shown previously(1) this basic proof-of-publication functionality is sufficient to build a crypto-currency even without actually validating the contents of the so-called transaction outputs. The scalability of this sucks, so let's add two more chains below the root to start forming a tree. For fairness we'll only allow miners to either mine a, a+b, or a+c; attempting to mine a block with both the b and c chains simultaneously is not allowed. struct BlockContents: uint256 childBlockHash # may be null bool childSide # left or right uint256 merkleRoot Furthermore we shard the TXO space by defining txoid = H(txout) and allowing any txout in chain a, and only txouts with LSB=0 in b, LSB=1 in c; the beginning of a binary radix tree. With some variance thrown in we get the following: b0 ⇽⇽ b1 ⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ b6 ⇽ b7 ⇽ b8 ↙↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ↖↖ ↖ ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽⇽ c4 ⇽ c5 ⇽ c6 ⇽⇽ c7 We now have three different versions of the TXO set: ∑a, ∑a + ∑b, and ∑a+∑c. Each of these versions is consistent in that for a given txoutid prefix we can achieve consensus over the contents of the TXO set. Of course, this definition is recursive: a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ↖↖ ↖ ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽⇽ c4 ⇽ c5 ⇽ c6 ⇽⇽ c7 ↖ ↖ ↖↖ ↖ d0 ⇽ d1 ⇽⇽ d2 ⇽⇽ d3 ⇽ d4 ⇽⇽⇽ d5 d6 Unicode unfortunately lacks 3D box drawing at present, so I've only shown left-sided child chains. Herding the child-chains
Re: [Bitcoin-development] Tree-chains preliminary summary
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. Scaling is a problem if every person is a fully validating node; then, indeed, you get an O(n^2) problem. Which can be solved by extending some tentative trust to your peers, but lets put all those possible solutions aside. Given tens of thousands of fully validating nodes, you get O(m*n), where m is the number of fully validating peers and is a large constant (10s of thousands). We don't know how large m can or will be; we have only just started to scale up. Bitcoin doesn't scale is pure FUD. It might not scale in exactly the way you want, but it WILL scale. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- 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:28:51AM -0400, Peter Todd wrote: On Sat, Mar 22, 2014 at 12:43:34PM -0700, Mark Friedenbach wrote: Btw, any chance we could get a summary description of tree-chains posted to bitcoin-development? Sure: Introduction BTW for those whose email clients have problems with unicode: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html Also, I was in a bit of a rush - catching a flight - and know I should have cited a few things, including, but not limited to, various peoples' work on chain-to-chain transfers and SPV proofs. -- 'peter'[:-1]@petertodd.org 5f3189269d2c39711d6a340a617267d72f95848a9ab8e7ba signature.asc Description: Digital 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
Re: [Bitcoin-development] Tree-chains preliminary summary
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 For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. P.S. A year or so ago you complained that if I cared so much about decentralization, I should make P2Pool better. Your homework: What do tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do with that? What about the cube-square law? And why don't I think TXO commitments solve the blocksize problem? 1) https://bitcointalk.org/index.php?topic=309073.0;all -- 'peter'[:-1]@petertodd.org 20366a15799010ae0432be831c197e06b19133028a9aa6f3 signature.asc Description: Digital 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
Re: [Bitcoin-development] Tree-chains preliminary summary
A few months ago I had a conversation with an executive at a Bitcoin company, and I suggested their developers should get involved with the development list. I was told that they are all subscribed but refuse to post. Puzzled, I asked why, maybe the process isn't clear or we didn't talk about what they were interested in? No, it's because in that executives words They see how Peter Todd shoots people down in flames and want nothing to do with that. Peter, you were named explicitly as the source of the problem. Your immediate knee-jerk reaction to anyone who disagrees with you is making this forum aggressive and ugly - it puts other people off from contributing. For what it's worth, if I were the moderator of this list I would have banned you a long time ago because I value a friendly atmosphere more than your insights, which are often deeply suspect (as in this case). Besides, ground up redesigns of Bitcoin like what you propose are more appropriate for bitcointalk. So please take it there. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For the record, tree chains is designed to be a soft-fork upgrade to bitcoin, at least if we can get the economics to work out. Assuming it does, you would do this by defining bitcoin itself to be the top level chain, and carrying what appear to be anyone can spend txouts from block to block so that transaction outputs can be created when funds are redeemed in the top block chain from children lower in the tree. Very similar ideas as the chain to chain stuff via spv proofs that Mark and Adam were talking about here earlier, although I think the order and reorganisation guarantees is a big advantage over their unsynched chain model. Most of the other ideas are identical, and they deserve credit. I'm on the currency design panel at the Princeton Bitcoin Research Conference this week - tree chains will be discussed informally if not on the panel itself. Regarding cryptocurrency research related posts, the feedback I've gotten has always been quite positive. You are in the minority as far as I can tell, and anyway the volume of such posts is a small part of the total list volume. As for the rest of your email, doctor, heal thyself. Gavin's constant namecalling of legit and well accepted scaling concerns as FUD has irritated many people for over a year now, among many other things. Statements similar to what you claim are said about me are also often said to me about you and Gavin. But anyway, reply off list please. On 25 March 2014 11:20:05 GMT-04:00, Mike Hearn m...@plan99.net wrote: A few months ago I had a conversation with an executive at a Bitcoin company, and I suggested their developers should get involved with the development list. I was told that they are all subscribed but refuse to post. Puzzled, I asked why, maybe the process isn't clear or we didn't talk about what they were interested in? No, it's because in that executives words They see how Peter Todd shoots people down in flames and want nothing to do with that. Peter, you were named explicitly as the source of the problem. Your immediate knee-jerk reaction to anyone who disagrees with you is making this forum aggressive and ugly - it puts other people off from contributing. For what it's worth, if I were the moderator of this list I would have banned you a long time ago because I value a friendly atmosphere more than your insights, which are often deeply suspect (as in this case). Besides, ground up redesigns of Bitcoin like what you propose are more appropriate for bitcointalk. So please take it there. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFQBAEBCAA6BQJTMbMyMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwheooB/9pKwUKLni8ZBPfe7qQ e3dTTWXeottw1dOT1iUDvk2VVRe0ou38UZhqVQTr9KL3sf6OKsijwb7mgPdoSolA ZJ30mPk68KPMdmESfDeXvl8l/hdXCdI1mHmeAcUwirH85eVc9olBL5AKOpfIFtPx ReagvnMVy5nWguGnRNq4O3A5G7BBcFWnIhTjj656Hsqywf0j2l9P+JcgSpHhOupF q/v6Ybeae5UJHmINMA9Mw5isZT1uFGDxYPoG6xvz0/O/gaPVTXNQiQJa9rq9v0wp +EQEF5br+wN1VmBQOYV+6ig5Ttz4s4i+tCyVIZPF5HKmipBuK+mtDT81dqxRqh7q dF86 =37x3 -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
Re: [Bitcoin-development] Tree-chains preliminary summary
On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote: For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. Peter, take this unprofessional, personal crap off-list. Mike's anecdote of hostility is not an isolated one. Just today, a bitcore developer commented on Peter Todd's ..apocalyptic vision and... negative view on bitcoin which turned off some other developers from participating more interactively. As I commented on IRC, open source projects are no strangers to people who simultaneously (a) make useful contributions and (b) turn potential contributors away with an abrasive or hostile attitude toward others. It's an unsolved problem in OSS, that I saw for 15+ years in the Linux kernel community. For this list, as Mike suggested on IRC, introducing an openly stated moderation policy may be the one route. -- 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
Re: [Bitcoin-development] Tree-chains preliminary summary
I would echo the need for some kind of moderation. I believe Peter Todd is an extremely intelligent individual, who has a lot to offer the Bitcoin community. He has a firm grasp of a lot of really deep Bitcoin concepts and his *technical* insight is generally positive. Technically. But the way he communicates on this list is *extremely* corrosive and breeds hostility. It makes it a scary place to discuss things, with frequent, public ridicule of everything posted. I agree that I would rather have a friendly environment to discuss technicals, even if it means losing additional technical insight. People who would explicitly insult other contributors intelligence and character on a public list should be subject to some kind of negative reinforcement. Maybe there's solutions other than outright banning. -Alan On 03/25/2014 01:37 PM, Jeff Garzik wrote: On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote: For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. Peter, take this unprofessional, personal crap off-list. Mike's anecdote of hostility is not an isolated one. Just today, a bitcore developer commented on Peter Todd's ..apocalyptic vision and... negative view on bitcoin which turned off some other developers from participating more interactively. As I commented on IRC, open source projects are no strangers to people who simultaneously (a) make useful contributions and (b) turn potential contributors away with an abrasive or hostile attitude toward others. It's an unsolved problem in OSS, that I saw for 15+ years in the Linux kernel community. For this list, as Mike suggested on IRC, introducing an openly stated moderation policy may be the one route. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OK, deal. You guys stop calling my concerns FUD, accusing me of having ulterior motives, etc. and I'll pay the same respect to you. On 25 March 2014 14:13:36 GMT-04:00, slush sl...@centrum.cz wrote: I fully agree, please keep friendly environment on this list. Btw I also met people who were making fun about Peter's reactions on bitcoin-dev. slush On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner etothe...@gmail.com wrote: I would echo the need for some kind of moderation. I believe Peter Todd is an extremely intelligent individual, who has a lot to offer the Bitcoin community. He has a firm grasp of a lot of really deep Bitcoin concepts and his *technical* insight is generally positive. Technically. But the way he communicates on this list is *extremely* corrosive and breeds hostility. It makes it a scary place to discuss things, with frequent, public ridicule of everything posted. I agree that I would rather have a friendly environment to discuss technicals, even if it means losing additional technical insight. People who would explicitly insult other contributors intelligence and character on a public list should be subject to some kind of negative reinforcement. Maybe there's solutions other than outright banning. -Alan On 03/25/2014 01:37 PM, Jeff Garzik wrote: On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote: For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. Peter, take this unprofessional, personal crap off-list. Mike's anecdote of hostility is not an isolated one. Just today, a bitcore developer commented on Peter Todd's ..apocalyptic vision and... negative view on bitcoin which turned off some other developers from participating more interactively. As I commented on IRC, open source projects are no strangers to people who simultaneously (a) make useful contributions and (b) turn potential contributors away with an abrasive or hostile attitude toward others. It's an unsolved problem in OSS, that I saw for 15+ years in the Linux kernel community. For this list, as Mike suggested on IRC, introducing an openly stated moderation policy may be the one route. -- 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 -- 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 -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
Re: [Bitcoin-development] Tree-chains preliminary summary
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. For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. P.S. A year or so ago you complained that if I cared so much about decentralization, I should make P2Pool better. Your homework: What do tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do with that? What about the cube-square law? And why don't I think TXO commitments solve the blocksize problem? 1) https://bitcointalk.org/index.php?topic=309073.0;all -- 'peter'[:-1]@petertodd.org 20366a15799010ae0432be831c197e06b19133028a9aa6f3 -- 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 -- 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
I'm afraid I'm going to be the jerk that requested more details and then only nitpicks seemingly minor points in your introduction. But its because I need more time to digest the contents of your proposal. Until then: But moving value between chains is inconvenient; right now moving value requires trusted third parties. Two-way atomic chain transfers does help here, but as recent discussions on the topic showed there's all sorts of edge cases with reorganizations that are tricky to handle; at worst they could lead to inflation. This isn't true. The re-org issue is fairly handled in the 2-way pegging scheme that Greg Maxwell developed and Adam Back described a week ago on this list. Depending on the implementation it could even be configurable by the person performing the peg too - allowing the transfer to specify the confirmation depth required during the quieting period in order to protect against re-orgs up to a sufficient depth. I think this is worked out quite well with sufficient enumeration of edge cases, and I don't think they are particularly tricky to handle or lead to money-losing situations under the explicit security assumptions. More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I will look at your proposal in more depth. But I also think you should give 2-way pegging a fair shake as pegging to side chains and private accounting servers may eliminate the need. -- 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
Peter, I think you and I both know there is WAAYY to much MONEY to be taken from naive end-users by the companies that employ people who call your concerns FUD. And for everyone else, I want to apologize in advance for anything I might happen to say that might be abrasive, arrogant, angry, or 'in need of moderation'. So for those who do not wish to hear or read such things, delete my message now. === disclaimer: strong language follows === What the fuck Groupthink? committee for GROUPTHINKPROFIT? I'd rather have Peter Todd calling some developers idiots on the list than some fucking idiots who get paid way to fucking much calling 'end-users' stupid for believing MtGox. Hell, I was one of these idiots that fell for a marketing scam by a company that had a good story. But here is the damn point. The Excecutive who was whining about how his devs won't show up should probably consider hiring people who make VOCAL points on the mailing list. Or maybe he should consider that his developers might know his business model is shit and if they DID say something, it would be CLEAR to the world that only an idiot would use their companies services, and kill the company. Would you rather hear of vulnerabilities and scaling limits on bitcoin-development, or would you rather hear about them by a chorus of They got hacked, their code must suck, but AFTER the fact. It seems to be an unfortunate fact of life that sleazy people take a shitload of money from nice people. Moderate Peter and I into oblivion at your own risk. Wouldn't you rather have us pointing out obvious flaws than ignoring shit? ... But just remember, your employers probably make more money by ignoring shit On Tue, Mar 25, 2014 at 03:47:15PM -0400, Peter Todd wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OK, deal. You guys stop calling my concerns FUD, accusing me of having ulterior motives, etc. and I'll pay the same respect to you. On 25 March 2014 14:13:36 GMT-04:00, slush sl...@centrum.cz wrote: I fully agree, please keep friendly environment on this list. Btw I also met people who were making fun about Peter's reactions on bitcoin-dev. slush On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner etothe...@gmail.com wrote: I would echo the need for some kind of moderation. I believe Peter Todd is an extremely intelligent individual, who has a lot to offer the Bitcoin community. He has a firm grasp of a lot of really deep Bitcoin concepts and his *technical* insight is generally positive. Technically. But the way he communicates on this list is *extremely* corrosive and breeds hostility. It makes it a scary place to discuss things, with frequent, public ridicule of everything posted. I agree that I would rather have a friendly environment to discuss technicals, even if it means losing additional technical insight. People who would explicitly insult other contributors intelligence and character on a public list should be subject to some kind of negative reinforcement. Maybe there's solutions other than outright banning. -Alan On 03/25/2014 01:37 PM, Jeff Garzik wrote: On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote: For someone with 'Chief Scientist' as their job title, I'm surprised you think so little of hard evidence and so much of idol worshipping. Peter, take this unprofessional, personal crap off-list. Mike's anecdote of hostility is not an isolated one. Just today, a bitcore developer commented on Peter Todd's ..apocalyptic vision and... negative view on bitcoin which turned off some other developers from participating more interactively. As I commented on IRC, open source projects are no strangers to people who simultaneously (a) make useful contributions and (b) turn potential contributors away with an abrasive or hostile attitude toward others. It's an unsolved problem in OSS, that I saw for 15+ years in the Linux kernel community. For this list, as Mike suggested on IRC, introducing an openly stated moderation policy may be the one route. -- 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 -- Learn Graph Databases - Download FREE O'Reilly Book Graph
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] Tree-chains preliminary summary
On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io wrote: More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I don't think it would be entirely unfair to describe one of the possible ways a secondary coin becoming unbacked can play out as inflation— after all, people have described altcoins as inflation. In the worst case its no _worse_ inflation, I think, than an altcoin is— however. I will look at your proposal in more depth. But I also think you should give 2-way pegging a fair shake as pegging to side chains and private accounting servers may eliminate the need. I think that chain geometries which improve the scale/decentralization trade-off are complementary. If PT's ideas here do amount to something that gives better scaling without ugly compromise I believe it would still be useful no matter how well the 2-way peg stuff works simply because scaling and decenteralization are both good things which we would pretty much always want more of... -- 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
