Re: [Bitcoin-development] Reconsidering github
> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik 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] Anyone still using SOCKS4?
> On Mon, Jul 7, 2014 at 8:34 AM, Odinn Cyberguerrilla > 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
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 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] 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
[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
Re: [Bitcoin-development] Incentivizing the running of full nodes
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/16/2014 07:00 PM, Justus Ranvier wrote: >> There can be multiple independent transport networks for Bitcoin. >> >> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree >> patch). >> >> As long as multihomed hosts that act as bridges then information >> will propagate across all of them. -- Justus Ranvier >> - sent with R2Mail2 >> >> - Original Message - From: Matt Whitlock >> >>> Now another concern: won't this proposal increase the likelihood >>> of a network split? The free-market capitalist nodes will want to >>> charge their peers and will kick and ban peers that don't pay up >>> (and will pay their peers to avoid being kicked and banned >>> themselves), whereas the socialist nodes will want all of their >>> peers to feed them transactions out of the goodness of their >>> hearts and will thus necessarily be relegated to connecting only >>> to other altrustic peers. Thus, the network will comprise two >>> incompatible ideological camps, whose nodes won't interconnect. If the technical development emanating from the proposal follows a design which ensures that the notion of whether or not someone were to donate remains voluntary in nature (there's never any requirement that someone donate to anyone, but incentives can be made), then I don't feel that network split would be an issue, because it's just an issue of choice. Justus Ranvier suggested a system which would naturally include pay-to-play networks, and not just free P2P networks. The question of how to limit the number of entries the system registers in the framework of the proposed 'decentralizing lottery' would be fairly straightforward, there could one entry for a distinct period of time (say 30 days as an example) for anyone who meets the suggested criteria of: "those running full nodes (Bitcoin Core (...)), 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,'" for a chance to receive "the 'award amounts'" In my mind I imagine that the smart property qualities of Bitcoin may eventually enable people to represent what sort of time and energy they are putting into maintaining the network, so that rather solely a currency aspect, people who have done something collaborative with each other to help advance or develop Bitcoin would be able to show in their donations field that they have a smart property, which could be also expressed in equivalence terms as a value of a certain amount of btc, would also be able to have the smart property representing their voluntary efforts represented and given a voice in the blockchain, whether or not they want to participate in such a 'decentralizing lottery.' In point of fact, I contemplate that all aspects of this, at least ideally (to me) should be voluntary, such that if a person is donating through this system, that is voluntary, if they wish to have their donations result in a chance at winning the 'decentralizing lottery,' that is voluntary / an option, and if they win, they would have the option to accept the winnings or return them (the bitcoin 'award amount') back to the network. > > Also consider that currently there are many people have already > demonstrated a willingness to donate bandwidth and resources to the > public by running nodes, so those people aren't going to disappear. > Those who are already dedicated to running nodes will likely (mostly) remain, but any ideas reaching technical development and reality as a result of this concept would be intended to help grow that base by bringing in persons who might not otherwise be as interested to do so. > They could operate mixed-mode nodes, with a fraction of the allowed > incoming connections reserved for free peer, with free connections > might be limited in terms of time duration. Bitcoin-accepting > brick-and-mortars would probably allow free access to anyone connected > to their internal wifi to facilitate people wanting to pay. That's a great idea. The incentives could certainly go beyond just pointing to Bitcoin Core. Giving is important to everyone. > > Crowdfunded free bridges, assurance contracts, etc are all other ways > to let people get into the network with no upfront cost. > > > - -- > Support online privacy by using email encryption whenever possible. > Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ > 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj > JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok > o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ > Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpW
[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] 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 (rec<0 || 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: > • 3 signs your SCM is hindering your productivity > • Requirements for releasing software faster > • 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: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • 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] 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 > 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=121054471&iu=/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: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • 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] Translators Needed for Bitcoin Core
Thanks for this reminder, I will bring this up with some others who I think may be able to help in this area and dedicate some time. I may be able to free up some time with a little language work as well. > You do not need to be a developer to help in the improvement of Bitcoin. > > http://sourceforge.net/p/bitcoin/mailman/message/32255092/ > Bitcoin Core 0.9.2 feature freeze is May 13th, 2014. Now is the time for > native non-English speakers to join Transifex to clean up the translations > in all languages. This is important for more than just Bitcoin because > Litecoin will use these same translations. > > *What should volunteer translators do?* > https://bitcointalk.org/index.php?topic=571414 > Try the nightly builds of Bitcoin Core as it heads toward 0.9.2. Not > recommended for your production wallet. > > https://www.transifex.com/projects/p/bitcoin/ > Join Transifex as a translator and add your account to your language. > > https://groups.google.com/forum/#!forum/bitcoin-translators > Join the Translator mailing list to receive announcements when > translations > are needed for Bitcoin. You will also receive notifications if other > Bitcoin Project things in Transifex need translations (likely > bitcoin.org). > -- > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ 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 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 wrote: > >> On Tue, Mar 11, 2014 at 7:43 AM, Drak 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=122218951&iu=/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=122218951&iu=/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: > + > ...and another with: > + > > 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: > + > ...or > + > > 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 > before he has to produce , I'm wondering if there's something Bob > could do with to intentionally weaken the resulting ( + > ) so that he could sign a transaction with it without > needing to know . > > 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=122218951&iu=/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=122218951&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Procedure for non-tech contributions
Hi, you may want to check this out: http://www.reddit.com/r/Bitcoin/comments/1rh2h0/developers_core_developers_contributors/ Cheers, -Odinn http://abis.io > Hey, folks. Sorry if this is documented somewhere -- if so, just point me > at it. I couldn't find it, though. > > I'm a (non-developer) writer with experience in open-source communities, > and I'd like to contribute with writing/editing/marketing. What's the > procedure? Is there someone in charge of that area? > > Two examples: > > 1) Gavin recently asked for proofreading of 0.9.0rc2, but it was unclear > how to send the changes. (There are many possibilities, some better than > others. Git? Google Docs with revisioning? Microsoft Word with Track > Changes? The Bitcoin wiki?) > > 2) The page at https://en.bitcoin.it/wiki/BitcoinPayment says that "the > wiki receiving wallet (for the wiki itself) is also MtGox". Umm, I rather > doubt that. :-P But I'm not sure what the current info is, or whom to > alert. > > Off-list replies welcome. Thanks, > > --- > Tom Geller * Oberlin, Ohio * 415-317-1805 >Writer/Presenter * http://www.tomgeller.com > articles, marketing, videos, user guides, books > > > > -- > 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=126839071&iu=/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=122218951&iu=/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=126839071&iu=/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=126839071&iu=/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=126839071&iu=/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=121054471&iu=/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=121054471&iu=/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=121051231&iu=/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=123612991&iu=/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=123612991&iu=/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: > >> >> >> 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=119420431&iu=/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
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 > 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 wrote: >> On Friday, January 17, 2014 11:44:09 AM Wladimir wrote: >>> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr 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=119420431&iu=/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=119420431&iu=/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=119420431&iu=/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 > wrote: >> "static address" seems like a reasonable attempt at describing intended >> use/direction. >> >> On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell >> wrote: >>> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport >>> 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=119420431&iu=/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=119420431&iu=/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 PaymentRequest>PaymentDetails 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,
[Bitcoin-development] Bitcoin strengthening, giving, more - Re: Stealth Addresses
Hello, My apologies, to start with, as I am temporarily unable to reply directly to the thread. I am remembering this conversation due to a few things: 1) the discussion re. extending the payment protocol with new fields 2) discussions about "long addresses" 3) bitcoin strengthening / decentralization / cex.io,ghash.io growth etc. 4) microdonation / giving / microtransaction development, e.g. coinbase-bitmonet Android SDK, http://blog.coinbase.com/post/72785739620/android-sdk-released-accept-bitcoin-payment-in-your 5) multisignature via browser, e.g. https://coinb.in/multisig/ Different thoughts are running through my head here, so I will make a sincere effort to coagulate them into a couple of meaningful and coherent questions, and perhaps as time goes on, an issue or BIP. However, I will precede this with a "scenario" and with some "possibilities" (all of which are hypothetical - I think) before presenting the "questions" below. | | V "Scenario(s)" Suppose that there were to exist a method of extending the payment protocol such that either "very long addresses" or multiple addresses were presented by default from within the bitcoin client. In the scenario being imagined here, the standard option would exist to enter a payment address directly. However, coupled with this would be an option to enable microdonations (or put another way, multiple transactions associated with each instance of use of the protocol to facilitate a purchase) as a default (as background activity automatically corresponding to any given transaction). Whether or not this process is engaged in would be entirely voluntary, in other words, users' choice. The addresses to which this giving or microdonation would occur would be stipulated by the user but also would be limited to the ability of the network to support this microdonation process. So, for example: 1) Let us say that you are to buy a piece of gum and the price of that piece of gum is 0.8 BTC. 1)a. The user has the ability to support additional (individuals, organizations, causes, etc) for each transaction (instance of use of the protocol to facilitate a purchase). 1)b. The user has set as a default to be "microdonated" each time a transaction occurs, the following: 1)b.1 0.0003 BTC to Sean's Outpost 1)b.2 0.0004 BTC to a cousin who has a medical debt 1)b.3 0.6 BTC to a multisignature account which is intended to "give youth a future and old age a security" ( Re: https://www.youtube.com/watch?v=qLci5DoZqHU&feature=youtu.be&t=2m38s ) 1)b.4 0.5 BTC to a future US gov't-run Social Security address 1)b.5 0.0002 BTC to an anarchist collective's donation address 1)b.6 0.0002 BTC to a personal investment or retirement account 1)c. The user then purchases a compound bow for 0.17 BTC. The purchase occurs the day after the gum purchase was initiated. The user has left the default microdonation settings in place, so Sean's Outpost, the cousin, the multisignature account, the US gov't run Social Security address, the anarchist collective, and the personal investment / retirement account all receive something (automatically) again as per the user's settings. "Possibilities" 2) Some Possibilities (depending on implementation): 2)a. The transaction completes for the purchase of gum but the microtransactions are not allowed to complete until the compound bow purchase is complete due to that the gum price is lower than the collective microdonations which are set by the user as default. 2)b. The transaction for the purchase of gum is not completed due to the user realizing that the fee will be larger than the price of gum, but the microdonations are completed (the user has opted to allow them to occur anyway) and transaction(s) confirmed. Subsequently, the compound bow purchase occurs and the microdonations are given again. 2)c. The transaction for the purchase of gum is completed and the microdonations are completed, everything is confirmed, the next day the same thing happens with the compound bow purchase, more microdonations arrive. 2)d. The microdonations are interpreted by the system as part of a very long address created for the transaction. Due to the tiny price of the gum the microtransactions are held until another larger purchase is completed. The microtransactions occur "times 2" at the time of the compound bow purchase, since they could not be completed during the gum purchase, they are completed / confirmed at the time of the compound bow purchase. The user is alerted that the ordinary microdonations will be multiplied by two for the transaction and is offered an option to either run the default microdonation or the micronation "times two." The user confirms the "times two" option and the microdonations are completed. 2)e. The microdonations are each handled as seperate micr
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=111408631&iu=/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=111408631&iu=/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=111408631&iu=/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=111408631&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] ABIS protocol introduction
Hello, This concept, 'ABIS protocol,' has been many years in the making and is presented here as a basic concept. It is sent to you for you review and possible consideration. There will be further additions in the near future. Looking forward to your reply and any contributions you may provide. Cheers https://github.com/ABISprotocol/ABIS#abis -- 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=111408631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
