July 2018 - cypherpunks-legacy

Keyczar
by Ben Laurie 06 Jul '18

06 Jul '18

http://www.links.org/?p=374 When I joined Google over two years ago I was asked to find a small project to get used to the way development is done there. The project I chose was one that some colleagues had been thinking about, a key management library. I soon realised that unless the library also handled the crypto it was punting on the hard problem, so I extended it to do crypto and to handle key rotation and algorithm changes transparently to the user of the library. About nine months later I handed over my "starter project" to Steve Weis, who has worked on it ever since. For a long time we've talked about releasing an open source version, and I'm pleased to say that Steve and intern Arkajit Dey did just that, earlier this week: Keyczar[1]. "Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include: * A simple API * Key rotation and versioning * Safe default algorithms, modes, and key lengths * Automated generation of initialization vectors and ciphertext signatures" When we say simple, by the way, the code for loading a keyset and encrypting some plaintext is just two lines. Likewise for decryption. And the user doesn't need to know anything about algorithms or modes. Great work, guys! I look forward to the "real" version (C++, of course!). [1] http://www.keyczar.org/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com

1 0

Re: [cryptography] Digital cash in the news...
by Morlock Elloi 06 Jul '18

06 Jul '18

BitCoin has only one problem: maintenance of the relationship between unit BitCoin value and the material world (energy, as in KWh) is 'soft', it requires some sort of a volatile communal effort, which sets it for failure (as a counter example, the amount of Au atoms on this planet is rather independent from any communal effort.) The relationship between unit value and the material world needs to be fixed. It's just a matter of time. Then we may name it ButtCoin. > We expect money to be a store of value, among a few other > things. BitCoin has nothing in it that speaks to that goal, > that I can see [0]. This anti-property would however > make it more ideal for a bubble [1]. > > Quite how to fix that and retain the decentralised control > aspect, I'm unsure. The essence of a contract is that > someone delivers something to someone else; without > that first party (which speaks to centralisation at some > level) it is hard. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[IP] Arrests key win for NSA hackers
by Dave Farber 06 Jul '18

06 Jul '18

http://www.globeandmail.com/servlet/ArticleNews/freeheadlines/LAC/20040406/T ERROR06/international/International Arrests key win for NSA hackers By DAVID AKIN UPDATED AT 4:38 AM EDT Tuesday, Apr. 6, 2004 a530ea8.jpg A computer hacker who allowed himself to be publicly identified only as "Mudhen" once boasted at a Las Vegas conference that he could disable a Chinese satellite with nothing but his laptop computer and a cellphone. The others took him at his word, because Mudhen worked at the Puzzle Palace -- the nickname of the U.S. National Security Agency facility at Fort Meade, Md., which houses the world's most powerful and sophisticated electronic eavesdropping and anti-terrorism systems. It was these systems, plus an army of cryptographers, chaos theorists, mathematicians and computer scientists, that may have pulled in the first piece of evidence that led Canadian authorities to arrest an Ottawa man on terrorism charges last week. Citing anonymous sources in the British intelligence community, The Sunday Times reported that an e-mail message intercepted by NSA spies precipitated a massive investigation by intelligence officials in several countries that culminated in the arrest of nine men in Britain and one in suburban Orleans, Ont. -- 24-year-old software developer Mohammed Momin Khawaja, who has since been charged with facilitating a terrorist act and being part of a terrorist group. The Orleans arrest is considered an operational milestone for this vast electronic eavesdropping network and its operators. But Dave Farber, an Internet pioneer and computer-science professor at Carnegie-Mellon University in Pittsburgh, said the circumstances are also notable because it will be the first time that routine U.S. monitoring of e-mail traffic has led to an arrest. "That's the first admission I've actually seen that they actually monitor Internet traffic. I assumed they did, but no one ever admitted it," Mr. Farber said. Officials at the NSA could not be reached for comment. But U.S. authorities are uniquely positioned to monitor international Internet and telecommunications traffic because many of the world's international gateways are located in their country. And once that electronic traffic touches an American computer -- an e-mail message, a request for a website or an Internet-based phone call, for instance -- it is routinely monitored by NSA spies. "Foreign traffic that comes through the U.S. is subject to U.S. laws, and the NSA has a perfect right to monitor all Internet traffic," said Mr. Farber, who has also been a technical adviser to the U.S. Federal Communications Commission. That's what happened in February, when NSA officers at Fort Meade intercepted a message between correspondents in Britain and Pakistan, The Sunday Times reported. The contents of that message have not been revealed, but are significant enough that dozens of intelligence officials were mobilized in Britain, Canada and the United States. The intelligence officers at Fort Meade rely on a sophisticated suite of supercomputers and telecommunications equipment to analyze millions of messages and phone calls each day, looking for certain keywords or traffic patterns. Internet traffic is chopped up into small chunks called packets, and each individual package is then routed over the Internet, to be reassembled at the recipient's end. The packet is wrapped in what computer scientists sometimes refer to as the envelope. And just as the exterior of a regular piece of mail contains important addressing information, so does the envelope of a digitized packet. These bits of information are called headers, and they can be valuable to investigators as well. Headers typically contain generic descriptions of the packet's contents, in order to let computers make better decisions about how to route the packet through the Internet. E-mail traffic gets a lower priority than Internet video traffic, for instance. Headers also pick up the numeric or Internet Protocol (IP) address of all the computers a packet touches as it travels from its originating machine all the way to its destination. Every computerized device connected to the Internet has its own unique IP number. Investigators could program their supercomputers to flag packets of information that met certain criteria, such as a certain IP number, a certain traffic pattern or a certain kind of content. As soon as a packet is flagged, investigators would apply for warrants to assemble the packets and read the messages' contents. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

anonymous IP terminology (Re: [anonsec] Re: potential new IETF WG
by Adam Back 06 Jul '18

06 Jul '18

on anonymous IPSec (fwd from hal(a)finney.org)) User-Agent: Mutt/1.4.1i Sender: owner-cryptography(a)metzdowd.com Joe Touch <touch(a)ISI.EDU> wrote: > >The point has nothing to do with anonymity; > > The last one, agreed. But the primary assumption is that we can avoid a > lot of infrastructure and impediment to deployment by treating an > ongoing conversation as a reason to trust an endpoint, rather than a > third-party identification. Although anonymous access is not the primary > goal, it is a feature of the solution. Joe: I respectfully request that you call this something other than "anonymous". It is quite confusing and misleading. Some people have spent quite a bit of time and effort in fact working on anonymous IP and anonymous/pseudonymous transports. For example at ZKS we worked on an anonymous/pseudonymous IP product (which means cryptographically hiding the souce IP address from the end-site). There are some new open source anonymous IP projects. Your proposal, which may indeed have some merit in simplifying key management, has _nothing_ to do with anonymous IP. Your overloading of the established term will dilute the correct meaning. Zooko provided the correct term and provided references: "opportunistic encryption". It sounds to have similar objectives to what John had called opportunistic encryption and tried to do with freeSWAN. Lowever level terms may be unauthenticated as Hal suggested. Or non-certified key management (as the SSH cacheing of previously before seen IP <-> key bindings and warnings when they change). > Although anonymous access is not the primary goal, it is a feature > of the solution. The access is _not_ anonymous. The originator's IP, ISP call traces, phone access records will be all over it and associated audit logs. The distinguishing feature of anonymous is that not only is your name not associated with the connection but there is no PII (personally identifiable information) associated with it or obtainable from logs kept. And to be clear also anonymous means unlinkable anonymous across multiple connections (which SSH type of authentication would not be) and linkable anonymous means some observable linkage exists between sessions which come from the same source (though no PII), and pseudonymous means same as linkable anonymous plus association to a persistent pseudonym. Again there are actually cryptographic protcols for_ having anonymous authentication: ZKPs, multi-show unlinkable credentials, and refreshable (and so unlinkable) single-show credentials. Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Tor 0.1.1.10-alpha is out
by Roger Dingledine 06 Jul '18

06 Jul '18

This is the tenth development snapshot for the 0.1.1.x series. We fix more crash bugs, fix some anonymity-related problems, and provide major performance speedups and use less memory than the previous alphas. http://tor.eff.org/download.html Changes in version 0.1.1.10-alpha - 2005-12-11 o Correctness bugfixes on 0.1.0.x: - On Windows, build with a libevent patch from "I-M Weasel" to avoid corrupting the heap, losing FDs, or crashing when we need to resize the fd_sets. (This affects the Win32 binaries, not Tor's sources.) - Stop doing the complex voodoo overkill checking for insecure Diffie-Hellman keys. Just check if it's in [2,p-2] and be happy. - When we were closing connections, there was a rare case that stomped on memory, triggering seg faults and asserts. - We were neglecting to unlink marked circuits from soon-to-close OR connections, which caused some rare scribbling on freed memory. - When we're deciding whether a stream has enough circuits around that can handle it, count the freshly dirty ones and not the ones that are so dirty they won't be able to handle it. - Recover better from TCP connections to Tor servers that are broken but don't tell you (it happens!); and rotate TLS connections once a week. - When we're expiring old circuits, we had a logic error that caused us to close new rendezvous circuits rather than old ones. - Fix a scary-looking but apparently harmless bug where circuits would sometimes start out in state CIRCUIT_STATE_OR_WAIT at servers, and never switch to state CIRCUIT_STATE_OPEN. - When building with -static or on Solaris, we sometimes needed to build with -ldl. - Give a useful message when people run Tor as the wrong user, rather than telling them to start chowning random directories. - We were failing to inform the controller about new .onion streams. o Security bugfixes on 0.1.0.x: - Refuse server descriptors if the fingerprint line doesn't match the included identity key. Tor doesn't care, but other apps (and humans) might actually be trusting the fingerprint line. - We used to kill the circuit when we receive a relay command we don't recognize. Now we just drop it. - Start obeying our firewall options more rigorously: . If we can't get to a dirserver directly, try going via Tor. . Don't ever try to connect (as a client) to a place our firewall options forbid. . If we specify a proxy and also firewall options, obey the firewall options even when we're using the proxy: some proxies can only proxy to certain destinations. - Fix a bug found by Lasse Overlier: when we were making internal circuits (intended to be cannibalized later for rendezvous and introduction circuits), we were picking them so that they had useful exit nodes. There was no need for this, and it actually aids some statistical attacks. - Start treating internal circuits and exit circuits separately. It's important to keep them separate because internal circuits have their last hops picked like middle hops, rather than like exit hops. So exiting on them will break the user's expectations. o Bugfixes on 0.1.1.x: - Take out the mis-feature where we tried to detect IP address flapping for people with DynDNS, and chose not to upload a new server descriptor sometimes. - Try to be compatible with OpenSSL 0.9.6 again. - Log fix: when the controller is logging about .onion addresses, sometimes it didn't include the ".onion" part of the address. - Don't try to modify options->DirServers internally -- if the user didn't specify any, just add the default ones directly to the trusted dirserver list. This fixes a bug where people running controllers would use SETCONF on some totally unrelated config option, and Tor would start yelling at them about changing their DirServer lines. - Let the controller's redirectstream command specify a port, in case the controller wants to change that too. - When we requested a pile of server descriptors, we sometimes accidentally launched a duplicate request for the first one. - Bugfix for trackhostexits: write down the fingerprint of the chosen exit, not its nickname, because the chosen exit might not be verified. - When parsing foo.exit, if foo is unknown, and we are leaving circuits unattached, set the chosen_exit field and leave the address empty. This matters because controllers got confused otherwise. - Directory authorities no longer try to download server descriptors that they know they will reject. o Features and updates: - Replace balanced trees with hash tables: this should make stuff significantly faster. - Resume using the AES counter-mode implementation that we ship, rather than OpenSSL's. Ours is significantly faster. - Many other CPU and memory improvements. - Add a new config option FastFirstHopPK (on by default) so clients do a trivial crypto handshake for their first hop, since TLS has already taken care of confidentiality and authentication. - Add a new config option TestSocks so people can see if their applications are using socks4, socks4a, socks5-with-ip, or socks5-with-hostname. This way they don't have to keep mucking with tcpdump and wondering if something got cached somewhere. - Warn when listening on a public address for socks. I suspect a lot of people are setting themselves up as open socks proxies, and they have no idea that jerks on the Internet are using them, since they simply proxy the traffic into the Tor network. - Add "private:*" as an alias in configuration for policies. Now you can simplify your exit policy rather than needing to list every single internal or nonroutable network space. - Add a new controller event type that allows controllers to get all server descriptors that were uploaded to a router in its role as authoritative dirserver. - Start shipping socks-extensions.txt, tor-doc-unix.html, tor-doc-server.html, and stylesheet.css in the tarball. - Stop shipping tor-doc.html in the tarball. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [cryptography] Digital cash in the news...
by Morlock Elloi 06 Jul '18

06 Jul '18

BitCoin has only one problem: maintenance of the relationship between unit BitCoin value and the material world (energy, as in KWh) is 'soft', it requires some sort of a volatile communal effort, which sets it for failure (as a counter example, the amount of Au atoms on this planet is rather independent from any communal effort.) The relationship between unit value and the material world needs to be fixed. It's just a matter of time. Then we may name it ButtCoin. > We expect money to be a store of value, among a few other > things. BitCoin has nothing in it that speaks to that goal, > that I can see [0]. This anti-property would however > make it more ideal for a bubble [1]. > > Quite how to fix that and retain the decentralised control > aspect, I'm unsure. The essence of a contract is that > someone delivers something to someone else; without > that first party (which speaks to centralisation at some > level) it is hard. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[p2p-hackers] Don't Let the RIAA Put the Net at Risk!
by Seth Johnson 06 Jul '18

06 Jul '18

> http://www.nyfairuse.org/action/ftc/ Don't Let the RIAA Put the Net at Risk! Tell the FTC that the Internet is Peer to Peer, It is Ours, and We Intend to Keep It! Please forward this notice to any other concerned parties you may know. Please tell the FTC not to allow a few rich cartels and monopolies such as the RIAA, MPAA and Microsoft to put the Internet at risk: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm What's Going On: The FTC has issued a call for participation announcing a workshop on "P2P Filesharing" technology to take place in Washington, DC this December 15th and 16th. An RIAA-sponsored CapAnalysis paper submitted to the FTC, calls for an investigation of "P2P Filesharing" applications for deceptive practices that affect the privacy and security of users, subjecting them to such risks as adware, viruses, exposure to undesirable material, impairments of computer function, and last but not least, liability to charges of copyright infringement. Congress is also calling the FTC to investigate these products. We call all those who know the Internet is a common good, who make productive use of it and who develop applications for it as a regular part of their daily lives, to join us in telling the FTC what the real sources of these risks are. Please tell the FTC not to allow a few rich cartels and monopolies such as the RIAA, MPAA and Microsoft to put the Internet at risk: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm Get On the Bus! We are organizing a caravan of concerned citizens to travel to the nation's capital and defend our rights and powers against the RIAA, the MPAA and Microsoft. When we arrive: * We will call the FTC to protect Internet users by acting against a few rich cartels and monopolies that impede innovation and access to robust solutions, choice, transparency and control. * We will call the FTC to focus their attention on the real sources of the risks in question, and to respond to them appropriately. * We will pose the question to the FTC of how they can distinguish the applications they have selected for consideration at this workshop from the multitude of applications of the Internet and the ordinary functions of operating systems now in use on millions of interconnected desktops across the planet. * We will press the FTC to explain what risks are actually unique to the applications they have singled out. * We will call the FTC to separate copyright matters from consideration of the private interests of computer owners. * We will call the FTC to refer copyright policy to the appropriate body, the United States Congress. Please submit comments to the FTC here: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm Please contact us to let us know you will join us in this action and to offer your assistance with travel, lodging and sustenance: http://www.nyfairuse.org/cgi-bin/nyfu/contactus Links: The FTC "P2P Filesharing" Workshop: http://www.ftc.gov/bcp/workshops/filesharing/index.htm The CapAnalysis/RIAA Paper: http://ipcentral.info/blog/P2P%20White%20Paper.doc House and Senate Members Urge FTC Action Against P2P: http://www.gnutellanews.com/article/13743 >From Clean System to Zombie Bot in Four Minutes: http://slashdot.org/article.pl?sid=04/11/30/1932245 In Praise of P2P: http://www.economist.com/displayStory.cfm?Story_id=3422905 New Yorkers for Fair Use - www.nyfairuse.org -- DRM is Theft! We are the Stakeholders! New Yorkers for Fair Use http://www.nyfairuse.org [CC] Counter-copyright: http://realmeasures.dyndns.org/cc I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [cryptography] Digital cash in the news...
by Meredith L. Patterson 06 Jul '18

06 Jul '18

On Mon, Jun 13, 2011 at 6:50 AM, John Levine <johnl(a)iecc.com> wrote: > PS: For anyone who wants a crypto currency backed by gold, that's > functionally equivalent to a gold ETF, of which there are several, > such as ticker symbols IAU, GLD, GTU, SGOL, and AGOL. They do what > they do perfectly adequately, but they are in no sense currency. > Bubble sceptics can trade put options on them. Too bad there's no > options on bitcoins. There already are options on bitcoins. #bitcoin-otc [1] nominally supports them in its order book, though I see little use so far [2]. Apparently someone wrote a put for 100BTC at a strike price of $0.75/BTC with a 1.50BTC premium two months ago, maturing 31 May 2011 [3]; the option did in fact sell but I have no idea whether it was exercised. Bitcoin calls have been around on the forum since at least January [4], complete with risk reversal strategies ([5] is a textbook example of a collar though not a zero-premium one). [1] http://www.bitcoin-otc.com [2] http://bitcoin-otc.com/vieworderbook.php?notes=option [3] http://www.bitcoinmoney.com/post/4585101363/first-bitcoin-put-option-contra… [4] http://forum.bitcoin.org/?topic=2986.0 [5] http://forum.bitcoin.org/index.php?topic=2986.msg41580#msg41580 Cheers, --mlp _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[p2p-hackers] Don't Let the RIAA Put the Net at Risk!
by Seth Johnson 06 Jul '18

06 Jul '18

> http://www.nyfairuse.org/action/ftc/ Don't Let the RIAA Put the Net at Risk! Tell the FTC that the Internet is Peer to Peer, It is Ours, and We Intend to Keep It! Please forward this notice to any other concerned parties you may know. Please tell the FTC not to allow a few rich cartels and monopolies such as the RIAA, MPAA and Microsoft to put the Internet at risk: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm What's Going On: The FTC has issued a call for participation announcing a workshop on "P2P Filesharing" technology to take place in Washington, DC this December 15th and 16th. An RIAA-sponsored CapAnalysis paper submitted to the FTC, calls for an investigation of "P2P Filesharing" applications for deceptive practices that affect the privacy and security of users, subjecting them to such risks as adware, viruses, exposure to undesirable material, impairments of computer function, and last but not least, liability to charges of copyright infringement. Congress is also calling the FTC to investigate these products. We call all those who know the Internet is a common good, who make productive use of it and who develop applications for it as a regular part of their daily lives, to join us in telling the FTC what the real sources of these risks are. Please tell the FTC not to allow a few rich cartels and monopolies such as the RIAA, MPAA and Microsoft to put the Internet at risk: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm Get On the Bus! We are organizing a caravan of concerned citizens to travel to the nation's capital and defend our rights and powers against the RIAA, the MPAA and Microsoft. When we arrive: * We will call the FTC to protect Internet users by acting against a few rich cartels and monopolies that impede innovation and access to robust solutions, choice, transparency and control. * We will call the FTC to focus their attention on the real sources of the risks in question, and to respond to them appropriately. * We will pose the question to the FTC of how they can distinguish the applications they have selected for consideration at this workshop from the multitude of applications of the Internet and the ordinary functions of operating systems now in use on millions of interconnected desktops across the planet. * We will press the FTC to explain what risks are actually unique to the applications they have singled out. * We will call the FTC to separate copyright matters from consideration of the private interests of computer owners. * We will call the FTC to refer copyright policy to the appropriate body, the United States Congress. Please submit comments to the FTC here: http://www.ftc.gov/bcp/workshops/filesharing/comments.htm Please contact us to let us know you will join us in this action and to offer your assistance with travel, lodging and sustenance: http://www.nyfairuse.org/cgi-bin/nyfu/contactus Links: The FTC "P2P Filesharing" Workshop: http://www.ftc.gov/bcp/workshops/filesharing/index.htm The CapAnalysis/RIAA Paper: http://ipcentral.info/blog/P2P%20White%20Paper.doc House and Senate Members Urge FTC Action Against P2P: http://www.gnutellanews.com/article/13743 >From Clean System to Zombie Bot in Four Minutes: http://slashdot.org/article.pl?sid=04/11/30/1932245 In Praise of P2P: http://www.economist.com/displayStory.cfm?Story_id=3422905 New Yorkers for Fair Use - www.nyfairuse.org -- DRM is Theft! We are the Stakeholders! New Yorkers for Fair Use http://www.nyfairuse.org [CC] Counter-copyright: http://realmeasures.dyndns.org/cc I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [cryptography] Digital cash in the news...
by Meredith L. Patterson 06 Jul '18

06 Jul '18

On Mon, Jun 13, 2011 at 6:50 AM, John Levine <johnl(a)iecc.com> wrote: > PS: For anyone who wants a crypto currency backed by gold, that's > functionally equivalent to a gold ETF, of which there are several, > such as ticker symbols IAU, GLD, GTU, SGOL, and AGOL. They do what > they do perfectly adequately, but they are in no sense currency. > Bubble sceptics can trade put options on them. Too bad there's no > options on bitcoins. There already are options on bitcoins. #bitcoin-otc [1] nominally supports them in its order book, though I see little use so far [2]. Apparently someone wrote a put for 100BTC at a strike price of $0.75/BTC with a 1.50BTC premium two months ago, maturing 31 May 2011 [3]; the option did in fact sell but I have no idea whether it was exercised. Bitcoin calls have been around on the forum since at least January [4], complete with risk reversal strategies ([5] is a textbook example of a collar though not a zero-premium one). [1] http://www.bitcoin-otc.com [2] http://bitcoin-otc.com/vieworderbook.php?notes=option [3] http://www.bitcoinmoney.com/post/4585101363/first-bitcoin-put-option-contra… [4] http://forum.bitcoin.org/?topic=2986.0 [5] http://forum.bitcoin.org/index.php?topic=2986.msg41580#msg41580 Cheers, --mlp _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0