Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org wrote: Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC funds invested in companies, we owe it to them that we be open and transparent here. I would really prefer on a personal nor professional basis to be having this conversation period, never mind in public, but Mike - your and Gavin's decision to promote a unilateral hard-fork and code fork are extremely high risk for bitcoin and so there remains little choice. So I apologise again that we have to have this kind of conversation on a technical discussion list. This whole thing is hugely stressful and worrying for developers, companies and investors. I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor (without accusing you of any of those - I understand you personally just want to scale bitcoin, but are inclined to knock heads and try to force an issue you see, rather than work collaboratively). For you (and everyone) - Should there be a summit of some kind, that is open attendance, and video recorded so that people who are unable to attend can participate too, so that people can present the technical proposals and risks in an unbiased way? Dear Adam, All: At the community's convenience, it would be an honour to arrange an initial open summit to meet with representatives of the Chinese miners in Hong Kong (UTC+8) to facilitate a better understand between the different stakeholders of the Bitcoin ecosystem on this important issue. This could be arranged for this October, or earlier, if deemed necessary. Remote online participation would be welcome from those who might not be able to attend in person. However, it is hoped that such a meeting would be primarily document driven to facilitate orderly translation, discussion and decision. p. (It is not theoretical question, I may have a sponsor and host - not Blockstream, an independent, its a question for everyone, developers, users, CTOs, CEOs.) So here I come back to more frank questions: Governance The rest of the developers are wise to realise that they do not want exclusive control, to avoid governance centralising into the hands of one person, and this is why they have shared it with a consensus process over the last 4 years. No offence but I dont think you personally are thinking far enough ahead to think you want personal control of this industry. Maybe some factions dont trust your motives, or they dont mind, but feel more assured if a dozen other people are closely reviewing and have collective review authority. - Do you understand that attempting to break this process by unilateral hard-fork is extremely weakening of Bitcoin's change governance model? - Do you understand that change governance is important, and that it is important that there be multiple reviewers and sign-off to avoid someone being blackmailed or influenced by an external party - which could potentially result in massive theft of funds if something were missed? - Secondarily do you understand that even if you succeed in a unilateral fork (and the level of lost coins and market cap and damage to confidence is recoverable), that it sets a precedent that others may try to follow in the future to introduce coercive features that break the assurances of bitcoin, like fungibility reducing features say (topically I hear you once proposed on a private forum the concept of red-lists, other such proposals have been made and quickly abandoned), or ultimately if there is a political process to obtain unpopular changes by unilateral threat, the sky is the limit - rewrite the social contract at that point without consensus, but by calculation that people will value Bitcoin enough that they will follow a lead to avoid risk to the system? Security As you probably know some extremely subtle bugs in Bitcoin have at times slipped past even the most rigorous testings, often with innocuous but unexpected behaviours, but some security issues Some extremely intricate and time-sensitive security defect and incident response happens from time to time which is not necessarily publicly disclosed until after the issue has been rolled out and fixed, which can take some time due to the nature of protocol upgrades, work-arounds, software upgrade via contacting key miners etc. We could take an example of the openSSL bug. - How do you plan to deal with security incident response for the duration
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd p...@petertodd.org wrote: On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org wrote: Dear Adam, All: At the community's convenience, it would be an honour to arrange an initial open summit to meet with representatives of the Chinese miners in Hong Kong (UTC+8) to facilitate a better understand between the different stakeholders of the Bitcoin ecosystem on this important issue. This could be arranged for this October, or earlier, if deemed necessary. Great! FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a blockchain-tech conference October 14th-15th in Hong Kong as well; coordinating your summit with that conference could be useful. http://blockchainworkshops.org/ This workshop series has been attracting audiences of people looking to use blockchain tech in general; many of these use-cases will likely involve the Bitcoin blockchain in unpredictable ways. Importantly, these ways can drive demand significantly beyond our current assumptions based on most demand being consumer-merchant transactions. In addition, many of the attendees have significant experience with regulatory issues and interacting with governments on regulation of blockchain tech. Bitcoin faces existential risks to its existence by these regulation efforts, which include things like efforts to setup industry wide Anti-Money-Laundering/Know-Your-Customer programs, including programs that would tie on-chain transactions to identity information. Any blocksize discussion needs to be informed by these potential threats to usage of the technology, as well as challenges to using scaling solutions. Remote online participation would be welcome from those who might not be able to attend in person. However, it is hoped that such a meeting would be primarily document driven to facilitate orderly translation, discussion and decision. Agreed. Pieter Wuille's recent work is a great example of the kind of science-driven investigations that need to be done - and haven't been done very much - to get us some hard data to make decisions on. Thank you very much Peter for pointing this out! That is very kind of you. It would be great to work with Constance Choi, Primavera De Filippi, your goodself and others to make this happen. As you may know, the Hong Kong Monetary Authority considers bitcoin a virtual 'commodity' and not a currency per se. Regards, p. -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Various block size proposals
Thanks Bryan for collating these links in one great list. This is very helpful and thanks for sharing it. Feel free to fork https://github.com/EthanHeilman/BlockSizeDebate edit to add the list of proposals and create a pull request to Ethan. There's also a miningconsensus.slack.com group to have discussion w.r.t. fact/source checking, completeness (e.g. from IRC) etc. Tks. p. On Sat, Jun 13, 2015 at 3:13 AM, Bryan Bishop kanz...@gmail.com wrote: Here are some proposals regarding the minimum block size questions, as well as other related scalability issues. Dynamic block size limit controller (maaku) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html https://www.reddit.com/r/Bitcoin/comments/35c47x/a_proposal_to_expand_the_block_size/ Re: dynamic block size limit controller (gmaxwell) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html Various other gmaxwell-relayed ideas http://www.reddit.com/r/Bitcoin/comments/37pv74/gavin_andresen_moves_ahead_with_push_for_bigger/crp2735 Increasing the max block size using a soft-fork (Tier Nolan) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Elastic block cap with rollover penalties (Meni Rosenfield) https://bitcointalk.org/index.php?topic=1078521 worked example https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115 section 6.2.3 of https://cryptonote.org/whitepaper.pdf rollover transaction fees https://bitcointalk.org/index.php?topic=80387.0 Variable mining effort (gmaxwell) http://sourceforge.net/p/bitcoin/mailman/message/34100485/ BIP100 Soft-fork limit of 2 MB (jgarzik) http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Transaction fee targeting https://bitcointalk.org/index.php?topic=176684.msg9416723#msg9416723 Difficulty target scaling https://www.reddit.com/r/Bitcoin/comments/38937n/idea_make_the_difficulty_target_scale_with_block/ Annual 50% max block size increase https://www.reddit.com/r/Bitcoin/comments/351dft/what_about_gavins_2014_proposal_of_having_block/ Various algorithmic adjustment proposals https://bitcointalk.org/index.php?topic=1865.0 https://www.reddit.com/r/Bitcoin/comments/1owbpn/is_there_a_consensus_on_the_blocksize_limit_issue/ccwd7xh https://www.reddit.com/r/Bitcoin/comments/35azxk/screw_the_hard_limit_lets_change_the_block_size/ https://www.reddit.com/r/Bitcoin/comments/359y0i/quick_question_about_the_block_size_limit_issue/ http://www.reddit.com/r/Bitcoin/comments/385xqj/what_if_block_size_limits_were_set_to_increase/ http://www.age-of-bitcoin.com/dynamic-block-size-cap-scaling/ (against) http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html Average over last 144 blocks http://www.reddit.com/r/Bitcoin/comments/38fmra/max_block_size_2_average_size_of_last_144_blocks/ Extension blocks (Adam Back) (why would he burn this idea for something so trivial?) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08005.html http://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ http://www.reddit.com/r/Bitcoin/comments/39hgzc/blockstream_cofounder_president_adam_back_phd_on/cs3tgss Voting by paying to an address (note: vote censorship makes this impractical, among other reasons) http://www.reddit.com/r/Bitcoin/comments/3863vw/a_brandnew_idea_for_resolving_the_blocksize_debate/ http://www.reddit.com/r/Bitcoin/comments/1g0ywj/proposal_we_should_vote_on_the_blocksize_limit/ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02325.html Vote by paying fees https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08164.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html Double the max block size at each block reward halving https://www.reddit.com/r/Bitcoin/comments/359jdc/just_double_the_max_blocksize_on_every_block/ Reducing the block rate instead of increasing the maximum block size (Sergio Lerner) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html https://www.reddit.com/r/Bitcoin/comments/35kpgk/sergio_lerner_on_bitcoindevelopment_reducing_the/ Decrease block interval https://www.reddit.com/r/Bitcoin/comments/2vefmp/please_eli5_besides_increasing_the_block_size_why/ https://www.reddit.com/r/Bitcoin/comments/35hpkt/please_remind_me_once_again_why_we_cant_decrease/ Increase default soft block size limit in Bitcoin Core http://www.reddit.com/r/Bitcoin/comments/38i6qr/why_not_increase_the_default_block_size_limit/ https://github.com/bitcoin/bitcoin/pull/6231 Consider the size of the utxo set when determining max block size (note that utxo depth cannot have consensus) https://bitcointalk.org/index.php?topic=153401.20 Reduce and
Re: [Bitcoin-development] Meta suggestions for this block size debate
OK... sorry for my confusion. https://github.com/EthanHeilman/BlockSizeDebate it is. p. On Sat, Jun 6, 2015 at 2:37 PM, gabe appleton gapplet...@gmail.com wrote: Please use the one it's originally forked from that Ethan made. I don't want to be the one who sorts through what's valid and what isn't, as I don't have as low-level an understanding as I'd like. I don't feel qualified. On Jun 6, 2015 2:34 AM, Pindar Wong pindar.w...@gmail.com wrote: Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ 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 -- ___ 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
Re: [Bitcoin-development] Meta suggestions for this block size debate
Thanks Gabe. https://github.com/gappleto97/BlockSizeDebate github's reachable via vpn. p. On Sat, Jun 6, 2015 at 2:28 PM, gabe appleton gapplet...@gmail.com wrote: Yeah. We made a git repo instead, so we don't have to bother with the exclusive-by-default wiki policies. It's linked in this email chain. I'll be getting home tomorrow, so I should be able to start back up on this. A few days from now we should throw this on /r/Bitcoin so we can get some more public comment on it. They already gave me a few leads to chase. On Jun 5, 2015 11:34 PM, Pindar Wong pindar.w...@gmail.com wrote: Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ 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 -- ___ 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
Re: [Bitcoin-development] Meta suggestions for this block size debate
Gabe, Did you ever get an answer to this? Ill have some time tomorrow to be able to help with some work on this and will need to do it myself anyways since I'm not sure I understand the nuances, where bitcoin XT fits into the scheme of things (or not) etc. I would have thought that there would be a testnet4 by now using 8mb blocks... but hey that's just me. p. On Tue, Jun 2, 2015 at 11:52 AM, gabe appleton gapplet...@gmail.com wrote: I don't have permission to create a page. If someone else does, I'll happily get a framework started. On Mon, Jun 1, 2015 at 11:32 PM, Ethan Heilman eth...@gmail.com wrote: I second this, I don't have time to read the large number of emails generated every day from the block size debate. A summary of the various positions and arguments would be extremely helpful. On Mon, Jun 1, 2015 at 11:02 PM, gabe appleton gapplet...@gmail.com wrote: Also, can we try to get a wiki page for the debate? That way we could condense the information as much as possible. I'll be willing to assist if the page gets approval. On Jun 1, 2015 6:41 PM, Mats Henricson m...@henricson.se wrote: Hi! My fingers have been itching many times now, this debate drives me nuts. I just wish all posters could follow two simple principles: 1. Read up. Yes. All of what has been written. Yes, it will take many hours. But if you're rehashing what other smarter people have said over and over before, you're wasting hundreds of peoples time. Please don't. 2. Be helpful. Suggest alternatives. Just cristizising is just destructive. If you want no change, then say so. Mats -- ___ 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 -- ___ 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
Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse stephencalebmo...@gmail.com wrote: Pindar, yes and it's a good idea to separate the hard/soft fork upgrades. The point being here is that we're also establishing a process for the community to self-determine the way forward in a transparent and verifiable manner. What's not to like? :) I'll probably have some time on Sunday to help hack something up but I don't think this is that heavy a coding lift? What am I missing? As Matt mentioned, many members of the bitcoin community would be hesitant about giving miners this much power. I understand this concern and it's a valid one, including other dimensions such as better decentralization. Some might argue that the mining pools in China currently have such power and that's a bad thing:- https://blockchain.info/pools I happen to think that it's unhealthy for the network but the irony is that they are huge bitcoin fanbase that perhaps should be involved in this, and other, decisions. The question is how. Thus far our friends from f2pool have chimed in with some data from their perspective. It would be interesting to hear from the others and I'm finding ways to do exactly that. So let's find a way to involve, and not alienate them or others. Let's find a way to get more data and test assumptions and boundaries. It essentially lets them vote to change the rules of the system. It's data and yes, it gives then a very visible, verifiable 'vote' ... though I prefer to think of this as 'voice' as in a ' hu. ' But miners are not the only part of this ecosystem, and they are not the only ones affected by the choice of block size limit, so they probably shouldn't be the only ones with a vote. I fully agree and it doesn't have to be the only voice ... think 'choir' ... after all this is an ecosystem with each party playing their respective roles. But sustainable ecosystems have 'keystone' species, and I believe these to be the 'honest' miners that help secure the network. Instead, we vote with the software we run, and all upgrade. or not as the case may be. I think we're trying to find a level of rough consensus where members of the community feel comfortable enough to do this upgrade in their respective codebase. So, while I think an idea like this has its merits, I would bet that it's fairly unlikely to get enough support to be merged into bitcoin core. Bitcoin was 'unlikely' ... yet it happened. Nevertheless you raise the possibility of a different possible path forward and that's positive. So thank you for doing that! Bitcoin's humming in China, behind an GFW ... who could have guessed? 'Connect and Liberate' :) p. Best, Stephen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I think it would be helpful if we could all *chill* and focus on the solid engineering necessary to make Bitcoin succeed. p. On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang 1240...@gmail.com wrote: On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. If Western miners do not find a China-based VPN into China, or if Western pools do not manage to improve their connectivity to China, or run a node in China, it would be them to have higher orphans, not us. Because we have 50%+. -- ___ 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
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Two very valid and important points. Thank you for making these observations Peter. p. On Mon, Jun 1, 2015 at 7:26 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 01, 2015 at 06:42:05PM +0800, Pindar Wong wrote: On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. I'd rather think of mining as a responsibility than a right per se, but you're right in so far as it's competitive and self-correcting. It's important to remember that the service Bitcoin miners are providing us is *not* transaction validation, but rather decentralization. Validation is something every full node does already; there's no shortage of it. What's tricky is designing a Bitcoin protocol that creates the appropriate incentives for mining to remain decentralized, so we get good value for the large amount of money being sent to miners. I've often likened this task to building a robot to go to the grocery store to buy milk for you. If that robot doesn't have a nose, before long store owners are going to realise it can't tell the difference between unspoilt and spoilt milk, and you're going to get ripped off paying for a bunch of spoiled milk. Designing a Bitcoin protocol where we expect competition to result in smaller miners in more geographically decentralized places to get outcompeted by larger miners who are more geographically centralized gets us bad value for our money. Sure it's self-correcting, but not in a way that we want. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. Let's agree to disagree on this point. Note how that VPN, and likely VPS it's connected too, immediately adds another one or two points of failure to the whole system. Not only does this decrease reliability, it also decreases security by making attacks significantly easier - VPS security is orders of magnitude worse than the security of physical hardware. -- 'peter'[:-1]@petertodd.org 0e187b95a9159d04a3586dd4cbc068be88a3eafcb5b885f9 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
On Mon, Jun 1, 2015 at 7:58 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: 2015-06-01 0:40 GMT+01:00 Pindar Wong pindar.w...@gmail.com: On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. Hi, Is that an assumption? no, let me rephrase: The disadvantage alex refers to only exists if miners do not have the same network speed. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. Perhaps it's best not to assume that investing in Internet network infrastructure's a free or open market everywhere. Just like easy ASIC access, low price electricity, etc are not a free and open market. -- point well made and taken. p. p. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses
Hi, Perhaps at some point consider introducing something akin to a 'Bitcoin-Draft' (BD) status with some autoexpiry period? I understand that the Internet Engineering Task Force (IETF) http://www.ietf.org has the concept of 'Internet Drafts (ID) http://www.ietf.org/ietf-ftp/1id-guidelines.txt and this looks like it has worked for them so far. m2c. p. On Thu, Mar 12, 2015 at 4:16 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote: I used BIP0090 as a place-holder, but I would like to request a BIP number for this now. We have had repeated problems in the past with people working on and circulating prior draft proposals squatting on each others numbers, and each demanding access to the same numbers. As a matter of procedure I will not assign squatted numbers, but also discussion should come in advance of number assignment; general subject here seems reasonable but many proposals are withdrawn by the party tendering them after further discussion shows the effort to be without public interest or actually subsumed by other functionality. :) Proposals should not be called BIP[nn] until they're actually a BIP. Feel free to call it bip-kerin-multisignature or any other placeholder name that won't be confused with a finished BIP for drafting. If there is any public documentation on the process which caused you specific confusion, please feel free to point me at it and I'll be sure to fix it! Sorry for any confusion there. -- 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 -- 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] BIP for standard multi-signature P2SH addresses
Understood... perhaps just add something like: 'After copy-editing and acceptance,* a BIP number is assigned* and it will be published here.'? https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals p. On Thu, Mar 12, 2015 at 7:34 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote: Perhaps at some point consider introducing something akin to a 'Bitcoin-Draft' (BD) status with some autoexpiry period? I understand that the Internet Engineering Task Force (IETF) has the concept of 'Internet Drafts (ID) and this looks like it has worked for them so far. Thats more or less what posting to the list is supposed to be. Creating a draft document requires no approval, beyond filling out the right form. Perhaps calling out that as a distinct step would be better, indeed. -- 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] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
*Spendid* work Andrew (and all the other authors). Well done. This is a timely paper that deserves significantly wider circulation and comment. FWIW, Joichi Ito, from the MIT media Lab, made reference to your work during yesterday's MIT Bitcoin Expo https://www.youtube.com/watch?v=lIgjogLipvk[@ 2:46:54] p. On Wed, Mar 4, 2015 at 11:28 PM, Mike Hearn m...@plan99.net wrote: Nice, Andrew. Just one minor point. SPV clients do not need to maintain an ever growing list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and thus has O(1) disk usage. Re-orgs past the event horizon cannot be processed but are assumed to be sufficiently rare that manual intervention would be acceptable. On Mon, Mar 2, 2015 at 8:48 AM, Andrew Miller amil...@cs.umd.edu wrote: We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- 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 -- 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 -- 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
