Re: [Bitcoin-development] Block Size Increase Requirements
On 05/29/15 23:48, Gavin Andresen wrote: On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! I must have missed that analysis-- link please? Or summary of HOW they will optimize away 50% of the network? Or are you assuming that 50% of the network is colocated... (which is a potential problem independent of blocksize) If, for example, the majority of miners are in China (they are), and there is really poor connectivity in and out of China (there is) and a miner naively optimizes for profit, they will create blocks which are large and take a while to relay out of China. By simple trial-and-error an individual large miner might notice that when they create larger blocks which fork off miners in other parts of the world, they get more income. Obviously forking off 50% of the network would be a rather extreme situation and assumes all kinds of simplified models, but it shows that the incentives here are very far from aligned, and your simplified good-behavior models are very far from convincing. In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by little miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be evil for this to happen - just optimize for profits. But the disadvantage is tiny. And essentially zero if they connect to your fast relay network (or anything like it). The disadvantage is small with 1MB blocks, but already non-zero. 20MB blocks are much, much worse (lots of things here dont scale linearly, even just transfer over a high-packet-loss-link). I mentioned this in my original email as something which doesnt make me comfortable with 20MB blocks, but something which needs simulation and study, and might actually be just fine! But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? Do you have another explanation for why miners choose to leave fee-paying transactions in their mempool and create small blocks? Defaults? Dumb designs? Most miners just use the default 750K blocks, as far as I can tell, other miners probably didnt see transactions relayed across several hops or so, and a select few miners are doing crazy things like making their blocks fit in a single packet to cross the gfw, but that is probably overkill and not well-researched. Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money I'm not suggesting that we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money. I'm suggesting the blocksize be increased to 20MB (and then doubled every couple of years). Do you have convincing evidence that at 20MB miners will be able to break even on transaction fees for a long time? (The answer is no because no one has any idea how bitcoin transaction volumes are going to scale, period.) And in which miners make their money is the wrong metric-- we want enough mining so the network to be secure enough against double-spends. Sure, do you have a value of hashpower which is secure enough (which is a whole other rabbit hole
Re: [Bitcoin-development] Block Size Increase Requirements
On 05/29/15 22:36, Gavin Andresen wrote: Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by little miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be evil for this to happen - just optimize for profits. But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money, then either miners are not being funded (ie hashpower has to drop to very little), or the only people mining/funding miners are large orgs who are running Bitcoin (ie the web wallets, payment processors, big merchants, and exchanges of the world). Sadly, this is no longer a decentralized Bitcoin and is, in fact, pretty much how the banking world works today. I'm not sure who, if anyone, claims Bitcoin is novel or interesting for any reason other than its decentralization properties, and, in a world which you are apparently proposing, the natural course of things is to very strongly centralize. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? Yes, I am arguing that by increasing the blocksize the incentives to actually make Bitcoin scale go away. Even if amazing technologies get built, no one will have any reason to use them. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On 05/07/15 11:29, Mike Hearn wrote: Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article: On a related note, I'd like to agree strongly with Peter Todd that we should get away from doing forks-only-in-releases. We can add code to do a fork and then enable it in 0.11.1 or 0.11.11 if Gavin prefers more 11s. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Block Size Increase Requirements
OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I probably forgot one or two and certainly dont want to back myself into a corner on committing to something here, but those are a few things I see today as big blockers on larger blocks. Luckily, people have been making progress on building the software needed in all of the above for a while now, but I think they're all very, very immature today. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. Agreed, but that is water under the bridge at this point. You - rightly - opened the topic here and now we're discussing it. Mike and Gavin are due the benefit of doubt because making a change to a leaderless automaton powered by leaderless open source software is breaking new ground. I don't focus so much on how we got to this point, but rather, where we go from here. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On 05/07/15 19:34, Mike Hearn wrote: The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and process of things, and not about the change itself? No, I'm very concerned about both. I have witnessed many arguments in IRC about block sizes over the years. There was another one just a few weeks ago. Pieter left the channel for his own sanity. IRC is not a good medium for arriving at decisions on things - many people can't afford to sit on IRC all day and conversations can be hard to follow. Additionally, they tend to go circular. I agree, thats why this mailing list was created in the first place (well, also because bitcointalk is too full of spam, but close enought :)) That said, I don't know if you can draw a line between the ins and outs like that. The general public is watching, commenting and deciding no matter what. Might as well deal with that and debate in a format more accessible to all. Its true, just like its true the general public can opt to run any version of software they want. That said, the greater software development community has to update /all/ the software across the entire ecosystem, and thus provide what amounts to a strong recommendation of which course to take. Additionally, though there are issues (eg if there was a push to remove the total coin limit) which are purely political, and thus which should be up to the greater public to decide, the blocksize increase is not that. It is intricately tied to Bitcoin's delicate incentive structure, which many of the development community are far more farmiliar with than the general Bitcoin public. If there were a listserv that was comprised primarily of people on #bitcoin-wizards, I might have suggested a discussion there, first, but there isnt (as far as I know?). If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think? There have been many such discussions over time. On bitcointalk. On reddit. On IRC. At developer conferences. Gavin already knew what many of the objections would be, which is why he started answering them. But alright. Let's say he should have started a thread. Thanks for starting it for him. Now, can we get this specific list of things we should do before we're prepared? YesI'm gonna split the topic since this is already far off course for that :). A specific credible alternative to what? Committing to blocksize increases tomorrow? Yes, doing more research into this and developing software around supporting larger block sizes so people feel comfortable doing it in six months. Do you have a specific research suggestion? Gavin has run simulations across the internet with modified full nodes that use 20mb blocks, using real data from the block chain. They seem to suggest it works OK. What software do you have in mind? Let me answer that in a new thread :). -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On 05/07/15 14:52, Gavin Andresen wrote: For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still appreciate it if people do that; it is impossible to keep up with this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and also have time to respond thoughtfully to the objections raised. People have been sharing the same objections as on this list for months, I'm not sure what is new here. I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is how much transaction volume the main Bitcoin blockchain will be able to support over the next eleven years. I think this is a huge issue. You've been wandering around telling people that the blocksize will increase soon for months, when there is very clearly no consensus that it should in the short-term future. The only answer to this that anyone with a clue should give is it will very, very likely be able to support at least 1MB blocks roughly every 10 minutes on average for the next eleven years, and it seems likely that a block size increase of some form will happen at some point in the next eleven years, anything else is dishonest. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Block Size Increase
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
For now, lets leave the discussion to JUST the block size increase. If it helps - everyone should assume that their pet feature is included in a hard fork or, if you prefer, that no other features are included in a hard fork. On 05/06/15 23:11, Matt Whitlock wrote: I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions would be extremely risky for Bitcoin. If it could be guaranteed that raising the block size limit would be the only incompatible change introduced in the hard fork, then I would support it, but I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Replies inline. On 05/06/15 22:44, Tier Nolan wrote: On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. -snip- The question being discussed is what is the maximum block size merchants and users will accept. This puts a reasonable limit on the maximum size miners can increase the block size to. In effect, the block size is set by the minimum of the miner's and the merchants/user's size.min(miner, merchants/users). Indeed, the bitcoin community of users and miners can decide to do whatever they want, but this is univeral - they could decide whatever they want if they want to hardfork. That said, we should be having a rigorous technical discussion about whether it is sane to recommend a given course of action by releasing software which makes it happen. This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Would you accept a rule that the maximum size is 20MB (doubling every 2 years), but that miners have an efficient method for choosing a lower size? If miners could specify the maximum block size in their block headers, then they could coordinate to adjust the block size. If 75% vote to lower the size, then it is lowered and vice versa for raiding. Every 2016 blocks, the votes are counter. If the 504th lowest of the 2016 blocks is higher than the previous size, then the size is set to that size. Similarly, if the 504th highest is lower than the previous size, it becomes the new size. There could be 2 default trajectories. The reference client might always vote to double the size every 4 years. To handle large blocks (32MB) requires a change to the p2p protocol message size limits, or a way to split blocks over multiple messages. It would be nice to add new features to any hard-fork. I favour adding an auxiliary header. The Merkle root in the header could be replaced with hash(merkle_root | hash(aux_header)). This is a fairly simple change, but helps with things like commitments. One of the fields in the auxiliary header could be an extra nonce field. This would mean fast regeneration of the merkle root for ASIC miners. This is a pretty simple change. The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On 04/21/15 07:59, Peter Todd wrote: On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote: In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the height of the output being spent and then has identical semantics to CLTV. Depending on what you mean by identical this isn't actually reorg safe. For instance consider this implementation: nLockTime = stack[-1] + prevout.nHeight if (nLockTime txTo.nLockTime): return False Used with this scriptPubKey: 10 RCLTV DROP pubkey CHECKSIG If I create that output in tx1 which is mined at height 42 I can spend it in a tx2 at height 42+10 by setting tx2's nLockTime to 42+10, for instance 53. However if a reorg happens and tx1 ends up at height 43 after the reorg I'm stuck - tx2's nLockTime is set at 42. Thus RCTLV is only reorg safe if the height is compared against the actual block height of the block containing the spending transaction, not the spending transaction's nLockTime. Yes, as discussed on IRC months ago when the first email was sent, the assumption is that you would require N be at least 100. That way you are reorg safe up to the same limit as coinbase transactions, which are also only reorg safe in the case of no 100-block reorgs. Its not ideal in some contracts, but keeping the no-second-nLockTime-equivalent property is worth it IMO, and its still incredibly useful in many contracts. A slightly different API (and different name) was described by maaku at http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154 which does a better job of saving softfork-available opcode space. There are two major drawbacks to adding such an operation, however. 1) More transaction information is exposed inside the script (prior to CLTV we only had the sigchecking operation exposed, with a CLTV and RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions). 2) Bitcoin Core's mempool invariant of all transactions in the mempool could be thrown into one overside block and aside from block size, it would be valid becomes harder to enforce. Currently, during reorgs, coinbase spends need checked (specifically, anything spending THE coinbase 100 blocks ago needs checked) and locktime transactions need checked. With such a new operation, any script which used this new opcode during its execution would need to be re-evaluated during reorgs. Yup, definitely kinda ugly. If the above style of RCTLV was used, one possibility might be to make the relative locktime difference be required to be at least 100 blocks, same as the coinbase maturity, and just accept that it's probably not going to cause any problems, but could in an extremely big reorg. But re-orgs that big might be big enough that we're screwed anyway... With the 100 block rule, during a sufficiently large reorg that coinbases become unavailble, simply disconnect entire blocks - all txouts created by them. I think both of these requirements are reasonable and not particularly cumbersome, and the value of such an operation is quite nice for some protocols (including settings setting up a contest interval in a sidechain data validation operation). So to be clear, right now the minimal interface to script execution is simply: int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, unsigned int scriptPubKeyLen, const unsigned char *txTo, unsigned int txToLen, unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err); Where scriptPubKey is derived from the unspent coin in the UTXO set and txTo is the transaction containing the script that is being executed. The UTXO set itself currently contains CCoins entries, one for each transaction with unspent outputs, which basically contain: nVersion - tx nVersion nHeight - Height of the block the transaction is contained in. vout - Unspent CTxOut's of the transaction. The block nTime isn't directly available through the UTXO set, although it can be found in the block headers. This does require nodes to have the block headers, but at 4MB/year growth it's reasonable to assume the UTXO set will grow faster. Script execution does not have direct access to the current block height/block time, however it does have indirect access via nLockTime. Thus we have a few possibilities: 1) RCLTV against nLockTime Needs a minimum age COINBASE_MATURITY to be safe. 2) RCLTV against current block height/time Completely reorg safe. 3) GET_TXOUT_HEIGHT/TIME diff ADD CLTV To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age
[Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the height of the output being spent and then has identical semantics to CLTV. A slightly different API (and different name) was described by maaku at http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154 which does a better job of saving softfork-available opcode space. There are two major drawbacks to adding such an operation, however. 1) More transaction information is exposed inside the script (prior to CLTV we only had the sigchecking operation exposed, with a CLTV and RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions). 2) Bitcoin Core's mempool invariant of all transactions in the mempool could be thrown into one overside block and aside from block size, it would be valid becomes harder to enforce. Currently, during reorgs, coinbase spends need checked (specifically, anything spending THE coinbase 100 blocks ago needs checked) and locktime transactions need checked. With such a new operation, any script which used this new opcode during its execution would need to be re-evaluated during reorgs. I think both of these requirements are reasonable and not particularly cumbersome, and the value of such an operation is quite nice for some protocols (including settings setting up a contest interval in a sidechain data validation operation). Thoughts? Matt On 10/01/14 13:08, Peter Todd wrote: I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at: https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki The reference implementation, including a full-set of unittests for the opcode semantics can be found at: https://github.com/petertodd/bitcoin/compare/checklocktimeverify pre BIP: Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd p...@petertodd.org Status: Draft Type: Standards Track Created: 2014-10-01 /pre ==Abstract== This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future. ==Summary== CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it compares the top item on the stack to the nLockTime field of the transaction containing the scriptSig. If that top stack item is greater than the transation nLockTime the script fails immediately, otherwise script evaluation continues as though a NOP was executed. The nLockTime field in a transaction prevents the transaction from being mined until either a certain block height, or block time, has been reached. By comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we indirectly verify that the desired block height or block time has been reached; until that block height or block time has been reached the transaction output remains unspendable. ==Motivation== The nLockTime field in transactions makes it possible to prove that a transaction output can be spent in the future: a valid signature for a transaction with the desired nLockTime can be constructed, proving that it is possible to spend the output with that signature when the nLockTime is reached. An example where this technique is used is in micro-payment channels, where the nLockTime field proves that should the receiver vanish the sender is guaranteed to get all their escrowed funds back when the nLockTime is reached. However the nLockTime field is insufficient if you wish to prove that transaction output ''can-not'' be spent until some time in the future, as there is no way to prove that the secret keys corresponding to the pubkeys controling the funds have not been used to create a valid signature. ===Escrow=== If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting hit by a bus they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party. With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force. However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of the form: IF now + 3 months CHECKLOCKTIMEVERIFY DROP Lenny's pubkey CHECKSIGVERIFY
Re: [Bitcoin-development] Area of Focus
There was recently some discussion around dnsseeds. Currently some dnsseeds are getting blocked by ISPs because the hosts they pick up (which run bitcoin core nodes) often run rather web servers alongside which serve malware or whatever else and thus end up on IP-based malware blacklists. Of course we really dont want to move off of DNS because it has this big built-in anonymity network where the DNS seed servers only get information about your ISP, not you, and its cached so you dont get as much information about how many users are making those requests. A potential solution might be supporting some subdomain which has results XORed with some constant mask to tweak the real IP. Additionally, it might be cool to stuff a TXT//whatever record with a signature of the results provided by the DNSseed operator. Matt On 12/20/14 07:42, Will Bickford wrote: Hi all, I'm looking to help with Bitcoin core development in my spare time (a few hours per week). A little bit about me: * I use C++ and Qt daily * I love to automate and enhance software systems * I enjoy root causing and fixing issues I saw Gavin say we needed help with testing in a Reddit AMA a while ago. I'm curious where I can make the best impact. Any feedback would be appreciated. Thanks! Will Bickford In Google We Trust -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Area of Focus
Well, some ISPs, when they see an IP address serving malware, will (apparently) simply replace DNS results for anything returning that IP with a warning page. One solutions is to just blindly block everything with HTTP(S), as Christian has done, but this is a rather ugly solution, since many perfectly good nodes will get caught in the crossfire. Hiding what actual IPs we're returning in the results seems much cleaner, despite being an ugly hack. On 12/20/14 11:14, Jeremy Spilman wrote: On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote: There was recently some discussion around dnsseeds. Currently some dnsseeds are getting blocked by ISPs because the hosts they pick up (which run bitcoin core nodes) often run rather web servers alongside which serve malware or whatever else and thus end up on IP-based malware blacklists. On Sat, 20 Dec 2014 02:08:17 -0800, Roy Badami r...@gnomon.org.uk wrote: Why would we want to have anything to do with people who are hosting malware? Or do I misunderstand? It sounds like Matt is saying the nodes the dnsseed is pointing to as valid full nodes, that those IPs are hosting the malware. Since the dnsseed picks up any stable nodes it can find without auditing, it's perhaps not surprising some servers in the world are running a full node and a malware server together. I guess what confused me about this though, how are ISPs reading the dnsseed's node list, scanning *those* IPs for malware, and then ending up blocking the dnsseed? Seems like a pretty winding path to end up blocking a DNS server? Since when do ISPs null-route a DNS server for happening to resolve some domains to IPs which happen to also be hosting some malware? Null-route those endpoint IPs sure, but the DNS server too? I guess there was that incident of Microsoft taking over No-IP.com -- are dnsseeds being blocked ostensibly because they are acting as dyanamic DNS infrastructure for malware sites? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ACK NACK utACK Concept ACK
Also utACK (untested ack) and tested ack when people are being explicit. On 12/09/14 21:14, Sergio Lerner wrote: Is that the full terminology or are there more acronyms? Is this documented somewhere? Best regards, Sergio. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Depends, without BIP62 a /lot/ of the even basic contracts that people want to use today (or wanted to use 18 months ago) are unusable, in fact, without BIP62, the atomic swaps suggested as important for sidechains are not secure. While redoing Bitcoin in a hardfork is nice, its a very long-term thing, so I'm not sure about making people wait for a large hardfork just to use payment channels. Also, I echo the difficulty of writing consensus-compatible code and highly suggest anyone with money behind an implementation that is doing script verification in code that isnt Bitcoin Core rethink that decision. Matt On 11/06/14 21:58, Tamas Blummer wrote: Thanks Peter, Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible. The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning. Freezing the consensus code, studying its bugs appears more appropriate to me. What we learn could define a hard fork or a better chain we migrate to as discussed by blockstream. Tamas Blummer -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP status changes
On 10/15/14 08:47, Wladimir wrote: These BIPs should go to Final state - they are implemented all over the place, and are thus entirely fixed in place now. Any changes would require a new BIP as amandment: - BIP 14 (BIP Protocol Version and User Agent) - BIP 21 (URI Scheme) ACK. - BIP 22 (getblocktemplate - Fundamentals) - BIP 31 (Pong Message) - BIP 34 (Block v2, Height in coinbase) - BIP 35 (mempool message) - BIP 37 (Bloom filtering) Let me know if you (don't) agree. Wladimir -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)
See-also: this related bug on Curve25519 and some MS Research curves that generated far more discussion. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 Matt On 10/13/14 10:01, Melvin Carvalho wrote: FYI: This is an issue I filed related to adding secp256k1 into Web Crypto API which will be implemented natively in (some) web browsers. If there is any feedback from crypto implementers, please feel free to add comments to this thread: https://www.w3.org/Bugs/Public/show_bug.cgi?id=2 -- Forwarded message -- From: ** bugzi...@jessica.w3.org mailto:bugzi...@jessica.w3.org Date: 13 October 2014 09:18 Subject: [Bug 2] Named Curve Registry (adding secp256k1) To: melvincarva...@gmail.com mailto:melvincarva...@gmail.com https://www.w3.org/Bugs/Public/show_bug.cgi?id=2 Myron Davis myr...@gmail.com mailto:myr...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||myr...@gmail.com mailto:myr...@gmail.com Resolution|NEEDSINFO |--- --- Comment #2 from Myron Davis myr...@gmail.com mailto:myr...@gmail.com --- Could this be looked at again? Last response was waiting for feedback from crypto implementors. Currently secp256k1 is supported in the following SSL/TLS libraries now Botan NSS openssl LibreSSL PolarSSL JSSE The three other curves are all all have parameters which do not define how they were generated. secp256k1 curve has some great advantages in faster signature verification and how the values were determined for the curve. (i.e. not random). http://www.ietf.org/rfc/rfc4492 The curve has had a lot of eyes on it with lots of hardware and software supporting this curve. With discovery of backdoor's in NIST's random number generator (https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I would like to see a determined parameter curve instead of a random curve option. Thanks -- You are receiving this mail because: You reported the bug. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decreasing block propagation time
It already is https://bitcointalk.org/index.php?topic=766190.0;all. Well, ok, a variation on the idea is. Matt On 10/02/14 04:39, Rebroad (sourceforge) wrote: https://bitcointalk.org/index.php?topic=145066.0 The idea proposed in the above article seemed like an excellent idea. What is holding this up from being implemented? Does someone need to code it, or write a BIP first? -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] RIP Hal Finney
I'm sure many of you have already seen this, but Hal Finney passed away on Tuesday. While his body is being cryogenically preserved, we should all take a moment to thank Hal for everything he did for the cypherpunk community, specifically helping hugely in the early days of Bitcoin as well as PGP. Matt http://lists.extropy.org/pipermail/extropy-chat/2014-August/082585.html -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
For those who have been using this to get faster relays to/from the network, you may have noticed some instability recently. This is because the nodes were all being upgraded to use some new relaying code which should cut down on duplicate transaction relaying in blocks, improving relay speed within the network and to nodes which run new clients which use the same relaying technique. Essentially instead of relaying entire blocks, nodes keep a rolling window of recently-seen transactions and skip those when relaying blocks. You can find a simple client which connects to a local bitcoind and a relay node at http://bitcoin.ninja/RelayNodeClient.jar and the source for the whole thing at https://github.com/TheBlueMatt/RelayNode. Matt On 11/06/13 05:50, Matt Corallo wrote: Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin network on IRC and elsewhere (1). To this extent, I'm organizing a system of peering between nodes in the network by creating a system of high-speed relay nodes for miners and merchants/exchanges. This system will a) act as a fallback in the case that the public Bitcoin network encounters issues and b) decrease block propagation times between miners. It is NOT designed to in any way replace or decrease the need for the public Bitcoin P2P network. It is NOT any kind of attempt at centralization, and I still encourage interested parties to establish their own private peering agreements with large miners as needed. Currently the network consists of one specially-designed relay node, but I hope to bring more online in the coming days. This network is open to everyone via a few public relay nodes, but also will have nodes which are made available only to large miners and merchants/exchanges to mitigate the ability of malicious parties to DoS the network. To peer with the public relay nodes, simply select the closest region out of us-west (West Coast US), us-east (East Coast US), eu (Western Europe), au (Australia), or jpy (Japan) and add public.REGION.relay.mattcorallo.com to your addnode list. Note that since all of the relay nodes will relay between each other, you gain no latency advantage by peering with more than the closest node to you (and currently all the regions map to one node, so there they're redundant anyway). For each relay node, you can connect to either port 8334 or 8335. Connecting on port 8334 will relay only blocks, and port 8335 will relay both blocks and transactions. The relay nodes will request any transactions which appear in your invs no matter which port you connect to. Relay node details: * The relay nodes do some data verification to prevent DoS, but in order to keep relay fast, they do not fully verify the data they are relaying, thus YOU SHOULD NEVER mine a block building on top of a relayed block without fully checking it with your own bitcoin validator (as you would any other block relayed from the P2P network). * The relay nodes do not follow the standard inv-getdata-tx/block flow, but instead relay transactions/blocks immediately after they have done their cursory verification. They do keep some track of whether or not your nodes claim to have seen the transactions/blocks before relaying, but you may see transactions/blocks being sent which you already have and have not requested, if this is a problem for you due to bandwith issues, you should reconsider your bandwith constraints and/or are peering with too many nodes. * The relay nodes will all relay among themselves very quickly, so there is no advantage to peering with as many relay nodes as you can find, in fact, the increased incoming bandwidth during block relay spikes may result in higher latency for your nodes. * The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. Additionally, because the relay nodes do not respond to standard getdata requests, if you miss a relay and then reconnect, that data will not be sent again by the relay nodes. The relay nodes are NOT a replacement for having peers on the standard P2P network, they are only there to augment the existing P2P network. If you are a merchant/exchange/large miner/other important node operator and wish to gain access to additional domain names which map to relay nodes with fewer peers, please fill out the form at https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform You can find the source for the relay nodes at https://github.com/TheBlueMatt/RelayNode If you have any comments/concerns/suggestions, please do not hesitate to email bitcoin-peer...@mattcorallo.com Thanks, Matt (1) There has been extended discussion on #bitcoin-wizards as well as #bitcoin-dev of the very small number of active, listening nodes. Additionally, because many of those nodes are versions prior to 0.8.4, it seems very likely
Re: [Bitcoin-development] Policy for DNS seeds
Absolutely not. Time and time again we've seen anonymized data sets that dont work out so well. I'm sure its possible to do but there are too many factors and we dont want to succumb to this. Also, these generally look good (and essentially the same as what had been a gentleman's agreement for those who read IRC actively, the purpose of codifying this is essentially that we ended up adding a lot of DNS Seeds run by people who dont follow development closely and/or are not aware of the issues involved). Thanks for writing this up, Matt On 07/21/14 13:53, Christian Decker wrote: How about research projects into node distribution? Specifically I wonder whether the collection and analysis of DNS query origin is allowed when queries are anonymized and aggregated. This would prevent the identification of a single user, which I assume is the rationale for point 4. Other than that I'm perfectly fine with accepting the rules for seed.bitcoinstats.com Regards, Christian -- Christian Decker On Mon, Jul 21, 2014 at 2:43 PM, Wladimir laa...@gmail.com wrote: We've established a few basic rules for the DNS seeds as used in the Bitcoin Core software. See below. If you run one of the DNS seeds please reply to this and let us know whether you agree to these terms. if you think some requirements are unreasonable let us know too. If we haven't heard from you by 2014-08-04 we will remove your DNS seed from the list of defaults. Expectations for DNSSeed operators Bitcoin Core attempts to minimize the level of trust in DNS seeds, but DNS seeds still pose a small amount of risk for the network. Other implementations of Bitcoin software may also use the same seeds and may be more exposed. In light of this exposure this document establishes some basic expectations for the expectations for the operation of dnsseeds. 0. A DNSseed operating organization or person is expected to follow good host security practices and maintain control of their serving infrastructure and not sell or transfer control of their infrastructure. Any hosting services contracted by the operator are equally expected to uphold these expectations. 1. The DNSseed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operators understanding and capability. 2. For the avoidance of doubt, the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed. 3. The results may not be served with a DNS TTL of less than one minute. 4. Any logging of DNS queries should be only that which is necessary for the operation of the service or urgent health of the Bitcoin network and must not be retained longer than necessary or disclosed to any third party. 5. Information gathered as a result of the operators node-spidering (not from DNS queries) may be freely published or retained, but only if this data was not made more complete by biasing node connectivity (a violation of expectation (1)). 6. Operators are encouraged, but not required, to publicly document the details of their operating practices. 7. A reachable email contact address must be published for inquiries related to the DNSseed operation. If these expectations cannot be satisfied the operator should discontinue providing services and contact the active Bitcoin Core development team as well as posting on bitcoin-development. Behavior outside of these expectations may be reasonable in some situations but should be discussed in public in advance. See https://github.com/bitcoin/bitcoin/pull/4566 Wladimir -- 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 -- 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] DNS seeds unstable
This is very strange...when did you run this test and can anyone else reproduce this? Matt On 05/15/14 11:50, Andreas Schildbach wrote: testnet-seed.bluematt.me OK (but only returns one node) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
Oops, missed the lost On May 16, 2014 3:04:40 PM EDT, Matt Corallo bitcoin-l...@bluematt.me wrote: Oh, I missed that this was the testnet seed. Yea, that one never got set up properly and was just pointing to a static seed node (that is now down...). The mainnet seed actually works. On 05/16/14 19:01, Laszlo Hanyecz wrote: Matt, I get the same: $ host testnet-seed.bluematt.me testnet-seed.bluematt.me is an alias for bitcoin-seednode.bluematt.me. bitcoin-seednode.bluematt.me is an alias for desktopv2.bluematt.me. desktopv2.bluematt.me has address 152.23.202.18 $ dig +trace desktopv2.bluematt.me. any ; DiG 9.8.5-P1 +trace desktopv2.bluematt.me. any ;; global options: +cmd .451792 IN NS l.root-servers.net. .451792 IN NS d.root-servers.net. .451792 IN NS e.root-servers.net. .451792 IN NS c.root-servers.net. .451792 IN NS j.root-servers.net. .451792 IN NS b.root-servers.net. .451792 IN NS h.root-servers.net. .451792 IN NS f.root-servers.net. .451792 IN NS g.root-servers.net. .451792 IN NS a.root-servers.net. .451792 IN NS i.root-servers.net. .451792 IN NS m.root-servers.net. .451792 IN NS k.root-servers.net. ;; Received 512 bytes from 2a00:5540:5014::1#53(2a00:5540:5014::1) in 2 ms me. 172800 IN NS b2.me.afilias-nst.org. me. 172800 IN NS ns2.nic.me. me. 172800 IN NS a0.cctld.afilias-nst.info. me. 172800 IN NS b0.cctld.afilias-nst.org. me. 172800 IN NS c0.cctld.afilias-nst.info. me. 172800 IN NS d0.cctld.afilias-nst.org. me. 172800 IN NS a2.me.afilias-nst.info. me. 172800 IN NS ns.nic.me. ;; Received 509 bytes from 2001:7fe::53#53(i.root-servers.net) in 1807 ms bluematt.me. 86400 IN NS ns.bluematt.me. bluematt.me. 86400 IN NS ns3.he.net. bluematt.me. 86400 IN NS ns4.he.net. bluematt.me. 86400 IN NS ns1.rollernet.us. bluematt.me. 86400 IN NS ns2.rollernet.us. ;; Received 162 bytes from 2001:500:26::1#53(b0.cctld.afilias-nst.org) in 118 ms desktopv2.bluematt.me. 3600IN A 152.23.202.18 bluematt.me. 86400 IN NS ns4.he.net. bluematt.me. 86400 IN NS ns3.he.net. bluematt.me. 86400 IN NS ns2.rollernet.us. bluematt.me. 86400 IN NS ns1.rollernet.us. bluematt.me. 86400 IN NS ns.bluematt.me. ;; Received 178 bytes from 2607:fe70:0:4::b#53(ns2.rollernet.us) in 126 ms Thanks, Laszlo On May 16, 2014, at 6:53 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: This is very strange...when did you run this test and can anyone else reproduce this? Matt On 05/15/14 11:50, Andreas Schildbach wrote: testnet-seed.bluematt.me OK (but only returns one node) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Ubuntu LTS Packaging?
Hmm? It's up to date... 0.9.1 doesn't change anything for dynamically-linked-to-openssl builds. Matt On April 12, 2014 10:26:07 AM EDT, Oliver Egginger bitc...@olivere.de wrote: Hello, so far, nothing yet? See: https://launchpad.net/~bitcoin/ I'm developing currently a LiveCD for hot/cold wallet management on Ubuntu LTS basis. For critical vulnerabilities I have to provide timely updates. I have now decided to maintain my own repository for this project. If there are better alternatives, let me know. regards Oliver -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
I disagree with this proposal both in spirit and in practice. We all know satoshi was the best programmer like no one ever was. Clearly he intended this monetary supply from the beginning, who are we but mere mortals to go against satoshi's will? Also, should we really do this with a soft fork when we can take this opportunity to redesign the whole system with a hard fork? This is out chance to switch to a whole new script engine! Matt On April 1, 2014 3:00:07 PM EDT, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! Thanks, -- Pieter -- ___ 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] Finite monetary supply for Bitcoin
I move to reclaim bip 42 as reserved for a bip containing either a reference to musical dolphins or towels in the name. Matt On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote: In case there are no further objections (excluding from people who disagree with me), I'd like to request a BIP number for this. Any number is fine, I guess, as long as it's finite. With ten people commenting on this proposal there are quite a few ways in which you could partition their views. Only one possible integer partitioning has everyone in the same partition, so consensus seems unlikely. But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal. -- ___ 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] Dedicated server for bitcoin.org, your thoughts?
We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. Jeremy Spilman jer...@taplink.co wrote: I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands. One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid. This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting... For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file. You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash. This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly released, if that's really a problem. I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgrade Formalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions. For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet. On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote: The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress. Oh, it did? When was that? I must have missed this excitement :) Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier. Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space
I'm not sure where you got the idea that Bitcoin-development was ideal for hiring scamcoin developers, but it's not. Most of the people on this list are smart enough to realize posts like this are dumb ideas backed by greedy entrepreneurs who don't understand the system they're trying to improve 99.9% of the time. Evan Duffield eduffiel...@gmail.com wrote: Hello, We’re a startup looking for 1 or 2 really good C++ programmer that is familiar with the bitcoin internals to help with a for-profit startup. We will be able to provide more information about the project after signing a non-compete/non-disclosure agreement. Our coin will be one of the truly unique coins that are not just a clone of the original Bitcoin code. In short the project will be a merge-mined altcoin that will provide a very useful service to the whole crypto-coin ecosystem. If you have added any features to Bitcoin or related technologies this is a definite bonus. Please include information about the work you’re done in the space. We have detailed plans on how to implement it and the roles we are looking to fill. If interested please email eduffiel...@gmail.com with a description of your work experience and we’ll vett the applications and share our plans to see if you’re interested. Thanks, Evan Kyle Hawk Financial Group, LLC -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
An attacker with some small hashpower isolates you (as an individual) from the network by MITMing your network. You just switch the the attackers chain as if nothing happened because of the network rule that defines it as OK. Today, you will see that you're behind and warn the user. Was it really so hard to write a three-sentence paragraph to clarify the attack instead of insulting people? Still, posting ideas here without spending time to ensure you understand the Bitcoin network well is frowned upon. Matt On 12/23/13 17:51, Ryan Carboni wrote: I think you misunderstood my statement. If time 3 days, and after 4 blocks have been mined, then difficulty would be reset. In theory, one would have to isolate roughly one percent of the Bitcoin network's hashing power to do so. Which would indicate an attack by a state actor as opposed to anything else. Arguably, the safest way to run Bitcoin is through a proprietary dial-up network. On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach m...@monetize.io mailto:m...@monetize.io wrote: Ryan, these sort of adjustments introduce security risks. If you were isolated from the main chain by a low-hashpower attacker, how would you know? They'd need just three days without you noticing that network block generation has stalled - maybe they wait for a long weekend - then after that the block rate is normal but completely controlled by the attacker (and isolated from mainnet). There are fast acting alternative difficulty adjustment algorithms being explored by some alts, such as the 9-block interval, 144-block window, Parks-McClellan FIR filter used by Freicoin to recover from just such a mining bubble. If it were to happen to bitcoin, there would be sophisticated alternative to turn to, and enough time to make the change. On 12/22/2013 07:10 PM, Ryan Carboni wrote: I think Bitcoin should have a sanity check: after three days if only four blocks have been mined, difficulty should be adjusted downwards. This might become important in the near future. I project a Bitcoin mining bubble. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Who or what is /Satoshi:0.8.99/Gangnam Style:2.1/ ?
No, mine identifies as BitcoinJ, RelayNode, version string On 11/21/2013 10:27 AM, Jeff Garzik wrote: Is that Matt's relay, which has reduced validity checking? On Thu, Nov 21, 2013 at 8:48 AM, Mike Hearn m...@plan99.net wrote: I added some additional logging to my node and ran it for a few days. There's a pull req open for my extra logging, it is quite trivial. Here's what it looks like: 2013-11-21 13:41:04 AcceptToMemoryPool: 5.9.24.81:7834 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 2d1bbcc2bf64dfcb57a2f0180b2607a48a34de4422c446929b26b190083bbfe7 (poolsz 2087) 2013-11-21 13:41:05 AcceptToMemoryPool: 198.12.127.2:29057 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 28bb94978bdaa224faeafa95d03a0c4f5743396d6f592469c5ac2b64184ac716 (poolsz 2088) 2013-11-21 13:41:06 ERROR: AcceptToMemoryPool : nonstandard transaction: dust 2013-11-21 13:41:06 42323d9553e4c592d27765dc3ef9152c186cb7d67b08d783d72974a56085032d from 82.68.68.254:39232 /Satoshi:0.8.1/ was not accepted into the memory pool: dust 2013-11-21 13:41:06 AcceptToMemoryPool: 198.12.127.2:29057 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 2fdb19e5e87d518b7b6bb7371d547a5f60c2bb056ba4522190460f0bc41b51fb (poolsz 2089) 2013-11-21 13:41:08 AcceptToMemoryPool: 5.9.24.81:7834 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 52c8ed6a48f89d48b1152b67ac0b718a7aadb5f9a0c70c18b9b2fed058ca3323 (poolsz 2090) 2013-11-21 13:41:08 AcceptToMemoryPool: 198.12.127.2:29057 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 980bbdbd4a6b365fa6f13fb5247eb6cb1e54847e490c3b7c3026d1548fb9efc6 (poolsz 2091) 2013-11-21 13:41:08 AcceptToMemoryPool: 64.120.253.194:60896 /Satoshi:0.8.99/Gangnam Style:2.0/ : accepted 03f79c611bbdc1afa7afa67eb0bbd4d8bc86a730a7066622e2709ae506e61e0f (poolsz 2092) 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted af8096ad637af1ca022a5146e07cf1fc6bfbec877935f9e114b279fcfe26c06d (poolsz 2093) 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834 /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted 751c2415d058d45ca602fdf1b6490edb6e57fc718e914d628c11b17e25aac834 (poolsz 2094) Despite that I have 87 connections from regular nodes, virtually all transactions seen by my node are being announced by this modified software, which appears to run on several different machines. I am wondering if anyone out there knows/owns these nodes and if they are relaying transactions without checking their validity. That seems the most likely reason for how they are always able to win the race to be the first to announce to my node. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
On 11/08/13 06:46, Mike Hearn wrote:
I took a brief look at the code - it's looking very reasonable. You can
replace any construct like
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
which is quite verbose, just with
Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and
of course static imports help too)
Thanks, fixed.
I think for this concept to take off, you'd need a website and to
recruit someone to help you market it. Pool operators won't reach out to
you.
Yes, I've done some initial outreach and plan on doing another major
round now that the initial network is up and Im working on running some
relay time benchmarks. Finding someone to help push peering would be
nice, if you have any suggestions, Im all ears.
I still find it perhaps more elegant to just boost the connectivity of
the existing network with bitcoind changes, but this can help for now.
Agreed, improving relay times across the regular P2P network would be
nice, however I really dont see this as a part of the P2P network. Its
more of a backup relay network that just happens to follow the P2P
protocol (mostly, it doesnt do full block verification, so technically
it breaks spec). In this model, this is really a nice augment to the P2P
network no matter what improvements are made. Having more protocols/ways
blocks are relayed is always nice (anyone wanna launch a satellite?)
Matt
--
DreamFactory - Open Source REST JSON Services for HTML5 Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
In the short-term, maybe. Keep in mind that the code for tx relay is fairly different and the bandwidth for transaction relay on these nodes is already lower than it is for blocks (by design). That said, I'd like to look into doing tx-less block relays for transactions that peers already have to limit block relay times even for large blocks, in which case tx relay is very much required. Matt On 11/13/13 15:13, John Dillon wrote: You should split the block-only and block+tx not only by port number, but also by DNS address. DoS attack by flooding blocks is fundamentally more difficult than DoS attack by flooding transctions, so doing the split by IP address ensures that in the event of an attack the more important block relaying functionality is less likely to be damaged. In the meantime point both DNS addresses to the same IP until it becomes an issue. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin network on IRC and elsewhere (1). To this extent, I'm organizing a system of peering between nodes in the network by creating a system of high-speed relay nodes for miners and merchants/exchanges. This system will a) act as a fallback in the case that the public Bitcoin network encounters issues and b) decrease block propagation times between miners. It is NOT designed to in any way replace or decrease the need for the public Bitcoin P2P network. It is NOT any kind of attempt at centralization, and I still encourage interested parties to establish their own private peering agreements with large miners as needed. Currently the network consists of one specially-designed relay node, but I hope to bring more online in the coming days. This network is open to everyone via a few public relay nodes, but also will have nodes which are made available only to large miners and merchants/exchanges to mitigate the ability of malicious parties to DoS the network. To peer with the public relay nodes, simply select the closest region out of us-west (West Coast US), us-east (East Coast US), eu (Western Europe), au (Australia), or jpy (Japan) and add public.REGION.relay.mattcorallo.com to your addnode list. Note that since all of the relay nodes will relay between each other, you gain no latency advantage by peering with more than the closest node to you (and currently all the regions map to one node, so there they're redundant anyway). For each relay node, you can connect to either port 8334 or 8335. Connecting on port 8334 will relay only blocks, and port 8335 will relay both blocks and transactions. The relay nodes will request any transactions which appear in your invs no matter which port you connect to. Relay node details: * The relay nodes do some data verification to prevent DoS, but in order to keep relay fast, they do not fully verify the data they are relaying, thus YOU SHOULD NEVER mine a block building on top of a relayed block without fully checking it with your own bitcoin validator (as you would any other block relayed from the P2P network). * The relay nodes do not follow the standard inv-getdata-tx/block flow, but instead relay transactions/blocks immediately after they have done their cursory verification. They do keep some track of whether or not your nodes claim to have seen the transactions/blocks before relaying, but you may see transactions/blocks being sent which you already have and have not requested, if this is a problem for you due to bandwith issues, you should reconsider your bandwith constraints and/or are peering with too many nodes. * The relay nodes will all relay among themselves very quickly, so there is no advantage to peering with as many relay nodes as you can find, in fact, the increased incoming bandwidth during block relay spikes may result in higher latency for your nodes. * The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. Additionally, because the relay nodes do not respond to standard getdata requests, if you miss a relay and then reconnect, that data will not be sent again by the relay nodes. The relay nodes are NOT a replacement for having peers on the standard P2P network, they are only there to augment the existing P2P network. If you are a merchant/exchange/large miner/other important node operator and wish to gain access to additional domain names which map to relay nodes with fewer peers, please fill out the form at https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform You can find the source for the relay nodes at https://github.com/TheBlueMatt/RelayNode If you have any comments/concerns/suggestions, please do not hesitate to email bitcoin-peer...@mattcorallo.com Thanks, Matt (1) There has been extended discussion on #bitcoin-wizards as well as #bitcoin-dev of the very small number of active, listening nodes. Additionally, because many of those nodes are versions prior to 0.8.4, it seems very likely that maliciously creating network splits or at least drastically reducing the number of peers for most nodes would not be particularly challenging in the current network. Also, http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf noted that they were able to single-handledly decrease the network-wide orphan rate by around 50% by improving network peering. Finally, you've all seen the recent discussion on malicious mining algorithms. Though those are not entirely prevented by reducing block propagation times, they can be significantly limited compared to the current, rather disjoint, network. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error
Re: [Bitcoin-development] More appropriate XDG menu category for bitcoin-qt
(Finally) got around to this, sorry for the delay. 0.8.5 has the new category and pull request is at https://github.com/bitcoin/bitcoin/pull/2999 Matt On Fri, 2013-08-02 at 12:08 -0700, Kip Warner wrote: Hey list, Currently the bitcoin-qt application's XDG desktop integration on some desktop environments requests that it be placed under the Office menu category.[1] This is a rather broad category and I would like to suggest that this be refined further into Finance, given that XDG's menu specification allows for this.[2] I believe the line in question in bitcoin-qt.desktop should be as follows: Categories=Office;Finance; I would have provided this trivial patch myself, but my knowledge of Git is rather weak and I apologize. Respectfully, [1] https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/bitcoin-qt.desktop [2] http://standards.freedesktop.org/menu-spec/latest/apas02.html -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
I really beg to differ on this one. If you're an Ubuntu user who is behind only one distro (quantal) you're stuck on version 0.6.2 with no updates since 2012 (yes, that means on May 15th you'll be lost). For those still on Debian Squeeze (ie barely out of date), you get 0.3.24! Yes, 0.3.24 including every issue we've fixed since (https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures) and bitcoin is not available in wheezy. Those are just the two I bothered to look up, but, additionally, nearly every distro I know of links bitcoin against libdb5.1 (latest Ubuntu, Arch, etc) which means wallets run once with those packages will never be usable an official Bitcoin build ever again. I can't necessarily fault them for this since 4.8 is quite old, but its certainly not doing mostly a pretty good job Matt On Mon, 2013-05-06 at 23:48 -0500, Petr Praus wrote: I think it's worth noting that quite a large portion of Linux users probably get the mainline Bitcoin client from the packages. I think Bitcoin package maintainers are doing mostly a pretty good job :) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [RFC] Fees/Minimum Priorities based on Mempool and Memory-Limited Mempool
I hacked together a new min fee/prio calculator and memory-limited mempool a while back and figured Id post the code here to get some comments. Its more of a discussion-starter than a strict proposal and has a few obvious holes (hence posting here instead of pull-requesting). It works as such (note that all constants are really place-holders, so please recommend reasonable constants): 1) Watches when transactions enter mempool and calculates minimum fee/priority based on a fairly dumb algorithm... It finds the highest FEE_POLICY_TOP_N_TX (10) fee/prio transactions in mempool that have been in mempool at least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks and averages together their fee/prio then multiplies by FEE_POLICY_FACTOR (1.1). 2) It limits mempool size to a default of 10*MAX_BLOCK_SIZE (bringing it down to 9*MAX_BLOCK_SIZE each time it has to throw out transaction). When transactions are throw out, it keeps 2/9 of the mempool size in highest-prio transactions and 7/9 of the mempool in highest-fee transactions. 3) Any transactions which have a fee lower than the lowest-fee transaction thrown out of the mempool and a priority lower than the lowest-priority transaction thrown out of the mempool will not be accepted into the mempool at all. Obvious bugs: 1) It doesnt yet do anything for minimum fee/prio when it hasnt seen at least FEE_POLICY_TOP_N_TX (10) transactions sitting in mempool for at least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks (ie hasnt been running for 6 blocks or blocks are being filled completely). The likely way to address this is to look at previous blocks and find the lowest fee/prio transactions included in them. 2) It will relay all transactions until the mempool has filled up (or if the mempool never fills). Something should be done initially to limit DoS potential. Code is at https://github.com/TheBlueMatt/bitcoin/commits/fees Matt -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Integration testing for BitCoin
These tests are run on each pull requests and on each new commit to master. They arent very complete, but they do test a lot of block acceptance rules. https://github.com/TheBlueMatt/test-scripts Matt On Fri, 2013-04-05 at 12:24 -0500, Adam Ritter wrote: Hey guys, I just bought some BitCoins after being lazy to do it for the last few years, but also looked at the client code and the messages that are going on this mailing list. I saw that there are quite some unit tests, but I didn't find integration test for BitCoin, and I believe that it's quite important for the future of BitCoin (making the current code more stable, testing attack scenarios, refactoring and extending code). I have wrote some integration tests before at other projects, and they usually turned out useful, but I have 0 experience with the BitCoin development and codebase. I wrote a short document of what I think would be the safest way to do the testing (but not yet the tests themselves, as I don't have enough experience..I'd like to have something like testing that the wallets are empty, and after somebody mines she'll have more money..after she sends money to the other person, the other person will see it...things like this, just to get to know the code base). What do you guys think? The plan is here: https://github.com/xiphias/bitcoin/blob/master/src/test/integration/README.md Please feel free to comment/fork, I'll try to write all your replies in the document as well. Also here's the text to make it easier to comment: Integration testing for bitcoin Tests that simulate multiple bitcoin users and can verify that the whole network of bitcoin clients work together to achieve the goals of Bitcoin. Also maybe [System testing](http://en.wikipedia.org/wiki/System_testing) would be a better name for the tests, but I'm not sure. Goals - - Make the bitcoin code easier to refactor while increasing the guarantee that it doesn't break the overall behaviour of the client. - Make it easier to have multiple experimental coins (for example LightCoin or PPCoin) in the codebase, while guaranteeing that the original BitCoin protocol doesn't break - Make it easy to test attack scenarios (like DOS, releasing an incompatible BitCoin client), monitoring - Have tests without (or at least minimal number of) unreadable constants and unreadable fake data to make them easier to verify. Proposed implementation The first implementation should use the JSON-RPC interface and build up as much verification of BitCoin network as possible. It should be in C++, which makes it easier to move to the second implementation. The JSON-RPC calls should be hidden by a C++ interface. The second implementation should use the same interface that was used for JSON-RPC, but using the BitCoin code directly (while not breaking the JSON-RPC tests). For this the BitCoin client has to be refactored as a library, getting rid of all global variables (and having them in a data structure), so that multiple BitCoin clients can be run in the same process. The improvement of the second implementation should have dependency injection for the time and for finding/verifying a mined block, so that the tests don't need to use real CPU power for mining, and they can run faster and test more complex scenarios. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
Actually, there is one more minor algorithmic change I would like to make to the way the hash function is computed really quick before it gets merged, I'll have that finished up by the end of today. Matt On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote: Matts latest code has been tested by Andreas and seems to work correctly. He had to extend the client a bit to refresh the filter every 25k blocks because even with the extra flag, eventually the filter degrades into uselessness, but it did still improve the situation quite a bit. Because it's unit tested, been reviewed by me several times, has an interoperable implementation that has also been tested by Andreas in a build of his smartphone app, I'm going to ACK the current code and request that it be merged in to 0.8. What do you say Gavin? The next step after that would be profiling. It's a big performance improvement for SPV clients already, but not as much as I anticipated. I suspect there's a simple bottleneck or missed optimization somewhere. But that can obviously come post-0.8 -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Thu, 2013-01-10 at 16:21 +0100, Mike Hearn wrote: Here's a quick update on where we're up to. Thanks to Matts excellent work, I was able to test his bitcoinj and bitcoin-qt work together today. There are a few minor tweaks needed, but I feel like we're maybe a week away from having all the code in a mergeable state. Here is the remaining work: - There are a couple of bugfixes needed on the bitcoinj side: the fallback to downloading full blocks is problematic and needs to be deleted, there's an API change we want First of the two is done. - Adjust the default FP rate requested by BCJ to be 0.0001, this is appropriate for the latest blocks in the chain and yields 0-5 false positives per block Is a part of the larger API changes mentioned above. - Introduce a new part to the filter protocol that allows clients to control auto-expansion. This turned out to be very volatile, we saw jumps from 0-3 FPs per block to 500 in the space of 1 block, perhaps if a SatoshiDice transaction got into the filter. A simple yes/no flag can suffice for now, but a better solution would be for the client to submit templates for output scripts that would trigger auto-adding the matched outpoint - autoexpansion is only needed in the case where the input script doesn't contain any predictable data. For pay-to-address and P2SH it does, so expansion doesn't help. Matt said he'd hopefully try to look at this soon. The flags mentioned have been implemented, both to disable autoexpansion, enable it for all outputs, enable for only pay to pubkey outputs (the most likely use-case), or use a set of templates. The matched templates part isn't properly tested and I would like comments on that part (see the last few commits at https://github.com/bitcoin/bitcoin/pull/1795). With auto-expansion disabled, the FP rate adjusted and a bugfix on the bcj side I was able to sync a wallet using a bloom filtered chain. Although it's tight, I think this work should go into 0.8 - it'll be much more compelling to advertise it this way, we can say Upgrade to 0.8 and help network performance for everyone. And in the case that we discover a showstopper problem, we just don't deploy the code that uses the new messages into clients. Ive been missing lately, when is 0.8 targeted for freeze? Matt -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote: On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote: I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt. https://en.bitcoin.it/wiki/BIP_0037 Two comments I made on the pullreq page, which are probably better discussed here: * The 0x/(n-1)*i seed value seems intended to result in large bit differences between the different hash function's seeds. Together with the tweak, however, the first and the last now get seeds tweak and tweak-1. I think something simpler like k1*i+k2*n+tweak is better (with k1 and k2 arbitrary large odd 32-bit integers). Meh, sure, whatever...I dont really think the seed values matter significantly (Murmur3 isnt that bad of a hash function...) (and the original algorithm wont result in a significant bit difference between the seeds in many cases). * I feel uneasy about the arbitrary filter parameters used for the implicitly created filter when sending filteradd without filterload. The server cannot be expected to make a reasonable guess how the client is going to use the filter, and the client still has to track how large the server-side filter grows anyway. I'd prefer to make this simply illegal (DoS 100): filteradd always requires an active filter. I think there is some consensus here, and I have no problem doing it this way (in large part, filteradd should not be used at all). Maybe the actual filter data in filterload can be made optional: if it is omitted, it's assumed to be all zeroes (though that would mean the size has to be specified). I'm not sure here, if you are sending a filter just to use filteradd to add things to it manually, you are doing something very, very, very wrong... Though we could certainly do some kind of compressed bloom filter encoding to allow for small filter loads (loading the few things you need to filteradd right away) where you anticipate adding significantly more filter elements down the road (can anyone even come up with a case where you anticipate doing this?), the filter is small enough (max 36kB) that I see little benefit for the large increase in complexity (or is this another repeat of the merkle branch discussion?) Matt -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Draft BIP for Bloom filtering
On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen wrote: RE: sharing parts of the merkle branches when returning a 'merkleblock' : I think I agree that complicating the BIP for what should be a very rare case (more than a handful of transactions in a block match the transactions in your wallet) is the right decision. I believe you meant NOT complicating? I want to make sure I'm understanding this bit correctly: In addition, because a merkleblock message contains only a list of transaction hashes, any transactions that the requesting node hasn't either received or announced with an inv will be automatically sent as well. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Requiring serving/relaying nodes to keep track of which transactions they have or have not sent to their peers makes me nervous. I think requiring an extra 'inv' round-trip would be simpler to implement and less likely to lead to some kind of DoS attack. Sadly that requires (potentially) more DoS potential because you require nodes to store each transaction that could be requested instead of just going ahead and forwarding them. I agree the BIP should not specify that the sending node is required to keep track of which transactions have been announced/sent to clients, however since the reference client does so currently, that implementation is significantly simpler (note that it is a bounded set in the reference client, so even the reference client doesn't really fully comply with the BIP as stated here). Matt -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
Although Jenkins may not be the best system, we already have jenkins and pull-tester (which is a dumb python script I wrote to test all incoming pull requests from github). They both run the same set of scripts, namely those at https://github.com/TheBlueMatt/test-scripts (its pretty basic right now, but since it is on github, I was hoping someone would find the inspiration to add to it). I dont really care if we keep using jenkins, but I figure we might as well keep all the tests in one place? Anyway, I'm all for more testing (I'm always complaining about how we need more tests for stuff...). Matt On Tue, 2012-09-25 at 19:32 +0100, steve wrote: Hi All, After the failure to get any real testing done for the 0.7 release (all of which is my fault) I have decided to rejig things. I am heavily into test driven development, and I have a strong background in requirements management, and automation. I want to leave bettermeans behind, maybe we might be able to keep the voting aspect of it, and link it into mantis. So, what I have been doing over the past few weeks is developing a rudimentary requirements set, basic requirement tracking, tests to prove/stress the requirements. The next most important thing is to get release/acceptance tests done - these primarily focus on new stuff doesnt break old (ie lose a wallet, etc) and needs no special requirements. To this end I have installed various opensource applications (mantis, salomeTMF, bugzilla, etc) and am currently evaluating the best workflow process. This was a much longer post, but decided against it. :) So, what I want to know is who wants to be a part helping me out with all this? I am finalising the workflow flow diagrams and they should be ready for inspection soon. Anyone interested in helping out/reviewing processes? even if it is just some encouragement, it is all greatly appreciated. Drop me an email if you want access to the current setup and help me review the different software for the bitcoin workflow process. cheers, steve -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
It seems to me the whole idea of segmenting blocks would add very little (to nothing) with any sane block size. Sure, if a block were to be 10GB, it may make sense. However, even in that case, it would be easier to relay a list of tx hashes (which may be a bit expensive) and txes separately instead of using a notion of block segments. That said, I don't see blocks ever being that large and if they do become that large, as only a few full nodes will remain, upgrading their protocol would be (relatively) easy. I would instead encourage focus on decreasing block relay times for the current network and as blocks approach 10MB (so that they can approach 10MB). Matt On Mon, 2012-09-10 at 20:34 +0100, Matthew Mitchell wrote: Do you mean getdata? Here is the reason for the 6 new messages: getseginv,seginv - These are for learning about what segments of a block a node has. Else you could remove these messages and simply have nodes advertise blocks via inventory messages. In this case nodes would have to wait until they had fully received a block before relaying anything. No longer is there a benefit with nodes being able to relay segments of blocks before they have received the entire block. gettreelevel,treelevel - These are to received a level of the merle tree. Instead you might use get data but gettreelevel is more compact than get data and is clearly differentiates itself as part of the new protocol. Perhaps these messages could include the block headers alongside the hashes and you could request many at once like with the getheaders message? If you skip these messages, then you could verify the transactions at the end but there would be problems when peers give bad segments where data would need to be downloaded again. getsegment,segment - These are clearly important to request and receive segments for the blocks. These allows for nodes to download arbitrary segments of blocks. The optimum number of segments could be calculated by node software using measurements of download speeds and latency times, the number of connections and how likely redundancy is to occur. If a node is up-to-date and likely has many of the transactions in blocks, it can start asking for the deepest merle level (tx hashes) and ask nodes for segments, avoiding transactions it already has. I'll get around to doing measurements myself sometime to estimate the benefit of this proposal. It will certainly be beneficial when block sizes reach some size but not much is really known except what can be assumed/guessed. I should also mention the bitcointalk topic here: https://bitcointalk.org/index.php?topic=103295.0 On 10 Sep 2012, at 19:59, Luke-Jr l...@dashjr.org wrote: Most of the problem with block propagation lies in implementation, not protocol... Distributing missing transaction on an as-needed basis is a possible improvement at the protocol level, but there hasn't (AFAIK) been any research into whether the little benefit outweighs the cost yet. In any case, I don't see why 6 new messages are needed instead of simply adding a single new type to getinv? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bloom Filter Implementation
I spend some time implementing some of the changes discussed in the previous thread New P2P commands for diagnostics, SPV clients, and wanted to field comments before I write up a BIP. I have implemented a simple bloom filter that works on transactions as well as a new block relay type which relays blocks as header+coinbase tx +vectortx hash which allows for faster relay for clients which already have transactions in memory pool. In order to request that all future MSG_TX inv messages and blocks (only those relayed in the new format) are filtered, SPV clients will send a filterload message with a serialized bloom filter. Nodes can also send filteradd messages which add particular data blocks to the filter (not recommended for anonymity) and call filterclear which disables filtering on a node's connection until re-enabled. The filter will match any tx which: 1. Has a script data element in either a scriptPubKey or scriptSig which matches the filter. 2. Spends an input who's COutPoint is in the filter. 3. Has a hash in the filter (see #4 for why this matters). 4. Has a script data element in a prevout's scriptPubKey. This allows for matching pay-to-pubkey transactions without sending a new filter after each transaction which matched (which would cause some nasty timing issues where you may miss transactions if you get transactions back-to-back before you can send a new filter). Matching of prevouts only occurs on free txes, not those in blocks. Thus, before requesting a block, SPV clients should update the remote node's filter, if required, to be sure it includes the hash of any transaction which would not otherwise match the filter so that the node knows when its transactions are included in blocks. I can't say I'm a big fan of requiring SPV nodes constantly update the filter when they learn about new transactions (could get nasty during IDB, if the node has a lot of transactions, as you could end up re-requesting blocks many times), but I really don't think its worth loading all prevouts when a node is in IBD to fix it. The branch can be found at https://github.com/TheBlueMatt/bitcoin/compare/master...bloom Matt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
On Sun, 2012-07-29 at 20:52 -0400, Gavin Andresen wrote: Is there interest to port more tests (P2SH, checksig, checkmultisig, block verification, maybe even DoS rules) into data-driven format? It might be something that I'd like to help with if pull requests in that direction are welcome. Yes, more tests are definitely welcome. check*sig tests are tricky, because they have to refer to previous unspent transactions and private keys (so require a particular block chain to test against). Brilliant ideas on a simple data-driven format welcome. block verification tests would be great; a collection of good/bad block chains, starting from a common chain (maybe the testnet3 tesnet-in-a-box chain) would be very useful for regression testing. I wrote a simple block chain tester (that is capable of forking, checking invalid blocks, etc) as a part of the bitcoinj test suite. Its more targeted at testing bitcoinj directly and keeping the bitcoinj test suite light weight, so if it were to be more generic some tweaks could be done (not requiring tweaking the minimum difficulty/genesis block hash/etc would be first). It doesn't have that many test cases yet, but it is capable of sanity-testing reorgs/etc. Its mostly the first two commits listed at http://code.google.com/r/bluemattme-bitcoinj/source/list?name=fullverif Matt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase script parse failures
I mentioned this on IRC a week or so ago, noticing that though they are not executed and required to be well-formed, we still count any sigops that appear in them (which I guessed may be an interesting attack if you could get a miner to put a byte in there that is the equivalent of OP_CHECKSIG because we dont count the sigops in the coinbase scriptSig during mining, however luke pointed out that we always push the content of coinbase scriptSigs properly by default, and those modifying the code should spend time researching this stuff anyway, so if they break it, its their fault (and now they can find this email)). Matt On Mon, 2012-07-23 at 02:07 -0400, Jeff Garzik wrote: While writing the script engine for pynode, I ran a test to validate my script tokenizer -- a python script which does nothing more than split up scriptPubKey and scriptSig into component opcodes and data elements. No execution, just tokenization of the script's data stream. Scanning the entire blockchain, my script found over 8,000 tokenization failures, and 100% of those were in coinbase transactions' scriptSig. The scripts used to generate this can be found at https://github.com/jgarzik/pynode The following data dump are just the first few, and most recent few, of the invalid scripts I found in the blockchain: Scanning block #142312 046acff93b0e76cd10490551bf871ce9ac9fad62e67a0 7ff1d1e (1 tx) TX 50cfd3361f7162b3c0c00dacd3d0e4ddf61e8ec0c51bfa54c4ca0e61876810a9 txin 0 parse failed Scanning block #142357 0743c432f84ad688b7b60d1474ccd7baa3d762df0b3f5 1205712 (1 tx) TX 587da4d4870515e57efc27623aa92fae0b7aef5908162de57fef0bbe6382be73 txin 0 parse failed Scanning block #143014 07fe6ecd20a8c454cd43c78d912b499c46a1179e30f7c ff002b3 (1 tx) TX 4c8f43c5115c5f29f3761176fa59cde2de2ad976efcbc5faae8ee79fa5dd6264 txin 0 parse failed ... Scanning block #190315 06a0bc3be527033c02d3bcfa72af2f4213c4b0feec923 9573342 (336 tx) TX f0ba80ce080eb49148b69c47d744bbb85e4e07e4e4d0273b402c0989d79c359c txin 0 parse failed Scanning block #190321 01c3bacc869917cacdafb6e00c552ac294835107b574a 44a0362 (38 tx) TX 4c91f5ad0616df92165819902d0b117d9e68345f5fe964de6146f89838b9295e txin 0 parse failed Scanning block #190331 00e3d3eaf93600684b085df7d58f84ef952c91e84eb4a 251d5d8 (128 tx) TX 5ee371d65e323934570566b1d92dceb8456e887814da8ef2a53971683bd11da4 txin 0 parse failed -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Mon, 2012-07-23 at 09:54 +0200, Andreas Petersson wrote: Some concerns regarding Bloom Filters. I talked with Stefan Thomas on the Hackathon Berlin about this. I tried to follow the discussion closely but i have not taken a look at the code yet (is there already an implementation?) so please correct me if i got something wrong. AFAIK there was no implementation. I pushed one for bitcoinj+bitcoind today that compiles, but I haven't tested it much further (though its really quite a simple implementation): https://github.com/TheBlueMatt/bitcoin/commits/bloom http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter The way the Bloom filters are planned now this requires a complicated setup. basically the client will ask the server to replay the whole blockchain, but filtered. This is not optimal for the following reasons: This will require the server to do a full scan of his data and only filter out non-matching entries. My implementation has yet to implement block filtering, for now its only tx inv filtering. However, its really not that complicated and doing a scan of any individual transaction is very fast. So during the download phase, it really isn't much of any extra load on block chain providers (aside from having to load inputs in the current implementation, but that could be optimized some). Really lightweight clients (like Bitcoincard), clients with shared private keys (electrum-style), or brainwallets - will ask the following question quite often to supernodes: Given my public keys/addresses, what is the list of unspent outputs. i think it would make sense to include such a command, instead or in addition to the filterload/filterinit. And perhaps more severe: as far as i understand classic bloom filters, the server has no method of indexing his data for the expected requests. There is simply no data structure (or maybe it has to be invented) which allows the use of an index for queries by bloom filters of *varying length* and a generic hashing method. im not sure what a really efficient data structure for these kinds of query is. but i think it should be possible to find a good compromise between query flexibility, server load, client privacy. one possible scheme, looks like this: the client takes his list of addesses he is interested in. he hashes all of them to a fixed-length bit array (bloom filter) of length 64KiB (for example), and combines them with | to add more 1's with each address. the server maintains a binary tree data structure of unspent outputs arranged by the Bloom filter bits. to build the tree, the server would need to calculate the 64KiB bits for each address and arrange them in a binary tree. that way he can easily traverse the tree for a given bloom query. if a client whishes to query more broadly he can calculate the bloom filter to 64KiB and after that fill up the last 50% of the Bits with 1. or 95%. the trailing 1 bits even don't need to be transmitted to the server when a client is querying. of course, if the client is more privacy-concerned he could also fill up random bits with 1, which would not change much actually. the value of 64KiB is just out of thin air. according to my experimentation using BloomFilter from Guava - currently, also 8KiB would be sufficient to hava a 3% false positive rate for the 4 active addresses we have right now. someone more familiar with hashing should please give his opinion if cutting a bloom filter in half has any bad consequences. Andreas Though I like the idea of having a give me all unspent outputs for my pubkeys command, I see quite a future for clients somewhere between I store nothing but pubkeys and don't know about the chain and I store a full chain and the bloom filters as described are pretty useful for many clients in that in between. Also, for clients that are Really lightweight clients (given that they don't know about the chain) should probably just stick with an electrum-style server-client system with specialized servers (IMHO) instead of relying on P2P nodes to provide them with a list of unspent outputs/etc. In response to Mike's what-the-filter-should-match: The way it is now, it just checks each input+output to see if the hash160 of the dest addr, hash160 of the pubkey or hash160 of the p2sh sh matches the filter as-is. From the list provided, I think adding a check to allow adding a specific outpoint to a filter would be nice. However, in terms of data elements in txes, Im not so sure. Its by no means a bad idea, and it wouldnt be too much overhead, but making filters match a very broad set of criteria seems like a bit much to me, but maybe others disagree? Matt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond.
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote: filterinit(false positive rate, number of elements): initialize filterload(data): input a serialized bloom filter table metadata and data. Why not combine these two? I believe its because it allows the node which will have to use the bloom filter to scan transactions to chose how much effort it wants to put into each transaction on behalf of the SPV client. Though its generally a small amount of CPU time/memory, if we end up with a drastic split between SPV nodes and only a few large network nodes, those nodes may wish to limit the CPU/memory usage each node is allowed to use, which may be important if you are serving 1000 SPV peers. It offers a sort of negotiation between SPV client and full node instead of letting the client specify it outright. 'filterload' and 'filteradd' enable special behavior changes for 'mempool' and existing P2P commands, whereby only transactions matching the bloom filter will be announced to the connection, and only matching transactions will be sent inside serialized blocks. Need to specify the format of how these arrive. It means that when a new block is found instead of inv-getdata-block we'd see something like inv-getdata-merkleblock where a merkleblock structure is a header + list of transactions + list of merkle branches linking them to the root. I think CMerkleTx already knows how to serialize this, but it redundantly includes the block hash which would not be necessary for a merkleblock message. A series of CMerkleTx's might also end up redundantly encoding branches of the merkle tree, so, yes as a part of the BIP/implementation, I would say we probably want a CFilteredBlock or similar -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote: Why not combine these two? I believe its because it allows the node which will have to use the bloom filter to scan transactions to chose how much effort it wants to put into each transaction on behalf of the SPV client. If that's the case then the negotiation protocol needs to be specified too. It seems heavy though. If a node is getting overloaded it could just disconnect intensive peers or refuse new connections. IMHO it already is. A node requests a filter using filterinit by specifying the false positive rate it wants and a guessed number of items. The node which will have to hold that filter then responds with the closest filter to what the SPV node requested that it is willing to provide. If the SPV node responds with a filterload command, it has accepted the offer, otherwise it will simply disconnect and find a better full node. I'd much rather have an overloaded node respond with 50% fp rate filters as an option if there aren't many full nodes available than simply disconnect SPV clients. At least thats my thinking, but you may be right that it is too heavy for too little gain. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote: Yes, the format is something that must be hashed out (no pun intended). Need input from potential users about what information they might need. Matts point that a branch-per-transaction may duplicate data is well made, that said, I suspect a format that tries to fix this would be much more complicated. How about see this project as a three part change? First step - add the mempool command and make nodes sync up their mempools on startup. ACK Second step - if protocol version = X, the block message consists of a header + num transactions + vectorhash instead of the full transactions themselves. If vectorhash is sorted in the order of the merkle tree, you dont need to forward the merkle tree to non-filtered nodes, further saving some small amount of bandwidth. For filtered nodes, you would still need to forward merkle branches anyway. On receiving such a block, we go look to see which transactions we're missing from the mempool and request them with getdata. Each time we receive a tx message we check to see if it was one we were missing from a block. Once all transactions in the block message are in memory, we go ahead and assemble the block, then verify as per normal. This should speed up block propagation. Miners have an incentive to upgrade because it should reduce wasted work. ACK Third step - new message, getmerkletx takes a vectorhash and returns a merkletx message: merkle branch missing the root + transaction data itself for each requested transaction. The filtering commands are added, so the block message now only lists transaction hashes that match the filter which can then be requested with getmerkletx. I really dont think it would be /that/ difficult to make it getmerkletxs vectorhashes. And then respond with a partial merkle tree to those transactions. Matt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Near-term scalability
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote: The idea can be more generalized in that there are many cases where the generator of a transaction doesn't care about confirmation times, and would really be willing to make their transaction lower priority than other 0-fee transactions. Just to be clear, I think this solution is a hack and don't support it because it's yet another change of network rules. Some random people will get whacked because of a heuristic rule of thumb. Its arguably not a change to network rules as its something that users can already do today by patching their clients. Obviously any implementation would have sane defaults which allowed for a significant number of transactions to/from a given address at a time, avoiding whacking random people unless they are large enough that they should really already be fully aware of how bitcoin works. If it's implemented, SD could/would switch to fresh addresses and nothing would have been achieved except making an already complex system more complex. I would think SD would switch to using fresh addresses for each bet. But even that is a good thing, at least where user privacy is concerned. However, I would hope that SD would see the rule tweak and, in order to avoid having to generate a number of new addresses per second (or, if they went the pool route, having a huge pool of many thousands of addresses), they would consider implementing sendmulti support. I disagree with the notion that you need less important than free. If you care about the confirmation time of a transaction that was sent to you and you need space in a limited resource, you can pay for it. It's an auction like any other. Besides, the idea that transactions are free today is just a psychological trick befitting governments but not us - transactions are funded by aggressive hyperinflation. I would never describe Bitcoin as a free system and I suggest nobody else does either. I agree, free transactions isnt something we should aggressively push as a feature of Bitcoin, its simply not. However, in the current system free transactions are usually confirmed within a small number of blocks, and for a number of users, that is an important feature that draws them to get through the initial hurdles of converting money to Bitcoin and understanding enough of the system to trust it. I believe that if we can incentive large transaction creators to avoid delaying free transactions, we should and giving them the option to delay their own transactions seems like a perfectly reasonable way to do so. Even if you drop all the per-address limit stuff, allowing transaction creators to add a simple flag to transactions seems reasonable when they want to encourage Bitcoin to continue to grow as it does today. Obviously keeping free transactions confirming won't be possible forever, but hopefully that will be as a result of natural growth which can encourage further growth without the need for free transactions and not as a result of a few actors in the community creating a transaction volume significantly greater than their user-base. If grouped fee calculations are implemented, we can keep the nice property that the person who cares about double spending risk pays the fees, and if you assume most transactions are hub-and-spoke from buyers to merchants, rather than a pure p2p graph, in practice it'll work out to seeming free most of the time even if seen globally it doesn't make much difference. ACK, thats an important thing to implement IMO, but I really dont see it as something that replaces the option to deprioritize your own transactions to below 0-fee transactions. It could even allow users who receive payouts which are below 0-fee transactions to place a fee on the subsequent transactions to allow the payouts to confirm quicker (if done right). My point was that the easiest way to do it would be to ship a pruned snapshot with Bitcoin, and such a system, while verifiable, would increase Bitocin's centralization. I'm not sure why. If you want to audit everything from scratch, after checking the code you could just blow away the included files and then -connect=archive.bitcoin.org or something like that. After rebuilding the chain from scratch, check the databases for consistency with the included data. I would be surprised if more than a handful of devs audit such a thing. And I would say that does define an increase in centralization. It reduces the number of nodes with full copies of the block chain, yes, but as long as there's at least one copy of the old data in an accessible location new nodes can still bootstrap just fine. Sadly, old nodes do not know where to look for such data, and I'm fairly certain people running old nodes don't read the forums enough to catch when it is announced that old nodes should make sure to -connect=archive.bitcoin.org in order to avoid initially having horrible initial bootstrap times and
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote: As for full nodes... I like the organic growth and random nature of the mempools. On the fence, WRT full node mempool sync at startup. I dont particularly care either way, but I have a feeling miners will really want that so that they can get fee-paying transactions right away. Matt -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding callback hooks to the satoshi client
I spent some time changing the internal bitcoin code to use callback hooks, but its far from complete (or even really usable from anything other than the code in the satoshi client itself, it doesnt even have any deregister methods!). As it sits now, it is likely to get more eyeballs and merged for 0.7. If you need additional specific callbacks, adding them would be cool, though I wouldn't recommend relying on the blockstore API to remain even remotely stable for the foreseeable future. https://github.com/bitcoin/bitcoin/pull/771 Matt On Wed, 2012-03-21 at 22:13 -0700, Eric Lombrozo wrote: Hey, guys. I've been writing a number of apps that require realtime event notifications, where the JSON-RPC API clearly doesn't suffice. There are two approaches I've been taking to this end: 1) Writing my own library for dealing with raw bitcoin structures and connecting to bitcoin nodes via the bitcoin protocol. 2) Making custom builds of the satoshi client putting callback hooks in key points. Neither of these two approaches is ideal. (1) involves a lot of code duplication, (2) involves patching the satoshi client source each time I grab a later version, with the everpresent risk of something breaking and the need to continue maintaining these patches. Moreover, unfortunately many of these key points happen to be in files like main.cpp which see frequent changes. I would like to propose adding these callback hooks to the main branch. I am willing to help locate these key points, reorganize the code to place these methods in separate source files, define a callback mechanism, and contribute source code. -Eric Lombrozo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding a pong message
On Tue, 2012-03-13 at 14:45 -0400, Luke-Jr wrote: On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote: https://github.com/bitcoin/bitcoin/pull/932 adds a pong message that echoes back a 64 bit nonce contained in the ping, if the protocol version is new enough. The goal of this is to make it easier for clients, especially mobile clients, to quickly check if a connection is stale, and also to see if a remote node is overloaded so we can avoid talking to it. A common case where this happens is if the remote node is itself downloading the block chain or doing something equally intensive. Any objections? Not really an objection per se, but what's wrong with TCP keepalives? It wont tell you if the node itself is overloaded (not just the OS' network stack). Looks good to me. Matt -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
I changed the description of the message parameter to be a bit more descriptive, however, I dont want to change the name of the parameter because some clients have already implemented that and I really prefer to make as minor of changes as possible to this BIP even if it is officially only a Draft. Matt On Sat, 2012-02-04 at 16:03 +, Gary Rowe wrote: Seems reasonable to me. On 4 Feb 2012 14:03, thoma...@gmx.de wrote: Just another question concerning BIP21: On the wiki, the description of the message parameter reads: message that shown to the user after scanning the QR code I believe that the purpose of this parameter is to contain a description of the transaction. This has use cases that go beyond QR codes. If I am right, then I would say that naming it message is misleading. In fact, message suggests that a message will be sent to someone (the recipient of the funds? a third party?), which is not the case here. That parameter should probably be called description. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) The send crap was not in the original spec, is not implemented anywhere, and should have been removed as part of the BIP 21 copy/paste. It is now gone. As for the expire time, well thats a bit problematic IMHO. Technically BIP 21 is still a draft, but it is implemented in all versions of Bitcoin-Qt for drag and drop and adding a field which restricts the validity of a URI for new clients, but which old clients will gladly accept could result in some ugly situations IMO. Matt -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
OK, so I just did some heavy changes to the methods for forward compatibility in BIP 21. Instead of a version number, now new variables will be added either as-is or with a mustimplement: prefix. If a clients does not know what the variable is that is after mustimplement:, it should consider the entire URI invalid and either notify the user or just drop it silently. That way things like expiretime can be added without worrying about old clients ignoring the field. All that said, I dont think its an ideal solution, depending on the names of variables to provide information is ugly. If anyone has a better idea on how to do backward compatibility, please suggest it. In terms of the expiretime field being implemented now, I dont think its appropriate. Because some clients already have an old implementation, the possibility of it getting ignored is too large. The BIP now states that It is recommended that additional variables prefixed with mustimplement: not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade. Mostly, however, I want to keep the list of changes from the Bitcoin-Qt implementation to this BIP very, very minimal this late the 0.6 release cycle (I want to get this BIP finalized and implemented for 0.6, so that at least Bitcoin-Qt will have no version which support OS URI opening with a broken implementation). Matt On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote: On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) The send crap was not in the original spec, is not implemented anywhere, and should have been removed as part of the BIP 21 copy/paste. It is now gone. As for the expire time, well thats a bit problematic IMHO. Technically BIP 21 is still a draft, but it is implemented in all versions of Bitcoin-Qt for drag and drop and adding a field which restricts the validity of a URI for new clients, but which old clients will gladly accept could result in some ugly situations IMO. Matt -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC
Because many made the mistake and it isnt specified in this email, this meeting is tomorrow (not 30 minutes ago). On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote: This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon can be found: http://privatepaste.com/4088b049af Hopefully this can become a weekly thing. For now this is to discuss and inform about the coming changes to bitcoin. -- Where: Freenode IRC #bitcoin-dev When: 21:00 UTC (16:00 New York time) until 22:00* What: OP_EVAL Bitcoin is starting decentralising as any healthy free thinking community should. Projects are thiving and the economy is growing. New ideas are being realised and will edge out old models disruptively. My hope is that we don't all become fractured. By having weekly regular meetings, projects can harmonise in lock step. Concepts and algorithms can be proposed and debated. You'd be surprised what having a scheduled regular platform can achieve. A soap-box on an island in central waters. For me, I don't have time to wade through IRC discussions, forum posts and mailing lists. At least if the important things are discussed in one place it makes bitcoin development and the system more accessible. Before meeting: - A wiki page is created for in advance of a weekly meeting. - Announced on forums/mailing lists. - Throughout the week talking points are added to the meeting page. After: - Log of discussion is posted online. - I will type an accessible summary for the community at large on http://bitcoinmedia.com/ - Next weekly meeting is scheduled. Amir Taaki *We can go over this hour, but this is to stop meetings dwindling off topic into banal banter and stay focused. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] upnp isnt working
On Fri, 2011-12-30 at 00:57 -0800, Amir Taaki wrote: hey, so sipa/gmaxwell proposed on irc that maybe upnp is not working anymore but there isnt any way to test. well i made an alternate chain, and ran the daemon on my vps. sometimes it accepts connections, sometimes not. It's all very patchy. anyway just putting this out there I believe the issue isn't lack of working, but lack of re announcing to the router that the port needs to remain open. Matt -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On Thu, 2011-12-15 at 13:59 -0600, theymos wrote: Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: I'm not against this, but I think its way overcomplicated when compared to the DNS or HTTPS methods. - Extend the protocol so that reply messages can be signed by a fixed public key - Extend checkorder messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. OK, not too debatable, but considering how terrible bitcoind's account handling is, the second might not be easy to get right... - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing reply messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. This is where I think this method becomes way overcomplicated. Not only do you have to update the IP-Transaction code, but now you have to implement the full DNS System that is the other option as well. Note that to make this secure, we have to have a full DNSSEC-capable resolver built-into bitcoind (there are libs, but it has to happen). Yes you can ask the user does this fingerprint look right to you? Y/N but that always opens you up to a ton of users getting screwed out of coins and I don't think it should be enabled, except in bitcoind, and since the main target of this whole alias system is bitcoin-qt users, well... Matt -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.4rc1 known bugs
On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote: Quick status update on 0.4; I probably won't have time to tackle these properly before Tuesday: + sipa found what looks like a deadlock between the addr-handling and IRC-join-handling code. + UukGoblin reports a deadlock problem on a bitcoind handling getwork requests. If you want to get more familiar with the bitcoin code and you have a lot of patience, tracking down deadlocks a great way to do it. + ArtForz found a performance bug with transactions that have thousands of inputs and outputs on the solidcoin test network. (not as big an issue for bitcoin due to fees being based on transaction size, but still worrying) + (my fault) Gitian doesnt build properly. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
