-
https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/
-
https://medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649
-
http://crypto.biu.ac.il/sites/default/files/6th_BIU_Winter_School/BIU6-Tromer-session1.pdf
-
https://courses.cs.ut.ee/MTAT.07.022/2013_fall/uploads/Main/alisa-report
#include <linux/hrtimer.h> | |
#include <linux/module.h> | |
#include <linux/kernel.h> | |
static struct hrtimer timer; | |
enum hrtimer_restart yell_rick( struct hrtimer *timer ) | |
{ | |
ktime_t time; | |
printk(KERN_INFO "I turned myself into a logger morty! I'm dmesg RIIIICK!\n"); |
The following was sent to [bitcoin-dev] on October 9, 2017 under the subject "Generalized sharding protocol for decentralized scaling without Miners owning our BTC".
Dear list,
In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along.
With the recent removal of the 140-character limit in Direct Messages by Twitter, DM's have now become a much more useful platform for communicating between individuals and groups. Sadly, DM's are still sent in plaintext between users and Twitter has no plans currently on encrypting these messages, at least as of August 2015. Since these are stored in plaintext at rest, an adversary can see the content of the message you are sending, which the two parties might not wish to happen. Fortunately as a few applications with basic Twitter support which also have excellent support for OTR, all hope isn't lo
Hashes of DVDs that I booted each node from: | |
Compute OS DVD: 5f43aa1244a01b3cf9da4abeadde9e34b954a873565fc56b58c10780f3ce0e4c | |
Network OS DVD: 375550be4c64ebc68a9306421bb71ad3556bc73f156a231503084f923900f4cb | |
Commitment String generated by Compute Node: | |
6yV3Ji7zuVWVCQEfkhQEfkhQ6Vfv51t5VfQHQVaLDGH6zkeunkmohr | |
Hash of Disc A: | |
2axdkGL6QzngjvY9jRBX5AqhSokukji8eQuYUfJwhp7sxcXvPr | |
Hash of Disk B: |
/* | |
This snippet is esssentially the same as being in the Twitter longer tweets test, for tweetdeck. | |
The Tweet length counter is fixed by tricking TweetDeck into counting up to 140 characters, twice, so you'll see 140 | |
instead of 280 in the counter but going over 140 will give you another set of 140 charactrs. | |
*/ | |
TD.services.TwitterClient.prototype.makeTwitterCall=function(b,e,f,g,c,d,h){c=c||function(){};d=d||function(){};b=this.request(b,{method:f,params:Object.assign(e,{weighted_character_count:!0}),processor:g,feedType:h});return b.addCallbacks(function(a){c(a.data)},function(a){d(a.req,"",a.msg,a.req.errors)}),b}; | |
twttrTxt=Object.assign({},twttr.txt,{isInvalidTweet:function(){return!1},getTweetLength:function(x){return x=twttr.txt.getTweetLength.apply(this,arguments),x<140||x/140>2?x:x%140}}); |
#!/bin/sh | |
# zbalance: quickly get your zcash addresses (taddr and zaddr) and their balances. | |
# REQUIRES zcash-cli (https://z.cash) AND jq (https://stedolan.github.io/jq) | |
zaddr_withbalance () { | |
while read a | |
do echo $(zcash-cli z_getbalance $a) $a | |
done | |
} |
Putting cryptographic primitives together is a lot like putting a jigsaw puzzle together, where all the pieces are cut exactly the same way, but there is only one correct solution. Thankfully, there are some projects out there that are working hard to make sure developers are getting it right.
The following advice comes from years of research from leading security researchers, developers, and cryptographers. This Gist was [forked from Thomas Ptacek's Gist][1] to be more readable. Additions have been added from
This is a guide on how to email securely.
There are many guides on how to install and use PGP to encrypt email. This is not one of them. This is a guide on secure communication using email with PGP encryption. If you are not familiar with PGP, please read another guide first. If you are comfortable using PGP to encrypt and decrypt emails, this guide will raise your security to the next level.