Re: [Bitcoin-development] Reconsidering github
On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik jgar...@bitpay.com wrote: 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. Despite my complaining about github, I don't like the idea of moving somewhere else. The current way of working - to use github for storing the tree, and use a custom script for signing+merging - is fine with me. Github has a low barrier to contribution. Almost every open source developer already has a github account. Switching to something self-hosted makes it more difficult for people to contribute. Plus if we have to take the hosting upon ourselves, we have to handle sysadmin work ourselves as well. That's not a good use of the limited manpower available. Also it will be a lot of work to migrate over all the current issues and pulls. I don't look forward to that. I don't see the point of this, sorry. Wladimir -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I agree with Wladimir, keep it simple. There being many other more urgent questions to address, imho. -- 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] ASIC-proof mining
Just as an aside to this lengthy convo, the Cryptonote-based BCN recently had some interesting updates which made it easier for ordinary computers (nothing special) to handle it. I realize that's not Bitcoin, but I thought I'd throw it out there. Thanks Mike. Indeed, I am aware of current approach, which is why I was suggesting this as an alternative. I haven't thought about it enough, and perhaps it was too radical a rethinking - just wanted to see what the smarter minds thought. Thanks again. -Randi On 7/5/14, 4:43 AM, Mike Hearn wrote: Is it possible instead to allocate a portion of the reward to a # of runner up(s) even though the runner-up(s) block will be orphaned? There's really no concept of a runner up because hashing is progress free. It's unintuitive and often trips people up. There's no concept that everyone is 95% of the way to finding a solution and then someone pips you to the post. It's more like playing the lottery over and over again. Doesn't matter how many times you did it before, the next time your chances are the same. A better concept is of rewarding near miss solutions which is what we already do of course, via pools, which pay you for shares which don't quite meet the difficulty target but almost do. So the question is how can we implement pools which have this reward structure (which obviously works well) without miners simultaneously giving up their right to block creation either due to technical problems or sheer lazyness. -- 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 -- 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
Re: [Bitcoin-development] Anyone still using SOCKS4?
Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention of leaking of information? Or maybe I am misremembering. Here's what I'm thinking of... 1) https://trac.torproject.org/projects/tor/wiki/doc/Preventing_Tor_DNS_Leaks 2) More regarding TOR, I keep seeing these warnings about SOCKS and DNS information leaks. Should I worry? The warning is: Your application (using socks5 on port %d) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via Polipo or socat) instead. https://www.torproject.org/docs/faq#WarningsAboutSOCKSandDNSInformationLeaks I'm not sure that means I'm screaming fire or anything, but isn't there some good reason for SOCKS4 and SOCKS4A? Or maybe another way to ask this is: Looking at an example in which someone is running Tor, Privoxy, I2P, and FoxyProxy together while running Bitcoin Core, would there be a problem with having a setting for SOCKS4A for traffic in such a setup given the changes proposed to remove SOCKS4 as suggested in bitcoin-development? Probably there is just a simple answer to that last question, like no. But I thought I'd ask. On Wed, Jun 11, 2014 at 5:39 PM, Wladimir laa...@gmail.com wrote: If no one screams fire, we plan on removing support for it in the next major release, for two reasons: - It would remove some crufty, hardly tested code paths - SOCKS5 offers better privacy as it allows DNS redirection Another one: - SOCKS5 supports IPv6 Last call... Wladimir -- 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 -- 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
Re: [Bitcoin-development] Anyone still using SOCKS4?
On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: Wait, I thought SOCKS4 was supposed to help somehow in terms of prevention of leaking of information? SOCKS4a (unlike SOCKS4) supports doing DNS lookups on the server, but it is not supported by bitcoin core. So it is not part of this discussion. And SOCKS5 can do all of that just as well. But if you feel like contributing SOCKS4a support that's fine with me. Wladimir OK, thanks Wladimir. -- 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
[Bitcoin-development] CoinJoin bounty fund question
Hoping that this is the right place for this, I am asking a question as to what happens with what is in the CoinJoin bounty fund address at: http://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (a P2SH / multisignature address) I encouraged people to donate to it in late 2013 (around mid-November) after seeing some reddit discussions ~ I think the original one I saw was at http://www.reddit.com/r/Bitcoin/comments/1qmhkh/coinjoin_fundraising_drive/ Since that time I know it's been implemented in various places, such as things seen floating about the web with some relation to CoinJoin or another: such as: https://github.com/calafou/coinjoin and blockchain.info https://twitter.com/blockchain/status/402224010492006400/ | https://github.com/blockchain/Sharedcoin etc.. I'm curious what the CoinJoin bounty fund supports at this point and where it's intended to go (I assume, CoinJoin related stuff, but I'm interested to know a bit more detail). And if it will help fund other things I am curious about what those other things are too. Again, hopefully the bitcoin-development list is the right place for this question, I felt it would be better asked here rather than on twitter or similar. Respect, Odinn -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Incentivizing the running of full nodes
I have been noticing for some time the problem which Mike H. identified as how we are bleeding nodes ~ losing nodes over time. This link was referenced in the coindesk article of May 9, 2014: http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CANEZrP2rgiQHpekEpFviJ22QsiV%2Bs-F2pqosaZOA5WrRtJx5pg%40mail.gmail.com/#msg32196023 (coindesk article for reference: http://www.coindesk.com/bitcoin-nodes-need/) The proposed solution is noted here as a portion of an issue at: https://github.com/bitcoin/bitcoin/issues/4079 Essentially that part which has to do with helping reduce the loss of nodes is as follows: a feature similar to that suggested by @gmaxwell that would process small change and tiny txouts to user specified donation targets, in an incentivized process. Those running full nodes (Bitcoin Core all the time), processing their change and txouts through Core, would be provided incentives in the form of a 'decentralizing lottery' such that all participants who are running nodes and donating no matter how infrequently (and no matter who they donate to) will be entered in the 'decentralizing lottery,' the 'award amounts' (which would be distinct from 'block rewards' for any mining) would vary from small to large bitcoin amounts depending on how many participants are involved in the donations process. This would help incentivize individuals to run full nodes as well as encouraging giving and microdonations. The option could be expressed in the transactions area to contribute to help bitcoin core development for those that are setting up change and txouts for donations, regarding the microdonation portion (which has also has been expressed conceptually at abis.io This addresses the issue of how to incentivize more interested individuals to run full nodes (Bitcoin Core). The lottery concept (which would be applicable to anyone running the full node regardless of whether or not they are mining) is attractive from the point of view that it will complement the block reward concept already in place which serves those who mine, but more attractive to the individual who doesn't feel the urge to mine, but would like to have the chance of being compensated for the effort they put into the system. I hope that this leads to additional development discussion on these concepts regarding incentivizing giving. This may also involve a process BIP. I look forward to your remarks. Respect, Odinn -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper
I completed a whitepaper for Bitcoin a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of wasting it on miners. Subsidized transaction fees are thus lower. I look at this and agree of course that the nodes are decreasing, see, https://getaddr.bitnodes.io/ But when I see stuff in the white paper like misbehaving nodes in the context of an audit agent, a single non-forking blockchain, the notion of Misbehaving nodes that would be banned from the network so as to motivat(e) honest behavior, ~ really, all of this does sound as though a sort of morality is being formulated rather than a mathematical solution. This is not to say that the white paper hasn't addressed a problem that needs to be addressed, namely... the problem of the nodes disappearing, and a few other things. But to take that and then layer onto that the issues associated with proof of stake... There does seem to be a simpler way to address this and I think first without suggesting the complex issue of some kind of thing that would involve dividends for those in a proof-of-stake system, consensus achieved by stake-weighted voting, and so forth, one would be better off removing all references to voting and stake, and determining ways simply to incentivize more substantively those who actually run a full node. Additionally I am hesitant to characterize behavior as has been described in the white paper, as it would seem that (in such a system) there would be an inclination or a tendency to exclude certain patterns or groups of participants rather than determine ways in which all participants or potential peers can serve the network. https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE Because the code is not yet written, this idea is half-baked so to speak. Comments appreciated on my project thread, which will be a development diary. I plan a hard fork of the Bitcoin blockchain in early 2016, after a year of public system testing, and conditioned on wide approval. https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403 -Steve Stephen L. Reed Austin, Texas, USA 512.791.7860-- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 proposed changes
I am curious if the Android developer who had been working on two factor authentication and bitcoin had worked toward an open issue or pull request? I had been looking around for some sign that this had occurred but hadn't found it, I am interested to know what is the progress in this area (in a fully decentralized way that resides fully on one's device or devices). For some reason maidsafe keeps rising up in my brain, have bitcoin core developers touched bases with maidsafe developers on these kind of fine points? Just thoughts and questions. -Odinn On Tue, Feb 18, 2014 at 4:40 PM, Andreas Schildbach andr...@schildbach.de wrote: On 02/18/2014 08:14 PM, Ryan X. Charles wrote: BitPay is working on a new standard based on bitcoin-like addresses for authentication. It would be great if we could work with the community to establish a complete, decentralized authentication protocol. Sounds interesting, let us know as soon as you have anything. SINs. See https://en.bitcoin.it/wiki/Identity_protocol_v1 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug in key.cpp
You are right there is a bug in there. But the value is not 25% I think. Tinker some more. :-) I think i see a bug: line 273 of key.cpp if (rec0 || rec=3) return false; Afaict, 3 is a perfectly valid value, meaning 25% of sig- key recoveries would fail erroneously... -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25
I wish to state that I fundamentally disagree with this proposal of use cases for W3C payments workshop. Please read my following explanation and then do what you will: At one time I was invited to join the Web Payments conference calls. I considered it and then declined due to the very CLAs that Brent mentioned in the message that started this thread. I was trying to remember the language that I objected to relating to the W3C CLA. Found it: https://web-payments.org/minutes/ As mentioned, I was offered to join these calls but I declined due to, in part, the following: Upon review of the page at web-payments.org, I noticed that it provides a means to connect with web payments group by teleconference. However, there is an agreement that the site would require me to accept merely to join the teleconference and collaborate with others in the web payments group. I would say unfortunately, but in my case I will say fortunately, I don't agree with the required agreement as shown here at http://www.w3.org/community/about/agreements/cla/ which is shown as follows at https://web-payments.org/minutes/ There are no costs associated with joining the group or limitations on who may join the teleconference as long as they agree to the Web Payments community Some of the things I don't like about the proposed agreement / requirement are fundamental. At the core, it should be understood that collaborative efforts, or teleconferences involving innovators who strive to develop concepts for eventual development of a social good, for example, should not be subject to a requirement that anyone agree to a license in relation to their participation or contribution. Such requirements inhibit innovation and free thought. For example, the web payments group provides that in order for me to participate, I must first agree to license my Essential Claims under the W3C CLA RF Licensing Requirements and numerous other requirements. Although I was interested in some sort of collaboration with the Web Payments Community Group, these CLAs - lengthy, burdensome, and in my personal view, highly dubious and potentially restricting with respect to innovation and free thought - caused me to reconsider, and thus I will not be entering into web or telephone conferences or related collaborations with the W3C / Web Payments folks until such time as they remove these burdensome requirements which are applied merely to join a call. Hello Bitcoiners, I have been working on some use cases for the W3C payments workshop. I'd like to include Bitcoin, but I might not have the time: Here is what I have: https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases Which is editable with a w3c username and password. Just be a member of the webpayments community group: http://www.w3.org/community/webpayments/ More formally you can submit a pull request to: https://github.com/w3c-webmob/payments-use-cases - Due to discussions with others am attempting to apply the following template: Name: name of the solution Use Cases: Key use cases for the solution Regions and currencies: Any SDKs or APIs which are available to developers with the following things to consider (for use cases): (1) add real money to the service (2) buy a physical good in the real wold (e.g., a cup of coffee) (3) pay for physical service (e.g., gym membership)? (4) convert virtual money back into paper money (5) transfer money from one person to another (even if the second person is not signed up for the service)? (6) buy product online (7) resolve disputes? (8) view transactions? (9) secure the wallet (10) etc. Thanks for your time and have a great day! -Brent Shambaugh -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
Hello, I see a lot of talk on this topic and get the senst that it is focused on default display only regarding the mBTC / uBTC questions. However, if the focus is broader, involving whether or how to express other currencies or moving further along to what that might even mean (since many people have different ideas about what a currency is) perhaps there is another issue to open, or a process BIP to address how to display other concepts, for example: other currencies microdonations etc. I sense however that may be outside the scope of this thread, so I'll just stop here and try to read samples of the other stuff going on here. -Odinn http://abis.io Resurrecting this topic. Bitcoin Wallet moved to mBTC several weeks ago, which was disappointing -- it sounded like the consensus was uBTC, and moving to uBTC later --which will happen-- may result in additional user confusion, thanks to yet another decimal place transition. On Sun, Nov 17, 2013 at 9:28 PM, Wendell w...@grabhive.com wrote: We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved. -wendell grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411 On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote: Go straight to uBTC. Humans and existing computer systems handle numbers to the left of the decimals just fine (HK Dollars, Yen). The opposite is untrue (QuickBooks really does not like 3+ decimal places). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Hello, I wanted to just add a very brief note to this discussion, that presently for multisignature creation and management (new transaction etc) I've been using this: https://coinb.in/multisig/ There were some initial bumps in the road but they were worked out, see full thread more or less beginning from here: https://bitcointalk.org/index.php?topic=390046.msg4687868#msg4687868 Curious as to what wallets actually support multisig / P2SH at this point? Unsure. Am assuming more than previously. On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Mar 11, 2014 at 7:43 AM, Drak d...@zikula.org wrote: I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. It also assumes a reality different from our current one. Multisig wallets are a different reality from our current one, so when we move to that new reality we should do it correctly from the beginning. -- -- Gavin Andrese -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
One wonders also re. bitmessage, though that may not be relevant to this particular list. On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote: On 3/5/2014 7:49 AM, Mike Hearn wrote: A new practical technique has been published that can recover secp256k1 private keys after observing OpenSSL calculate as little as 200 signatures: How can we patch this issue? If you're following good practices you're not particularly vulneable to it, if at all, even if you make use of shared hosting. First of all you shouldn't be re-using addresses, which means you won't be passing that ~200 sig threshold. More important though is you shouldn't be using single factor Bitcoin addresses. Use n-of-m multisig instead and architect your system such that that every transaction that happens in your service has to be authorized by both the online server(s) that host your website as well as a second hardened server with an extremely limited interface between it and the online server. The hardened second factor *should* use a separate codebase, ideally even a second language, to authenticate actions that withdraw funds or generate new addresses based on data given to it by the online server. In the best case your customers are PGP-signing requests so you can verify their intent independently and cryptographically on both servers. Mircea Popescu's MPEx exchange is an example of this model, although I don't think they're doing any multisig stuff. Failing that you can at least use the second server to do things like limit losses by flagging higher-than-expected withdrawl volumes and unusual events. Since this second-factor server only deals with business logic - not the website - you can certainly find a secure hosting arrangement for it with physical control. I recommend you stick the machine in your apartment and use tor + hidden services to connect to it from your VM instances. Note too that even if all you're doing is accepting Bitcoins from customers, perhaps in exchange for goods, all of the above *still* applies modulo the fact that the payment protocol is very incomplete. With P2SH (finally!) supported in all the major Bitcoin wallets there simply is no excuse not to have such an architecture other than lazyness and transaction fees; if you fall into the latter category you're business may very well be wiped out anyway by increased fees. -- 'peter'[:-1]@petertodd.org 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Nothing is safe. Take risks. Engage one trouble at a time. Perform unexpected actions. Observe the results. Rinse and repeat. Ignore the lions. They too shall pass. Do not sleep under a roof. Carry no money or food. Go alone to places frightening to the common brand of men. Become a criminal of purpose. Be put in jail, and extricate yourself by your own wisdom. -- Miyamoto Musashi (Niten Ichi-ryū) Some people may have seen my service Reality Keys, which can perform a role a bit like an External State Oracle as described previously by Mike Hearn and others. (I like to think of it as a Certificate Authority for propositions, doing for facts what Verisign do for identities.) You register a possible outcome with us, we publish a public key for yes and another for no, and once the outcome happens or fails to happen, we publish the appropriate private key. A few people have been asking for advice on the best way to use our keys to make m-of-n contracts, where each party locks up their stake in a transaction, then the winner gets their private key from Reality Keys and uses it to release the funds. Peter Todd suggested what seems like a very nice way to do this without needing non-standard transactions or refund transactions. I've had a go at implementing it and it seems to work, but I don't know enough about this to distinguish the ECC bit of it from magic, so I'm wondering if people who do understand it could comment on whether it's a safe thing to be doing. What I'm trying to do here is to combine the public key of each party with the public key of the outcome they're representing, eg I make a public key with: alice-pub + reality-key-yes-pub ...and another with: bob-pub + reality-key-no-pub That goes into a 1/2 P2SH address (in the simplest possible case), which is spendable by one of Alice or Bob after the outcome occurs with either: alice-priv + reality-key-yes-priv ...or bob-priv + reality-key-no-priv I'm making the transaction with add_pubkeys, then spending it with add_privkeys, both from: https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173 What's worrying my superstitious mind is that knowing reality-key-no-pub before he has to produce bob-pub, I'm wondering if there's something Bob could do with bob-pub to intentionally weaken the resulting (bob-pub + reality-key-no-pub) so that he could sign a transaction with it without needing to know reality-key-no-priv. My example script (and specifically the bit that's scaring me) is here: https://github.com/edmundedgar/realitykeys-examples/blob/master/realitykeysdemo.py#L247 PS. I hope I'm not too far off-topic. Peter Todd suggested it might be worth talking about here as it potentially has implications for other protocols. If people prefer to respond at bitcointalk instead, we've been discussing it here: https://bitcointalk.org/index.php?topic=260898.60 -- Edmund Edgar Founder, Social Minds Inc (KK) Twitter: @edmundedgar Linked In: edmundedgar Skype: edmundedgar http://www.socialminds.jp Reality Keys @realitykeys e...@realitykeys.com https://www.realitykeys.com -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. It's good that the core devs keep doing good work on these topics, thanks. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. I don't hear anyone lying. It's not. Actually, it is, and comparatively speaking, Bitcoin is better than the most common alternatives in use by people around the world. There are obvious issues (dust, how to handle fee issues moving forward, one could blather on forever about that), but again, I think core devs have done fairly well and will probably continue to do so along with many others. That's just my own 0.4 BTC though (my way of saying, at time of posting this, my own 2 cents). Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. That was not very specific. Could you be more specific? -- 'peter'[:-1]@petertodd.org b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2 -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
Am suggesting a (possible) mitigation of [possible flooding, etc], via some kind of discussion (potentially process BIP, related to bundling and / or randomization) not now, but down the road. However, needs more thought and analysis (you mentioned code audit?) before it could be floated around or acted on in any way shape or form. Thanks for this discussion, things to think about am watching, listening (...) There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind json API (gettx/raw) (newbie questions #2)
Hey everybody, here's another question that I have: I'd like a small bit of clarification about the gettx / getrawtransaction (decoded) api call. I understand that I can find the address that a transaction output is directed at / available to for future use sits in the vout array in the scriptPubKey.addresses array. I'm a little uncertain as to why that piece of information would be typed as an array when all it ever seems to contain is one (not more, not less) address(es). Are there any cases of transactions right now that don't contain exactly 1 item in that array, i.e. more or less than a single address (per single vout element, not per tx)? Or is the thinking behind this array to somehow make the data structure more extensible for potential future use? But then I can't think of any use cases where it appears to make any sense to put more than 1 address there... This might be such a use case, just maybe -- https://coinb.in/multisig Also I recommend checking out http://abis.io These may be things you are thinking about in the context of this. Or am I even asking the wrong questions? For spending those coins, i.e. using them in a future transaction it's all about owning the public/private key that is contained in the vout script, right? So the address doesn't really matter and it could be 2 or more (or none at all?) addresses in there, and what matters is just that the next guy has the key to spending those coins... ? Once again I'm coming to these questions from a project where I'm trying to calculate unspent outputs and from that balances for all accounts and I'm not sure yet what other special cases there might be in the blockchain that I need to be aware of and handle properly in order to (re-)produce accurate data! Thanks for your help, much appreciated! - Denis Be the change you want to see in the world. (Mahatma Gandhi) -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Malware authors and best practices for addressing the issue from development / licensing perspective or other
Hello, I have a request, which is how do developers address the circumstance in which someone utilizes your code as part of some effort to deprive (or steal as the case may be) someone of their bitcoin? This hasn't happened to me, but I have posed a question about it at bitcointalk: https://bitcointalk.org/index.php?topic=454903.msg5045596#msg5045596 It was prompted by the apparent use of sx by a malware author who then generated something called Stealthbit (which is malware, and which no-one should touch). [fortunately I have not tried to access or use Stealthbit.) However, this is a question that also touches on bitcoin development generally, due to that (it's happened before, it will happen again, etc.) people may end up using bitcoin code (if they haven't already) to develop something else that would then be used expressly to deprive someone of their bitcoins (such as steal them, but I am not thinking only of theft here). My question for developers is: Given that code is open source and anything can be done with it, good or bad, what are common development approaches to mitigate or potentially prevent malware authors from being able to easily appropriate the code you develop? I realize this question may sound dumb and out of place being that it is pretty obvious that code which is developed in a free, open source context can technically be used for anything. However, beyond suggesting that people just go to bitcoin.org for wallet technology, what can be done in the development community that would lessen the likelihood that the code you develop might be misappropriated? Please note: I am not sure how this issue might be approached from a development perspective, or license (MIT, Affero GPL, etc.) perspective, or any other perspective.. I'm just asking the question. I support bitcoin and other decentralized currency efforts including walled development such as darkwallet, and I appreciate what you all are doing. Maybe I'm asking the wrong question and it should be put another way, but I hope you will rephrase my question(s) in a way that makes more sense in the context of the list discussion here. Thanks for your work. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Greatly appreciate seeing this discussion occur. This is something that potentially could be supported through a bounty - possibly a process BIP? Possibly related: https://gist.github.com/ABISprotocol/8515891 Yes, recurring payments and subscriptions is a frequently-requested feature. It needs a new BIP. Here is an outline: The situation is somewhat analogous to HTML5 local storage. The remote (merchant) wants to initiate a persistent behavior. This is bitcoin, so we have a push model for payment, and the user has complete control. The merchant can, at most, send a subscription request. The user is responsible for making on-time payments after that point. Centralized services like coinbase.com or blockchain.info will have an easy time of it. An automated program on their backend, sending payments as needed, is easy and direct. More inventive services might employ multisig transactions, generating and signing one signature of a TX, then sending that TX to the human for further signing and publishing. A few competing vendors could offer bots that provide this signing service. Decentralized, standalone wallet clients will be somewhat troublesome. We can store a local subscription request, and send recurring payments... if the wallet app is running. If not, the user will be missing payments, that perhaps they intended to make (rent!). Each of these solutions can be cancelled at any time by the user. As such, a courtesy subscription cancelled message sent to the merchant is recommended. User controls the usage of their money at all times, the way things should be. And finally, you do not want to make it /too easy/ to send money over and over again. From a human-interface perspective, a textual reminder to send money might be preferred over actual recurring payment automation: reminder email + manual spend inserts a bit of additional human thought and review into the process, with all that entails. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
ABISprotocol hat: on regarding: stuff not getting into blockchain in a day's time, microdonations not facilitated as much as they could be, that would be: very bad much news such fail Seriously, that would not be so good. Hope I made you laugh a bit vendor hat: on BitPay sure would like to see CPFP in upstream. I think the main hurdle to merging was that various people disagreed on various edge case handling and implementation details, but no fundamental objections. On Fri, Jan 17, 2014 at 1:41 PM, Luke-Jr l...@dashjr.org wrote: On Friday, January 17, 2014 11:44:09 AM Wladimir wrote: On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr l...@dashjr.org wrote: https://github.com/bitcoin/bitcoin/pulls/luke-jr These are pretty much all well-tested and stable for months now. #3242: Autoconf improvements needs rebase, and comment from jgarzik and me taken into account (about -enable-frontends=). I'll try to get this done over the weekend. The others appear to be more controversial as they affect mining/consensus. I'd really like to see ACKs from more reviewers and testers there before merging. Can you elaborate on this? I can see how Proposals might, if buggy, affect consensus, but the rest shouldn't. I don't think there's anything controversial in any of these (does someone disagree with CPFP?). Luke -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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/ -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
clarification, I am not a doge dev. It was intended just as a joke, to make you laugh. regarding pull requests improving these issues I am under the impression that the developers will take care of what needs to be taken care of in that regard. Am presently in collaboration on a bitcoin project that may implement aspects of the ABIS concept as presented, but it is in very very early stage(es). I hope you had a good laugh, that was my intent. good morning / afternoon / evening On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: ABISprotocol hat: on regarding: stuff not getting into blockchain in a day's time, microdonations not facilitated as much as they could be, Please point to your pull requests improving these issues. If your organization didn't contribute anything to further these issues then there can't be much surprise that they didn't make it in, either. that would be: very bad much news such fail Seriously, that would not be so good. Hope I made you laugh a bit So it's more like a jester's hat then :) How did I end up on the dogecoin-development list?!? Wladimir -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Yes. Good idea(s). Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I think it meets all the criteria required: - Communication between parties is a single message from the payee, which may be public - Multiple payments to the same address are not publicly linkable on the blockchain - The payee has explicitly designated they expect to receive more than one payment at that address - Payer can publicly prove they made a payment to the reusable address by revealing a secret I have high hopes for this feature. The war *against* address reuse may soon be a distant memory. On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik jgar...@bitpay.com wrote: static address seems like a reasonable attempt at describing intended use/direction. On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@gmail.com wrote: But may I suggest we consider changing the name stealth address to something more neutral? ACK. Regardless of the 'political' overtones, I think stealth is a little cringe-worthy. Private address would be fine if not for confusion with private-keys. Static address is perhaps the best in my view. (also helps improve awareness that normal addresses are intended to be more one-use-ness)-- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Hello Peter et. al. As I read more into this stealth discussion I am curious to know what you think of the background microdonation concept I posted recently. It is shown in full here http://sourceforge.net/mailarchive/message.php?msg_id=31837430 Given the lengthy nature of the concept as presented I would be happy to distill it further, but I am interested in your thoughts as to the idea generally and how to further present it. -Odinn On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: It's a given this will be implemented for Payment Protocol. The question is whether it's also usable outside of PP. I think what stealth addresses is showing is that the concept of an address being instructions on how to generate a txout/tx that results in me getting Bitcoins is actually quite valuable; it and BIP32-derivation addresses with chaincodes are pretty clear cases where just replacing address with scriptPubKey isn't sufficient. I was kind of imagining that we could encourage people to replace all their static address text that live on Github pages, and README.me, and forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention could be to require only transporting xSTL addresses within a URI, even going so far as to not support them copy/pasted. 101 characters is not much longer (and sometimes shorter) than PaymentRequest URIs end up being. Yeah, I don't see anything wrong with stealth addresses whatever length they wind up being. It's a good intermediate step, and without them people will just pass around unsigned payment requests and other stuff. I think there are ways to make stealth addresses easy enough to use that people actually prefer using them for P2P payments which do not involve a full-stack merchant. In that case, if it was a PaymentRequest it would almost certainly not be signed, and would be more easily shared over email or SMS as a URI than as a file attachment or, even worse, putting the unsigned PR file up on a third-party server which probably won't do a good job securing it. At the DarkWallet hackathon we had discussed how to integrate stealth addresses into OpenPGP keys as a new user id type for instance, and similarly into x.509 certs. The big advantage here is the identity of *who* you are paying is important, not just I got this signed payment request. Basically the concept becomes identity signed payment address and the signature binding the identity to the address is a one time and offline thing; an issue with the payment protocol as it stands is that it encourages signing keys to be kept online to issue payment requests. If you have a scheme where the private keys that bound the identity to the address can be kept offline you're much better off, because the attacker can only create a fake payment request, they can't divert the funds to themselves. So with that in mind, I strongly suggest sticking with defining a reasonable stealth address spec. But when you do, keep in mind that you may want to upgrade it in the future, preferably in a backwards compatible way. Also, it shouldn't be limited to exactly 2-of-2 CHECKMULTISIG, there's no reason why n and m can't be picked as needed. Sure, it means the addresses are not fixed length, but for something that is mostly an internal detail and only occasionally visible to advanced users, I see no issues there. Along those lines: what would a BIP32 chain code address look like? What happens when you want to use that with a multisig-protected wallet? * PP Implementation Overview * The basic PaymentRequestPaymentDetails is expecting 'output' containing one or more TxOuts with script and amount. I believe the general approach is to put a fallback address into 'output' for backward compatibility, and put Q and Q2 into an extension field. So we add a new optional field to PaymentDetails which contains the one or two PubKeys. Not sure if we want different protobuf tags, or if the difference in length of the value makes it obvious enough which approach is being used; optional bytes stealthOnePubKey = 1000 optional bytes stealthTwoPubKey = 1001 I think you're missing the bigger picture here, not least of which is that backwards compatibility is a bit of a misnomer for an unreleased standard. :) Why put this into the PaymentDetails? That a stealth address is to be used for the payment is a property of the outputs being requested, not the payment itself. We're better off if that goes into the Output message, and further more it suggests that the Output message shouldn't contain raw scriptPubKey's but rather addresses. After all, IsStandard() means we have to inspect the scriptPubKey to see if we can even pay to what the sender is requesting. Once you establish that it's addresses that Outputs specify, then it's easy enough to make a stealth address type, or a BIP32-chain-code address type, or whatever else comes up in the future.
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I've been lurking on this convo since it began, but I wanted to say thanks, theymos cheers to you all and yay for decentralization, wherever it leads. -odinn muh latest: http://github.com/ABISprotocol/ABIS On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”
In the same post I mentioned
Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/;
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?
I am considering the idea more seriously, but I'd like some feedback
before taking steps.
Saïvann
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
