July 2018 - cypherpunks-legacy

Re: [HacDC:Byzantium] Byzantium Discovery PDF
by Ben Mendis 06 Jul '18

06 Jul '18

Here is the core of the authentication issue: It's necessary to one of our scenarios, but a non-starter for the other. The Doctor and many of the more paranoid members of this list they envision Byzantium as the solution to a technologically sophisticated adversary who as taken control of their Internet access. They look to examples like Syria and think that anything less that perfect anonymity is just going to get people killed. They are concerned with hiding and staying hidden while still communicating with the outside world. On the other hand, if we're talking about a natural disaster such as Haiti or Katrina or DC-when-the-wind-blows, then having some authentication (even if it is weak) could be vital to organizing an effective response and recovery effort. Users would be communicating with their friends and neighbors or emergency responders, not random strangers. Far from hiding, they want to be found and identified and helped. This all hinges on whether or not we anticipate that a technologically sophisticated adversary is out to get us. In my opinion Syria is a special case. On the other hand, natural disasters (big and small) are a fact of life in every part of the world. We're revisiting the issue of solving for Katrina versus solving for Egypt. I think we need to keep focusing on solving for Katrina first. However, as a concession to the Egypt use case, any authentication/identity solutions we come up with should be strictly optional. That said, implementing distributed authentication/identity is a hard problem, so it behooves us to start thinking about it early and investigating the possibilities. Ben the Pyrate. On 08/30/2012 11:15 AM, Dave Duchesneau wrote: > I have a few comments to Project Byzantium (where I mostly just lurk for > now), prefaced by some excerpts from recent dialog. > >>> Conclusion: Sometimes authentication is necessary and [desirable]... >>> Sometimes it really is needed, and sometimes it is not. >> I agree with your conclusion (but not with all of your reasoning). >> ...[Authentication] in a decentralized network...is very hard to manage. >> ...Byzantium is...designed to let people communicate... >> ...in a time of emergency... >> ... the lack of [authentication] isn't *necessarily* detrimental... >>> I have heard horror stories of people who thought using GPG... >>> was good security culture, until they realized that their >>> professional profile had been automatically connected to their >>> 'activist' profile...to the users detriment. Rather than >>> providing security, it incriminated them post-hoc... >>> These are things to consider... >> GPG itself doesn't do anything. If you use multiple identities >> (i.e. mail addresses) with the same key, then you're responsible >> for the resulting connection. If you want to keep multiple >> distinct "profiles", then use distinct keys... > The problems associated with a project like Byzantium are both deep and > wide. Taken together, the problems are hard to solve because the *best* > solution to one problem may increase the difficulty of solving another, or > even create a brand-new problem altogether. The difficulty of solving the > inherent problems is further compounded by the lack of visibility into the > future importance of one problem relative to another. Thus, before one > focuses on solving a particular problem, it may be prudent to ensure that > the problem itself merits so much attention. However, the attention should > be focused first on accurately defining the actual problem rather than > engineering a solution. > > For example, in the case of authentication, I think it merits a lot of > attention, in order to identify exactly what is needed, and in what > circumstances. This necessitates understanding what is to be gained and > what must be given up, and under what circumstances such trade-offs may be > appropriate or inappropriate. Put another way, ask yourself under what > circumstances would you be willing to trade breathable air for drinkable > water, or vice-versa? All of a sudden we find ourselves asking more > questions and questioning our assumptions, which is as it should be. As > usual, once we've asked the right questions and understand their relative > importance in a given context, getting good answers may be relatively > straightforward. > > Personally, I'm delighted to see the discussion that is taking place here, > because it increases the odds of getting the truly relevant issues out in > the open, where the implications (e.g., cause-and-effect relationships) may > be better understood by a wider audience (or even, at all). We may be > smarter collectively, but only if we can harness what we know individually. > > Dave Duchesneau > ddd(a)crisis-force.org > > > > -----Original Message----- > From: Baptiste Jonglez [mailto:baptiste@jonglez.org] > Sent: Thursday, August 30, 2012 3:12 AM > To: byzantium(a)hacdc.org > Subject: Re: [HacDC:Byzantium] Byzantium Discovery PDF > > On Thu, Aug 30, 2012 at 02:25:21AM -0700, black_sector(a)riseup.net wrote: >> Signed authentication destroys anonymity in most cases. There are times >> when you want to know who everyone is that you are dealing with. There are >> other times when leaving a 'crypto-trail' right back to your door is >> actually a bad thing, and not something you would want for your comrades. > While I also disagree with Nicholas when it comes to require some sort > of log-in to use the services, I don't think he was thinking of > involving any crypto. > >> I think that MD5 and similar is often a good alternative for signed >> authentication. Perhaps it is not sufficient for a repository handler, but >> it is generally sufficient for end users. After all, an authenticated >> package only means you have verified the source but not that the package >> is untampered with necessarily. Checking the MD5 or Sha* actually tells >> you about the condition of the package, client side. If the file checks >> out and passes MD5, then making sure you authenticated the sender is not >> that relevant. If however the package is corrupted or tampered with, >> knowing who provided it warns you that the source is unreliable. > Wait, there is something wrong here. Do you really think MD5 (or sha*, > for that matters) is an algorithm that provides *authentification*? > > It just doesn't make sense. If an attacker is tampering with a file, > he can *also* modify the md5sum written to a file just next to it. > > Signing a file with a GPG key, for instance, is way more > robust. Assuming the algorithm isn't flawed, in order to tamper with the > file without being noticed, you must either take control of the > private key (which is supposed to be well protected), or use your own > key and make it look like it's the right one, which is also quite > hard. > >> It is worth noting that even major repository maintainers often make no >> promises that their software is free of malware. They do not audit every >> package. You can get a rootkit from a major linux distro (potentially) by >> adding an app that got by somebody, without adding anything third party. >> Linux is more secure than Windows and more people are watching for these >> things, but it took a good minute before somebody actuaolly audited Google >> Chrome and found data-mining software in it. An authenticated open-source >> application is not automatic protection against various threats. Being >> able to audit something only counts if somebody actually does, and then we >> have to trust that they will bring it to public attention. > Your example is flawed, since Google Chrome is *not* Free Software > (unless you're referring to Chromium, which is). > > As for Free Software projects, it's all a matter of trust. The project > leader(s) often keep a close eye on code contribution. If the source > code is compiled by a project member and then immediately signed with > a PGP key, it's pretty robust against tampering (again, you can never > be 100% sure). > > As for source code alteration, you might remember the attack on > kernel.org: thanks to git, we were sure (as far as sha256 collision > are hard to produce) that the attackers didn't modify the repository, > or else the developers' trees would no longer match the ones on > kernel.org. > >> Conclusion: Sometimes authentication is necessary and desireable, but I >> would not advocate its use only because it is common or standard in Linux >> and the server world. I like to keep it simple and only add what is >> actually needed. Sometimes it really is needed, and sometimes it is not. > I agree with your conclusion (but not with all of your reasoning). > > As haxwithaxe pointed out, authentification in a decentralized network > like this is very hard to manage. > > Besides, I doubt the goal of Byzantium is to build some kind of > Facebook over mesh networking (again, I might be wrong). It's designed > to let people communicate with each others, potentially in a time of > emergency. > > And more fundamentally, the lack of authentification isn't > *necessarily* detrimental. Have you ever used IRC? :) > >> I have heard horror stories of people who thought using GPG for their >> emails was good security culture, until they realized that their >> professional profile had been automatically connected to their 'activist' >> profile. Now they are linked and government and corporate search engines >> can connect the dots to the users detriment. Rather than providing >> security, it incriminated them post-hoc. >> >> >> These are things to consider. I strongly dislike how GPG automatically >> connects profiles together. That is why I do not use it myself. > GPG itself doesn't do anything. If you use multiple identities > (i.e. mail addresses) with the same key, then you're responsible for > the resulting connection. If you want to keep multiple distinct > "profiles", then use distinct keys. > > Baptiste > ----- 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

Re: [liberationtech] in anticipation of Stockholm Internet Forum...
by Stefan Geens 06 Jul '18

06 Jul '18

> I'm almost certain that the FRA law specifically allows the Sapo > (Sdkerhetspolisen) to grab everything. > > All the best, > Jake I thought so too, until I read the law and the legal analysis around it while researching the article. The original 2008 law can indeed be interpreted as you do, but then came the revised 2009 law as a result of all the uproar. The 2009 version is much more restrictive in who can order a tap, why, how, and for how long. For example, a tap can only be initiated by "the government, government offices and the armed forces", a court order is required, and is only valid for a specific length of time - max 6 months (renewable by the court). (Section 4 and 5) For the sake of completion: In the extraordinary case that there is such urgency that getting a court order would take too long, an appointed duty officer at the FRA can make the decision to tap in the interim, but the court will then look at the evidence ASAP and if it turns out the tap is unwarranted, it is stopped, the collected data has to be destroyed and there is an investigation into how and why the unwarranted request was made. (Section 5b) The 2009 version of the law, which is currently in force: https://lagen.nu/2008:717 or as a PDF: http://62.95.69.3/SFSdoc/09/090967.PDF The original law in 2008, for comparison, as a PDF: http://62.95.69.3/SFSdoc/08/080717.PDF Regards, Stefan -- stefan.geens(a)gmail.com @stefangeens @ogleearth @dliberation +46 73 504 5261 Skype: stefan.geens PGP: 0x54ABD155F7CE9B68 -- On 14 Apr, at 15:14, Jacob Appelbaum wrote: > On 04/14/2012 03:51 AM, Fabio Pietrosanti (naif) wrote: >> On 4/14/12 9:47 AM, Andre Rebentisch wrote: >> snip [...] >>> but only after obtaining court >>> permission, and upon the explicit request of government or defense >>> agencies." >>> >>> In other words, Sweden does monitor all traffic. >> >> Almost all countries have capabilities to monitor internet traffic at >> borders. >> >> It seems to me that Sweden is so civil that even the intelligence need >> to ask a court order to do so. >> >> In italy Law Enforcement need a court order, but Intelligence does not. >> > > I'm almost certain that the FRA law specifically allows the Sapo > (Sdkerhetspolisen) to grab everything. > > All the best, > Jake > _______________________________________________ > liberationtech mailing list > liberationtech(a)lists.stanford.edu > > Should you need to change your subscription options, please go to: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" > > You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech > > Should you need immediate assistance, please contact the list moderator. > > Please don't forget to follow us on http://twitter.com/#!/Liberationtech _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- 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

Re: wikileaks dns (was Re: Blocking International DNS)
by Stephane Bortzmeyer 06 Jul '18

06 Jul '18

On Fri, Dec 03, 2010 at 08:27:57AM -0600, Dan White <dwhite(a)olp.net> wrote a message of 28 lines which said: > Their A records on Sunday were: (No longer working.) Several people are keeping track of working IP addresses and avertise them in the DNS (wikileaks.something.example). Other have full mirrors. A current list: http://etherpad.mozilla.org:9000/wikileaks copy it, so you can access the DNS mirrors even if mozilla.org is taken down... <operational>It's a very interesting exercice in resiliency.</operational> ----- 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

Re: wikileaks dns (was Re: Blocking International DNS)
by Stephane Bortzmeyer 06 Jul '18

06 Jul '18

On Fri, Dec 03, 2010 at 08:27:57AM -0600, Dan White <dwhite(a)olp.net> wrote a message of 28 lines which said: > Their A records on Sunday were: (No longer working.) Several people are keeping track of working IP addresses and avertise them in the DNS (wikileaks.something.example). Other have full mirrors. A current list: http://etherpad.mozilla.org:9000/wikileaks copy it, so you can access the DNS mirrors even if mozilla.org is taken down... <operational>It's a very interesting exercice in resiliency.</operational> ----- 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

Re: [liberationtech] in anticipation of Stockholm Internet Forum...
by Stefan Geens 06 Jul '18

06 Jul '18

> I'm almost certain that the FRA law specifically allows the Sapo > (Sdkerhetspolisen) to grab everything. > > All the best, > Jake I thought so too, until I read the law and the legal analysis around it while researching the article. The original 2008 law can indeed be interpreted as you do, but then came the revised 2009 law as a result of all the uproar. The 2009 version is much more restrictive in who can order a tap, why, how, and for how long. For example, a tap can only be initiated by "the government, government offices and the armed forces", a court order is required, and is only valid for a specific length of time - max 6 months (renewable by the court). (Section 4 and 5) For the sake of completion: In the extraordinary case that there is such urgency that getting a court order would take too long, an appointed duty officer at the FRA can make the decision to tap in the interim, but the court will then look at the evidence ASAP and if it turns out the tap is unwarranted, it is stopped, the collected data has to be destroyed and there is an investigation into how and why the unwarranted request was made. (Section 5b) The 2009 version of the law, which is currently in force: https://lagen.nu/2008:717 or as a PDF: http://62.95.69.3/SFSdoc/09/090967.PDF The original law in 2008, for comparison, as a PDF: http://62.95.69.3/SFSdoc/08/080717.PDF Regards, Stefan -- stefan.geens(a)gmail.com @stefangeens @ogleearth @dliberation +46 73 504 5261 Skype: stefan.geens PGP: 0x54ABD155F7CE9B68 -- On 14 Apr, at 15:14, Jacob Appelbaum wrote: > On 04/14/2012 03:51 AM, Fabio Pietrosanti (naif) wrote: >> On 4/14/12 9:47 AM, Andre Rebentisch wrote: >> snip [...] >>> but only after obtaining court >>> permission, and upon the explicit request of government or defense >>> agencies." >>> >>> In other words, Sweden does monitor all traffic. >> >> Almost all countries have capabilities to monitor internet traffic at >> borders. >> >> It seems to me that Sweden is so civil that even the intelligence need >> to ask a court order to do so. >> >> In italy Law Enforcement need a court order, but Intelligence does not. >> > > I'm almost certain that the FRA law specifically allows the Sapo > (Sdkerhetspolisen) to grab everything. > > All the best, > Jake > _______________________________________________ > liberationtech mailing list > liberationtech(a)lists.stanford.edu > > Should you need to change your subscription options, please go to: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" > > You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech > > Should you need immediate assistance, please contact the list moderator. > > Please don't forget to follow us on http://twitter.com/#!/Liberationtech _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- 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

Re: [tahoe-dev] Resurrecting Mojo Nation
by Jack Byer 06 Jul '18

06 Jul '18

(This is a cross-post from: https://bitcointalk.org/index.php?topic=86384) A market mechanism for buying and selling hard drive space would look a lot like the commodity markets. If you express a contract in a standard form they can be traded on an exchange to achieve price discovery. The following is not a complete specification but just an example of how such a system might work. Contract trading could be done on #bitcoin-otc or a similar platform (including the reputation function). Contracts will be priced in bitcoins. Storage is expressed in blocks of 1 MiB and the base time interval is one increment of the Bitcoin block chain. Block servers (nodes that sell space) can list the contracts they are willing to accept in human and machine-readable form as something like this: "BLOCKSTORAGE,O,10,10000,144,0.001,0.0005,0.00025" This means that the node is offering (O) to contract with any node with a reputation of 10 or more. Up to 10000 blocks are available for 144 time units. The total cost of the contract is 0.001 BTC per block. Of this total cost 0.0005 is due up front and 0.00025 is due at the completion of the contract. The remainder is due in periodic intervals (perhaps as often as every time increment). When a node that is looking to sell storage can express the contract it is looking for as a bid (B). It could either work as both the block server and the client can scan the order book to look for a matching contract or the exchange can handle the matching. There would need to be a means to express what should happen to the data at the end of the contract. It can either be deleted (the client no longer needs it) or it can be transferred to another block server or it can be returned to the client. At the end of each contract the client and the block server both leave feedback on each other which will either increase or decrease their respective reputations. Block servers with high reputations will be able to charge more up front because the clients can be more confident they will actually be able to get their data back at the end of the contract. Clients with high reputation won't need to pay as much up front because the block servers can be more confident they will be paid at the end of the contract. In general a higher reputation will lead to better prices for both a client and a block server. The client should have a method of verifying that the block server actually retained the data instead of just tossing it into the bitbucket. One possible way to do this is to periodically transmit a block number and two offsets and ask for the hash of the data between the two offsets. The client could pre-select this verification blocks before transmitting the data and have enough hashes stored ahead of time for the number of verification it expects to need. This is just a rough draft and probably still has holes that need to be filled in but how does it look as a basic outline? _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

[drone-list] Eric Holder's speech on the legality of drone use
by Nabiha Syed 06 Jul '18

06 Jul '18

Good afternoon, folks: In case you haven't seen it yet, here's the full-text of Attorney General Eric Holder's speech at Northwestern University, in which he touches upon the legality of targeted killing (via drones). Thought some of you would find it interesting. http://www.lawfareblog.com/2012/03/text-of-the-attorney-generals-national-s… Nabiha _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- 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

RE: [p2p-hackers] P2P Authentication
by Matthew Kaufman 06 Jul '18

06 Jul '18

Alen Peacock: > Personally, I'm put off by the centralization. I'm not > really concerned about the library size or complexity of > PKI,. In fact, my experience indicates that implementing > centralized CAs is a good deal less complex than trying to > distribute identity verification throughout the system with > no centralization. Agreed... Hierarchical PKI with a single root is distinctly easier than multiple roots, random chains of trust, or reputation models, which is why we've started with the simplest design for the default PKI that ships with the amicima MFP and MFPNet libraries. > Completely decentralized p2p applications have the > advantage of being especially resilient to DoS and other > attacks on centrality. > Introducing centralized components negates this advantage. It negates some advantages, not all. > In the case of using CAs in a p2p app, the entire network can > be disabled by attacking the CAs. As has already been pointed out, the network still runs, but new clients can't be authenticated. However, it is possible to make that unlikely... For instance, if enough trusted entities already have the ability to sign keys, you can reduce the odds that an attacker can successfully disable ALL of the CAs. Adding additional roots to the PKI, especially if they are public roots that are unlikely to be disabled, also helps... It doesn't seem likely that the world will shut down the existing secure web PKI in order to take your P2P app off the air. > p2p networks pose an interesting challenge because you have > to design for the fact that malicious or misbehaving clients > *will* be present. This is actually true of the entire Internet and isn't unique to p2p networks at all. All protocol implementations and higher level applications that run on them must be designed to deal with malicious or misbehaving clients will be present... See buffer overflows of mail servers and http servers, for instance. > Since there is no single entity or known > group of entities controlling the nodes (as in typical > distributed applications), there is no way to enforce > adherence to protocols other than with the protocols > themselves. This isn't about p2p networks at all, but about open-source distribution, it seems. Lots of totally proprietary p2p and client-server applications have been shipped where "a single entity" controls the implementation... Skype comes to mind as an example in the P2P space. These have the temporary advantage of unpublished protocols and implementations, but this won't stop a dedicated attacker for long, which brings us back to the original point, that everything attached to the Internet needs to assume that malicious and misbehaving things will try to mess things up. Whether or not that really matters is another point... There's numerous ways one could build a highly incorrect Gnutella peer, for instance, and yet it doesn't seem to have become commonplace. > This may sound idealistic and naive, perhaps > justly so, but the further away from protocols that require > centralized architectures we get, the better (IMHO, of course). Well, that's why we're all here on the "P2P" hackers list, I suppose, because we believe that decentralization is good, but it doesn't really change the most basic of the design parameters at all. Matthew Kaufman matthew(a)matthew.at www.amicima.com _______________________________________________ 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.07100, 11.36820 http://www.leitl.org 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

[drone-list] Eric Holder's speech on the legality of drone use
by Nabiha Syed 06 Jul '18

06 Jul '18

Good afternoon, folks: In case you haven't seen it yet, here's the full-text of Attorney General Eric Holder's speech at Northwestern University, in which he touches upon the legality of targeted killing (via drones). Thought some of you would find it interesting. http://www.lawfareblog.com/2012/03/text-of-the-attorney-generals-national-s… Nabiha _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- 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

Re: [tahoe-dev] Resurrecting Mojo Nation
by Jack Byer 06 Jul '18

06 Jul '18

(This is a cross-post from: https://bitcointalk.org/index.php?topic=86384) A market mechanism for buying and selling hard drive space would look a lot like the commodity markets. If you express a contract in a standard form they can be traded on an exchange to achieve price discovery. The following is not a complete specification but just an example of how such a system might work. Contract trading could be done on #bitcoin-otc or a similar platform (including the reputation function). Contracts will be priced in bitcoins. Storage is expressed in blocks of 1 MiB and the base time interval is one increment of the Bitcoin block chain. Block servers (nodes that sell space) can list the contracts they are willing to accept in human and machine-readable form as something like this: "BLOCKSTORAGE,O,10,10000,144,0.001,0.0005,0.00025" This means that the node is offering (O) to contract with any node with a reputation of 10 or more. Up to 10000 blocks are available for 144 time units. The total cost of the contract is 0.001 BTC per block. Of this total cost 0.0005 is due up front and 0.00025 is due at the completion of the contract. The remainder is due in periodic intervals (perhaps as often as every time increment). When a node that is looking to sell storage can express the contract it is looking for as a bid (B). It could either work as both the block server and the client can scan the order book to look for a matching contract or the exchange can handle the matching. There would need to be a means to express what should happen to the data at the end of the contract. It can either be deleted (the client no longer needs it) or it can be transferred to another block server or it can be returned to the client. At the end of each contract the client and the block server both leave feedback on each other which will either increase or decrease their respective reputations. Block servers with high reputations will be able to charge more up front because the clients can be more confident they will actually be able to get their data back at the end of the contract. Clients with high reputation won't need to pay as much up front because the block servers can be more confident they will be paid at the end of the contract. In general a higher reputation will lead to better prices for both a client and a block server. The client should have a method of verifying that the block server actually retained the data instead of just tossing it into the bitbucket. One possible way to do this is to periodically transmit a block number and two offsets and ask for the hash of the data between the two offsets. The client could pre-select this verification blocks before transmitting the data and have enough hashes stored ahead of time for the number of verification it expects to need. This is just a rough draft and probably still has holes that need to be filled in but how does it look as a basic outline? _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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