Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
their transactions could be for the 80% to not build on blocks containing doublespends by the 20%. There's no way in a decentralized network to come to consensus about what transactions are or are not valid without mining itself, so you could end up in a situation where unless you're part of one of the big pools you can't reliably mine at all because your blocks may get rejected for containing doublespends. One of my goal with standard replace-by-fee is to prevent this scenario by forcing merchants and others to implement ways of accepting zeroconf transactions safely that work in a decentralized environment regardless of what miners do; we have a stronger and safer Bitcoin ecosystem if we're relying on math rather than trust to secure our zeroconf transactions. We're also being more honest to users, who right now often have the very wrong impression that unconfirmed transactions are safe to accept - this does get people ripped off all too often! Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am waiting to get some feedback: https://github.com/bitcoin/bitcoin/pull/6176 Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm working on porting it to v0.10.2, and once that's done I'm going to put up a bounty for anyone who can find a DoS attack in the patch. If no-one claims the bounty after a week or two I think I'll start feeling confident about using it in production. -- 'peter'[:-1]@petertodd.org 03188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab -- ___ 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org wrote: Having said that... honestly, zeroconf is pretty broken already. Only with pretty heroic measures like connecting to a significant fraction of the Bitcoin network at once, as well as connecting to getblocktemplate supporting miners to figure out what transactions are being mined, are services having any hope of avoiding getting ripped off. For the average user their wallets do a terrible job of showing whether or not an This is no excuse for further degrading the overall network security. There are many issues to address in the bitcoin ecosystem. It negatively impacts users to roll out scorched earth replace-by-fee given today's ecosystem. Yes, zero conf security is poor. An outright attack on zero conf degrades user security even more. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
? --- First get the full-RBF patch to v0.10.2: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2 The above implementation of RBF includes additional code to find and preferentially connect to other RBF nodes, as well as Bitcoin XT nodes. Secondly, try out my replace-by-fee-tools at: https://github.com/petertodd/replace-by-fee-tools You can watch double-spends on the network here: http://respends.thinlink.com/ References -- 1) Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet, Peter Todd, May 23rd 2015, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html 2) From Zero to Hero: Bitcoin Transactions in 8 Seconds, June 2nd, 2014, Erik Voorhees, https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734 3) Coinbase Merchant API, Accessed Jun 19th 2015, https://developers.coinbase.com/docs/merchants/callbacks#confirmations 4) Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network, March 14th 2015, Grace Caffyn, Coindesk, http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/ 5) First-Seen-Safe Replace-by-Fee, May 25th 2015, Peter Todd, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html 6) Cost savings by using replace-by-fee, 30-90%, May 25th 2015, Peter Todd, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html 7) Tampering with the Delivery of Blocks and Transactions in Bitcoin, Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015, http://eprint.iacr.org/2015/578 -- 'peter'[:-1]@petertodd.org 070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net wrote: If we have ECDSA proof that an entity intentionally made and publicly announced incompatible promises regarding the disposition of particular Bitcoins under their control, then why shouldn't that be assumed to be a fraud attempt unless shown otherwise? Making multiple incompatible versions of a spend is a -requirement- of various refund contract protocols. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net wrote: On 2015-06-19 17:40, Jeff Garzik wrote: Making multiple incompatible versions of a spend is a -requirement- of various refund contract protocols. Is there not a dedicated field in a transaction (nSequence) for express purpose of indicating when a protocol like this is in use? No. You cannot know which is the 'right' or wrong transaction. One tx has obvious nSequence adjustments, the other - the refund transaction - may not. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net wrote: On 2015-06-18 14:53, Jeff Garzik wrote: Consensus changes - worded another way - change Bitcoin's Constitution - The Rules that everyone in the system is -forced- to follow, or be ignored by the system. Bitcoin does not and can not function as a set of rules imposed by some people onto other people. This is an engineering list. The quote precisely describes how the bitcoin consensus system functions. Users' choice is largely binary: Follow the rules, or bitcoin software ignores you. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] FYI - Mailing List Move Preparations
Thanks for setting this up, Warren! On Thu, Jun 18, 2015 at 9:57 PM, Warren Togami Jr. wtog...@gmail.com wrote: After discussions in #bitcoin-dev in the past day we decided it would be a bad idea to link the old and new lists in some way during a transition period. We decided we are better off announcing the switchover very soon, and after that point all posts to the old list will be rejected with a message telling them where to find the new list. The proposed switchover will be on Tuesday, June 23rd, 2015. We will know an exact scheduled time for the move probably tomorrow. At the time of the switchover, the old list will reject all messages, archives will be exported and imported into the new list server, then the new list will be opened. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Please subscribe now and feel free to make test posts. We are testing configuration options to fix some long standing spam filter-related issues. Any posts to the new list prior to the final switchover will be wiped from the archives. If you have opinions on this, please join us in Freenode #bitcoin-dev and talk to warren. Warren Togami -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org wrote: On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. This is a long, unreasonable list of work. None of this exists and it equates to upgrade all wallets and websites everywhere It requires all exchanges, payment processors, merchants, etc. to - basically everybody but miners - to update. It is a far, far larger amount of work to write, test and deploy than simply increasing the block size limit. Think through roll-out of these ambitious suggestions, before suggesting as an alternative! Not a realistic alternative except in an alternate universe where (a) developer work at all companies is cost free, plus (b) we can pause the business universe while we wait for The Perfect Solution. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Exactly -- both block size proponents and block size change conservatives seem to be glossing over this aspect - much to my dismay. Choosing the size limit is choosing the size of a scarce resource. By fiat. It is wrong to think that a technical consensus can choose what is best here. The block size limit defines the scope of a resource for which all fee market actors bid. That, in turn, defines who is in the fee market and how they behave, what market choices are made. It doesn't matter how or why the limit was originally enacted, what Satoshi meant to do. What matters, economically, is what is. What the software and our $3B economy market knows and sees today. (I think some block size change proponents miss this!) The solution lies in transitioning this size limit to the free market. In the end, the users must choose their desired level of growth, decentralization, etc. We cannot rely on some dev's idea of the proper level of fee, proper level of growth, proper level of decentralization. And IMO, a floating limit with training wheels is better and stronger for bitcoin's health from a governance, user choice and free market perspective than simply hard fork to 2MB, come back again in 6 months. On Sun, Jun 14, 2015 at 6:34 AM, Benjamin benjamin.l.cor...@gmail.com wrote: The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as you described. It's not at all a technical or engineering decision. It's the question of how to potentially re-design a fundamental part of Bitcoin, and the proposals so far don't address this. What is the price of the scarce resource of the blockchain and the mechanism to decide on price, once the subsidy runs out? On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson m...@henricson.se wrote: Jeff, with all due respect, but I've seen you saying this a few times now, that this decision is oh so difficult and important. But this is not helpful. We all know that. Even I. Make a suggestion, or stay out of the debate! Mats On 06/14/2015 07:36 AM, Jeff Garzik wrote: The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo
Re: [Bitcoin-development] comments on BIP 100
Adding - in re pay-to-FOO - these schemes are inherently short term, such that it is near-impossible for the market to plan for what happens in 12+ months. On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 5:23 PM, Adam Back a...@cypherspace.org wrote: Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. In the latest draft there is an explicit 32MB ceiling now. Users will need to opt into growth beyond 32MB via a 2nd hard fork. 2. there should be a growth limiter (no more than X%/year) As a general principle, this is an area of market disagreement, and should not be our call. Encoding this into software veers into personal opinion about what economic policy should be. That said -- BIP 100, as a compromise, includes a growth limiter. Abrupt change (1MB - 32MB!) is awful on markets. Good policies include a measured pace of transition from policy A to policy B. It gives the community time to assess system effectiveness - while also allowing free market input. In the long run I hope the cap is removed (see below), and the intention is to -slowly- and -transparently- move from the tightly controlled limit to something the free market and users are choosing. 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] paying with difficulty has severe negative elements that will likely cause it never to be used: - complex and difficult for miners to reason - fails the opportunity cost test - dollar cost lost losing the block race versus value gained by increasing block size - inherently unpredictable in the short term - user experience is that it's possibly difficult to see a gain in utility versus the revenue you are giving up - REQUIRES informal miner collusion - probably less transparent than BIP 100 - in order to solve the who-goes-first problem. - net result: tough sell Paying bitcoins to future miners makes a lot more sense. Initially I was a fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd anyone-can-spend has much more clear incentives, if you want to go down that road. Problems with pay-to-increase-block-size: - how much to pay? You are inherently setting your growth policy on top of bitcoin by choosing a price here. - another who-goes-first problem Anyway, there is a natural equilibrium block size that the free market and user choice will seek. Related: There is a lot of naive miner = max income = max block size reasoning going on, with regards to fees. This is defining the bounds of an economically scarce resource. There are many reasons why a miner will today, in the real world, limit their block size. WRT fee income, if block size is too large the fee competition in the overall market is low-to-zero, fee income rapidly collapses. Then factor in price and demand elasticity on top of that. Quite frankly, there seems to be a natural block size equilibrium ceiling, and I worry about miners squeezing the market by maximizing their fee income through constrained block sizes and competition at the low end. This is of course already possible today - miners may openly or covertly collude to keep the block size low. I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous
Re: [Bitcoin-development] User vote in blocksize through fees
On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang 1240...@gmail.com wrote: To tell you the truth. It is only because most miners are not located in the West. If Slush, Eligius and BTC Guild still on top 3, the core developers, including brain-dead Mike Hearn, would be very happy to do BIP100 just like they did BIP34 and BIP66. Shame on you! BIP 100 requires a hard fork to engage. Users proactively opt-in. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
The choice is very real and on-point. What should the block size limit be? Why? There is a large consensus that it needs increasing. To what? By what factor? The size limit literally defines the fee market, the whole damn thing. If software high priests choose a size limit of 300k, space is scarce, fees are bid high. If software high priests choose a size limit of 32mb, space is plentiful, fees are near zero. Market actors take their signals accordingly. Some business models boom, some business models fail, as a direct result of changing this unintentionally-added speedbump. Different users value adoption, decentralization etc. differently. The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market. A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance problems associated with actors lobbying developers, even if a cloistered and vetted Technical Advisory Board as has been proposed. On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote: I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Miner voting, while imperfect, is the least-worst of various solutions which inject market input into the system. It is is known quantity, field tested, and must be sustained, in public, over a time span of months. As this thread shows, stakeholder and direct user voting is nigh impossible to get right. Choosing block size is fundamentally a central bank directive shaping the fee market. Whatever actor or algorithm or natural equilibrium picks the block size, that choice will dictate the level of competition for fees, the level of scarcity of an economically scarce resource. Picking the block size advantages some businesses over others, some business models over others. Software (and software devs) should not be the ones picking that limit. Checks-and-balances are also important. BIP 100 notably includes two steps at which user input is visibly and actively injected: 1) hard fork to enable, and 2) a second hard fork if the system is to scale beyond 32MB. The network users (not miners) twice approve the system. Further, one must remember all the basic miner incentives that do align with users, notably that of maintaining the value of bitcoin tokens as their primary income stream. On Sun, Jun 14, 2015 at 12:16 AM, Stephen stephencalebmo...@gmail.com wrote: While this idea is theoretically interesting because it involves many stakeholders, rather than just miners, I think in practice this would not work very well. Users don't want to worry about this kind of technicality, they just want to be able to make a transaction and have it be processed. In addition, while this gives stakeholders some weight with the fees they supply, these fees are marginal compared to the block size subsidy. If this proposal were actually implemented, I think miners would vote for whatever they think is best, and users would not contradict them with their votes to ensure a fast confirmation time. Users are incentivized to be in agreement with miners because the miners provide them with the confirmations they need, but fees do not provide a great incentive for miners to be in agreement with users, and likely won't for some time. Best, Stephen On Jun 12, 2015, at 2:11 PM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
On Wed, Jun 10, 2015 at 11:59 AM, Andy Schroder i...@andyschroder.com wrote: Hello, A couple of motivations for a mailing list switch: 1. Sometimes the mailing list delays delivery for 10 minutes to several days. 2. There are usually lots of ads at the footer of the messages. Really confuses new readers (for me at least), and seems like it really pollutes such a historical dialog that may be referenced long into the future. How would it be if the 10 Commandments, Magna Carta, Bill of Rights, The Sermon on the Mount, or The Gettysburg Address had ads intertwined within them? 3. Don't think HTML messages are allowed. 4. Seems like digital signatures are always broken on messages because the list server slightly modifies them (?), so my e-mail client doesn't verify them all. Not only -- mail header rewrites cause all my emails to go into people's spam folders, if they were not directly listed in the To/CC headers... 1. Andy Schroder On 06/10/2015 02:36 PM, s7r wrote: The mail list is public, so it's not like the data on it is somehow sensitive. Sourcefoge is fine, it has a nice web UI where you can browse the message and sort/order them as you want, etc. Why would you want to move to a paid solution? And why would you want users to have to pay per message? This is the worst idea ever from my point of view. We want to encourage people to join the community, run full nodes, ask questions, come with solutions, ideas for improvements and so on. Everyone should read and write and contribute as much as possible with ideas in debates. You never know who can have bright ideas in some contexts. Bottom line is so far sourceforge handles the mail lists just fine. I don't see a single advantage another mail list provider / system could offer, except some headache and extra work for migration. The software distribution via sourcefoge was cancelled for obvious reasons which I fully understand and agree to, but it has nothing to do with the mail lists. We have way more important things to brainstorm about. On 6/10/2015 7:46 PM, Andy Schroder wrote: Regarding changing the e-mail list provider. Is anyone interested in sponsoring it? There are non-free options, but it may be difficult to always ensure the fee is being paid to the provider. I think finding an agreeable free solution may have been the issue before? I've also thought of trying to make a pay per message or byte solution (and this cost could be dynamic based upon the number of current mailing list subscribers). This could solve the who pays problem (the sender pays), as well as motivate people to be more concise and clear with their messages, and at the same time limit spam. Any thoughts? Andy Schroder On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote: On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/ All our downloads (even old ones) have recently been deleted from sourceforge, for this reason. They haven't been mentioned in Bitcon Core release announcements for a long time. No opinion on the mailing list. Though I think it's less urgent. The issue of moving the mailinglist has come up before a few times and people can't agree where to move to. Wladimir -- -- ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
That attitude and doxxing is not appropriate for this list. On Tue, May 26, 2015 at 4:30 PM, joli...@airmail.cc wrote: You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks and you have big banks as clients. Shit like replace-by-fee and leading the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out. https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Virtual Notary.
On Wed, May 20, 2015 at 3:25 AM, Emin Gün Sirer el33th4...@gmail.com wrote: Hi everyone, Given the recent discussions on projects that use the Bitcoin blockchain to record factoids, people on this list might be interested in the Virtual Notary project. Virtual Notary is essentially an online witness (aka attestor) to online factoids. It can provide: * proof of Bitcoin funds (without revealing public addresses or fund location on the blockchain) * proof of Bitcoin address ownership * proof of Tweet For what it's worth, a subsidiary of Dunvegan Space Systems is pursuing exactly this as a business. EMail jgar...@dss.co if you want to know more. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Proposed additional options for pruned nodes
A general assumption is that you will have a few archive nodes with the full blockchain, and a majority of nodes are pruned, able to serve only the tail of the chains. On Tue, May 12, 2015 at 8:26 AM, gabe appleton gapplet...@gmail.com wrote: Hi, There's been a lot of talk in the rest of the community about how the 20MB step would increase storage needs, and that switching to pruned nodes (partially) would reduce network security. I think I may have a solution. There could be a hybrid option in nodes. Selecting this would do the following: Flip the --no-wallet toggle Select a section of the blockchain to store fully (percentage based, possibly on hash % sections?) Begin pruning all sections not included in 2 The idea is that you can implement it similar to how a Koorde is done, in that the network will decide which sections it retrieves. So if the user prompts it to store 50% of the blockchain, it would look at its peers, and at their peers (if secure), and choose the least-occurring options from them. This would allow them to continue validating all transactions, and still store a full copy, just distributed among many nodes. It should overall have little impact on security (unless I'm mistaken), and it would significantly reduce storage needs on a node. It would also allow for a retroactive --max-size flag, where it will prune until it is at the specified size, and continue to prune over time, while keeping to the sections defined by the network. What sort of side effects or network vulnerabilities would this introduce? I know some said it wouldn't be Sybil resistant, but how would this be less so than a fully pruned node? -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Proposed additional options for pruned nodes
True. Part of the issue rests on the block sync horizon/cliff. There is a value X which is the average number of blocks the 90th percentile of nodes need in order to sync. It is sufficient for the [semi-]pruned nodes to keep X blocks, after which nodes must fall back to archive nodes for older data. There is simply far, far more demand for recent blocks, and the demand for old blocks very rapidly falls off. There was even a more radical suggestion years ago - refuse to sync if too old (2 weeks?), and force the user to download ancient data via torrent. On Tue, May 12, 2015 at 1:02 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik jgar...@bitpay.com wrote: One general problem is that security is weakened when an attacker can DoS a small part of the chain by DoS'ing a small number of nodes - yet the impact is a network-wide DoS because nobody can complete a sync. It might be more interesting to think of that attack as a bandwidth exhaustion DOS attack on the archive nodes... if you can't get a copy without them, thats where you'll go. So the question arises: does the option make some nodes that would have been archive not be? Probably some-- but would it do so much that it would offset the gain of additional copies of the data when those attacks are not going no. I suspect not. It's also useful to give people incremental ways to participate even when they can't swollow the whole pill; or choose to provide the resource thats cheap for them to provide. In particular, if there is only two kinds of full nodes-- archive and pruned; then the archive nodes take both a huge disk and bandwidth cost; where as if there are fractional then archives take low(er) bandwidth unless the fractionals get DOS attacked. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Proposed additional options for pruned nodes
One general problem is that security is weakened when an attacker can DoS a small part of the chain by DoS'ing a small number of nodes - yet the impact is a network-wide DoS because nobody can complete a sync. On Tue, May 12, 2015 at 12:24 PM, gabe appleton gapplet...@gmail.com wrote: 0, 1, 3, 4, 5, 6 can be solved by looking at chunks chronologically. Ie, give the signed (by sender) hash of the first and last block in your range. This is less data dense than the idea above, but it might work better. That said, this is likely a less secure way to do it. To improve upon that, a node could request a block of random height within that range and verify it, but that violates point 2. And the scheme in itself definitely violates point 7. On May 12, 2015 3:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote: It's a little frustrating to see this just repeated without even paying attention to the desirable characteristics from the prior discussions. Summarizing from memory: (0) Block coverage should have locality; historical blocks are (almost) always needed in contiguous ranges. Having random peers with totally random blocks would be horrific for performance; as you'd have to hunt down a working peer and make a connection for each block with high probability. (1) Block storage on nodes with a fraction of the history should not depend on believing random peers; because listening to peers can easily create attacks (e.g. someone could break the network; by convincing nodes to become unbalanced) and not useful-- it's not like the blockchain is substantially different for anyone; if you're to the point of needing to know coverage to fill then something is wrong. Gaps would be handled by archive nodes, so there is no reason to increase vulnerability by doing anything but behaving uniformly. (2) The decision to contact a node should need O(1) communications, not just because of the delay of chasing around just to find who has someone; but because that chasing process usually makes the process _highly_ sybil vulnerable. (3) The expression of what blocks a node has should be compact (e.g. not a dense list of blocks) so it can be rumored efficiently. (4) Figuring out what block (ranges) a peer has given should be computationally efficient. (5) The communication about what blocks a node has should be compact. (6) The coverage created by the network should be uniform, and should remain uniform as the blockchain grows; ideally it you shouldn't need to update your state to know what blocks a peer will store in the future, assuming that it doesn't change the amount of data its planning to use. (What Tier Nolan proposes sounds like it fails this point) (7) Growth of the blockchain shouldn't cause much (or any) need to refetch old blocks. I've previously proposed schemes which come close but fail one of the above. (e.g. a scheme based on reservoir sampling that gives uniform selection of contiguous ranges, communicating only 64 bits of data to know what blocks a node claims to have, remaining totally uniform as the chain grows, without any need to refetch -- but needs O(height) work to figure out what blocks a peer has from the data it communicated.; or another scheme based on consistent hashes that has log(height) computation; but sometimes may result in a node needing to go refetch an old block range it previously didn't store-- creating re-balancing traffic.) So far something that meets all those criteria (and/or whatever ones I'm not remembering) has not been discovered; but I don't really think much time has been spent on it. I think its very likely possible. -- 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 -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
* *This message was created with 100% recycled electrons. Please think twice before printing.* !DSPAM:554e4e5450787476022393! -- 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 !DSPAM:554e4e5450787476022393! -- Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development !DSPAM:554e4e5450787476022393! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlVPXp0ACgkQjwioWRGe9K1+2ACfViY0D2ksVFe29SwhxbtmNSC3 TQAAnRoJLI9wW3DQRPqQ7PorKxelC2S2 =Er51 -END PGP SIGNATURE- -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY
That reminds me - I need to integrate the patch that automatically sweeps anyone-can-pay transactions for a miner. On Thu, May 7, 2015 at 7:32 PM, Tier Nolan tier.no...@gmail.com wrote: One of the suggestions to avoid the problem of fees going to zero is assurance contracts. This lets users (perhaps large merchants or exchanges) pay to support the network. If insufficient people pay for the contract, then it fails. Mike Hearn suggests one way of achieving it, but it doesn't actually create an assurance contract. Miners can exploit the system to convert the pledges into donations. https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770 Consider a situation in the future where the minting fee has dropped to almost zero. A merchant wants to cause block number 1 million to effectively have a minting fee of 50BTC. He creates a transaction with one input (0.1BTC) and one output (50BTC) and signs it using SIGHASH_ANYONE_CAN_PAY. The output pays to OP_TRUE. This means that anyone can spend it. The miner who includes the transaction will send it to an address he controls (or pay to fee). The transaction has a locktime of 1 million, so that it cannot be included before that point. This transaction cannot be included in a block, since the inputs are lower than the outputs. The SIGHASH_ANYONE_CAN_PAY field mean that others can pledge additional funds. They add more input to add more money and the same sighash. There would need to be some kind of notice boeard system for these pledges, but if enough pledge, then a valid transaction can be created. It is in miner's interests to maintain such a notice board. The problem is that it counts as a pure donation. Even if only 10BTC has been pledged, a miner can just add 40BTC of his own money and finish the transaction. He nets the 10BTC of the pledges if he wins the block. If he loses, nobody sees his 40BTC transaction. The only risk is if his block is orphaned and somehow the miner who mines the winning block gets his 40BTC transaction into his block. The assurance contract was supposed to mean If the effective minting fee for block 1 million is 50 BTC, then I will pay 0.1BTC. By adding his 40BTC to the transaction the miner converts it to a pure donation. The key point is that *other* miners don't get 50BTC reward if they find the block, so it doesn't push up the total hashing power being committed to the blockchain, that a 50BTC minting fee would achieve. This is the whole point of the assurance contract. OP_CHECKLOCKTIMEVERIFY could be used to solve the problem. Instead of paying to OP_TRUE, the transaction should pay 50 BTC to 1 million OP_CHECKLOCKTIMEVERIFY OP_TRUE and 0.01BTC to OP_TRUE. This means that the transaction could be included into a block well in advance of the 1 million block point. Once block 1 million arrives, any miner would be able to spend the 50 BTC. The 0.01BTC is the fee for the block the transaction is included in. If the contract hasn't been included in a block well in advance, pledgers would be recommended to spend their pledged input, It can be used to pledge to many blocks at once. The transaction could pay out to lots of 50BTC outputs but with the locktime increasing by for each output. For high value transactions, it isn't just the POW of the next block that matters but all the blocks that are built on top of it. A pledger might want to say I will pay 1BTC if the next 100 blocks all have at least an effective minting fee of 50BTC -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Fri, May 8, 2015 at 10:59 AM, Alan Reiner etothe...@gmail.com wrote: This isn't about everyone's coffee. This is about an absolute minimum amount of participation by people who wish to use the network. If our goal is really for bitcoin to really be a global, open transaction network that makes money fluid, then 7tps is already a failure. If even 5% of the world (350M people) was using the network for 1 tx per month (perhaps to open payment channels, or shift money between side chains), we'll be above 100 tps. And that doesn't include all the non-individuals (organizations) that want to use it. The goals of a global transaction network and everyone must be able to run a full node with their $200 dell laptop are not compatible. We need to accept that a global transaction system cannot be fully/constantly audited by everyone and their mother. The important feature of the network is that it is open and anyone *can* get the history and verify it. But not everyone is required to. Trying to promote a system where the history can be forever handled by a low-end PC is already falling out of reach, even with our miniscule 7 tps. Clinging to that goal needlessly limits the capability for the network to scale to be a useful global payments system To repeat, the very first point in my email reply was: Agree that 7 tps is too low Never was it said that bit Therefore a reply arguing against the low end is nonsense, and the relevant question remains on the table. How high do you want to go - and can Layer 1 bitcoin really scale to get there? It is highly disappointing to see people endorse moar bitcoin volume! with zero thinking behind that besides adoption! Need to actually project what bitcoin looks like at the desired levels, what network resources are required to get to those levels -- including traffic to serve those SPV clients via P2P -- and then work backwards from that to see who can support it, and then work backwards to discern a maximum tps. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote: (1) Blocks are essentially nearing full now. And by full he means that the reliability of the network (from the average user perspective) is about to be impacted in a very negative way Er, to be economically precise, full just means fees are no longer zero. Bitcoin behaves as it always has. It is no longer basically free to dump spam into the blockchain, as it is today. In the short term, blocks are bursty, with some on 1 minute intervals, some with 60 minute intervals. This does not change with larger blocks. (2) Leveraging fee pressure at 1MB to solve the problem is actually really a bad idea. It's really bad while Bitcoin is still growing, and relying on fee pressure at 1 MB severely impacts attractiveness and adoption potential of Bitcoin (due to high fees and unreliability). But more importantly, it ignores the fact that for a 7 tps is pathetic for a global transaction system. It is a couple orders of magnitude too low for any meaningful commercial activity to occur. If we continue with a cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to be useful for the vast majority of the world (which probably leads to failure). We shouldn't be talking about fee pressure until we hit 700 tps, which is probably still too low. [...] 1) Agree that 7 tps is too low 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just for a single feed. If you include relaying to multiple nodes, plus serving 500 million SPV clients en grosse, who has the capacity to run such a node? By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. 3) In RE fee pressure -- Do you see the moral hazard to a software-run system? It is an intentional, human decision to flood the market with supply, thereby altering the economics, forcing fees to remain low in the hopes of achieving adoption. I'm pro-bitcoin and obviously want to see bitcoin adoption - but I don't want to sacrifice every decentralized principle and become a central banker in order to get there. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: More generally, consider the situation we're in now. Gavin is going off pitching this idea to the general public (which, I agree, is an important step in pulling off a hardfork) while people who actually study the issues are left wondering why they're being ignored (ie why is there no consensus-building happening on this list?). This sub-thread threatens to veer off into he-said-she-said. 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. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com wrote: On 5/7/2015 12:54 PM, Jeff Garzik wrote: 2) Where do you want to go? Should bitcoin scale up to handle all the world's coffees? Alan was very clear. Right now, he wants to go exactly where Gavin's concrete proposal suggests. G proposed 20MB blocks, AFAIK - 140 tps A proposed 100MB blocks - 700 tps For ref, Paypal is around 115 tps VISA is around 2000 tps (perhaps 4000 tps peak) I ask again: where do we want to go? This is the existential question behind block size. Are we trying to build a system that can handle Paypal volumes? VISA volumes? It's not a snarky or sarcastic question: Are we building a system to handle all the world's coffees? Is bitcoin's main chain and network - Layer 1 - going to receive direct connections from 500m mobile phones, broadcasting transactions? We must answer these questions to inform the change being discussed today, in order to decide what makes the most sense as a new limit. Any responsible project of this magnitude must have a better story than zomg 1MB, therefore I picked 20MB out of a hat Must be able to answer /why/ the new limit was picked. As G notes, changing the block size is simply kicking the can down the road: http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea Necessarily one must ask, today, what happens when we get to the end of that newly paved road. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
I have a lot more written down, a WIP; here are the highlights. - The 1MB limit is an ancient anti-spam limit, and needs to go. - The 1MB limit is economically entrenched at this point, and cannot be removed at a whim. - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. - The core dev team is not and should not be an FOMC. - The bar for major economic change to a $3.2B system should necessarily be high. In the more boring world of investments, this would accompanied by Due Diligence including but not limited to projections for success, failure scenarios, upside risks and downside risks. Projections and fact-based simulations. - There are significant disruption risks on the pro (change it) and con (keep 1MB) sides of the debate. - People are privately lobbying Gavin for this. That is the wrong way to go. I have pushed for a more public debate, and public endorsements (or condemnations) from major miners, merchants, payment processors, stackholders, ... It is unfair to criticize Gavin to doing this. -- 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 Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote: That's why I conclude the opposite - if there is no fork, then people's confidence in Bitcoin will be seriously damaged. Yes, that is a possibility. If it's impossible to do something as trivial as removing a temporary hack Satoshi put in place, then what about bigger challenges? This is absolutely not a trivial change. It is a trivial *code* change. It is not a trivial change to the economics of a $3.2B system. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net wrote: To be extremely specific: should Bitcoin development intenionally limit the network's capabilities to leave room for other projects, or should Bitcoin attempt to be the best system possible and let the other projects try to keep up as best they can? Avoid such narrow, binary thinking. Referencing the problem described in http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent (not the solution - block size change - just the problem, tx/block Poisson mismatch) This problem - block creation is bursty - is fundamental to bitcoin. Raising block size does not fix this problem (as [1] notes), but merely kicks the can down the road a bit, by hiding it from users a bit longer. Bitcoin is a settlement system, at the most fundamental engineering level. It will never be an instant payment system for all the world's coffees (or all the world's stock trades). It is left to Layer 2 projects to engineer around bitcoin's gaps, to produce an instant, secure, trustless, egalitarian payment system using the bitcoin token. [1] also notes this. It is therefore not a binary decision of leaving room for other projects, or not. Layer-2 projects are critical to the success of bitcoin, and complement bitcoin. [1] http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea Holistic thinking implies you build a full-stack system with bitcoin -- 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
Dear list, Apparently my emails are being marked as spam, despite being sent from GMail's web interface. I've pinged our sysadmin. Thanks for letting me know. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net wrote: In summary, I asked a question neither you, nor Peter Todd, want to answer and want to actively discourage people from even asking at all. Incorrect; your question included built-in assumptions with which I disagree. Bitcoin needs to be the best it can be (Layer 1), but all solutions cannot and should not be implemented at Layer 1. We need to scale up both bitcoin (L1) and solutions built on top of bitcoin (L2). -- 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 Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net wrote: On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of projects which aren't Bitcoin that benefit from filling in the gap left by Bitcoin's restricted transaction rate capability. If Bitcoin fills that gap, Bitcoin wins and those other projects lose. Should decisions about Bitcoin development take into account the desires of competing projects? heh - I tend to think people here want bitcoin to succeed. My statement refers to picking winners and losers from within the existing bitcoin community stakeholders. The existential question of the block size increase is larger - will failing to increase the 1MB limit permanently stunt bitcoin's growth? -- 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
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Looking for a good bitcoin script decompiler in Python
python-bitcoinlib supports script parsing and execution.
On Wed, Apr 29, 2015 at 6:16 PM, Richard Moore m...@ricmoo.com wrote:
I have a library, pycoind (https://github.com/ricmoo/pycoind) you might
find useful.
import pycoind
str(pycoind.script.Tokenizer('76a9143f320f852a51643d3ffbaa1f49bfe521dd97764a88ac'.decode('hex')))
'OP_DUP OP_HASH160 3f320f852a51643d3ffbaa1f49bfe521dd97764a OP_EQUALVERIFY
OP_CHECKSIG'
On Apr 29, 2015, at 1:12 PM, Braun Brelin bbre...@gmail.com wrote:
Hi all,
I'm trying to find a good python script that will take the hash of the
locking and
unlocking tx scripts and output the actual op codes.
Any ideas where to look?
Thanks,
--
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
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ric...@geneticmistakes.com
www: http://GeneticMistakes.com
--
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
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
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] Build your own nHashType
On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse stephencalebmo...@gmail.com wrote: Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Think about what slow transaction verification speed means. Slower propagation across the network. More work per node. Greater opportunity for algorithmic attacks, races and other shenanigans by attackers. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo elombr...@gmail.com wrote: As for 0-conf security, there are instances where 0-conf transactions make a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such services which could be immediately shut off upon detection of a double-spend. Indeed. 0-conf risk calculus must include business conditions. Business cases such as placing an order for a physical good, making an in-person purchase at a brick-n-mortar store, or subscriptions already have countermeasures in place if funds go astray. Order fulfilment can be stopped, subscriptions cancelled, photos handed to police. A thief wants to maximize return, which usually means either stealing a few large amounts or many small amounts. Double-spending against a SatoshiDICE clone is easy to automate. Many other purchase situations are difficult to repeat without getting caught, or the level of effort (cost) is greater than the payout of double-spending a small amount. 0-conf is typically only used for small amounts, where useful theft relies on high repetition. Purely online, mostly anonymous services like SatoshiDICE will be easily attacked if they accept 0-conf transactions as there is little customer/reputation relationship to leverage. However, that observation cannot be easily applied to most other businesses. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
big to fail'. Where the blockchain improves on everything else is in transparency. If you reverse transactions a lot, it will be obvious from an analysis. I would much rather deal with a known, predictable, and relatively continous transaction reversal rate (percentage) than have to deal with sudden failures where some anonymous bad actor makes off with a fortune. We already have zero-conf double-spend transaction reversal, why not explicitly extend that a little in a way that senders and receivers have a choice to use it, or not? [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Repeating past statements, it is acknowledged that Peter's scorched earth replace-by-fee proposal is aptly named, and would be widely anti-social on the current network. At a high level, we can see that this thread is contentious because this covers _what we want bitcoin to be_, and that is an opinion (versus engineering fact), and it varies from person to person. However, hope is the denial of reality...instead we should walk forward with our eyes open[1]. My interest in bitcoin originates from the science fiction concept of credits[2], a universal money that transcends national borders and even planets. That is what I hoped bitcoin would be. universal payments is both a laudable goal and a shopworn bitcoin marketing slogan. The fundamental engineering truths diverge from that misty goal: Bitcoin is a settlement system, by design. The process of consensus settles upon a timeline of transactions, and this process -- by design -- is necessarily far from instant. Alt-coins that madly attempt 10-second block times etc. are simply a vain attempt to paper over this fundamental design attribute: consensus takes time. As such, the blockchain can never support All The Transactions, even if block size increases beyond 20MB. Further layers are -- by design -- necessary if we want to achieve the goal of a decentralized payment network capable of supporting full global traffic. Bitcoin payments are like IP packets -- one way, irreversible. For larger value transfers this attaches attendent risk of loss -- as we've seen in the field time again. The world's citizens en masse will not speak to each other with bitcoin (IP packets), but rather with multiple layers (HTTP/TCP/IP) that enable safe and secure value transfer or added features such as instant transactions. This opinion is not a conspiracy to put the bankers back in charge -- it is a simple acknowledgement of bitcoin's design. The consensus system settles on a timeline. Bitcoin transactions are, by definition, not instant. Zero confirmation transactions are, by definition, not secure. Proposals such as Oleg's are _necessary_ to fully build out the bitcoin system. Avoid short-sighted, short-term thinking that views the lowest layer (one-way value xfer) at the most optimal layer at which free persons will transact freely instantly across planet Earth. It is foolish to think the entire world will connect directly to the P2P block network and broadcast all the morning coffees to all the miners. That's not how the system works. It is a settlement layer. We _must_ build decentralized layered solutions on top of bitcoin, rather than stuffing everything into bitcoin itself. [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn m...@plan99.net wrote: I know you will ignore this as usual, but the entire replace-by-fee folly is based on your fundamental misunderstanding of miner incentives. Miners are not incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. Making Bitcoin much less useful reduces demand for the bitcoins they are mining, reducing coinbase and fee income in future blocks. Quite possibly, to the point where those miners are then making a loss. Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. If enough miners do it they will simply break Bitcoin to the point where it's no longer an interesting payments system for lots of people. Then miners who have equipment to pay off will be really screwed, not to mention payment processors and all the investors in them. I'm sure you can confuse a few miners into thinking your ideas are a super-duper way to maximise their income, and in the process might facilitate a pile of payment fraud. But they aren't. This one is about as sensible as your let's never increase the block size and let's kill SPV clients crusades - badly thought out and bad for Bitcoin. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World
Re: [Bitcoin-development] determining change addresses using the least significant digits
Yes. You can certainly add additional inputs and outputs -- and as such you can increase privacy and defrag your wallet at the same time. On Fri, Feb 6, 2015 at 2:11 AM, Wladimir laa...@gmail.com wrote: On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner cryptocurrenc...@quidecco.de wrote: A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Any thoughts? Adding/subtracting a randomized offset amount is one way, but there have also been more sophisticated ideas to obfuscate the amount, e.g. by adding multiple change outputs or even distributing over multiple transactions (potentially coinjoined for further privacy). Mike Hearn had some ideas regarding obfuscation of payment amounts, which still make sense, and he wrote about them here: https://medium.com/@octskyward/merge-avoidance-7f95a386692f Wladimir -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
+1 I just ran an it-works test on #5743. Not exhaustive, but I do agree it should be included w/ other DERSIG changes. On Tue, Feb 3, 2015 at 1:19 PM, Gavin Andresen gavinandre...@gmail.com wrote: I think we should just do it, and include it with the other DERSIG changes for 0.10. On Tue, Feb 3, 2015 at 1:15 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I understand it's late, which is also why I ask for opinions. It's also not a priority, but if we release 0.10 without, it will first need a cycle of making this non-standard, and then in a further release doing a second softfork to enforce it. It's a 2-line change; see #5743. -- Pieter -- -- Gavin Andresen -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
It is not fear, it is field experience. JSON has proven to be a bug generator for the reasons already stated. JSON does not include type marshalling and input validation. Protobufs/msgpack/etc. engineered those to occur automatically, because that is an area shown by field experience to be a constant source of bugs and inconsistent parsing/validation behavior. On Wed, Jan 28, 2015 at 11:52 AM, Nicolas DORIER nicolas.dor...@gmail.com wrote: For the number of field there is in the spec, I don't consider having a JSON to schama really worthwhile. If you fear it is error prone, then we should provide some testing data for the BIP70. (Which I already did for protobuf, but was rejected, because deemed no useful thanks to the code generator... But such code generator gave me inconsistencies with gavin's implementation for example) Why do you think type support is very useful in our case ? we have 3 types, and dealing only with bytes, int, and string. It cost me more time to find a suitable cross plateform lib for protobuf (in c#, that works in ios and winrt) than I would by just coding the json wrapper classes by hand. (JSON libs are more wildspread and supported than protobuf) 2015-01-28 17:04 GMT+01:00 Jeff Garzik jgar...@bitpay.com: Not to mention the tiresome and error-prone task of writing your own JSON-to-schema marshalling code -- or something equivalent to the protobufs compiler and libs for JSON. protobufs -- and its modern competitors such as msgpack -- natively provide type support in a way that must be hacked into JSON or XML. The protobuf/msgpack design is engineered to avoid bugs routinely found in JSON parsing code; due to the amount of code effort involved in JSON input sanity checking, bugs and inconsistencies inevitable arise. We have seen this in bitcoind with JSON-RPC. On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn m...@plan99.net wrote: On the other hand, if you charge the developer (and not the plateform) to check certificate validity, it means that you have to develop a different codebase for all plateform you are targeting, because each plateform store trusted root certificate in a different manner with different APIs, and also have different types representing a X509 Certificate. That's what cross-platform abstraction libraries are for. Both Java and Qt provide a key store library that can load from either the OS root store or a custom one. If your chosen app platform doesn't, OK, then you'll have to make or find one yourself. Perhaps contribute it upstream or make it a library. But that's not a limitation of BIP70. Just as a reminder, there is no obligation to use the OS root store. You can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT etc stores and load it in your app. We do this in bitcoinj by default to avoid cases where BIP70 requests work on some platforms and not others, although the developer can easily override this and use the OS root store instead. Of all possible solutions, using a third party service to convert things to JSON is one of the least obvious and highest effort. I don't know anyone else who arrived at such a conclusion and respectfully disagree that this is a problem with the design choices in BIP70. It sounds like a bizarre hack around lack of features in whatever runtime you're using. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Not to mention the tiresome and error-prone task of writing your own JSON-to-schema marshalling code -- or something equivalent to the protobufs compiler and libs for JSON. protobufs -- and its modern competitors such as msgpack -- natively provide type support in a way that must be hacked into JSON or XML. The protobuf/msgpack design is engineered to avoid bugs routinely found in JSON parsing code; due to the amount of code effort involved in JSON input sanity checking, bugs and inconsistencies inevitable arise. We have seen this in bitcoind with JSON-RPC. On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn m...@plan99.net wrote: On the other hand, if you charge the developer (and not the plateform) to check certificate validity, it means that you have to develop a different codebase for all plateform you are targeting, because each plateform store trusted root certificate in a different manner with different APIs, and also have different types representing a X509 Certificate. That's what cross-platform abstraction libraries are for. Both Java and Qt provide a key store library that can load from either the OS root store or a custom one. If your chosen app platform doesn't, OK, then you'll have to make or find one yourself. Perhaps contribute it upstream or make it a library. But that's not a limitation of BIP70. Just as a reminder, there is no obligation to use the OS root store. You can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT etc stores and load it in your app. We do this in bitcoinj by default to avoid cases where BIP70 requests work on some platforms and not others, although the developer can easily override this and use the OS root store instead. Of all possible solutions, using a third party service to convert things to JSON is one of the least obvious and highest effort. I don't know anyone else who arrived at such a conclusion and respectfully disagree that this is a problem with the design choices in BIP70. It sounds like a bizarre hack around lack of features in whatever runtime you're using. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] IMPULSE: Instant Payments using the Bitcoin protocol
The user experience is significantly more secure than today. Presumably the future supports many payment facilitators, including m-of-n oracles, and this is perfectly compatible with that. On Thu, Jan 22, 2015 at 10:19 AM, Tom Harding t...@thinlink.com wrote: On 1/17/2015 12:45 PM, Rune Kjær Svendsen wrote: PDF: http://impulse.is/impulse.pdf I'd love to hear this list's thoughts. Will success be defined by BitPay Payment Channels Accepted Here signs appearing in shop windows? -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
None of those listed were in the context of performance. Parsing of binary or text is quite fast these days, and is not really a consideration versus other needs such as a predictable encoding for a single data representation. XML and JSON both can represent the same post-evaluation user data a million different ways, which is awful for anything you are signing and hashing. Text formats also transit binary data very poorly, leading to unnecessary wrapping and unwrappiing (a programmatic, visibility bug; again performance not a primary concern). This is evident because both XML and JSON have standards efforts under way to correct some of these problems and make them more deterministic. However, such standards are not field deployed and widely supported by parsers and generators alike. On Mon, Jan 19, 2015 at 2:16 PM, Richard Brady rnbr...@gmail.com wrote: Fair points, although for me the line is blurred between which of those are security considerations vs performance considerations. Richard On 19 January 2015 at 19:09, Jeff Garzik jgar...@bitpay.com wrote: Text formats such as XML or JSON are far less deterministic, are more loosely specified, have wide variance in parsing, are not very hash-able, the list goes on. On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady rnbr...@gmail.com wrote: Hi Gavin, Mike and co Is there a strong driver behind the choice of Google Protocol Buffers for payment request encoding in BIP-0070? Performance doesn't feel that relevant when you think that: 1. Payment requests are not broadcast, this is a request / response flow, much more akin to a web request. 2. One would be cramming this data into a binary format just so you can then attach it to a no-so-binary format such as HTTP. Some great things about protocols/encodings such as HTTP/JSON/XML are: 1. They are human readable on-the-wire. No Wireshark plugin required, tcpdump or ngrep will do. 2. There are tons of great open source libraries and API for parsing / manipulating / generating. 3. It's really easy to hand-craft a test message for debugging. 4. The standards are much easier to read and write. They don't need to contain code like BIP-0070 currently does and they can contain examples, which BIP70 does not. 5. They are thoroughly specified by independent standards bodies such as the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard. 6. They're a family ;-) Keen to hear your thoughts on this and very keen to watch the payment protocol grow regardless of encoding choice! My background is SIP / VoIP and I think that could be a fascinating use case for this protocol which I'm hoping to do some work on. Best, Richard -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Text formats such as XML or JSON are far less deterministic, are more loosely specified, have wide variance in parsing, are not very hash-able, the list goes on. On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady rnbr...@gmail.com wrote: Hi Gavin, Mike and co Is there a strong driver behind the choice of Google Protocol Buffers for payment request encoding in BIP-0070? Performance doesn't feel that relevant when you think that: 1. Payment requests are not broadcast, this is a request / response flow, much more akin to a web request. 2. One would be cramming this data into a binary format just so you can then attach it to a no-so-binary format such as HTTP. Some great things about protocols/encodings such as HTTP/JSON/XML are: 1. They are human readable on-the-wire. No Wireshark plugin required, tcpdump or ngrep will do. 2. There are tons of great open source libraries and API for parsing / manipulating / generating. 3. It's really easy to hand-craft a test message for debugging. 4. The standards are much easier to read and write. They don't need to contain code like BIP-0070 currently does and they can contain examples, which BIP70 does not. 5. They are thoroughly specified by independent standards bodies such as the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard. 6. They're a family ;-) Keen to hear your thoughts on this and very keen to watch the payment protocol grow regardless of encoding choice! My background is SIP / VoIP and I think that could be a fascinating use case for this protocol which I'm hoping to do some work on. Best, Richard -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
ASN.1 is not nearly as flexible when it comes to well-supported libraries, generators, and the ecosystem that surrounds the actual encoding. You don't see ASN.1 compilers + language support packages for [all popular programming languages], as you do with protobufs. Google engineers were well aware it existed I'm sure. There are wider considerations beyond the low-level specified format. Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is far less developed in the programming ecosystem, far less approachable for programmers. BIP70 wouldn't have been as easily and widely adopted if ASN.1 had been chosen. On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock b...@mattwhitlock.name wrote: Even if a compact binary encoding is a high priority, there are more standard choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema. In practice, I'm mostly agnostic about what encoding is actually used in BIP70, and I wouldn't fault BIP70 for choosing Google Protocol Buffers, but the very existence of Protobuf perplexes me, as it apparently re-solves a problem that was solved 40 years ago by ASN.1. It's as though the engineers at Google weren't aware that ASN.1 existed. On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote: Hi Gavin, Mike and co Is there a strong driver behind the choice of Google Protocol Buffers for payment request encoding in BIP-0070? Performance doesn't feel that relevant when you think that: 1. Payment requests are not broadcast, this is a request / response flow, much more akin to a web request. 2. One would be cramming this data into a binary format just so you can then attach it to a no-so-binary format such as HTTP. Some great things about protocols/encodings such as HTTP/JSON/XML are: 1. They are human readable on-the-wire. No Wireshark plugin required, tcpdump or ngrep will do. 2. There are tons of great open source libraries and API for parsing / manipulating / generating. 3. It's really easy to hand-craft a test message for debugging. 4. The standards are much easier to read and write. They don't need to contain code like BIP-0070 currently does and they can contain examples, which BIP70 does not. 5. They are thoroughly specified by independent standards bodies such as the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard. 6. They're a family ;-) Keen to hear your thoughts on this and very keen to watch the payment protocol grow regardless of encoding choice! My background is SIP / VoIP and I think that could be a fascinating use case for this protocol which I'm hoping to do some work on. Best, Richard -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Correct. I should have said more likely to be deterministic Bitcoin Core does not *rely* on determinism in BIP70; I was referring to recent upstream efforts to make protobufs usable in a deterministic fashion by default. On Mon, Jan 19, 2015 at 3:03 PM, Alan Reiner etothe...@gmail.com wrote: I'm a bit confused. It's been a long time since I looked at protobuf (and will have to dig into it soon), but I seem to recall it doesn't have any of the determinism properties you guys just said. It is intended to allow you to skip details of the on-the-wire representations and just send a bunch of named fields between systems. I thought there was no guarantee that two identical protobuf structures will get serialized identically...? On 01/19/2015 02:57 PM, Richard Brady wrote: Thanks guys, great answers. The design choice certainly makes a lot more sense now regardless of whether one agrees with it or not. Regards, Richard -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant.http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
Sounds like this warrants a micro-BIP just to get everybody on the same page. On Wed, Jan 14, 2015 at 11:37 AM, Ruben de Vries ru...@blocktrail.com wrote: For p2sh multisig TXs the order of the public keys affect the hash and there doesn't seem to be an agreed upon way of sorting the public keys. If there would be a standard (recommended) way of sorting the public keys that would make it easier for services that implement some form of multisig to be compatible with each other without much hassle and making it possible to import keys from one service to another. I'm not suggesting forcing the order, just setting a standard to recommend, there doesn't seem to be much reason for (new) services to not follow that recommendation. Ryan from BitPay broad this up before ( https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in bitcore they've implemented lexicographical sorting on the hex of the public key. In a short search I can't find any other library that has a sorting function, let alone using it by default, so bitcore is currently my only reference. Ruben de Vries CTO, BlockTrail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY
Mike, Can you be more specific? You reference original design without saying how it was different/better. On Fri, Jan 9, 2015 at 8:20 AM, Mike Hearn m...@plan99.net wrote: A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. It's worth noting that the original protocol as designed by Satoshi did not have this limitation. It has evolved this way because of ad-hoc DoS fixes over time (btw I'm not saying they were the wrong thing to do, as non ad hoc solutions are significantly more work). But it seems like eventually a different approach to handling DoS attacks based on resource prioritisation and scheduling will become needed / implemented, and at that point the original design could be safely brought back to life. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Area of Focus
Getting back to the original topic... I would recommend first taking a look at how the current tests are built (via autoconf/automake) in src/test. There are several surfaces to test, RPC, REST, P2P, internal unit tests, and more. Then, Travis applies a second level of testing via the bitcoinj-based regression tests. Some automated tests that operate at the Qt level would be interesting. In general, the current tests only scratch the surface of what Needs To Be Tested... but part of figuring out a good test is (a) knowing bitcoin and (b) knowing the current test regimes. Join #bitcoin-dev IRC and ask questions. Read the bitcoin wiki. On Sat, Dec 20, 2014 at 2:42 AM, Will Bickford wbi...@gmail.com 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak btcd...@gmail.com wrote: We all want to see more modular code, but the first steps should just be to relocate blocks of code so everything is more logically organised in smaller files (especially for consensus critical code). Refactoring should come in a second wave preferably after a stable release. This is my opinion as well. In the Linux kernel, we often were faced with a situation where you have a One Big File driver with 1MB of source code. The first step was -always- raw code movement, a brain-dead breaking up of code into logical source code files. Refactoring of data structures comes after that. While not always money-critical, these drivers Had To Keep Working. We had several situations where we had active users, but zero hardware access for debugging, and zero access to the vendor knowledge (hardware documentation, engineers). Failure was not an option. ;p Performing the dumb Break Up Files step first means that future, more invasive data structures are easier to review, logically segregated, and not obscured by further code movement changes down the line. In code such as Bitcoin Core, it is important to think about the _patch stream_ and how to optimize for reviewer bandwidth. The current stream of refactoring is really a turn-off in terms of reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly. It is a seemingly never-ending series of tiny refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work. Some change is in order, gentlemen. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
If code movement is not compressed into a tight time window, code movement becomes a constant stream during development. A constant stream of code movement is a constant stream of patch breakage, for any patch or project not yet in-tree. The result is to increase the work and cost on any contributor whose patches are not immediately merged. For the record, since this is trending reddit, I __do__ support the end result of 0.10 refactoring, the work towards the consensus lib. My criticism is of a merge flow which _unintentionally_ rewards only certain types of patches, and creates disincentives for working on other types of patches. On Mon, Dec 15, 2014 at 4:19 PM, Cory Fields li...@coryfields.com wrote: On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik jgar...@bitpay.com wrote: On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields li...@coryfields.com wrote: That's exactly what happened during the modularization process, with the exception that the code movement and refactors happened in parallel rather than in series. But they _were_ done in separate logical chunks for the sake of easier review. That's exactly what was done except it wasn't Yes, in micro, at the pull request level, this happened * Code movement * Refactor At a macro level, that cycle was repeated many times, leading to the opposite end result: a lot of tiny movement/refactor/movement/refactor producing the review and patch annoyances described. It produces a blizzard of new files and new data structures, breaking a bunch of out-of-tree patches, complicating review quite a bit. If the vast majority of code movement is up front, followed by algebraic simplifications, followed by data structure work, further patches are easy to review/apply with less impact on unrelated code. I won't argue that at all because it's perfectly logical, but in practice that doesn't translate from the macro level to the micro level very well. At the micro level, minor code changes are almost always needed to accommodate useful code movement. Even if they're not required, it's often hard to justify code movement for the sake of code movement with the promise that it will be useful later. Rather than arguing hypotheticals, let's use a real example: https://github.com/bitcoin/bitcoin/pull/5118 . That one's pretty simple. The point of the PR was to unchain our openssl wrapper so that key operations could be performed by the consensus lib without dragging in bitcoind's structures. The first commit severs the dependencies. The second commit does the code movement from the now-freed wrapper. I'm having a hard time coming up with a workflow that would handle these two changes as _separate_ events, while making review easier. Note that I'm not attempting to argue with you here, rather I'm genuinely curious as to how you'd rather see this specific example (which is representative of most of my other code movement for the libbitcoinconsensus work, i believe) handled. Using your model above, I suppose we'd do the code movement first with the dependencies still intact as a pull request. At some later date, we'd sever the dependencies in the new files. I suppose you'd also prefer that I group a bunch of code-movement changes together into a single PR which needs little scrutiny, only verification that it's move-only. Once the code-movement PRs are merged, I can begin the cleanups which actually fix something. In practice, though, that'd be a massive headache for different reasons. Lots in flux with seemingly no benefits until some later date. My PR's can't depend on eachother because they don't actually fix issues in a linear fashion. That means that other devs can't depend on my PRs either for the same reason. And what have we gained? Do you find that assessment unreasonable? Cory -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
I don't recall being contacted directly, but the attack has been discussed. It relies on a number of conditions. For example, if you are over Tor, they try to kick the machine off Tor, _assuming_ that it will fall back to non-Tor. That's only true for dual stack nodes, which are not really 100% anonymous anyway -- you're operating from your public IP anyway. On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: This paper was just posted on reddit that describes how an attacker can de-anonymize clients on the bitcoin network. It mentions that the core devs were contacted prior to publication. I was just wondering, how many of these issues have already been addressed? Paper (University of Luxembourg): http://orbilu.uni.lu/handle/10993/18679 Kind regards, Jean-Paul -- 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=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
Overall, super duper awesome. :) Tweeted this post. I do have a concern about 2-of-2 arrangements. To me, this screams twice as fragile if not done properly; and I've seen a few naive implementations in the field that seemed quite fragile. 2FA/2-of-2 does solve the common problem of single device compromise. It also makes funds unspendable if -either- device's keys become lost. On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn m...@plan99.net wrote: Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ 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
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving problems not otherwise solvable with a hard fork. However, hard forks clearly have risks, notably the Big Risk akin to a US Constitutional Convention: once you open the door, anything can happen, any rule no matter how sacred can be changed. Soft forks are not without their own risks, e.g. reducing some things to SPV levels of security. Leaning towards soft fork, but it is a good discussion to have. A poorly implemented soft fork may potentially require a hard fork to fix rollout bugs. On Thu, Nov 6, 2014 at 11:05 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP62 and future script upgrades
On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: On another topic, I'm skeptical of the choice of nVersion==3 - we'll likely end up doing more block.nVersion increases in the future, and there's no reason to think they'll have anything to do with transactions. No sense creating a rule that'll be so quickly broken. Moderately agreed. Earlier in BIP 62 lifetime, I had commented on ambiguity that arose from bumping tx version simply because we were bumping block version. The ambiguity was corrected, but IMO remains symptomatic of potential problems and confusion down the road. Though I ACK'd the change, my general preference remains to disconnect TX and block version. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing regularity of block times?
That's what we do for testnet today: https://en.bitcoin.it/wiki/Testnet If no block is found for 20 minutes, one minimum-diff block may be mined. On Thu, Oct 30, 2014 at 7:18 PM, Rusty Russell ru...@rustcorp.com.au wrote: Hi all, I've been toying with an algorithm to place a ceiling on confirmation latency by allowing weaker blocks after a certain time. Hope this isn't noise, but thought someone must have considered this before, or know of flaws in the scheme? Gory details: http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html Thanks, Rusty. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Death by halving (pro-active proposals)
Seconded - IMO a key future use of the chain will be securing other chains. I'm interested in pursuing the merged-mining angle. Getting chain hashes to a miner, and getting that miner payment from the chain, is key to this. Consider a future where there are 10,000 chains secured by one block... On Wed, Oct 29, 2014 at 10:34 AM, Sergio Lerner sergioler...@certimix.com wrote: Instead of discussing what will happen when the subsidy is halved (which nobody really knows) maybe we can think about of what we can do to mitigate any damage in case something unwanted happens. Let's be proactive. For instance, any form of merged-mining (like higher frequency side-chains) will end-up increasing miners profit, even by a small margin. Then that margin can compensate miners not to turn off their equipment. Then we can encourage merge-mining on SHA-256, instead of discouraging SHA-256 alt-coins. Also we can encourage mining during the trouble period by creating a donation pool: suppose we manage to convince miners to donate 1% of their revenue in order to pay back to the miners for the first month after the reward halving. If every block pays 1% for 10 months, then every block during the first month of halving will earn 20% more. Of course, convincing miners of this may be difficult, but not impossible. It could be done automatically with nLockTime freeze of transactions with high fees, so no TTP is necessary. So here are two proposals, any other idea? Best regards, Sergio. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule
On Mon, Oct 27, 2014 at 7:24 AM, Melvin Carvalho melvincarva...@gmail.com wrote: Do you think it would a reasonable idea to put down some thoughts and proposals in a BIP? It would certainly be nice to start with a document that reflects the new REST interface. That makes a good starting point for further discussion. In general the interface exports what information is already available. As Wladimir notes, there is no plan to turn this into a full fledged block explorer, if that implies adding indices etc. Feedback on the HTTP headers and form, and additional thoughts proposals are welcome. My pull request is intended to present something minimal, that is easy to review and merge. My own list of further to-dos includes * last-modified and etag headers * export UTXOs a la Mike Hearn's getutxos query * eventually rebuild the RPC server to something multithreaded a la https://github.com/jgarzik/rpcsrv PR #2844 @ https://github.com/bitcoin/bitcoin/pull/2844 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] death by halving
On Sat, Oct 25, 2014 at 2:06 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: Hashrate might drop by more than 50% immediately after the halving (and before difficulty is updated), thus a combination of the halving and slow difficulty update pose a real threat. Flag day herd behavior like this is unlikely for well informed and well prepared market participants. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] death by halving
It is an overly-simplistic miner model to assume altruism is necessary. The hashpower market is maturing in the direction of financial instruments, where the owner of the hashpower is not necessarily the one receiving income. These are becoming tradeable instruments, and derivatives and hedging are built on top of that. Risk is hedged at each layer. Market players also forge agreements with miners, and receive -negative- value if hashpower is simply shut down. Simplistic models cannot predict what hashpower does in the face of business-to-business medium- and long-term contracts. On Sat, Oct 25, 2014 at 2:22 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: Flag day herd behavior like this is unlikely for well informed and well prepared market participants. It is simply rational to turn your mining device off until difficulty adjusts. Keeping mining for 2+ weeks when it costs you money is an altruistic behavior, we shouldn't rely on this. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)
Take the discussion of this site to another M-L, please. It is off-topic. Actual discussion of the paper and side-chains is on-topic. This M-L is publicly archived. On Wed, Oct 22, 2014 at 6:52 PM, Daniel Murrell dsmurr...@gmail.com wrote: Sorry Bryan, this was the first paper posted to this list since I've been on it that I added to my site. I was quite excited about this. I was not planning on and certainly won't be making this advertisement after every paper posted on this list (I may do it on reddit). I did post on reddit a few times yes, but I assumed that this list's user base didn't overlap extremely (does it?). I'm not sure why my posts got down voted there. The down voters gave me no constructive feedback about the usefulness of my site, and neither have you. Are you able to give me your feedback on the site I've spent quite some time setting up privately so that we don't spam this list again? On Wed, Oct 22, 2014 at 11:35 PM, Bryan Bishop kanz...@gmail.com wrote: On Wed, Oct 22, 2014 at 5:01 PM, Daniel Murrell dsmurr...@gmail.com wrote: p.s. I'm not trying to monetize this site. I just tried to make something I thought could be useful. [Unsolicited administrivia follows.] You have been posting this in a bunch of places for a while now, at least three times today by my count on other mediums. I also observed negative karma scores associated with these posts. Maybe you could consider toning down the message frequency? I think by now everyone knows you want them to use your site. I also think that in the limit that it would be inappropriate for /everyone/ to post all possible research sites, or even vaguely topical discussion sites, for every paper posted. Personally, I would much rather have discussions happen on the mailing list anyway, although if I had a different opinion I certainly hope I would still send this message. Thank you. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue
The whole issue is a troll, and I'm afraid you got sucked in. There are no plans to add a blacklist to Bitcoin Core. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
[Bitcoin-development] Applying clang-format to Bitcoin Core
We are slowly applying a consistent style to the C++ source, via clang-format (LLVM) and $repo/src/.clang-format. If you have a patch that is difficult to apply to the tree due to reformatting, simply apply clang-format and then rediff. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander tho...@thomaszander.se wrote: Any and all PGP related howtos will tell you that you should not trust or sign a formerly-untrusted PGP (or GPG for that matter) key without seeing that person in real life, verifying their identity etc. Such guidelines are a perfect example of why PGP WoT is useless and stupid geek wanking. A person's behavioural signature is what is relevant. We know how Satoshi coded and wrote. It was the online Satoshi with which we interacted. The online Satoshi's PGP signature would be fine... assuming he established a pattern of use. As another example, I know the code contributions and PGP key signed by the online entity known as sipa. At a bitcoin conf I met a person with photo id labelled Pieter Wuille who claimed to be sipa, but that could have been an actor. Absent a laborious and boring signed challenge process, for all we know, sipa is a supercomputing cluster of 500 gnomes. The point is, the online entity known as Satoshi is the relevant fingerprint. That is easily established without any in-person meetings. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
It applies to OP, bitcoin community development and Satoshi. value of in person vetting of identity is undeniable... no it is quite deniable. Satoshi is the quintessential example. We value brain output, code. The real world identity is irrelevant to whether or not bitcoin continues to function. The currency of bitcoin development is code, and electronic messages describing cryptographic theses. _That_ is the relevant fingerprint. Governmental id is second class, can be forged or simply present a different individual from that who is online. PGP WoT wanking does not solve that problem at all. On Mon, Sep 15, 2014 at 9:32 AM, Brian Hoffman brianchoff...@gmail.com wrote: I would agree that the in person aspect of the WoT is frustrating, but to dismiss this as geek wanking is the pot calling the kettle. The value of in person vetting of identity is undeniable. Just because your risk acceptance is difference doesn't make it wanking. Please go see if you can get any kind of governmental clearance of credential without in-person vetting. Ask them if they accept your behavioral signature. I know there is a lot of PGP hating these days but this comment doesn't necessarily apply to every situation. On Sep 15, 2014, at 9:08 AM, Jeff Garzik jgar...@bitpay.com wrote: On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander tho...@thomaszander.se wrote: Any and all PGP related howtos will tell you that you should not trust or sign a formerly-untrusted PGP (or GPG for that matter) key without seeing that person in real life, verifying their identity etc. Such guidelines are a perfect example of why PGP WoT is useless and stupid geek wanking. A person's behavioural signature is what is relevant. We know how Satoshi coded and wrote. It was the online Satoshi with which we interacted. The online Satoshi's PGP signature would be fine... assuming he established a pattern of use. As another example, I know the code contributions and PGP key signed by the online entity known as sipa. At a bitcoin conf I met a person with photo id labelled Pieter Wuille who claimed to be sipa, but that could have been an actor. Absent a laborious and boring signed challenge process, for all we know, sipa is a supercomputing cluster of 500 gnomes. The point is, the online entity known as Satoshi is the relevant fingerprint. That is easily established without any in-person meetings. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP72 amendment proposal
Indeed -- Every byte added to the QR code makes it more difficult to be used in restaurants, pubs and other low-light conditions. BitPay tested some of these scenarios. Scannability is absolutely impacted. On Fri, Sep 12, 2014 at 9:49 AM, Mike Hearn m...@plan99.net wrote: A few thoughts on this: (1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk here is that a MITM intercepts the payment request, which will be typically requested just seconds after the QR code is vended. 80 bits of entropy would still be a lot and take a long time to brute force, whilst keeping QR codes more compact, which impacts scannability. (2) This should not be necessary in the common HTTPS context. The QR code itself is going to be fetched from some service, over HTTPS. I see no reasonable attacker that can MITM the request for the BIP70 message but not the request to get the QR code. Adding a hash makes QR codes more bloated and harder to scan, all on the assumption that HTTPS is broken in some odd way that we haven't actually ever seen in practice. (3) This can be useful in the Bluetooth context, but then again, we could also do things a different way by signing with the key in the first part of the URI, thus avoiding the need for a hash. I know I've been around the loop on this one with Andreas many times. But this BIP doesn't fix any actually existing problem in the previous spec. It exists because Andreas thinks SSL is useless. If SSL is useless we all have much bigger problems. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Reconsidering github
It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as github, nice and convenient as it is. To that end, I note that Linux does its own git repo, and now requires 2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication As a first step, one possibility is putting the primary repo on bitcoin.org somewhere, and simply mirroring that to github for each push. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
Encryption is of little value if you may deduce the same information by observing packet sizes and timings. On Tue, Aug 19, 2014 at 7:38 PM, J Ross Nicoll j...@jrn.me.uk wrote: The concern is that if you can monitor traffic in and out of a single node, you can determine which transactions originate from it vs those which it relays. That's not great, certainly, but how many nodes actually require that level of security, and surely they can use Tor or VPN services if so? Further, unless the remote nodes are in some way trusted, you're changing the attack from read-only to requiring the ability to perform a man in the middle attack - that doesn't seem much harder to me. As Gregory states, there's been at least two recent serious if not catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin network had been vulnerable are the stuff of nightmares. Very difficult to see the risk/reward payoff being worthwhile. Ross On 19/08/2014 18:35, Johnathan Corgan wrote: On 08/19/2014 09:38 AM, Gregory Maxwell wrote: We've dodged several emergency scale vulnerabilities by not having TLS. I'm still trying to understand the original premise that we want encrypted communications between nodes. I can certainly see the value of having *authenticated* traffic with specific nodes, using an HMAC for the protocol messages in place of the current checksum. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote: On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote: Encryption is of little value if you may deduce the same information by observing packet sizes and timings. That is simply incorrect. The resources required to do that kind of monitoring are very high; even the NSA can't pull it off consistently for Hardly. For example, when a new block arrives on the network, a single observer at a single location may obtain a binary likely|not bitcoin protocol decision from a spike in usage correlated with sudden, global network activity after a period of inactivity. I'll not detail all such metrics. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Outbound connections rotation
Simply by observing timing from sufficiently geo-graphically and network-ly dispersed nodes, you may deduce the original broadcaster of a transaction. Rotating peers doesn't help. That said, periodic rotation can be helpful. Every 2-10 minutes is excessive. On Mon, Aug 18, 2014 at 12:46 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Motivation: Each bitcoin non-UPnP client behind NAT has 8 outbound connections which change only rarely (due to occasional remote side disconnections). A subset of these 8 entry nodes uniquely identifies a user. An attacker can listen for transactions in Bitcoin network and for each transaction record the first 8 peers which forwarded the transaction. If two distinct transactions (with unrelated bitcoin addresses) come from the same set of 8 peers, the attacker can conclude that they originated from the same user. This gives another method (in addition to transaction graph analysis) for an attacker to link different BC addresses of the same user. Also note that by default bitcoin clients advertise their public IP addresses. The attacker can link the advertised IP's to corresponding 8 entry nodes and use it to deanonymise Bitcoin clients. If a bitcoin client periodically rotates his set of outbound connections, his 8-peers fingerprint is blurred over time. Corresponding pull request is #4723. Some details are here: https://www.cryptolux.org/index.php/Bitcoin -- Ivan -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Synchronization: 19.5 % orphaned blocks at height 197'324
This issue is being worked on, under the category of headers first synchronization. Until that is finished, it is recommended that you download bootstrap.dat via torrent: https://bitcointalk.org/index.php?topic=145386.0 On Sun, Aug 10, 2014 at 9:42 AM, m...@bitwatch.co m...@bitwatch.co wrote: Hello all, I'm currently synchronizing a new node and right now, at a progress of a height of 197'324 blocks, I count in my debug.log an aweful amount of 38'447 orphaned blocks which is about 19.5 %. It has been I while since I watched the synchronization process closely, but this number seems pretty high to me. I'm wondering about the following: would it be possible for a malicious party to generate chains of blocks with low difficulity which are not part of the main chain to slow down the sync process? Build and version information: https://github.com/jmcorgan/bitcoin/tree/026686c7de76dfde6fcacfc3d667fb3418a946a7 (sipa/jmcorgan address index) Rebased with: https://github.com/bitcoin/bitcoin/tree/94e1b9e05b96e4fe639e5b07b7a53ea216170962 (almost up-to-date mainline) Compressed debug.log attached: https://www.dropbox.com/s/uvtd91xiwmdmun7/debug.7z?m= (filesize: 7.67 MB, uncompressed: 41.3 MB) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
This is not a generic I run a website! advertisement feature. NODE_EXT_SERVICES is tightly focused on services that exist if-any-only-if a P2P bitcoin node (bitcoind) is reachable via the same advertised address. You may usefully create overlay networks of specialized services. On Fri, Aug 8, 2014 at 6:41 AM, Christian Decker decker.christ...@gmail.com wrote: I wonder whether we actually want to support this kind of advertisement in the P2P protocol. We have a working mechanism for protocol extensions in the P2P network (service flags) so this is obviously only for services that are not P2P extensions, so why have them in there at all? I'd argue that a parallel network, external to Bitcoin, could take over the task of advertising external services. Regards, Chris -- Christian Decker On Fri, Aug 8, 2014 at 11:26 AM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net wrote: He wants to use it to advertise services that are not part of the P2P protocol itself, but run on a different port. Reserving services bits for those is not acceptable. Why not? Does the port matter much? Yes. The services bits are for advertising services on the P2P network. That's not open for discussion. It also wouldn't work. A bit is not enough to find an external service except in the naive case where the advertised service would have a fixed port. Not even bitcoind has a fixed port. So there needs to be a mechanism to find how to connect to the 'external service'. This is provided by the proposed extension. It would in principle be possible to advertise an extra service bit *in addition to* this one, to make it easier to find through the addr mechanism. But it would be confusing and IMO an abuse of P2P service bits. 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] NODE_EXT_SERVICES and advertising related services
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn m...@plan99.net wrote: What's wrong with the existing mechanism exactly? It would be wrong to add NODE_INSIGHT, NODE_ELECTRUM_SERVER, etc. bits even though you do have useful bitcoin-related APIs that exist on the same system as bitcoind. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] NODE_EXT_SERVICES and advertising related services
Yes, that is the one change I am still pondering: adding categories (classes), rather than one single bit. Thus the modified proposal would become: - eliminate NODE_EXT_SERVICES - for a class of services, such as insight w/ added blockchain indexes queries, add NODE_EXT_INDEXED_CHAIN - for another class of services, add NODE_EXT_ - Re-use the same P2P message and structure (CExtService, extservices P2P message) for all NODE_EXT_xxx classes. This preserves vendor/API neutrality, while saving effort on the part of clients seeking these services. The point about service discovery necessitating some node walking is valid, which makes categories somewhat attractive. Having the service run on some arbitrary other port isn't particularly useful, IMO -- A statement disproved by reality. Multi-port is the method most commonly found in the field today. Logically so, because it is the easiest to deploy: * The most likely setup TODAY is multi-daemon: bitcoind + your own software * The most likely configuration for multi-daemon is self-evidently multi-port (versus two services appearing on the same port) It is quite useful, and indeed, the most likely setup to be found in operation. On Fri, Aug 8, 2014 at 7:38 AM, Mike Hearn m...@plan99.net wrote: I'd like to see a mechanism whereby a Bitcoin node can delegate processing of unknown messages to an external process, so a P2P node can be composed out of separated programs, but such a service would be indistinguishable at the network layer from one provided by Bitcoin Core itself, so a service bit would be appropriate for those. For instance, Insight could then offer a command set that extends the p2p protocol for doing block explorer type queries. There's no need for the protocol to be Insight specific. You'd just have NODE_INDEXED_CHAIN instead. Having the service run on some arbitrary other port isn't particularly useful, IMO - the biggest win from having some separated protocol would be the ability to use TLS, but if you're connecting to an IP address rather than a domain name (like if you discovered via service bits/getextsrv) this doesn't add much. It boils down to minor syntax differences in how numbers are laid out in a grid. And the performance issue remains. Additionally, nothing in this spec requires that a local bitcoind be running. What stops someone from advertising just NODE_EXTENDED_SERVICES and nothing else? I don't think a generic service advertisement mechanism is a bad thing to have, by the way, just pointing out that nothing makes this more focused than service bits already are. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir laa...@gmail.com wrote: On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn m...@plan99.net wrote: I'd like to see a mechanism whereby a Bitcoin node can delegate processing of unknown messages to an external process, so a P2P node can be composed out of separated programs, but such a service would be indistinguishable at the network layer from one provided by Bitcoin Core itself, so a service bit would be appropriate for those. This diverges from the topic but seems like a good idea to me in general, not so much as replacement for jgarzik's proposal. Something like `getutxos` or this proposal could be implemented as an external application or script, instead of having to integrate everything into bitcoind. Seconded. Command plug-ins and such seem like an idea worth exploring. We don't need to shove everything into bitcoind. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] NODE_EXT_SERVICES and advertising related services
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir laa...@gmail.com wrote: Bitcoind would need a local interprocess message bus for that, and would need to act as router for messages from/to the P2P network. ZeroMQ seems like a good choice for that. That's not completely crazy as there are already plans to add zeromq as an optional dependency for notifications [1]. Generally agreed, though for ZMQ it is a bit different than a P2P service. IMO, ZMQ really wants to be a plug-in that registers some internal signals. It wants to capture the precise points where a block was accepted internally. PR #4599 tries to lead by example: https://github.com/bitcoin/bitcoin/pull/4599 A P2P service would be a slightly different sort of plug-in. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] NODE_EXT_SERVICES and advertising related services
getutxos is a special case, since we already maintain that index as part of normal operation. While I dislike some aspects of getutxos (covered elsewhere), if merged, it would be more appropriate as a special case to keep getutxos fully internal to bitcoind for implementation reasons. On Fri, Aug 8, 2014 at 8:11 AM, Mike Hearn m...@plan99.net wrote: Something like `getutxos` or this proposal could be implemented as an external application or script, instead of having to integrate everything into bitcoind. Right, although getutxos needs access to the UTXO set which bitcoind already has. An external plugin would have to recalculate it from scratch which seems redundant. However there are many other useful services that could be added in such a way, like -txindex or the nLockTime storage facility we talked about the other day. Bitcoind would need a local interprocess message bus for that Maybe, that feels like it could be overkill though. Probably just something like ./bitcoind -servicecookie=long random string -allowextservices=127.0.0.1/8 and then any program can connect to bitcoind as normal, send registersrv with the cookie and a list of command ids it's interested in, maybe a service bit to set, and start receiving those messages wrapped in a new structure that gives some kind of client ID (like IP address). So any library that can do the basic P2P protocol could then be extended with not much code to get a multiplexed stream of messages from different clients. An additional standalone program can then bridge this mechanism to running a shell command for particular messages, though given the history of shell based exploits I'd feel safer with something that doesn't do that -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] deterministic transaction expiration
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding t...@thinlink.com wrote: 4. add a new IsStandard rule rejecting transactions with an nLockTime more than N blocks behind the current tip (for some fixed value N, to be determined) It cannot be assumed that transaction creation time and transaction publish-to-outside-world time are the same, even though they often are. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Miners MiTM
gmaxwell noted on IRC that enabling TLS could be functionally, if not literally, a DoS on the pool servers. Hence the thought towards a more lightweight method that simply prevents client payout redirection + server impersonation. On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn m...@plan99.net wrote: Certificate validation isn't needed unless the attacker can do a direct MITM at connection time, which is a lot harder to maintain than injecting a client.reconnect. Surely the TCP connection will be reset once the route reconfiguration is completed, either by the MITM server or by the client TCP stack when it discovers the server doesn't know about the connection anymore? TLS without cert validation defeats the point, you can still be connected to a MITM at any point by anyone who can simply interrupt or corrupt the stream, forcing a reconnect. -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
[Bitcoin-development] NODE_EXT_SERVICES and advertising related services
Link: https://github.com/bitcoin/bitcoin/pull/4657 It is not necessary to build all functionality into bitcoind, to form a decentralized network. BitPay's insight open source block explorer API project requires, and runs on top of, bitcoind. Therefore, at the same IP address as bitcoind, other services are made available to the public (scriptPubkey queries, other added-value queries). This results in a decentralized network of anyone running a full node and an insight server, as a subset of the whole P2P net. One then does not need to trust BitPay's insight server, but may query any number of insight servers from multiple operators, and survey the results. Obviously, we want to build this in a generic, vendor-neutral way. As such, NODE_EXT_SERVICES is advertised via the addr P2P message. Nodes that recognize the NODE_EXT_SERVICES bit may connect to that node, query a services list via getextsrv P2P message, and then take further action based on the results. The results are quite straightforward: service name, service port (or -1 if undefined), list of string key/value attribs Services may only advertise added services if and only if the external services are at the same IP address that is being advertised. This is not a fully baked proposal by any means, but more of a trial balloon to get discussion moving. There is no need to implement all services inside bitcoind... -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] deterministic transaction expiration
...because nLockTime is the exact opposite of expiration. A locked TX begins life invalid, and becomes valid (not-expired) after nLockTime passes. A new field containing expiration time would work. On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding t...@thinlink.com wrote: How is eventual expiration of a tx that started life with an nLockTime in the future breaking, any more than any other tx expiring? On 8/6/2014 6:54 AM, Mike Hearn wrote: We could however introduce a new field in a new tx version. We know we need to rev the format at some point anyway. On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik jgar...@bitpay.com wrote: ...and existing users and uses of nLockTime suddenly become worthless, breaking payment channel refunds and other active uses of nLockTime. You cannot assume the user is around to rewrite their nLockTime, if it fails to be confirmed before some arbitrary deadline being set. On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding t...@thinlink.com wrote: ... If nLockTime is used for expiration, transaction creator can't lie to help tx live longer without pushing initial confirmation eligibility into the future. Very pretty. It would also enable fill or kill transactions with a backdated nLockTime, which must be confirmed in a few blocks, or start vanishing from mempools. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
A fork is not necessarily required, if you are talking about information that deals primarily with pre-consensus mempool behavior. You can make a network TX with some information that is digitally signed, yet discarded before it reaches miners. On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker decker.christ...@gmail.com wrote: +1 for the new field, overloading fields with new meaning is definitely not a good idea. To add a new field the best way to do it is create a new, parallel, tx format where fields are committed by merkle radix tree in an extensible and provable way. You'd then commit to that tree with a mandatory OP_RETURN output in the last txout, or with a new merkle root. Changing the tx format itself in a hard-fork is needlessly disruptive, and in this case, wastes opportunities for improvement. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+ Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6 //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2 sJKN =oPSo -END PGP SIGNATURE- -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
That won't necessarily work through large reorgs. You don't want to create a situation where a miner cannot mine a previously mined transactions. On Wed, Aug 6, 2014 at 1:02 PM, Tom Harding t...@thinlink.com wrote: Today we have first-eligible-height (nLockTime), and mempool expiration measured from this height would work for the goals being discussed, no fork or protocol rev. With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition, lock the whole thing until some point in the future. On 8/6/2014 9:15 AM, Jeff Garzik wrote: A fork is not necessarily required, if you are talking about information that deals primarily with pre-consensus mempool behavior. You can make a network TX with some information that is digitally signed, yet discarded before it reaches miners. On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker decker.christ...@gmail.com wrote: +1 for the new field, overloading fields with new meaning is definitely not a good idea. To add a new field the best way to do it is create a new, parallel, tx format where fields are committed by merkle radix tree in an extensible and provable way. You'd then commit to that tree with a mandatory OP_RETURN output in the last txout, or with a new merkle root. Changing the tx format itself in a hard-fork is needlessly disruptive, and in this case, wastes opportunities for improvement. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+ Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6 //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2 sJKN =oPSo -END PGP SIGNATURE- -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future.http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] How to create a pull tester JAR
Thanks for posting that (and implicitly archiving the knowledge). Anything that makes test improvement easier is welcomed. On Tue, Aug 5, 2014 at 11:00 AM, Mike Hearn m...@plan99.net wrote: I just checked in a change to bitcoinj git master that makes it much easier to create a pull tester jar. Here are instructions for how to do it. You will need: - A Java Development Kit (JDK), version 6 or up should work. As Java 6 was released eight years ago, this should not be a challenging requirement. If you have a Mac just running java from the command line should give you a GUI prompt to install it automatically. Otherwise apt-get or fetch the latest from the interwebs. - Apache Maven. This is a rough equivalent of autotools, except it does dependency resolution for you. Grab it from http://maven.apache.org/download.cgi then unzip it and make sure the bin directory is in your PATH. You may need to set the JAVA_HOME environment variable if you installed Java to an odd place. - git Make sure you can run javac from the command line, then make sure you can run mvn, it should complain it can't find a POM (this is a build config file) and not, say, that it can't find Java. Now grab bitcoinj from git master: git clone https://github.com/bitcoinj/bitcoinj.git ... and build cd bitcoinj mvn -DskipTests package It will go off and download the libraries needed, compile, and create a bundled executable JAR called core/target/pull-tests.jar. This is sort of analogous to static linking in the Java world. It should be fast - expect a full build plus downloads to take less than a minute. You can use it either with the QA scripts in the bitcoin core qa/pull-tester directory or just run things directly: ./bitcoind -regtest -connect=0.0.0.0 -listen -whitelist=127.0.0.1 -datadir=/tmp/pulltester java -jar core/target/pull-tests.jar It should go ahead and print lots of debug spew, then at the end say it's happy. Let me know if you encounter any problems with this. Java JARs (which are just zip files renamed) are easily reproduced if you use the same version of javac and the same bitcoinj version. The ZIP container has timestamps, but unzipping them and simply diffing the files between two builds should reveal no differences. I am happy to provide a pull-tests.jar from my local machine if anyone would like to do this. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
Glad this was brought up. Transaction expiration is something that I have wanted to see happen in bitcoin for a long, long time. The user experience of unconfirming transactions setting around in limbo is just horrible. Bitcoin software by necessity has gotten better about attaching fees so this sort of behavior is uncommon, but that does not eliminate the problem. Of course, we cannot presume that a transaction will truly disappear -- The Internet Never Forgets -- but given a bit of mempool adjusting, we can achieve the next best thing: the majority of the network forgets the transaction and becomes willing to relay a respend of some or all of the inputs. This uses existing client logic where the client must rebroadcast a transaction until it is confirmed. In general, if a transaction has not made it into a block within 144*X blocks, there is _some_ reason it is getting rejected by the miners. The mempool janitor is a garbage collector design. This is inferior to the superblock model described at https://github.com/bitcoin/bitcoin/issues/3723 Other models can also achieve similar results. There are a lot of issues tied together here: transaction expiration, the desire to cap the mempool ram usage, scalability, DoS prevention, ... mempool ties a lot together. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
I feel like a lot of this will be driven by implementation, and costs of changing the implementation. Additional look-backs are of course doable, but they incur some disk I/O costs. The fields available in memory for each mempool TX are uint256 tx_hash; // hash of next field CTransaction tx; int64_t nFee; // Cached to avoid expensive parent-transaction lookups size_t nTxSize; // ... and avoid recomputing tx size int64_t nTime; // Local time when entering the mempool double dPriority; // Priority when entering the mempool unsigned int nHeight; // Chain height when entering the mempool As a first pass, we may prune the mempool without additional db lookups quite easily based on time criteria. Or, additional in-memory indexes may be constructed to maintain hashes ordered by priority/fees. Those techniques seem likely to be attempted before resorting to looking back two or three TXs deep at coin age -- which I admit is an interesting metric. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
On Tue, Aug 5, 2014 at 3:10 PM, Kaz Wesley kezi...@gmail.com wrote: Any approach based on beginning a transaction expiry countdown when a transaction is received (as in mempool janitor) seems unviable to me: ... That's why I think including information in the transaction itself, as with my nLockTime/IsStandard proposal, is necessary for transactions to reliably eventually die off from mempools. reliably die off from mempools leads into the land of tightly synchronizing memory pools across the network which is a problem of... large scope and much debate. :) For the moment, simply capping the mempool's size at each local node is a much more reachable goal. Capping, then, implies some culling policy. In general, bitcoind Tx mempool size is rather open ended, and that needs sorting out. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Abusive and broken bitcoin seeders
Seeing this on one of my public nodes: 2014-07-30 13:13:26 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11847 2014-07-30 13:13:33 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=29, us=162.219.2.72:8333, peer=11848 2014-07-30 13:14:21 receive version message: /getaddr.bitnodes.io:0.1/: version 70001, blocks=313169, us=162.219.2.72:8333, peer=11849 That is abusive, taking up public slots. There is no reason to connect so rapidly to the same node. Other seeders are also rapidly reconnect'ers, though the time window is slightly more wide: 2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=162.219.2.72:8333, peer=11843 2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/: version 6, blocks=23, us=162.219.2.72:8333, peer=11846 The version message helpfully tells me my own IP address but not theirs ;p -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
Miners are free to set the block's timestamp to whatever they please, within a certain +/- time window. Time might even go backwards a tiny bit from the last block to the next block. On Thu, Jul 24, 2014 at 9:14 PM, Ron OHara ron.ohar...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I thought I should shortcut my research by asking a direct question here. As I understand it, the blockchain actually provides an extra piece of reliable data that is not being exploited by applications. Which data? The time. In this case 'the time' as agreed by 50% of the participants, where those participants have a strong financial incentive to keep that 'time' fairly accurate. (+/- about 10 minutes) Is this a reasonable understanding of 'time'? ... aka timestamps on the block Ok... 'time' on the blockchain could be 'gamed' ... but with great difficulty. An application presented with a fake blockchain can use quite a few heuristics to test the 'validity' of the block chain. It can review the usual cryptographic proofs, and check that difficulty is growing/declining only in a realistic manner up to the most recent block. Even use some arbitrary test like difficulty 10,000,000,000 ... on the presumption that any less means that the Bitcoin system has failed massively from where it currently is and has become an unreliable time source. Reliable 'time' has been impossible up until now - because you need to trust the time source, and that can always be faked. Using the blockchain as an approximate time source gives you a world wide consensus without direct trust of any player. So if this presumption is correct, then we can now build time capsule applications that can not be tricked into exposing their contents too early by running them in a virtual environment with the wrong system time. Is this right? or did miss I something fundamental? Ron - -- public identify: https://www.onename.io/ron_ohara -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4 hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc= =T5fw -END PGP SIGNATURE- -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Decentralizing ming
Before they got traction, yes. But he projected a bit, as anyone could, to see the trend. On Thu, Jul 17, 2014 at 1:22 PM, slush sl...@centrum.cz wrote: On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik jgar...@bitpay.com wrote: Historical note: On one hand, Satoshi seemed to dislike the early emergence of GPU mining pools quite a bit. To my knowledge, Satoshi left the project before mining pools got a traction. slush -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Decentralizing ming
Yes. That, and several other things. If you can figure out how to propagate a block without re-propagating all the transactions everyone already has, you address the large-blocks-slower-to-relay problem, and additionally create an incentive for miners to mine blocks consisting of publicly broadcast transactions (versus a bunch of secret ones mined with secret agreements). Democratizing transaction selection takes a bit of power away from the miners and gives it back to the network at large. GBT is another piece of that puzzle. On Fri, Jul 18, 2014 at 6:43 AM, Mike Hearn m...@plan99.net wrote: Oops, sorry, I see the subject line changed. This is what I get for working down the thread list top to bottom :) I think the best path forward now is to finish off getblocktemplate support in the various tools so it's possible to pool for payout purposes without giving up control of block creation modulo the coinbase. Combined with the recent sipa performance enhancing goodness, it would hopefully persuade some non-trivial chunk of hashpower to go back to running their own node and start the process of turning pools merely into payout trackers rather than block selectors. On Fri, Jul 18, 2014 at 12:41 PM, Mike Hearn m...@plan99.net wrote: Jeff, I think the message you're replying to got clipped. Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a gentlemen's agreement to postpone it as long as possible, to help make sure the distribution of coins was as even as possible. Indeed this predated pooled mining. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Squashing redundant tx data in blocks on the wire
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen gavinandre...@gmail.com wrote: I'd encourage you to code up a prototype first (or at the same time), in whatever programming language / networking library you're most familiar with. +1 Maybe not even using the existing p2p protocol; there could be a mining-only very-fast-block-propagation network separate from the existing p2p network. Combining your optimizations with broadcast as many near-miss blocks as bandwidth will allow on a mining backbone network should allow insanely fast propagation of most newly solved blocks. Yes, I would encourage thinking along these lines. That was the motivation of the UDP P2P protocol extension I wrote: https://bitcointalk.org/index.php?topic=156769.0 The intention was to experiment with sending block header + tx list + coinbase, via UDP best effort broadcast. Incentives: If your neighbors receiving this message already have the TXs in the TX list, then the block is complete, and may be relayed further. If your neighbors do not have all TXs in the block, they must fetch them at additional time/latency cost. Thus, you have an incentive to relay blocks containing TXs already distributed out into network mempools and cached in the signature cache. We want to capture that incentive in whatever protocol is eventually used. Miners have a TX fee incentive to include many transactions. In theory, they want to include as many TX as possible. It will help us scale quite a bit to solve this problem. -- 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] Squashing redundant tx data in blocks on the wire
On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen gavinandre...@gmail.com wrote: But if there was some agreed-upon canonical ordering, then it should theoretically be possible to take shortcuts in the what order. You'd start with setof(transactions I think everybody knows about) Select some subset, based on miner's policy Sort that subset with the canonical ordering algorithm Very efficiently broadcast, taking all sorts of shortcuts assuming most of your peers already know the set you started with and expect the same canonical ordering (see gmaxwell's thoughts on block encoding). Related implementation detail: Having pursued this train of thought, I noted that you don't want to include too-young transactions that you received in the past few seconds, because those are likely still propagating around the network. Second half-baked thought: I wonder if broadcasting your transaction selection policy (11KB of free transactions, sorted by priority, then 111K of fee-paying transactions, sorted by fee) might make it possible to save even more bandwidth by letting your peers create a very good approximation of your block with just that information Absolutely. One path I would like to see pursued is multiple p2pool-esque chains. Each with their own policy, perhaps with their own administrative team. ie. you could have a fully decentralized p2pool-like chain, or multiple such chains, each with a stated policy/reward pattern. Or, GHash/BTCGuild/Eligius could run a semi-centrally managed chain ultimately guaranteed not only by protocol but by administrators' digital signatures. In each case, advertising technical attributes about your pool [chain] policy would give nodes the better ability to predict what is in an upcoming block. And the flip side of that, such predictions are never perfect. Need to make sure the fallback case, while undoubtedly more costly than the Fast Path, is not overly painful. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Squashing redundant tx data in blocks on the wire
On a flood-fill network, you don't want to create a storm of I already have this replies. On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley kezi...@gmail.com wrote: Peers exchanging mempool priority policies is great; that accomplishes the flexibility in what txes to remember that I was going for with the forget-filters, but much more neatly, with less overhead and some side benefits. Here's what I'm picturing now: - exchange priority policies in peer introductions - assign unique sequential IDs in the order the transactions were inved (per peer) - receiving a getdata for a tx updates last-known-peer-received inv to all invs up to the one referenced - include ID-last-received, last-known-peer-received in sparse block - reference txes in sparse block by index in receiver's prioritiziation with peer's sent invs up to ID-last-received and sender's prior invs up to last-known-peer-received Possible new messages: - sparseblock - invack message a node can send at times when it's received a bunch of invs it already has, so it hasn't acked with a getdata in a while - gettx: getdata, but using new sequential ID to save 28 bytes per tx It seems important for ordering policies to be able to be specified in as much detail as possible. Parameters that should be available: - total inputs - total outputs - bytes - coin days destroyed - net UTXO size change - sigops - is data carrier - is output raw multisig - age in mempool - what else? This parameter set should be extensible to allow for unforeseen future factors. Ordering policies should allow arbitrary algebraic combinations of their parameters, as well as thresholds. Boolean combinations of sub-policies would also be desirable. This could be implemented with a tx-script-like stack-based language, in which each supported tx property is pushed onto the stack by a particular opcode, and +-*//min/max/boolean operators combine them to yield the sort key. Difficult parameters: * Coin-days-destroyed: changes, peers need agreement on when (if?) it's recalculated. Probably can just not recalculate, but peers still need agreement on time seen to get CDD. * Age in mempool: seems intractable in terms of time, but could be done easily in terms of how many txes old is this sequential ID One potential pitfall: this allows for an environment of completely heterogeneous mempool policies. I think that's a good thing, but we need to avoid a situation where only least-common-denominator transactions make it farther than a hop or two, and we don't want nodes to have a strong preference for connecting to like-minded peers since clustering reduces overall connectivity. It may be worthwhile to add a parallel mechanism for relay policies, to differentiate between what a node would keep in its mempool vs. what it wouldn't even relay and doesn't want to see at all. Relay policies could be specified just like prioritization policies, but with the final stack value evaluated in a boolean context. An interesting additional use of policy-scripts would be a standardized way for miners to include a policy script in a coinbase, allowing miners a mechanism to advertise things like their relative price of sigops vs bytes. Nodes may then choose to take this information into account in order to optimize their mempool policies for likelihood of consistency with future blocks. Since policy scripts provide only relative information on prices of different transaction properties rather than an absolute fee, this should not allow miners to vote fees up, although care would need to be taken they wouldn't be able to drive up prices by claiming common transaction types are at the high end of the fee scale. -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Pay to MultiScript hash:
In a system like bitcoin, where the system has to keep running, you have to consider how to roll out upgrades, and the costs associated with that. * the general cost of any network-wide change, versus P2SH which is already analyzed by devs, rolled out and working * the cost of P2SH output is predictable, versus less predictable outputs * the cost of updating everybody to relay this new transaction type, whereas P2SH Just Works already * cost of increasing rate of UTXO growth versus P2SH * default public, versus P2SH's default private It is true that publishing the script in the txout has the advantage of being easily audited by third parties scanning the blockchain, but in the interest of space efficiency you may accomplish the same thing by offering the script upon request out-of-band. The script is hash-sealed by the P2SH address, enabling perfect proof. Don't have a transcript handy, but these things are usually logged and google-searchable. In any case, it would be nice to get together and start building a cookbook of useful scripts like the ones you've been describing. The power of bitcoin scripts is only beginning to be explored. Use cases and examples are very helpful. On Thu, Jul 17, 2014 at 1:59 AM, Jeremy jlru...@mit.edu wrote: Additional costs would be in terms of A) chance of user error/application error -- proposed method is much simpler, as well as extra bytes for control flow ( 4 per script if I am counting right). The costs on a normal script do seem slightly more friendly, except this method allows for hidden-till-spent permission groups, as well as as smaller blockchain bloat overall (if scriptSig script has to store the logic for all the potential permission group, it will be a larger script versus only needing one permission group's script). An added benefit could also be in blockchain analysis -- you can actively monitor the utxo pool for your known associated scripts, whereas you couldn't for specialty scripts assembled per group. Enables repeated spends with groups as a cost object w/o having to recall all participants. ie, pay to the same perm groups as the other employee did last time, but include me as a root this time. Do you have a transcript of that chat by any chance? An interesting way to do that would be to push the sigs onto the stack have implicit orders, then do expressions with their aliases, and then be able to assign spending groups. ex: code_sep push script0 push script1 push script2 push script3 group_sep mkgroup_2, 0,1 ; the id will be 4 mkgroup_3, 0,2,3 ; the id will be 5 mkUnionGroup_2, 4,5 ; the id will be 6 2_of_3_group 0, 1, 2 mkIntersectionGroup_2 5, 6 complement_last ; complements last group, mutation del_group 1 ; deletes the group #1, groups then reindex after deletion (maybe the group was useful base class). etc... multisig check perm groups (checks if any groups on stack are valid from script) or even something like adding a little SAT scripting language with an eval. push script0 push script1 push script2 push script3 push a=(1 2 0), b=a-1, a | 3 | b eval On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik jgar...@bitpay.com wrote: On Wed, Jul 16, 2014 at 1:56 PM, Jeremy jlru...@mit.edu wrote: Right now, this could be expressed multiple ways (ie, using an op_dup if then else chain) , but all would incur additional costs in terms of complicated control flows. Instead, I would propose: Can you quantify additional costs in terms of complicated control flows? There is an implication in terms of increased utxo pool bloat, but also an implication in terms of increased txn complexity (each 20 byte hash allows for a 500 byte script, only one of the 500 byte scripts has to be permanently stored on blockchain). When considering these costs, using a normal P2SH output + a script with OP_IF and friends seems more straightforward? Doing boolean logic with multisig groups is quite possible, e.g. group AND group, group OR (group AND group) etc. Definitely a valid use case. I discussed how to do this on IRC with gmaxwell several months ago. I call it multi-multisig for lack of a better name. -- Jeremy Rubin -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
[Bitcoin-development] Decentralizing ming
Define acceptable. The 40% thing is marketing and a temporary solution. And people come down on both sides of whether or not marketing 40% is a good idea. I think it is a baby step that is moving in the right direction. You want the numbers and sentiment moving in that direction (down, versus own the market! /IPO). The more critical piece is fleshing out the various proposals and technical solutions for decentralized transaction selection and other aspects of SPOF-proofing mining. Historical note: On one hand, Satoshi seemed to dislike the early emergence of GPU mining pools quite a bit. On the other hand, Satoshi noted that the network would probably devolve down to a few big players if we ever reached VISA/MC transaction levels. Satoshi clearly never figured this part out :) Today, there is consensus on the need for a keep bitcoin free and open technical solution, but it remains to be seen how much we engineers can really do to make life fair. Making transaction selection a bit more independent from hashpower seems one step. There are several other proposals floating about. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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] Draft BIP for geutxos message
, it is useful for obtaining acceptable performance and resolving various UI cases. Another example of when this data can be useful is for performing floating fee calculations in an SPV wallet. This use case requires some other changes to the Bitcoin protocol however, so we will not dwell on it here. https://github.com/mikehearn/bips/commit/6058b92f5d9804ee4104649f53afc2fa53248c81?short_path=35c7795#specification Specification Two new messages are defined. The getutxos message has the following structure: Field Size DescriptionData typeComments 1check mempoolbool Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend. ?outpointsvector The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message. The response message utxos has the following structure: Field Size DescriptionData typeComments 4chain heightuint32 The height of the chain at the moment the result was calculated. 32chain tip hash uint256 Block hash of the top of the chain at the moment the result was calculated. ?hit bitmapbyte[] An array of bytes encoding one bit for each outpoint queried. Each bit indicates whether the queried outpoint was found in the UTXO set or not. ?result utxosresult[] A list of result objects (defined below), one for each outpoint that is unspent (i.e. has a bit set in the bitmap). The result object is defined as: Field Size DescriptionData typeComments 4tx versionuint32 The version number of the transaction the UTXO was found in. 4heightuint256 The height of the block containing the defining transaction, or 0x7FFF if the tx is in the mempool. ?outputCTxOut The output itself, serialized in the same way as in a tx message. https://github.com/mikehearn/bips/commit/6058b92f5d9804ee4104649f53afc2fa53248c81?short_path=35c7795#backward-compatibilityBackward compatibility Nodes indicate support by advertising a protocol version above 70003 and by setting a new NODE_GETUTXO flag in their nServices field, which has a value of 2 (1 https://github.com/mikehearn/bips/commit/6058b92f5d9804ee4104649f53afc2fa53248c81?short_path=35c7795#authentication Authentication The UTXO set is not currently authenticated by anything. There are proposals to resolve this by introducing a new consensus rule that commits to a root hash of the UTXO set in blocks, however this feature is not presently available in the Bitcoin protocol. Once it is, the utxos message could be upgraded to include Merkle branches showing inclusion of the UTXOs in the committed sets. If the requesting client is looking up outputs for a signed transaction that they have locally, the client can partly verify the returned output by running the input scripts with it. Currently this verifies only that the script is correct. A future version of the Bitcoin protocol is likely to also allow the value to be checked in this way. It does not show that the output is really unspent or was ever actually created in the block chain however. If the requesting client has a mapping of chain heights to block hashes in the best chain e.g. obtained via getheaders, then they can obtain a proof that the output did at one point exist by requesting the block and searching for the output within it. When combined with Bloom filtering this can be reasonably efficient. Note that even when the outputs are being checked against something this protocol has the same security model as Bloom filtering: a remote node can lie through omission by claiming the requested UTXO does not exist / was already spent (they are the same, from the perspective of a full node). Querying multiple nodes and combining their answers can be a partial solution to this, although as nothing authenticates the Bitcoin P2P network a man in the middle could still yield incorrect results. https://github.com/mikehearn/bips/commit/6058b92f5d9804ee4104649f53afc2fa53248c81?short_path=35c7795#implementation Implementation https://github.com/bitcoin/bitcoin/pull/4351/files -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
Re: [Bitcoin-development] Draft BIP for geutxos message
On the specific issue I raised, the BIP only says Querying multiple nodes and combining their answers can be a partial solution to this which is not very helpful advice. That's a partial answer to my question #2 with zero response for question #3. This sort of thing really needs a warning label like use only if you don't have a trusted solution and discussion of that choice is completely absent (question #1). On Wed, Jul 16, 2014 at 8:37 AM, Mike Hearn m...@plan99.net wrote: Thanks Jeff. I do feel like a lot of this is covered in the writeup I attached to the implementation pull request, and I went over it again in the ensuing discussion, and also in the BIP. The discussion of how to make it secure is covered in the Upgrade section of the writeup and in the Authentication section of the BIP. Please do let me know if these sections are missing something. The ideas discussed there are not implemented in this pull request because outside of some special cases, it is a very large project that involves a chain fork. You can see the start of a solution here: https://github.com/bitcoin/bitcoin/pull/3977 If one implements your BIP in a naive manner -- simply find a node, and issue a single query -- they are dangerously exposed to malicious information. The BIP should describe this major security issue, and describe at least one method of solving it (ditto implementation, if lighthouse has not already solved this). The BIP already does discuss this, in the authentication section. Suggestions for how to make it better are welcome. Comparison between this and BIP 35 (mempool command) are not apt, as miners and full nodes treat mempool returned data just like any other randomly solicited tx command on the network. Unlike mempool cmd, this getutxos cmd proffers post-verification trusted data. I don't think it does proffer that, but if a part of the BIP could be read as doing so, let me know which part and I'll fix it. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
