evgenykuzyakov

Implicit accounts

Background

Implicit accounts work similarly to Bitcoin/Ethereum accounts. It allows you to reserve an account ID before it's created by generating a ED25519 key-pair locally. This key-pair has a public key that maps to the account ID. The account ID is a lowercase hex representation of the public key. ED25519 Public key contains 32 bytes that maps to 64 characters account ID.

creatornader

Organization	Specification	Status	SSI Stack	Description
W3C	Decentralized Identifiers (DIDs)	Working Group	Secure Connections	New type of identifier which is globally unique, highly available & cryptographically verifiable.
W3C	Decentralized Identifier (DID) Resolution	Community Group	Secure Connections	Specifies guidelines for resolving and dereferencing DIDs to obtain DID Docs.
W3C	DID Spec Registries	Working Group	Secure Connections	Official registry for all known global parameters, properties, and values used by the decentralized identifier ecosystem. Includes the DID Method Registry, a list of DID methods with known implementations.
W3C	DID Use Cases	Working Group	Secure Connections	O

Deniallugo

SQL

• Чем SQL отличается от NoSQL
• Что такое транзакции?
• Что такое CAP теорема?
• Что такое ACID?

Python

• Что такое GIL? Его особенности работы (конкурентность vs параллелизм)

catap

import paramiko
import socket
import sys

nbytes = 4096
hostname = "127.0.0.1"
port = 2222

sock = socket.socket()
try:

chriseth

// This file is MIT Licensed.
//
// Copyright 2017 Christian Reitwiessner
// Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
// The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF O

chriseth

contract PatriciaTree {
    // List of all keys, not necessarily sorted.
    bytes[] keys;
    // Mapping of hash of key to value
    mapping (bytes32 => bytes) values;

    struct Label {
        bytes32 data;
        uint length;
    }

File tree

# build result
/bin

# bootstrap result
/bin/gb
/bin/gb-vendor

# build result
/bin/BINARY_NAME

srdjan

100+ different js counter apps...

chriseth

Having seen @pirapira's sketch of Bamboo ( https://github.com/pirapira/bamboo/ ), which proposed to add better control about the "smart contract program flow", even across calls, I thought that this should certainly be added to Solidity, and actually, it might even be possible now to a certain degree using inline assembly.

The problem is that with many functions in a contract, it is not always clear which can be called at which stage in the contract's lifetime. Certain smart contracts would be easier to understand if written as follows:

elliptic-shiho

import hashlib

b = 256
q = 2**255 - 19
l = 2**252 + 27742317777372353535851937790883648493

def H(m):
  return hashlib.sha512(m).digest()

def expmod(b,e,m):