- Anonymous Retrospective Broadcasts
- If we don't assume a centralized party that can be trusted to verify information, what we're left with is not really a contact tracing application but a particular kind of messaging application, where users create tracks through space and time, and can retrospectively broadcast anonymous messages to users whose tracks were spatially nearby to theirs in a particular time range.
- This messaging system should be privacy-preserving, in the sense that:
- Server Privacy: An honest-but-curious server should not learn information about any user's space-time tracks;
- Locality Integrity: A user should not be able to broadcast messages to users who were not nearby to them;
- User Privacy:
- A passive adversary cannot not learn any information about a user's space-time track outside of the segments they have broadcast messages to. This means that users who do not broadcast reveal no information about their movements.
# Quick hack to read latest JHU data and plot confirmed cases and deaths | |
# Dashboard: https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6 | |
# Data: https://github.com/CSSEGISandData/COVID-19/tree/master/csse_covid_19_data/csse_covid_19_time_series | |
caseplot <- function(filename, color) { | |
uu = read.csv(filename, header=TRUE, stringsAsFactors=FALSE) | |
vv = uu[which(uu[,2] == "US"),] | |
cumulative.confirmed = apply(vv[,5:60], 2, sum) | |
new.confirmed = diff(cumulative.confirmed) | |
plot(new.confirmed, col=color, type='o', xlab="", ylab="", main="", lty="dashed", pch=20) |
(platformvm.Genesis) { | |
Accounts: ([]platformvm.Account) (len=1 cap=1) { | |
(platformvm.Account) { | |
Address: (ids.ShortID) 6Y3kysjF9jnHnYkdS9yGAuoHyae2eNmeV, | |
Nonce: (uint64) 0, | |
Balance: (uint64) 20000000000000 | |
} | |
}, | |
Validators: (*platformvm.EventHeap)(0xc00011b220)({ | |
SortByStartTime: (bool) false, |
Vertcoin is a Bitcoin clone that aims to be ASIC-resistant by hard forking to new mining algorithms whenever ASICs are deployed on the network. Vertcoin was previously 51% attacked in Dec 2018 and has since changed its proof-of-work algorithm to Lyra2REv3. On Nov 30th 2019, a Vertcoin miner noticed a large upswing in hashrate rental prices for Lyra2REv3 on Nicehash. This was combined with workers connected to Nicehash's stratum server being sent work for unknown (non-public) Vertcoin blocks. I contacted Bittrex, Vertcoin's most prominent exchange, to recommend they disable the Vertcoin wallet on their platform once it became clear an attack was in progress, which they subsequently did.
On Sunday, 1 December 2019 15:19:47 GMT 603 blocks were removed from the VTC main chain and replaced by 553 attacker blocks. We
(Phaiax - 2019/12/1 - CC_BY_SA 4.0)
Lately I was porting a software from tokio/futures-1.0 to async-await.
I somehow thought async-std
was the successor of tokio
and ported everything to async-std
.
80% in, I noticed that my hyper
dependency requires tokio
and that it's not possible to replace tokio
with async-std
without also replacing hyper
. Also, tokio
and async-std
try to solve the same problem. So I started a journey into the inners of the rust async story to find out if it is possible to use both tokio
and async-std
at the same time. (tl;dr: it is). I had heard of reactors and executors before, but there was much new stuff to discover.
- Review clippy warnings; most of the time these are benign or irrelevant, but they can help spotting red flags.
- Build and run all the unit tests, assess the code coverage and keep note of the un(der)tested component.
- Review the dependencies listed in Cargo.toml and Cargo.lock: Will the latest version be used? (preferable but not always the right choice) Are these established, trustworthy packages? You may use the subcommand cargo-audit (thanks @dues__ for the pointer).
- Look for unsafe code blocks, and evaluate the risk (can an attacker control the input used in these blocks? etc.)
- Look for risky uses of unwrap(), which can cause panics, as opposed to pattern-matched error
from functools import reduce | |
import binascii | |
from os import urandom | |
from py_ecc.bn128 import * | |
from sha3 import keccak_256 | |
""" | |
Implements BLS signatture aggregation as described at: | |
https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html |
#!/usr/bin/env python | |
# vim: set fileencoding=utf-8 | |
# | |
# USAGE: | |
# Back up your tmux old config, run the script and redirect stdout to your conf | |
# file. Example: | |
# | |
# $ cp ~/.tmux.conf ~/.tmux.conf.orig | |
# $ python ./tmux-migrate-options.py ~/.tmux.conf.orig > ~/.tmux.conf | |
# |
default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
A new sighash flag has been proposed (originally for Lightning, now for Eltoo) which redacts information about the spending inputs, most notably their transaction IDs.
This facility is both powerful and dangerous: it means that signatures intended for one transaction can be used on other transactions. It also makes up a very strong increase in the malleability of transactions. SIGHASH_NOINPUT allows for much more flexible off-chain smart contracts than nonmalleable transactions. Note that Eltoo requires SIGHASH_NOINPUT, for instance. It's not clear whether such a dangerous feature will be adopted on BCH any time soon.
In this gist I'm going to explain that CHECKDATASIG covenants let us write smart contracts that emulate SIGHASH_NOINPUT. This capability alone should in principle allow to build Lightning, Eltoo with bilaterally funded smart contracts on BCH (though, with some significant