I am assuming minimal changes to commitment transaction structure, essentially swapping out
HTLC for PTLC, so no fast-forward schemes here.
Here are output labels because I get confused so often what things in BOLTs mean:
a_o_atx_* Alice-offered "offered PTLC" in Alice's txa_o_btx_* Alice-offered "received PTLC" in Bob's txb_o_atx_* Bob-offered "received PTLC" in Alice's txb_o_btx_* Bob-offered "offered PTLC" in Bob's tx
Abstract: In this document, I will outline a proof-of-liabilities (PoL) scheme for ecash systems and Cashu specifically, which is a Chaumian ecash system for Bitcoin. The PoL scheme consists of three parts. First, a publicly auditable list of all issued ecash tokens in the form of mint proofs, and second, a publicly auditable list of all redeemed ecash tokens in the form of burn proofs, which are both regularly published by the mint operator. Third, a mint publicly commits to rotate its keys regularly once each epoch and allows all ecash in circulation to recycle from old epochs to the newest one. If clients remain vigilant and mints agree on a certain set of rules of operation which are publicly verifiable, users of a mint can detect whether a cheating mint has printed unbacked ecash during a past epoch, and, in many cases, provide public proofs of the mint engaging in this adversary behavior. Users achieve this by regularly checking t
Maintainer: Keil Miller Jr
How to create and manage an AUR package.
The following link should be read:
| #!/usr/bin/env python3 | |
| # Distributed under the MIT software license | |
| import binascii, struct, sys, io, argparse | |
| from PIL import Image | |
| IMG_WIDTH = 512 # could be made adaptive... | |
| MIN_HEIGHT = 4 # minimum height of image; twitter won't let us upload anything smaller | |
| BYTES_PER_PIXEL = 4 # RGBA, 8 bit | |
| def div_roundup(x,y): |
| # Today the twitter user @ayubio said he had received the private key for a Brazillian bank's HTTPS certificate: | |
| # - https://twitter.com/ayubio/status/994260981294469120 | |
| # - https://twitter.com/ayubio/status/994262029929246722 | |
| # - https://twitter.com/ayubio/status/994277992351391744 | |
| # To prove he actualy had the key, another user asked him to sign a message with such key and so he did: | |
| # - http://pastebin.xyz/p?q=bXllODA | |
| # The commands bellow will check that signature | |
| # Store the message in a file (tweet.txt) in the same way @ayubio did: |
| import certstream | |
| keywords = ['paypal', 'paypol'] | |
| def extract_domains(domains): | |
| res = [] | |
| for domain in domains: | |
| for keyword in keywords: | |
| if keyword in domain: | |
| res.append(domain) |
| Objective: compare Task<T> vs ValueTask<T> in a scenario that should | |
| be ideal for ValueTask<T> - non-trivial results, but usually (always) | |
| already completed. | |
| Hypothesis: ValueTask<T> should be more efficient, as it does not (in | |
| the "already completed" case) involve allocation. | |
| Methodology: create a test rig that computes a number using multiple | |
| nested roll-up operations, comparing sync vs async-Task<T> vs async-ValueTask<T>; | |
| use "async"/"await" for the rollups in the async cases. Run all tests using |
| public static void Main() | |
| { | |
| var paraCadastrar = new [] | |
| { | |
| new { Chave = "CSVDEFAULT", Descricao = "Descrição detalhada (ou não)" }, | |
| new { Chave = "JSONDEFAULT", Descricao = "Descrição detalhada (ou não)" }, | |
| new { Chave = "YAML", Descricao = "Descrição detalhada (ou não)" }, | |
| new { Chave = "INIT", Descricao = "Descrição detalhada (ou não)" }, | |
| new { Chave = "CONFIG", Descricao = "Descrição detalhada (ou não)" }, | |
| new { Chave = "BSON", Descricao = "Descrição detalhada (ou não)" }, |