my gists, just random but connected thoughts relating to things involving programming and distributed systems.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

transactioncentric.md 2.1KB

transaction-centric

Why would you write a whole programming language interpreter just to validate transactions.

No, I already know the other answer, because of extensibility, but this is silly. It’s not that hard to make new source code and then compile it, what’s this solving a problem that doesn’t exist???

It also introduces unnecessary extra data in transactions, and we don’t really want to be extending the needs of our databases before we even start.

simple pay to address

We already are familiar with the types of transactions. These silly transaction languages assume a static software base. This is not entirely invalid as regards to blockchain’s tendency as all distributed permissionless things, to change the protocol slowly, but this doesn’t also have to apply to the code that makes this protocol.

So, why not just have a simple transaction type register and 4 bytes and you can have all the different kinds of transactions you want, with only their parameters and none of the parts that give semantics that are not implicit anyway.

transaction centric for transaction mesh

Causality can be proven beyond equivocation between a group of nodes engaging in a race to be proven the first to do some particular thing. It isn’t possible to guess what things you haven’t heard of, even if your neighbour just heard it, so when the neighbour reports some other event then he knows something you don’t.

Given enough such reports of most recently seen events circulating around the gossip network, one can establish positively the relative sequence of events that have a causal constraint (like a payment, you have to first receive one before you can make one, with the exception of a keybase, which you mine).

Distributed Journal Cache Protocol

The transaction centric nature of DJCP is a good match with hard coded identifiable transaction types with simple parsing (just parameters!). Validating transactions is expensive in the replay process and will present a bottleneck in the maximum transaction throughput capacity of the network.

confirmation of final draft payment