Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."
The current derivation method of Hierarchical Deterministic wallets has a weakness in which any individual private key may be combined with any ancestor extended public key (as long as there are no hardened keys in between) to generate the associated extended private key.
This proposal will set out to eliminate this weakness by:
-
- Using 1 leak protection of keys
-
- Using convention to prevent multiple keys being derived from the same parent.
There is a lot of considerations for security in use cases that would benefit from an extended public key on a server to generate public keys. Currently there are even certain business models that are impossible to use BIP32 due to the weakness.
from pycoin.tx.pay_to import address_for_pay_to_script, build_hash160_lookup, build_p2sh_lookup, ScriptMultisig | |
from pycoin.key import Key | |
def generate_multisig_address(priv_keys, N=3, M=2, netcode = COIN_NETWORK): | |
''' | |
Generate a multisig address from a list of pycoin keys (addresses public or private) | |
multisig N out of M | |
''' | |
#keys = sorted(keys, key=lambda k: k.sec_as_hex()) #sort keys to have the same multisig address from any similar list of keys | |
keys = [] |
#!/usr/bin/env ruby | |
require 'open-uri' | |
require 'JSON' | |
require 'digest/sha2' | |
require 'pry' | |
require 'bigdecimal' | |
require 'bitcoin' # Because I need to cheat every now and then | |
# Usage: | |
# gem install pry json ffi ruby-bitcoin |
In reply to "@Vlad_Roberto: No, not a programmer. I just know there's better ways to doing anything without massive energy consumption & Banks."
The problem of blockchain synchronization is the following:
Imagine you are sitting in a bunker. You have no idea what people are out there and what are their intentions. You only receive some incoming messages from strangers that may contain anything. They can be just random garbage or deliberately crafted messages to confuse you or lie to you. You never know. You cannot trust anyone.e
The problem of "money" or any other "social contract" is that everyone should be able to know what the majority agrees to without trusting some intermediaries (otherwise they can easily obuse their special position). If everyone votes for "X", then you sitting in a bunker must somehow independently figure out that all those other people indeed voted for "X" and not for "Y" or "Z". But remember: you cannot trust anyone's message and messages are the only thing you get from the outsi
EIP: draft Title: Ethereum Domain Name Service - Specification Author: Nick Johnson Status: Draft Type: Informational Created: 2016-04-04
Abstract
# coding=utf-8 | |
""" | |
LICENSE http://www.apache.org/licenses/LICENSE-2.0 | |
""" | |
import datetime | |
import sys | |
import time | |
import threading | |
import traceback | |
import SocketServer |
0x8D68583e625CAaE969fA9249502E105a21435EbF |
WARNING: These are notes and are not complete, they may contain errors. They certainly contain awkward language (sorry).
These are my notes from reading the Casper LLL Purity Checker currently being reviewed here: ethereum/casper#143
Specifically, the casper/contracts/purity_checker.py
file.