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
Stone Gao stonegao
Completed: https://gist.github.com/fiatjaf/ea7d21e81359e1eb8abcb8805306adaa?permalink_comment_id=4484926#gistcomment-4484926
tl;dr 5M sat bounty to make https://github.com/fiatjaf/no-fed work.
ActivityPub communication is between servers. A server talks to another server, pushing and pulling data. Identities live on servers. Nostr communication is between clients and servers.
Songs for Tunes lets artists upload songs to sell on an open decentralized marketplace with other artists. The goal is to fund music artists to keep producing great music.
To mint, you need music.
You must be the owner of an original Tune NFT. You can buy one here: https://opensea.io/collection/tunesproject
After that, you can mint directly from our web app: https://songs.tunesproject.org
| const eventFilter = (contractAddress, contractAbi, eventName, _provider) => { | |
| const provider = _provider | |
| // this will return an array with an object for each event | |
| const events = contractAbi.abi.filter(obj => obj.type ? obj.type === "event" : false); | |
| // getting the Transfer event and pulling it out of its array | |
| const event = events.filter(event => event.name === eventName)[0]; | |
| // getting the types for the event signature | |
| const types = event.inputs.map(input => input.type) | |
| // knowing which types are indexed will be useful later | |
| let indexedInputs = []; |
25/5/2020
Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B.
Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behaviour, and perhaps had never even heard of this software.
To understand how constructors through Solidity works (that is, how do we go from the compiled contract's bin to a live deployed contract with a different deployedBytecode), I took a deep dive into how one simple contract worked.
The contract Simple.sol:
pragma solidity ^0.5.12;
contract Simple {
| ==Phrack Inc.== | |
| Volume 0x0f, Issue 0x45, Phile #0x0c of 0x10 | |
| |=-----------------------------------------------------------------------=| | |
| |=--------------=[ Attacking Ruby on Rails Applications ]=---------------=| | |
| |=-----------------------------------------------------------------------=| | |
| |=---------------------=[ joernchen of Phenoelit ]=----------------------=| | |
| |=---------------------=[ [email protected] ]=----------------------=| | |
| |=-----------------------------------------------------------------------=| |
| package main | |
| import ( | |
| "fmt" | |
| "os" | |
| "os/exec" | |
| "syscall" | |
| ) | |
| func main() { |
Context: I was asked for a list of interesting reading relating to "distributed databases, behavior under partitions and failures, failure detection." Here's what I came up with in about an hour.
For textbooks, "Introduction to Reliable and Secure Distributed Programming" is a superb introduction to distributed computing from a formal perspective; it's really not about "programming" or "engineering" but about distributed system fundamentals like consensus, distributed registers, and broadcast. Used in Berkeley's Distributed Computing course (and HT to @lalithsuresh) Book Site
Notes from courses like Lorenzo Alvisi's Distributed Computing class can be great.
There are a bunch of classics on causality, [Paxos](ht
If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:
In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):
- Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
- Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
- Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
- Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
- Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
- Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht