CodeEthsol::
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html]
//simple contract
pragma solidity ^0.4.0;
contract SimpleStorage {
uint storedData;
function set(uint x) {
storedData = x;
}
function get() constant returns (uint) {
return storedData;
}
}
ethsolscp'SEMANTIC-UNIT (ethsolsut)
Name::
* cpt.ethsolsut,
* cpt.ethsol'sut,
* cpt.ethsol'type,
* cpt.ethsolsut,
ethsolsut'Location
Description::
// Data locations: Memory vs. storage vs. stack - all complex types (arrays,
// structs) have a data location
// 'memory' does not persist, 'storage' does
// Default is 'storage' for local and state variables; 'memory' for func params
// stack holds small local variables
// for most types, can explicitly set which data location to use
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'location,
ethsolsut'Visibility
Description::
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
Name::
* cpt.ethsol'visibility-attribute,
* cpt.ethsolsut'access,
ethsolsut'Visibility-specifier
Name::
* cpt.ethsol'visibility-specifier,
ethsolsut'Public-vs
Description::
public:
Public functions are part of the contract interface and can be either called internally or via messages.
For public state variables, an automatic getter function (see below) is generated.
...
Functions can be specified as being external, public, internal or private, where the default is public.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
... The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
'public' makes externally readable (not writeable) by users or contracts
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'public-sut,
* cpt.ethsolpublic,
ethsolsut'Private-vs
Description::
private:
Private functions and state variables are only visible for the contract they are defined in and not in derived contracts.
Note
Everything that is inside a contract is visible to all external observers. Making something private only prevents other contracts from accessing and modifying the information, but it will still be visible to the whole world outside of the blockchain.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
===
"private" means that other contracts can't directly query balances [sut] but data is still viewable to other parties on blockchain
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'private-sut,
ethsolsut'External-vs
Description::
external:
External functions are part of the contract interface, which means they can be called from other contracts and via transactions.
An external function f cannot be called internally (i.e. f() does not work, but this.f() works).
External functions are sometimes more efficient when they receive large arrays of data.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
Name::
* cpt.ethsol'external-sut,
ethsolsut'Internal-vs
Description::
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
...
For state variables, external is not possible and the default is internal.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#visibility-and-getters]
Name::
* cpt.ethsol'internal-sut,
ethsolsut'Doing
ethsolsut'Checking
Description::
Types are checked at compile-time, so if you make a mistake you will get a compiler error. For example, this is not possible:
contract Test {
bool bVar;
function causesError(address addr){
bVar = addr;
}
}
The error it would throw is this: Error: Type address not implicitly convertible to expected type bool.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
ethsosut'Converting
Description::
Type conversion
The compiler allows you to convert between types in certain cases. Let’s say you have the number 1 stored in a uint variable, and you want to use it in another variable of type int. That is possible - but you generally have to do the conversion yourself. This is how you would do it:
uint x = 1;
int y = int(x);
Type conversion is also checked at compile time and will generally be caught but there are exceptions; the most important one is when converting an address to a contract type. These type of casts can lead to bugs. We will be looking at some examples in a later section.
Finally, type conversion is something that should be used with care. It’s good in some cases, but excessive and/or careless casting is usually a sign that the code is not well written and can sometimes have bad consequences (such as data-loss). Remember types are there for a reason.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
SPECIFIC
Name::
* ethsolsut.specific,
* cpt.ethsolsut.specific,
Specific::
* address - ad,
* array - a,
* boolean - b,
* bytes - bt,
* contract - c,
* enum - en,
* event - e,
* function - f,
* library - l,
* mapping - m,
* number:
- int,
- int8,
- uint,
- uint8,
* string - s,
* struct - sc,
===
* REFERENCY-TYPE,
* VALUE-TYPE,
* NAME-VALUE-PAIR,
* API,
* JSON-INTERFACE,
ethsolsut.REFERENCE-TYPE
Description::
Reference Types
Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen.
Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage (where the state variables are held).
- array
- stuct
[http://solidity.readthedocs.io/en/v0.4.9/types.html#reference-types]
Name::
* cpt.ethsol'reference-type,
* cpt.ethsol'reference-type,
ethsolsut'Data-location
Description::
Data location
Every complex type, i.e. arrays and structs, has an additional annotation, the “data location”, about whether it is stored in memory or in storage. Depending on the context, there is always a default, but it can be overridden by appending either storage or memory to the type. The default for function parameters (including return parameters) is memory, the default for local variables is storage and the location is forced to storage for state variables (obviously).
There is also a third data location, “calldata”, which is a non-modifyable non-persistent area where function arguments are stored. Function parameters (not return parameters) of external functions are forced to “calldata” and it behaves mostly like memory.
Data locations are important because they change how assignments behave: Assignments between storage and memory and also to a state variable (even from other state variables) always create an independent copy. Assignments to local storage variables only assign a reference though, and this reference always points to the state variable even if the latter is changed in the meantime. On the other hand, assignments from a memory stored reference type to another memory-stored reference type does not create a copy.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#data-location]
===
* storage
* memory
* calldata
ethsolsut.VALUE-TYPE
Description::
Value Types
The following types are also called value types because variables of these types will always be passed by value, i.e. they are always copied when they are used as function arguments or in assignments.
- Booleans
- Integers
- Address
- Fixed-size byte arrays
- Dynamically-sized byte arrays
- Fixed point numbers
- Address-literals
- Rational and integer literals
- String literals
- Hexadecimal literals
- Enums
- Function types
[http://solidity.readthedocs.io/en/v0.4.9/types.html#value-types]
Name::
* cpt.ethsol'value-type,
ethsolscpsut.ADDRESS (ethsolad)
Description::
Represents an-ethereum-account-address.
===
The address type is a 160-bit value that does not allow any arithmetic operations.
It is suitable for storing addresses of contracts or keypairs belonging to external persons.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.6258fe71]
===
address which is a cryptographic hash (SHA3)
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
address: Holds a 20 byte value (size of an Ethereum address).
Address types also have members(see [Functions on addresses](#functions-on-addresses)) and serve as base for all contracts.
Operators:
<=, <, ==, !=, >= and >
[https://solidity.readthedocs.org/en/latest/types.html#address]
===
// Addresses - holds 20 byte/160 bit Ethereum addresses
// No arithmetic allowed
address public owner;
// Types of accounts:
// Contract account: address set on create (func of creator address, num transactions sent)
// External Account: (person/external entity): address created from public key
// Add 'public' field to indicate publicly/externally accessible
// a getter is automatically created, but NOT a setter
// All addresses can be sent ether
owner.send(SOME_BALANCE); // returns false on failure
if (owner.send) {} // REMEMBER: wrap in 'if', as contract addresses have
// functions executed on send and these can fail
// Also, make sure to deduct balances BEFORE attempting a send, as there is a risk of a recursive
// call that can drain the contract
// can override send by defining your own
// Can check balance
owner.balance; // the balance of the owner (user or contract)
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'address,
* cpt.ethsoladdress,
* cpt.ethsolad,
ethsolad'balance-number
Description::
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
ethsolad'call
Description::
Furthermore, to interface with contracts that do not adhere to the ABI, the function call is provided which takes an arbitrary number of arguments of any type. These arguments are padded to 32 bytes and concatenated. One exception is the case where the first argument is encoded to exactly four bytes. In this case, it is not padded to allow the use of function signatures here.
address nameReg = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
nameReg.call("register", "MyName");
nameReg.call(bytes4(keccak256("fun(uint256)")), a);
call returns a boolean indicating whether the invoked function terminated (true) or caused an EVM exception (false). It is not possible to access the actual data returned (for this we would need to know the encoding and size in advance).
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
ethsolad'send-function
Description::
It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to an address using the send function:
address x = 0x123;
address myAddress = this;
if (x.balance < 10 && myAddress.balance >= 10) x.send(10);
[http://solidity.readthedocs.io/en/latest/types.html#members-of-addresses]
ethsolscpsut.ARRAY (ethsola)
Description::
// Arrays
bytes32[5] nicknames; // static array
bytes32[] names; // dynamic array
uint newLength = names.push("John"); // adding returns new length of the array
// Length
names.length; // get length
names.length = 1; // lengths can be set (for dynamic arrays in storage only)
// multidimensional array
uint x[][5]; // arr with 5 dynamic array elements (opp order of most languages)
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsola,
* cpt.ethsolarray,
ethsolscpsut.BOOLEAN (ethsolb)
Name::
* cpt.ethsolb,
CodeEthsol::
bool voted;
===
bool b = true; // or do 'var b = true;' for inferred typing
ethsolscpsut.BYTES (ethsolbt)
Description::
Variables of type bytes and string are special arrays.
A bytes is similar to byte[], but it is packed tightly in calldata.
string is equal to bytes but does not allow length or index access (for now).
So bytes should always be preferred over byte[] because it is cheaper.
[http://solidity.readthedocs.io/en/v0.4.9/types.html#index-14]
===
// Bytes available from 1 to 32
byte a; // byte is same as bytes1
bytes2 b;
bytes32 c;
// Dynamically sized bytes
bytes m; // A special array, same as byte[] array (but packed tightly)
// More expensive than byte1-byte32, so use those when possible
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'bytes-type,
* cpt.ethsolbytes,
* cpt.ethsolbt,
CodeEthsol::
bytes3 b;
ethsolscpsut.CONTRACT-UNIT (ethsolc)
Description::
Solidity uses the contract data-type to model smart contracts. It is very similar to a class.
A contract has a number of fields and methods; for example, the contract type can have a constructor, it can inherit from other contracts, etc.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
Contracts in Solidity are similar to classes in object-oriented languages.
Each contract can contain declarations of State Variables, Functions, Function Modifiers, Events, Structs Types and Enum Types.
Furthermore, contracts can inherit from other contracts.
[https://solidity.readthedocs.io/en/v0.4.9/structure-of-a-contract.html]
Name::
* cpt.ethsolc,
* cpt.ethsol'contract-semantic-unit,
* cpt.ethsol'contract-datatype,
* cpt.sltcontract,
* cpt.sltc,
* cpt.ethsolc,
Example::
* https://github.com/fivedogit/solidity-baby-steps,
ethsolc'Stage
Description::
State Machine
Contracts often act as a state machine, which means that they have certain stages in which they behave differently or in which different functions can be called. A function call often ends a stage and transitions the contract into the next stage (especially if the contract models interaction). It is also common that some stages are automatically reached at a certain point in time.
An example for this is a blind auction contract which starts in the stage “accepting blinded bids”, then transitions to “revealing bids” which is ended by “determine auction autcome”.
Function modifiers can be used in this situation to model the states and guard against incorrect usage of the contract.
[https://solidity.readthedocs.org/en/latest/common-patterns.html#state-machine]
ethsolc.SPECIFIC (derived)
CodeEthsol::
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
ethsolscpsut.ENUM (ethsolen)
Description::
Enums are one way to create a user-defined type in Solidity.
They are explicitly convertible to and from all integer types but implicit conversion is not allowed.
[https://solidity.readthedocs.org/en/latest/types.html#enums]
Name::
* cpt.ethsolen,
* cpt.ethsolenum,
CodeEthsol::
enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }
===
enum Status {maintenance, active, suspended, bankrupt}
===
// Enums
enum State { Created, Locked, Inactive }; // often used for state machine
State public state; // Declare variable from enum
state = State.Created;
// enums can be explicitly converted to ints
uint createdState = uint(State.Created); // 0
[https://learnxinyminutes.com/docs/solidity/]
ethsolscpsut.EVENT (ethsole)
Description::
Events are used to dump information from Solidity contract code into the blockchain clients log. It is a way of making that information available to the “outside world”. On top of the events themselves, most clients also have a way of capturing this output and encapsulating it in an event data-structures. This is particularly important for efficiency between the blockchain clients and the “outside world” which will rely upon these events in order for other things to happen.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
event Transfer(address indexed _from, address indexed _to, uint256 _value);
Next we specify an event, which is how in Solidity we use the logging facility of the Ethereum Virtual Machine. When called, events cause the arguments to be stored in the transaction’s log. In this instance we are storing three parameters, _from which is of type address, _to_ which is another address, and _value which is a uint256 (256-bit unsigned integer). Notice that _from and _to have an additional attribute indexed. This attribute causes those arguments to be treated as log topics, rather than data.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
Name::
* cpt.ethsol'event,
* cpt.ethsole,
CodeEthsol::
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
CodeEthsol::
[https://learnxinyminutes.com/docs/solidity/]
// B. Events
// Events are notify external parties; easy to search and
// access events from outside blockchain (with lightweight clients)
// typically declare after contract parameters
// Typically, capitalized - and add Log in front to be explicit and prevent confusion
// with a function call
// Declare
event LogSent(address indexed from, address indexed to, uint amount); // note capital first letter
// Call
Sent(from, to, amount);
// For an external party (a contract or external entity), to watch:
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
// Common paradigm for one contract to depend on another (e.g., a
// contract that depends on current exchange rate provided by another)
ethsolscpsut.FUNCTION (ethsolf)
Name::
* cpt.ethsolf,
* cpt.sltfunction,
* cpt.sltf,
* cpt.ethsolf,
ethsolf'Output
Description::
// Functions can return many arguments, and by specifying returned arguments
// name don't need to explicitly return
function increment(uint x, uint y) returns (uint x, uint y) {
x += 1;
y += 1;
}
// Call previous functon
uint (a,b) = increment(1,1);
[https://learnxinyminutes.com/docs/solidity/]
ethsolf'Interface
JSON::
{
"constant": true,
"inputs": [ { "name": "", "type": "address" } ],
"name": "versions",
"outputs": [ { "name": "", "type": "uint256" } ],
"payable": false,
"type": "function"
}
===
{
"payable": false,
"type": "fallback"
}
SPECIFIC
Name::
* ethsolf.specific,
* cpt.ethsolf.specific,
Specific::
ethsolf.addmod(uint x, uint y, uint k) returns (uint):
compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.mulmod(uint x, uint y, uint k) returns (uint):
compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256.
ethsolf.sha3(...) returns (bytes32):
compute the Ethereum-SHA-3 hash of the (tightly packed) arguments
ethsolf.sha256(...) returns (bytes32):
compute the SHA-256 hash of the (tightly packed) arguments
ethsolf.ripemd160(...) returns (bytes20):
compute RIPEMD-160 hash of the (tightly packed) arguments
ethsolf.ecrecover(bytes32, uint8, bytes32, bytes32) returns (address):
recover public key from elliptic curve signature - arguments are (data, v, r, s)
[https://solidity.readthedocs.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions]
ethsolf.CONSTANT
Description::
Constant Functions
Functions can be declared constant. These functions promise not to modify the state.
pragma solidity ^0.4.0;
contract C {
function f(uint a, uint b) constant returns (uint) {
return a * (b + 42);
}
}
Note
Getter methods are marked constant.
Warning
The compiler does not enforce yet that a constant method is not modifying state.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
ethsolf.CONSTANT.NO
Description::
What is the difference between a function marked constant and one that is not?
constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.
“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.
[https://solidity.readthedocs.org/en/latest/frequently-asked-questions.html#what-is-the-difference-between-a-function-marked-constant-and-one-that-is-not]
ethsofl.INTERNAL
Description::
internal:
Those functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it), without using this.
ethsolf.FALLBACK
Description::
Fallback Function
A contract can have exactly one unnamed function. This function cannot have arguments and cannot return anything. It is executed on a call to the contract if none of the other functions matches the given function identifier (or if no data was supplied at all).
Furthermore, this function is executed whenever the contract receives plain Ether (without data). In such a context, there is usually very little gas available to the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as possible.
In particular, the following operations will consume more gas than the stipend provided to a fallback function:
Writing to storage
Creating a contract
Calling an external function which consumes a large amount of gas
Sending Ether
Please ensure you test your fallback function thoroughly to ensure the execution cost is less than 2300 gas before deploying a contract.
Warning
Contracts that receive Ether but do not define a fallback function throw an exception, sending back the Ether (this was different before Solidity v0.4.0). So if you want your contract to receive Ether, you have to implement a fallback function.
pragma solidity ^0.4.0;
contract Test {
// This function is called for all messages sent to
// this contract (there is no other function).
// Sending Ether to this contract will cause an exception,
// because the fallback function does not have the "payable"
// modifier.
function() { x = 1; }
uint x;
}
// This contract keeps all Ether sent to it with no way
// to get it back.
contract Sink {
function() payable { }
}
contract Caller {
function callTest(Test test) {
test.call(0xabcdef01); // hash does not exist
// results in test.x becoming == 1.
// The following call will fail, reject the
// Ether and return false:
test.send(2 ether);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#fallback-function]
ethsolf.MODIFIER
Description::
Modifiers can be used to easily change the behaviour of functions, for example to automatically check a condition prior to executing the function. They are inheritable properties of contracts and may be overridden by derived contracts.
pragma solidity ^0.4.0;
contract owned {
function owned() { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
// it - it will be used in derived contracts.
// The function body is inserted where the special symbol
// "_;" in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
modifier onlyOwner {
if (msg.sender != owner)
throw;
_;
}
}
contract mortal is owned {
// This contract inherits the "onlyOwner"-modifier from
// "owned" and applies it to the "close"-function, which
// causes that calls to "close" only have an effect if
// they are made by the stored owner.
function close() onlyOwner {
selfdestruct(owner);
}
}
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#function-modifiers]
===
// Modifiers validate inputs to functions such as minimal balance or user auth;
// similar to guard clause in other languages
// '_' (underscore) often included as last line in body, and indicates
// function being called should be placed there
modifier onlyAfter(uint _time) { if (now <= _time) throw; _ }
modifier onlyOwner { if (msg.sender == owner) _ }
// commonly used with state machines
modifier onlyIfState (State currState) { if (currState != State.A) _ }
// Append right after function declaration
function changeOwner(newOwner)
onlyAfter(someTime)
onlyOwner()
onlyIfState(State.A)
{
owner = newOwner;
}
// underscore can be included before end of body,
// but explicitly returning will skip, so use carefully
modifier checkValue(uint amount) {
_
if (msg.value > amount) {
uint amountToRefund = amount - msg.value;
if (!msg.sender.send(amountToRefund)) {
throw;
}
}
}
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsolf.modifier,
* cpt.ethsol'modifier-function,
ethsolf.OPERATOR
Description::
// 3. Simple operators
// Comparisons, bit operators and arithmetic operators are provided
// exponentiation: **
// exclusive or: ^
// bitwise negation: ~
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsoloperator,
ethsolscpsut.LIBRARY (ethsoll)
Description::
Libraries are similar to contracts, but their purpose is that they are deployed only once at a specific address and their code is reused using the DELEGATECALL (CALLCODE until Homestead) feature of the EVM. This means that if library functions are called, their code is executed in the context of the calling contract, i.e. this points to the calling contract, and especially the storage from the calling contract can be accessed. As a library is an isolated piece of source code, it can only access state variables of the calling contract if they are explicitly supplied (it would have no way to name them, otherwise).
...
Restrictions for libraries in comparison to contracts:
No state variables
Cannot inherit nor be inherited
Cannot recieve Ether
(These might be lifted at a later point.)
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#libraries]
Name::
* cpt.ethsol'library,
* cpt.ethsoll,
* cpt.ethsollibrary,
ethsolscpsut.MAPPING (ethsolm)
Description::
A mapping is a relational type, from keys to values,
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
===
Mapping types are declared as mapping _KeyType => _ValueType, where _KeyType can be almost any type except for a mapping and _ValueType can actually be any type, including mappings.
Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. The similarity ends here, though: The key data is not actually stored in a mapping, only its sha3 hash used to look up the value.
Because of this, mappings do not have a length or a concept of a key or value being “set”.
Mappings are only allowed for state variables (or as storage reference types in internal functions).
[https://solidity.readthedocs.org/en/latest/types.html#mappings]
===
// Dictionaries (any type to any other type)
mapping (string => uint) public balances;
balances["charles"] = 1;
console.log(balances["ada"]); // is 0, all non-set key values return zeroes
// 'public' allows following from another contract
contractName.balances("charles"); // returns 1
// 'public' created a getter (but not setter) like the following:
function balances(string _account) returns (uint balance) {
return balances[_account];
}
// Nested mappings
mapping (address => mapping (address => uint)) public custodians;
// To delete
delete balances["John"];
delete balances; // sets all elements to 0
// Unlike other languages, CANNOT iterate through all elements in
// mapping, without knowing source keys - can build data structure
// on top to do this
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'dictionary,
* cpt.ethsol'mapping,
* cpt.ethsolm,
ethsolscpsut.NUMBER (ethsoln)
Name::
* cpt.ethsoln,
ethsolscpsut.number.INTEGER
Description::
Integers in Solidity can be either signed or unsigned, and can be on the form intN/uintN, where N = 8*n for n = 1, 2, ... , 32. Some examples would be uint8, int32, int128, and uint240. Additionally, int and uint are shorthand for int256 and uint256, respectively.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-14-advanced-solidity-V.md]
===
int• / uint•: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.
Operators:
Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
Bit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)
Arithmetic operators: +, -, unary -, unary +, *, /, % (remainder), ** (exponentiation)
Division always truncates (it just maps to the DIV opcode of the EVM), but it does not truncate if both operators are literals (or literal expressions).
[https://solidity.readthedocs.org/en/latest/types.html#integers]
Name::
* cpt.ethsol'integer,
* cpt.ethsolinteger,
ethsol'int (ethsoln)
Name::
* cpt.ethsolint,
* cpt.ethsolint256,
ethsol'int8 (ethsoln8)
Name::
* cpt.ethsoluint8,
ethsol'uint (ethsolnu)
Description::
uint storedData;
//The line uint storedData; declares a state variable called storedData of type uint (unsigned integer of 256 bits).
===
uint used for currency amount (there are no doubles or floats) and for dates (in unix time)
...
uint constant VERSION_ID = 0x123A1; // A hex constant
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsoluint,
* cpt.ethsoluint256,
ethsol'uint8 (ethsolnu8)
Name::
* cpt.ethsoluint8,
ethsolscpsut.UNIT-OF-MEASUREMENT
Description::
// Currency units
// Currency is defined using wei, smallest unit of Ether
uint minAmount = 1 wei;
uint a = 1 finney; // 1 ether == 1000 finney
// Other units, see: http://ether.fund/tool/converter
// Time units
1 == 1 second
1 minutes == 60 seconds
// Can multiply a variable times unit, as units are not stored in a variable
uint x = 5;
(x * 1 days); // 5 days
// Careful about leap seconds/years with equality statements for time
// (instead, prefer greater than/less than)
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'unit-of-measurement,
ethsolscpsut.STRING (ethsols)
Description::
// same as bytes, but does not allow length or index access (for now)
string n = "hello"; // stored in UTF8, note double quotes, not single
// string utility functions to be added in future
// prefer bytes32/bytes, as UTF8 uses more storage
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsols,
* cpt.ethsolstring,
ethsolscpsut.STRUCT (ethsolsc)
Description::
// Structs and enums
struct Bank {
address owner;
uint balance;
}
Bank b = Bank({
owner: msg.sender,
balance: 5
});
// or
Bank c = Bank(msg.sender, 5);
c.amount = 5; // set to new value
delete b;
// sets to initial value, set all variables in struct to 0, except mappings
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'struct,
* cpt.ethsolsc,
* cpt.ethsolstruct,
CodeEthsol::
// Defines a new type with two fields.
struct Funder {
address addr;
uint amount;
}
ethsolscpsut.NAME-VALUE-PAIR (variable)
Description::
Solidity is a strongly-typed language which means that variables must have a type given to them.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
Name::
* cpt.ethsol'name-value-pair,
* cpt.ethsol'variable,
* cpt.ethsolv,
* cpt.ethsolvariable,
CodeEthsol::
address public minter;
// declares a state variable of type address that is publicly accessible.
===
mapping (address => uint) balances;
ethsolv.MEMORY-VARIABLE
Description::
contract Test {
int a = 999; // That's storage
function doIt() {
int b; // That's memory
assembly {
b := sload(a);
}
}
}
[http://ethereum.stackexchange.com/a/11677]
Name::
* cpt.ethsol'memory-variable,
* cpt.ethsolv.memory,
ethsolv.VAR
Description::
// Type inferrence
// var does inferred typing based on first assignment,
// can't be used in functions parameters
var a = true;
// use carefully, inference may provide wrong type
// e.g., an int8, when a counter needs to be int16
// var can be used to assign function to variable
function a(uint x) returns (uint) {
return x * 2;
}
var f = a;
f(22); // call
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsolvar,
ethsolv.CONSTANT
Description::
Constant State Variables
State variables can be declared as constant (this is not yet implemented for array and struct types and not possible for mapping types).
pragma solidity ^0.4.0;
contract C {
uint constant x = 32**22 + 8;
string constant text = "abc";
}
This has the effect that the compiler does not reserve a storage slot for these variables and every occurrence is replaced by their constant value.
The value expression can only contain integer arithmetics.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#constant-functions]
===
uint constant VERSION_ID = 0x123A1; // A hex constant
// with 'constant', compiler replaces each occurrence with actual value
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsol'constant,
* cpt.ethsolconstant,
ethsolv.GLOBAL
Description::
msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
Name::
* cpt.ethsol'global-variable,
* cpt.ethsolv.global,
Specific::
* block ##
* msg ##
* now ##
* this ##
* tx ##
ethsolv.this
Description::
// this
this; // address of contract
// often used at end of contract life to send remaining balance to party
this.balance;
this.someFunction(); // calls func externally via call, not via internal jump
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsolv.this,
ethsolv.block
Name::
* cpt.ethsol'block,
* cpt.ethsol'block,
API::
block.blockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most recent blocks excluding current
block.coinbase (address): current block miner’s address
block.difficulty (uint): current block difficulty
block.gaslimit (uint): current block gaslimit
block.number (uint): current block number
block.timestamp (uint): current block timestamp
[http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties]
===
// ** block - Information about current block **
now; // current time (approximately), alias for block.timestamp (uses Unix time)
block.number; // current block number
block.difficulty; // current block difficulty
block.blockhash(1); // returns bytes32, only works for most recent 256 blocks
block.gasLimit();
[https://learnxinyminutes.com/docs/solidity/]
ethsolsv.storage
Description::
// ** storage - Persistent storage hash **
storage['abc'] = 'def'; // maps 256 bit words to 256 bit words
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsolstorage,
ethsolscpsut.API
Name::
* cpt.ethsolAPI,
ethsolscpsut.JSON-INTERFACE (ABI)
Description::
The-interface of the-functions of a-contract in JSON-format.
===
[
{
"constant": true,
"inputs": [],
"name": "t32Hash_of_will",
"outputs": [ { "name": "", "type": "bytes32", "value": "0x0000000000000000000000000000000000000000000000000000000000000000", "displayName": "" } ],
"type": "function",
"displayName": "t32 Hash<span class=\"punctuation\">_</span>of<span class=\"punctuation\">_</span>will"
},
{
"constant": false,
"inputs": [ { "name": "sWillIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will In", "template": "elements_input_string" } ],
"name": "fWillNew",
"outputs": [],
"type": "function",
"displayName": "f Will New"
},
{
"constant": true,
"inputs": [],
"name": "aWill_owner",
"outputs": [ { "name": "", "type": "address", "value": "0x0998c9a0c7224ec2ed782a3ecfef53a0e25fa9fc", "displayName": "" } ],
"type": "function",
"displayName": "a Will<span class=\"punctuation\">_</span>owner"
},
{ "constant": true, "inputs": [ { "name": "sWillUserIn", "type": "string", "typeShort": "string", "bits": "", "displayName": "s Will User In", "template": "elements_input_string" } ], "name": "fWillCheck", "outputs": [ { "name": "bWill_correct", "type": "bool" } ],
"type": "function", "displayName": "f Will Check"
},
{
"inputs": [],
"type": "constructor"
}
]
Name::
* cpt.ABI.ethsol,
* cpt.ethsol'ABI,
* cpt.ethsol'JSON-interface,
* cpt.ethsolscpsut.ABI,
ethsolscp'SENTENCE (ethsolstc)
Name::
* cpt.ethsolstc,
* cpt.ethsol'sentence,
ethsolstc.ASSIGNMENT
Description::
// Destructuring/Tuples
(x, y) = (2, 7); // assign/swap multiple value
[https://learnxinyminutes.com/docs/solidity/]
Name::
* cpt.ethsolstc.assignment,
* cpt.ethsol'assignment-sentence,
ethsolstc.BRANCHING
Name::
* cpt.ethsolstc.branching,
CodeEthsol::
// 6. BRANCHING AND LOOPS
// All basic logic blocks work - including if/else, for, while, break, continue
// return - but no switch
// Syntax same as javascript, but no type conversion from non-boolean
// to boolean (comparison operators must be used to get the boolean val)
[https://learnxinyminutes.com/docs/solidity/]
ethsolstc.LOOP
Name::
* cpt.ethsolstc.loop,
CodeEthsol::
[https://learnxinyminutes.com/docs/solidity/]
// For loops that are determined by user behavior, be careful - as contracts have a maximal
// amount of gas for a block of code - and will fail if that is exceeded
// For example:
for(uint x = 0; x < refundAddressList.length; x++) {
if (!refundAddressList[x].send(SOME_AMOUNT)) {
throw;
}
}
// Two errors above:
// 1. A failure on send stops the loop from completing, tying up money
// 2. This loop could be arbitrarily long (based on the amount of users who need refunds), and
// therefore may always fail as it exceeds the max gas for a block
// Instead, you should let people withdraw individually from their subaccount, and mark withdrawn
ethsolstc.pragma
Name::
* cpt.ethsol'pragma,
* cpt.ethsolpragma,
* cpt.ethsolstc.pragma,
CodeEthsol::
pragma solidity ^0.4.0;
//The first line simply tells that the source code is written for Solidity version 0.4.0 or anything newer that does not break functionality (up to, but not including, version 0.5.0).
This is to ensure that the contract does not suddenly behave differently with a new compiler version.
[https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html 0-4-10.9aab3b86]
ethsolstc.import
Description::
Solidity supports import statements that are very similar to those available in JavaScript (from ES6 on), although Solidity does not know the concept of a “default export”.
At a global level, you can use import statements of the following form:
import "filename";
This statement imports all global symbols from “filename” (and symbols imported there) into the current global scope (different than in ES6 but backwards-compatible for Solidity).
import * as symbolName from "filename";
...creates a new global symbol symbolName whose members are all the global symbols from "filename".
import {symbol1 as alias, symbol2} from "filename";
...creates new global symbols alias and symbol2 which reference symbol1 and symbol2 from "filename", respectively.
Another syntax is not part of ES6, but probably convenient:
import "filename" as symbolName;
which is equivalent to import * as symbolName from "filename";.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#syntax-and-semantics]
Name::
* cpt.ethsol'import,
* cpt.ethsolimport,
ethsol'path-of-files
Description::
Paths
In the above, filename is always treated as a path with / as directory separator, . as the current and .. as the parent directory. When . or .. is followed by a character except /, it is not considered as the current or the parent directory. All path names are treated as absolute paths unless they start with the current . or the parent directory ...
To import a file x from the same directory as the current file, use import "./x" as x;. If you use import "x" as x; instead, a different file could be referenced (in a global “include directory”).
It depends on the compiler (see below) how to actually resolve the paths. In general, the directory hierarchy does not need to strictly map onto your local filesystem, it can also map to resources discovered via e.g. ipfs, http or git.
[https://solidity.readthedocs.io/en/v0.4.9/layout-of-source-files.html#paths]
ethsolstc.using-for
Description::
Using For
The directive using A for B; can be used to attach library functions (from the library A) to any type (B). These functions will receive the object they are called on as their first parameter (like the self variable in Python).
The effect of using A for *; is that the functions from the library A are attached to any type.
In both situations, all functions, even those where the type of the first parameter does not match the type of the object, are attached. The type is checked at the point the function is called and function overload resolution is performed.
The using A for B; directive is active for the current scope, which is limited to a contract for now but will be lifted to the global scope later, so that by including a module, its data types including library functions are available without having to add further code.
Let us rewrite the set example from the Libraries in this way:
pragma solidity ^0.4.0;
// This is the same code as before, just without comments
library Set {
struct Data { mapping(uint => bool) flags; }
function insert(Data storage self, uint value)
returns (bool)
{
if (self.flags[value])
return false; // already there
self.flags[value] = true;
return true;
}
function remove(Data storage self, uint value)
returns (bool)
{
if (!self.flags[value])
return false; // not there
self.flags[value] = false;
return true;
}
function contains(Data storage self, uint value)
returns (bool)
{
return self.flags[value];
}
}
contract C {
using Set for Set.Data; // this is the crucial change
Set.Data knownValues;
function register(uint value) {
// Here, all variables of type Set.Data have
// corresponding member functions.
// The following function call is identical to
// Set.insert(knownValues, value)
if (!knownValues.insert(value))
throw;
}
}
It is also possible to extend elementary types in that way:
pragma solidity ^0.4.0;
library Search {
function indexOf(uint[] storage self, uint value) returns (uint) {
for (uint i = 0; i < self.length; i++)
if (self[i] == value) return i;
return uint(-1);
}
}
contract C {
using Search for uint[];
uint[] data;
function append(uint value) {
data.push(value);
}
function replace(uint _old, uint _new) {
// This performs the library function call
uint index = data.indexOf(_old);
if (index == uint(-1))
data.push(_new);
else
data[index] = _new;
}
}
Note that all library calls are actual EVM function calls. This means that if you pass memory or value types, a copy will be performed, even of the self variable. The only situation where no copy will be performed is when storage reference variables are used.
[https://solidity.readthedocs.io/en/v0.4.9/contracts.html#using-for]
Name::
* cpt.ethsol'using-for,
ethsolscp'Error
Description::
Errors
There is no real error handling system in Solidity (yet). There are no try - catch or throw statements, or something to that effect. Contract designers need to deal with errors themselves. Solidity does some sanity checks on arrays and such, but will often respond simply by executing the (STOP) instruction. According to the developers, this is just put in as a placeholder until a more sophisticated error handling and recovery system is put in place.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
Name::
* cpt.ethsol'error,
ethsolscp'Style
Description::
// 13. STYLE NOTES
// Based on Python's PEP8 style guide
// Quick summary:
// 4 spaces for indentation
// Two lines separate contract declarations (and other top level declarations)
// Avoid extraneous spaces in parentheses
// Can omit curly braces for one line statement (if, for, etc)
// else should be placed on own line
[https://learnxinyminutes.com/docs/solidity/]
ethsolscp.SPECIFIC
Name::
* cpt.ethsolscp.specific,
Specific::
* https://github.com/fivedogit/solidity-baby-steps/tree/master/contracts,
* https://github.com/ConsenSys/dapp-store-contracts,
===
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/latest/ 0-4-10.9aab3b86]
ethsolscp.CROWDFUNDING
Name::
* cpt.ethsolscp.crowdfunding,
CodeEthsol::
[https://learnxinyminutes.com/docs/solidity/]
// *** EXAMPLE: A crowdfunding example (broadly similar to Kickstarter) ***
// ** START EXAMPLE **
// CrowdFunder.sol
/// @title CrowdFunder
/// @author nemild
contract CrowdFunder {
// Variables set on create by creator
address public creator;
address public fundRecipient; // creator may be different than recipient
uint public minimumToRaise; // required to tip, else everyone gets refund
string campaignUrl;
byte constant version = 1;
// Data structures
enum State {
Fundraising,
ExpiredRefund,
Successful
}
struct Contribution {
uint amount;
address contributor;
}
// State variables
State public state = State.Fundraising; // initialize on create
uint public totalRaised;
uint public raiseBy;
uint public completeAt;
Contribution[] contributions;
event LogFundingReceived(address addr, uint amount, uint currentTotal);
event LogWinnerPaid(address winnerAddress);
modifier inState(State _state) {
if (state != _state) throw;
_
}
modifier isCreator() {
if (msg.sender != creator) throw;
_
}
// Wait 6 months after final contract state before allowing contract destruction
modifier atEndOfLifecycle() {
if(!((state == State.ExpiredRefund || state == State.Successful) &&
completeAt + 6 months < now)) {
throw;
}
_
}
function CrowdFunder(
uint timeInHoursForFundraising,
string _campaignUrl,
address _fundRecipient,
uint _minimumToRaise)
{
creator = msg.sender;
fundRecipient = _fundRecipient;
campaignUrl = _campaignUrl;
minimumToRaise = _minimumToRaise;
raiseBy = now + (timeInHoursForFundraising * 1 hours);
}
function contribute()
public
inState(State.Fundraising)
{
contributions.push(
Contribution({
amount: msg.value,
contributor: msg.sender
}) // use array, so can iterate
);
totalRaised += msg.value;
LogFundingReceived(msg.sender, msg.value, totalRaised);
checkIfFundingCompleteOrExpired();
return contributions.length - 1; // return id
}
function checkIfFundingCompleteOrExpired() {
if (totalRaised > minimumToRaise) {
state = State.Successful;
payOut();
// could incentivize sender who initiated state change here
} else if ( now > raiseBy ) {
state = State.ExpiredRefund; // backers can now collect refunds by calling getRefund(id)
}
completeAt = now;
}
function payOut()
public
inState(State.Successful)
{
if(!fundRecipient.send(this.balance)) {
throw;
}
LogWinnerPaid(fundRecipient);
}
function getRefund(id)
public
inState(State.ExpiredRefund)
{
if (contributions.length <= id || id < 0 || contributions[id].amount == 0 ) {
throw;
}
uint amountToRefund = contributions[id].amount;
contributions[id].amount = 0;
if(!contributions[id].contributor.send(amountToSend)) {
contributions[id].amount = amountToSend;
return false;
}
return true;
}
function removeContract()
public
isCreator()
atEndOfLifecycle()
{
selfdestruct(msg.sender);
// creator gets all money that hasn't be claimed
}
function () { throw; }
}
// ** END EXAMPLE **
ethsolscp.STORAGE
Name::
* cpt.ethsolscp.storage,
ethsolscp.SUBCURRENCY
Description::
The following contract will implement the simplest form of a cryptocurrency. It is possible to generate coins out of thin air, but only the person that created the contract will be able to do that (it is trivial to implement a different issuance scheme). Furthermore, anyone can send coins to each other without any need for registering with username and password - all you need is an Ethereum keypair.
pragma solidity ^0.4.0;
contract Coin {
// The keyword "public" makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances;
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
// This is the constructor whose code is
// run only when the contract is created.
function Coin() {
minter = msg.sender;
}
function mint(address receiver, uint amount) {
if (msg.sender != minter) return;
balances[receiver] += amount;
}
function send(address receiver, uint amount) {
if (balances[msg.sender] < amount) return;
balances[msg.sender] -= amount;
balances[receiver] += amount;
Sent(msg.sender, receiver, amount);
}
}
This contract introduces some new concepts, let us go through them one by one.
The line address public minter; declares a state variable of type address that is publicly accessible. The address type is a 160-bit value that does not allow any arithmetic operations. It is suitable for storing addresses of contracts or keypairs belonging to external persons. The keyword public automatically generates a function that allows you to access the current value of the state variable. Without this keyword, other contracts have no way to access the variable. The function will look something like this:
function minter() returns (address) { return minter; }
Of course, adding a function exactly like that will not work because we would have a function and a state variable with the same name, but hopefully, you get the idea - the compiler figures that out for you.
The next line, mapping (address => uint) public balances; also creates a public state variable, but it is a more complex datatype. The type maps addresses to unsigned integers. Mappings can be seen as hashtables which are virtually initialized such that every possible key exists and is mapped to a value whose byte-representation is all zeros. This analogy does not go too far, though, as it is neither possible to obtain a list of all keys of a mapping, nor a list of all values. So either keep in mind (or better, keep a list or use a more advanced data type) what you added to the mapping or use it in a context where this is not needed, like this one. The getter function created by the public keyword is a bit more complex in this case. It roughly looks like the following:
function balances(address _account) returns (uint) {
return balances[_account];
}
As you see, you can use this function to easily query the balance of a single account.
The line event Sent(address from, address to, uint amount); declares a so-called “event” which is fired in the last line of the function send. User interfaces (as well as server appliances of course) can listen for those events being fired on the blockchain without much cost. As soon as it is fired, the listener will also receive the arguments from, to and amount, which makes it easy to track transactions. In order to listen for this event, you would use
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + result.args.to + ".");
console.log("Balances now:\n" +
"Sender: " + Coin.balances.call(result.args.from) +
"Receiver: " + Coin.balances.call(result.args.to));
}
}
Note how the automatically generated function balances is called from the user interface.
The special function Coin is the constructor which is run during creation of the contract and cannot be called afterwards. It permanently stores the address of the person creating the contract: msg (together with tx and block) is a magic global variable that contains some properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
Finally, the functions that will actually end up with the contract and can be called by users and contracts alike are mint and send. If mint is called by anyone except the account that created the contract, nothing will happen. On the other hand, send can be used by anyone (who already has some of these coins) to send coins to anyone else. Note that if you use this contract to send coins to an address, you will not see anything when you look at that address on a blockchain explorer, because the fact that you sent coins and the changed balances are only stored in the data storage of this particular coin contract. By the use of events it is relatively easy to create a “blockchain explorer” that tracks transactions and balances of your new coin.
[https://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#subcurrency-example]
Name::
* cpt.ethsolscp.cryptocurrency,
* cpt.ethsolscp.subcurrency,
ethsolscp.WILL
Name::
* cpt.ethsolscp.will,
CodeEthsol::
contract CMgrWill {
address public aWill_owner;
bytes32 public t32Hash_of_will;
function fMgrWill(){
aWill_owner = msg.sender;
}
function fWillNew(string sWillIn) {
if (msg.sender != aWill_owner) throw;
t32Hash_of_will = sha3(sWillIn);
}
function fWillCheck(string sWillUserIn) constant returns (bool bWill_correct) {
return (sha3(sWillUserIn) == t32Hash_of_will);
}
}
ethsol'Tool
Name::
* cpt.ethsol'tool,
* cpt.ethsoltool,
Specific::
* Browser-compiler,
* solcjs,
* Dapple,
* Populus,
* REPL,
* Solgraph,
===
* Solidity Parser in Javascript: https://github.com/ConsenSys/solidity-parser,
ethsoltool.solcjs
Description::
npm / Node.js
This is probably the most portable and most convenient way to install Solidity locally.
A platform-independent JavaScript library is provided by compiling the C++ source into JavaScript using Emscripten. It can be used in projects directly (such as Browser-Solidity). Please refer to the solc-js repository for instructions.
It also contains a commandline tool called solcjs, which can be installed via npm:
npm install -g solc
Note
The comandline options of solcjs are not compatible with solc and tools (such as geth) expecting the behaviour of solc will not work with solcjs.
[https://solidity.readthedocs.io/en/v0.4.9/installing-solidity.html#npm-node-js]
===
> solcjs --help
Usage: C:\Users\username\AppData\Roaming\npm\node_modules\solc\solcjs
[options] [input_file...]
Options:
--version Show version number [boolean]
--optimize Enable bytecode optimizer. [boolean]
--bin Binary of the contracts in hex. [boolean]
--abi ABI of the contracts. [boolean]
--output-dir, -o Output directory for the contracts. [string]
--help Show help [boolean]
Name::
* cpt.solcjs,
ethsoltool.Dapple
Description::
Dapple is a Solidity developer multitool designed to manage the growing complexity of interconnected smart contract systems.
Its core functionality encompasses three main areas:
Package management
Contract building
Deployment scripting
[http://dapple.readthedocs.io/en/master/]
Name::
* cpt.ethsoltool.dapple,
ethsol.EVOLUTING (0.4.9-2017-01-31)
AddressWpg::
* https://github.com/ethereum/solidity/blob/develop/Changelog.md,
ethsol.0-4-10.2017-03-15:
Features:
Add assert(condition), which throws if condition is false (meant for internal errors).
Add require(condition), which throws if condition is false (meant for invalid input).
Commandline interface: Do not overwrite files unless forced.
Introduce .transfer(value) for sending Ether.
Code generator: Support revert() to abort with rolling back, but not consuming all gas.
Inline assembly: Support revert (EIP140) as an opcode.
Parser: Support scientific notation in numbers (e.g. 2e8 and 200e-2).
Type system: Support explicit conversion of external function to address.
Type system: Warn if base of exponentiation is literal (result type might be unexpected).
Type system: Warn if constant state variables are not compile-time constants.
Bugfixes:
Commandline interface: Always escape filenames (replace /, : and . with _).
Commandline interface: Do not try creating paths . and ...
Commandline interface: Allow long library names.
Parser: Disallow octal literals.
Type system: Fix a crash caused by continuing on fatal errors in the code.
Type system: Disallow compound assignment for tuples.
Type system: Detect cyclic dependencies between constants.
Type system: Disallow arrays with negative length.
Type system: Fix a crash related to invalid binary operators.
Type system: Disallow var declaration with empty tuple type.
Type system: Correctly convert function argument types to pointers for member functions.
Type system: Move privateness of constructor into AST itself.
Inline assembly: Charge one stack slot for non-value types during analysis.
Assembly output: Print source location before the operation it refers to instead of after.
Optimizer: Stop trying to optimize tricky constants after a while.
[https://github.com/ethereum/solidity/blob/develop/Changelog.md]
ethsol.0-4-9.2017-01-31:
Features:
Compiler interface: Contracts and libraries can be referenced with a file: prefix to make them unique.
Compiler interface: Report source location for "stack too deep" errors.
AST: Use deterministic node identifiers.
Inline assembly: introduce invalid (EIP141) as an opcode.
Type system: Introduce type identifier strings.
Type checker: Warn about invalid checksum for addresses and deduce type from valid ones.
Metadata: Do not include platform in the version number.
Metadata: Add option to store sources as literal content.
Code generator: Extract array utils into low-level functions.
Code generator: Internal errors (array out of bounds, etc.) now cause a reversion by using an invalid instruction (0xfe - EIP141) instead of an invalid jump. Invalid jump is still kept for explicit throws.
Bugfixes:
Code generator: Allow recursive structs.
Inline assembly: Disallow variables named like opcodes.
Type checker: Allow multiple events of the same name (but with different arities or argument types)
Natspec parser: Fix error with @param parsing and whitespace.
ethsol.0-4-8.2017-01-13:
Features:
Optimiser: Performance improvements.
Output: Print assembly in new standardized Solidity assembly format.
Bugfixes:
Remappings: Prefer longer context over longer prefix.
Type checker, code generator: enable access to events of base contracts' names.
Imports: import ".dir/a" is not a relative path. Relative paths begin with directory . or ...
Type checker, disallow inheritances of different kinds (e.g. a function and a modifier) of members of the same name
ethsol.0-4-7.2016-12-15:
Features:
Bitshift operators.
Type checker: Warn when msg.value is used in non-payable function.
Code generator: Inject the Swarm hash of a metadata file into the bytecode.
Code generator: Replace expensive memcpy precompile by simple assembly loop.
Optimizer: Some dead code elimination.
Bugfixes:
Code generator: throw if calling the identity precompile failed during memory (array) copying.
Type checker: string literals that are not valid UTF-8 cannot be converted to string type
Code generator: any non-zero value given as a boolean argument is now converted into 1.
AST Json Converter: replace VariableDefinitionStatement nodes with VariableDeclarationStatement
AST Json Converter: fix the camel case in ElementaryTypeNameExpression
AST Json Converter: replace public field with visibility in the function definition nodes
ethsol.0-4-6.2016-11-22:
Bugfixes:
Optimizer: Knowledge about state was not correctly cleared for JUMPDESTs (introduced in 0.4.5)
ethsol.0-4-5.2016-11-21:
Features:
Function types
Do-while loops: support for a do <block> while (<expr>); control structure
Inline assembly: support invalidJumpLabel as a jump label.
Type checker: now more eagerly searches for a common type of an inline array with mixed types
Code generator: generates a runtime error when an out-of-range value is converted into an enum type.
Bugfixes:
Inline assembly: calculate stack height warning correctly even when local variables are used.
Code generator: check for value transfer in non-payable constructors.
Parser: disallow empty enum definitions.
Type checker: disallow conversion between different enum types.
Interface JSON: do not include trailing new line.
ethsol.0-4-4.2016-10-31:
Bugfixes:
Type checker: forbid signed exponential that led to an incorrect use of EXP opcode.
Code generator: properly clean higher order bytes before storing in storage.
ethsol.0-4-3.2016-10-25:
Features:
Inline assembly: support both suicide and selfdestruct opcodes (note: suicide is deprecated).
Inline assembly: issue warning if stack is not balanced after block.
Include keccak256() as an alias to sha3().
Support shifting constant numbers.
Bugfixes:
Commandline interface: Disallow unknown options in solc.
Name resolver: Allow inheritance of enum definitions.
Type checker: Proper type checking for bound functions.
Type checker: fixed crash related to invalid fixed point constants
Type checker: fixed crash related to invalid literal numbers.
Type checker: super.x does not look up x in the current contract.
Code generator: expect zero stack increase after super as an expression.
Code generator: fix an internal compiler error for L.Foo for enum Foo defined in library L.
Code generator: allow inheritance of enum definitions.
Inline assembly: support the address opcode.
Inline assembly: fix parsing of assignment after a label.
Inline assembly: external variables of unsupported type (such as this, super, etc.) are properly detected as unusable.
Inline assembly: support variables within modifiers.
Optimizer: fix related to stale knowledge about SHA3 operations
ethsol.0-4-2.2016-09-17:
Bugfixes:
Code Generator: Fix library functions being called from payable functions.
Type Checker: Fixed a crash about invalid array types.
Code Generator: Fixed a call gas bug that became visible after version 0.4.0 for calls where the output is larger than the input.
ethsol.0-4-1.2016-09-09:
Build System: Fixes to allow library compilation.
ethsol.0-4-0.2016-09-08:
This release deliberately breaks backwards compatibility mostly to enforce some safety features.
The most important change is that you have to explicitly specify if functions can receive ether via the payable modifier.
Furthermore, more situations cause exceptions to be thrown.
Minimal changes to be made for upgrade:
Add payable to all functions that want to receive Ether (including the constructor and the fallback function).
Change _ to _; in modifiers.
Add version pragma to each file: pragma solidity ^0.4.0;
Breaking Changes:
Source files have to specify the compiler version they are compatible with using e.g. pragma solidity ^0.4.0; or pragma solidity >=0.4.0 <0.4.8;
Functions that want to receive Ether have to specify the new payable modifier (otherwise they throw).
Contracts that want to receive Ether with a plain "send" have to implement a fallback function with the payable modifier. Contracts now throw if no payable fallback function is defined and no function matches the signature.
Failing contract creation through "new" throws.
Division / modulus by zero throws.
Function call throws if target contract does not have code
Modifiers are required to contain _ (use if (false) _ as a workaround if needed).
Modifiers: return does not skip part in modifier after _.
Placeholder statement _ in modifier now requires explicit ;.
ecrecover now returns zero if the input is malformed (it previously returned garbage).
The constant keyword cannot be used for constructors or the fallback function.
Removed --interface (Solidity interface) output option
JSON AST: General cleanup, renamed many nodes to match their C++ names.
JSON output: srcmap-runtime renamed to srcmapRuntime.
Moved (and reworked) standard library contracts from inside the compiler to github.com/ethereum/solidity/std (import "std"; or import owned; do not work anymore).
Confusing and undocumented keyword after was removed.
New reserved words: abstract, hex, interface, payable, pure, static, view.
Features:
Hexadecimal string literals: hex"ab1248fe"
Internal: Inline assembly usable by the code generator.
Commandline interface: Using - as filename allows reading from stdin.
Interface JSON: Fallback function is now part of the ABI.
Interface: Version string now semver compatible.
Code generator: Do not provide "new account gas" if we know the called account exists.
Bugfixes:
JSON AST: Nodes were added at wrong parent
Why3 translator: Crash fix for exponentiation
Commandline Interface: linking libraries with underscores in their name.
Type Checker: Fallback function cannot return data anymore.
Code Generator: Fix crash when sha3() was used on unsupported types.
Code Generator: Manually set gas stipend for .send(0).
Lots of changes to the documentation mainly by voluntary external contributors.
ethsol.0-3-6.2016-08-10:
Features:
Formal verification: Take external effects on a contract into account.
Type Checker: Warning about unused return value of low-level calls and send.
Output: Source location and node id as part of AST output
Output: Source location mappings for bytecode
Output: Formal verification as part of json compiler output.
Bugfixes:
Commandline Interface: Do not crash if input is taken from stdin.
Scanner: Correctly support unicode escape codes in strings.
JSON output: Fix error about relative / absolute source file names.
JSON output: Fix error about invalid utf8 strings.
Code Generator: Dynamic allocation of empty array caused infinite loop.
Code Generator: Correctly calculate gas requirements for memcpy precompile.
Optimizer: Clear known state if two code paths are joined.
ethsol.0-3-5.2016-06-10:
Features:
Context-dependent path remappings (different modules can use the same library in different versions)
Bugfixes:
Type Checking: Dynamic return types were removed when fetching data from external calls, now they are replaced by an "unusable" type.
Type Checking: Overrides by constructors were considered making a function non-abstract.
ethsol.0-3-4.2016-05-31:
No change outside documentation.
ethsol.0-3-3.2016-05-27:
Allow internal library functions to be called (by "inlining")
Fractional/rational constants (only usable with fixed point types, which are still in progress)
Inline assembly has access to internal functions (as jump labels)
Running solc without arguments on a terminal will print help.
Bugfix: Remove some non-determinism in code generation.
Bugfix: Corrected usage of not / bnot / iszero in inline assembly
Bugfix: Correctly clean bytesNN types before comparison
ethsol.0-3-2.2016-04-18:
Bugfix: Inline assembly parser: byte opcode was unusable
Bugfix: Error reporting: tokens for variably-sized types were not converted to string properly
Bugfix: Dynamic arrays of structs were not deleted correctly.
Bugfix: Static arrays in constructor parameter list were not decoded correctly.
ethsol.0-3-1.2016-03-31:
Inline assembly
Bugfix: Code generation: array access with narrow types did not clean higher order bits
Bugfix: Error reporting: error reporting with unknown source location caused a crash
ethsol.0.3.0.2016-03-11:
BREAKING CHANGES:
Added new keywords assembly, foreign, fixed, ufixed, fixedNxM, ufixedNxM (for various values of M and N), timestamp
Number constant division does not round to integer, but to a fixed point type (e.g. 1 / 2 != 1, but 1 / 2 == 0.5).
Library calls now default to use DELEGATECALL (e.g. called library functions see the same value as the calling function for msg.value and msg.sender).
<address>.delegatecall as a low-level calling interface
Bugfixes:
Fixed a bug in the optimizer that resulted in comparisons being wrong.
ethsol.0-2-2.2016-02-17:
Index access for types bytes1, ..., bytes32 (only read access for now).
Bugfix: Type checker crash for wrong number of base constructor parameters.
ethsol.0-2-1.2016-01-30:
Inline arrays, i.e. var y = [1,x,f()]; if there is a common type for 1, x and f(). Note that the result is always a fixed-length memory array and conversion to dynamic-length memory arrays is not yet possible.
Import similar to ECMAScript6 import (import "abc.sol" as d and import {x, y} from "abc.sol").
Commandline compiler solc automatically resolves missing imports and allows for "include directories".
Conditional: x ? y : z
Bugfix: Fixed several bugs where the optimizer generated invalid code.
Bugfix: Enums and structs were not accessible to other contracts.
Bugfix: Fixed segfault connected to function paramater types, appeared during gas estimation.
Bugfix: Type checker crash for wrong number of base constructor parameters.
Bugfix: Allow function overloads with different array types.
Bugfix: Allow assignments of type (x) = 7.
Bugfix: Type uint176 was not available.
Bugfix: Fixed crash during type checking concerning constructor calls.
Bugfix: Fixed crash during code generation concerning invalid accessors for struct types.
Bugfix: Fixed crash during code generating concerning computing a hash of a struct type.
ethsol.0.2.0.2015-12-02:
Breaking Change: new ContractName.value(10)() has to be written as (new ContractName).value(10)()
Added selfdestruct as an alias for suicide.
Allocation of memory arrays using new.
Binding library functions to types via using x for y
addmod and mulmod (modular addition and modular multiplication with arbitrary intermediate precision)
Bugfix: Constructor arguments of fixed array type were not read correctly.
Bugfix: Memory allocation of structs containing arrays or strings.
Bugfix: Data location for explicit memory parameters in libraries was set to storage.
ethsol.0-1-7.2015-11-17:
Improved error messages for unexpected tokens.
Proof-of-concept transcompilation to why3 for formal verification of contracts.
Bugfix: Arrays (also strings) as indexed parameters of events.
Bugfix: Writing to elements of bytes or string overwrite others.
Bugfix: "Successor block not found" on Windows.
Bugfix: Using string literals in tuples.
Bugfix: Cope with invalid commit hash in version for libraries.
Bugfix: Some test framework fixes on windows.
ethsol.0-1-6.2015-10-16:
.push() for dynamic storage arrays.
Tuple expressions ((1,2,3) or return (1,2,3);)
Declaration and assignment of multiple variables (var (x,y,) = (1,2,3,4,5); or var (x,y) = f();)
Destructuring assignment ((x,y,) = (1,2,3))
Bugfix: Internal error about usage of library function with invalid types.
Bugfix: Correctly parse Library.structType a at statement level.
Bugfix: Correctly report source locations of parenthesized expressions (as part of "tuple" story).
ethsol.0-1-5.2015-10-07:
Breaking change in storage encoding: Encode short byte arrays and strings together with their length in storage.
Report warnings
Allow storage reference types for public library functions.
Access to types declared in other contracts and libraries via ..
Version stamp at beginning of runtime bytecode of libraries.
Bugfix: Problem with initialized string state variables and dynamic data in constructor.
Bugfix: Resolve dependencies concerning new automatically.
Bugfix: Allow four indexed arguments for anonymous events.
Bugfix: Detect too large integer constants in functions that accept arbitrary parameters.
ethsol.0-1-4.2015-09-30:
Bugfix: Returning fixed-size arrays.
Bugfix: combined-json output of solc.
Bugfix: Accessing fixed-size array return values.
Bugfix: Disallow assignment from literal strings to storage pointers.
Refactoring: Move type checking into its own module.
ethsol.0-1-3.2015-09-25:
throw statement.
Libraries that contain functions which are called via CALLCODE.
Linker stage for compiler to insert other contract's addresses (used for libraries).
Compiler option to output runtime part of contracts.
Compile-time out of bounds check for access to fixed-size arrays by integer constants.
Version string includes libevmasm/libethereum's version (contains the optimizer).
Bugfix: Accessors for constant public state variables.
Bugfix: Propagate exceptions in clone contracts.
Bugfix: Empty single-line comments are now treated properly.
Bugfix: Properly check the number of indexed arguments for events.
Bugfix: Strings in struct constructors.
ethsol.0-1-2.2015-08-20:
Improved commandline interface.
Explicit conversion between bytes and string.
Bugfix: Value transfer used in clone contracts.
Bugfix: Problem with strings as mapping keys.
Bugfix: Prevent usage of some operators.
ethsol.0-1-1.2015-08-04:
Strings can be used as mapping keys.
Clone contracts.
Mapping members are skipped for structs in memory.
Use only a single stack slot for storage references.
Improved error message for wrong argument count. (#2456)
Bugfix: Fix comparison between bytesXX types. (#2087)
Bugfix: Do not allow floats for integer literals. (#2078)
Bugfix: Some problem with many local variables. (#2478)
Bugfix: Correctly initialise string and bytes state variables.
Bugfix: Correctly compute gas requirements for callcode.
ethsol.0-1-0.2015-07-10:
ethsol.0.2014.10:
Solidity was started in October 2014 when neither the Ethereum network nor the virtual machine had any real-world testing, the gas costs at that time were even drastically different from what they are now.
Furthermore, some of the early design decisions were taken over from Serpent.
[https://blog.ethereum.org/2016/06/10/smart-contract-security/]
ethctp'language.LLL (ethlll)
Description::
LLL is a thin layer on top of the EVM that resembles Lisp. All EVM opcodes are available in LLL. On top of that it provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such a macros, and has the ability to include other source files as well.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1/]
===
Lisp Like Language (LLL) is a low level language similar to Assembly. It is meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in EVM directly.
LIBLLL in GitHub
Examples of LLL
[https://ethereum-homestead.readthedocs.io/en/latest/contracts-and-transactions/contracts.html#id4]
===
There does not appear to be active development on LLL as the Ethereum Foundation has identified Solidity as it's primary language that will receive development support from them. However, it is not "dead" in the sense that there are still bug fixes and small changes happening to the repository infrequently.
Interesting side note: Inline ASM may be eventually supported in the Solidity Ethereum language.
Vitalik Buterin said in Nov. 2015:
LLL was always meant to be very simple and minimalistic; essentially just a tiny wrapper over coding in ASM directly. In my opinion just use serpent; it has direct access to opcodes so it is a superset of LLL but it also has a whole bunch of high-level features as well for when you want them. The downside is that the compiler is more complex and so theoretically might contain more bugs.
[http://ethereum.stackexchange.com/a/519]
Name::
* cpt.ethlll,
* cpt.lecLll,
===
* cpt.ethnet'LLL,
* cpt.Lisp-Like-Language,
* cpt.LLL-ethctp-lang,
ethctp'language.VIPER (ethvpr)
Description::
Viper is an experimental programming language that aims to provide the following features:
Bounds and overflow checking, both on array accesses and on arithmetic
Support for signed integers and decimal fixed point numbers
Decidability - it's possible to compute a precise upper bound on the gas consumption of any function call
Strong typing, including support for units (eg. timestamp, timedelta, seconds, wei, wei per second, meters per second squared)
Maximally small and understandable compiler code size
Limited support for pure functions - anything marked constant is NOT allowed to change the state
[https://github.com/ethereum/viper]
Name::
* cpt.ethvpr,
* cpt.lagViper,
* cpt.Viper-ethctp-lang,
ethctp'ABI (ethabi)
Description::
The JSON is called an ABI.
You do need the source code, as you have, and one way to get the ABI is to paste it in Solidity Browser, then copy the Interface value.
[http://ethereum.stackexchange.com/a/3150]
===
ABI stands for application binary interface.
In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code.
In ethereum, it's basicly how you can encode solidity contracts for the EVM and backwards how to read the data out of transactions.
[http://ethereum.stackexchange.com/a/235]
Name::
* cpt.ethABI,
* cpt.ethevm'ABI,
* cpt.ABI-EVM,
* cpt.Application-Binary-Interface,
ethctp'Security
Description::
But we've recently seen how easy it is to cause chaos with one misplaced line of code.
Add to that the myriad of security concerns and the difficulty in addressing them and you have a system not suitable for casual developers, especially with real money at stake.
You have to be invested, so to speak, to develop secure contracts.
[http://blog.syrinx.net/the-resurrection-of-lll-part-1/]
===
Some problems you should be aware of (and avoid):
Reentrancy [http://hackingdistributed.com/2016/07/13/reentrancy-woes/]: Do not perform external calls in contracts. If you do, ensure that they are the very last thing you do.
Send can fail [http://vessenes.com/ethereum-griefing-wallets-send-w-throw-considered-harmful/]: When sending money, your code should always be prepared for the send function to fail.
Loops can trigger gas limit [http://solidity.readthedocs.io/en/latest/security-considerations.html#gas-limit-and-loops]: Be careful when looping over state variables, which can grow in size and make gas consumption hit the limits.
Call stack depth limit [https://ethereum.stackexchange.com/questions/6260/solidity-callstack-attack]: Don’t use recursion, and be aware that any call can fail if stack depth limit is reached.
Timestamp dependency [https://github.com/ConsenSys/smart-contract-best-practices#timestamp-dependence]: Do not use timestamps in critical parts of the code, because miners can manipulate them.
These are provided just as examples of unexpected behaviors that can lead for theft or destruction of funds in your smart contract. The morale is: if you’re writing smart contracts, you’re writing code that handles real money. You should be very careful! Write tests, do code reviews, and audit your code.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05]
Name::
* cpt.ethctp'security,
AddressWpg::
* {2016-10-16} https://medium.com/@MyPaoG/explaining-the-dao-exploit-for-beginners-in-solidity-80ee84f0d470,
* {>2016.06} Making Smart Contracts Smarter http://www.comp.nus.edu.sg/~loiluu/papers/oyente.pdf,
* {2016-06-21} https://medium.com/@hrishiolickel/why-smart-contracts-fail-undiscovered-bugs-and-what-we-can-do-about-them-119aa2843007#.rucpuv5wz,
* {2016-06-19} https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/
* {2016-06-10} https://blog.ethereum.org/2016/06/10/smart-contract-security/
* {2016-05-27} A Call for a Temporary Moratorium on The DAO http://hackingdistributed.com/2016/05/27/dao-call-for-moratorium/
Dynamic-analysis
Description::
Dynamic Analysis is the process of executing code and data in real-time with the hope of finding issues during execution. It's a similar process to exploratory testing, with the same goals, but perhaps more technical.Dynamic analysis on the Ethereum blockchain has historically been costly at worst and tedious at best. If you were to perform dynamic analysis on the live Ethereum chain, transactions would cost you hard-earned Ether, which might limit the tests you perform. Moving away from the live chain is possible, but it's a tedious process to move the live data over to a separate chain, and you'd have to perform this process multiple times if you end up mucking with the chain state during testing.
[http://truffleframework.com/tutorials/chain-forking-exploiting-the-dao#what-is-dynamic-analysis-]
ethctp'DOING
ethctp'doing.DEVELOPING
Description::
Well, smart contract development is not a breeze, but it can be made much more efficient by the use of testrpc. Running a full Ethereum client (geth, eth, pyethapp, parity, etc.) can be a drain on a developer's resources, especially if running on an under-powered machine. Also, unless you set up a private network and tweak the settings, you have to wait a while for blocks to be mined before checking the results of your transactions. If you're connected to the main Homestead network you'll also be paying for your development testing with real digital currency. No, it's better to start simply and install ethereumjs/testrpc. Go ahead and follow the instructions in the README file to install it on your local machine.
[http://blog.syrinx.net/the-resurrection-of-lll-part-7/]
Name::
* cpt.ethctp'developing,
ethctp'doing.CREATING
Description::
Finally, before we get started it is important to know this: Writing smart contracts can be tricky. The transition from normal code writing to smart contract writing is not seamless. The environment in which smart contract code runs is different from that of normal code. The analogy with webservices is good, because it makes smart contracts and systems of smart contracts more tangible, and it makes it simpler to use already existing concepts and tools when working with them, but writing the actual code is still difficult.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
===
In part 1 of this series I introduced the idea that we may need to change the mindset of smart contract development to emphasize its difference from, well, almost every other type of software development.
[http://blog.syrinx.net/the-resurrection-of-lll-part-2/]
Name::
* cpt.entmsmc'creating,
* cpt.ethctp'creating,
* cpt.ethctp'writing,
Specific::
Contracts can even create other contracts using a special opcode (i.e. they do not simply call the zero address). The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack.
[http://solidity.readthedocs.io/en/v0.4.9/introduction-to-smart-contracts.html#create]
ethctp'doing.COMPILING
Name::
* cpt.ethctp'compiling,
ethctp'doing.TESTING
Name::
* cpt.ethctp'testing,
ethctp'doing.INTERACTING
Description::
Ethereum contracts are stored in special contract accounts, and the contract code is executed when the account is the target of a (successful) transaction.
If I, as a user, want to execute a contract, I first need to find out the address to the account in which the contract is stored, and then transact to it.
The parameters for a transaction are:
The gas-price I want to pay (gasPrice).
The maximum amount of gas that may be spent (gas).
The amount of ether I want to transfer (value).
My account address (from).
The target account address (to).
The nonce (nonce).
The transaction data (data).
Alternatively, it is possible to create the transaction object itself on the caller side, sign it locally, and pass in the signed bytes.
The parameters used above is used when making RPC calls, and the client will then create (and sign) the transaction object for you.
Anyways, if my transaction is valid, the Ethereum client will put that transaction data into a context, along with the current block data and some other things.
It then passes the code of the contract account and the context into a new instance of the EVM, and execute it.
[https://github.com/androlo/solidity-workshop/blob/master/tutorials/2016-03-09-advanced-solidity-I.md#accounts-transactions-and-code-execution]
===
Furthermore, every execution of a smart contract happens in public and, in addition to that, the source code is often available.
[https://solidity.readthedocs.io/en/v0.4.9/security-considerations.html#security-considerations]
===
The popular term “smart contracts” refers to code in a Contract Account – programs that execute when a transaction is sent to that account.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html#how-does-ethereum-work]
Name::
* cpt.ethctp'interacting,
ethctp'doing.UPDATING
Description::
Introduction
This tutorial series looks at modular systems of smart-contracts, and how to continuously update the code in a reliable way. Most contracts in your application will become obsolete at some point, and will require an update. Same as in other applications. It could be because new features must be added, a bug is found, or because a better, more optimized version has been made. Updating could of course cause problems so it must be done with care. Some of the things one must ensure is that:
- updating is possible.
- the new contract works as intended.
- all the calls made during the replacement procedure was executed successfully.
- replacing the contract has no side-effects in other parts of the system.
The first point may seem obvious but it usually requires a lot of work, because updating is not possible by default; the reason is because of how accounts, code and storage works.
Accounts, Code and Storage
A very important property of EVM contracts is that when a contract has been uploaded to the chain, the code can never be changed. Contracts are stored in special account objects, and these object has references to the contract (byte) code, and a database, and some other things. The database is a key-value store, also known as ‘storage’, and is where data such as the values of contract fields is stored.
When contracts are created, a new account is first made, then the code is loaded into a VM which runs the constructor part, initializes fields etc., and then adds the runtime portion (or body) of the contract to the account. After that is done, there is no way to change the code, and there is no way to update the database except through that code.
But what if you want to change the code? What if a bug is discovered?
The way you solve that is by connecting several contracts. Contract C could call contract D as part of its functionality, and the address to D could be settable in C, meaning it would be possible to change what D is. This is best explained through a series of simple examples.
A simple storage contract
contract Data {
uint public data;
function addData(uint data_) {
if(msg.sender == 0x692a70d2e424a56d2c6c27aa97d1a86395877b3a)
data = data_;
}
}
This simple contract allows a user to add and read an unsigned integer. The only account that is allowed to add data is the account with address 0x692a.... This address is a hex literal, so is added to the bytecode when the contract is compiled.
A potential problem is that we might want to replace this address later, or even the entire validation procedurer, but we can’t because of how code and storage works. A simple way of making the contract more flexible is to store the current owner address in storage instead, and make it possible to change.
contract DataOwnerSettable {
uint public data;
address public owner = msg.sender;
function addData(uint data_) {
if(msg.sender == owner)
data = data_;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
This contract has an owner field (mapped to storage). It is initialized with the address of the account that creates the contract, and can later be changed by the current owner by calling setOwner. The guard inside addData is still the same; the only thing that changed is that the owner address is no longer hard-coded.
Delegation
What if a settable owner is not enough, though? What if we want to be able to update not only the owner address, but the entire validation process? That is possible. We will do it in two steps. First we move the account validation code into a different contract.
contract AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
contract DataExternalValidation {
uint public data;
AccountValidator _validator;
function DataExternalValidation(address validator) {
_validator = AccountValidator(validator);
}
function addData(uint data_) {
if(_validator.validate(msg.sender))
data = data_;
}
function setValidator(address validator) {
if(_validator.validate(msg.sender))
_validator = AccountValidator(validator);
}
}
To use this, we first create an AccountValidator contract; it has the owner field now, and that field is automatically initialized with an account address. Then we create a DataExternalValidation-contract and inject the address of the validator through the contract constructor. When someone tries to write to data, it will call the validate function of the current validator contract to do the check rather then storing (or hard coding) the owner address and doing the equality check internally. Everything that has to do with access control is now delegated to the validator contract.
This is very nice, because it is now possible to replace the contract that does the actual check. Not only does it decouple this from the data, but since the AccountValidator is its own contract, we could potentially use that contract in other contracts as well and thus give owner control over more contracts then just one.
One thing remains though. We still can’t replace the code! All we have done is move the validation code out of the contract. The code of the AccountValidator contract can’t be changed anymore then that of the data contract. Fortunately, Solidity provides a very simple and powerful workaround - abstract functions.
Abstract Functions
Using abstract functions, the validator contract could be changed into this:
contract AccountValidator {
function validate(address addr) constant returns (bool);
}
contract SingleAccountValidator is AccountValidator {
address public owner = msg.sender;
function validate(address addr) constant returns (bool) {
return addr == owner;
}
function setOwner(address owner_) {
if(msg.sender == owner)
owner = owner_;
}
}
With these contracts, the data contract no longer works with a concrete validator contract, but an abstract (interface) representation. This makes sense, because it does not really needs to know what the validate function actually does, it only needs to know the signature.
Interfaces works the same way as it does in most other object-oriented languages, just declare functions without a body and they become abstract.
We still can’t change the code stored in a contract account, but we can change the code that is executed when a function is called, by delegating some functionality to other contract which are allowed to be replaced; all we need to do is change the validator contract to a different contract. For example, if we want to allow more owners then one we could use an instance of this contract:
contract MultiAccountValidator is AccountValidator {
mapping(address => bool) public owners;
function MultiAccountValidator() {
owners[msg.sender] = true;
}
function validate(address addr) constant returns (bool) {
return owners[addr];
}
function addOwner(address addr) {
if(owners[msg.sender])
owners[addr] = true;
}
}
Summary
Proper delegation is an important part of smart-contract systems. It is also something one has to consider from the very start, because the rules for how a set of contracts can be updated is generally contained in the contracts themselves. Also, the more contracts that are in the system the harder they become to manage, and a strategy that makes a small system work may not be suitable for a medium-sized or large one.
Another thing to keep in mind is that modularity comes with a cost, because it requires more code, storage variables and calls. On the public chain, where the gas limitations are quite severe (for obvious reasons), even a small modular system could be hard to deploy and run. Generally, when it comes to scalability vs. efficiency I tend to go with scalability. The large, expensive contracts in an excessively modular system can after all be improved and replaced, but if the contracts are locked down that may not be an option.
In our opinion, it is very important to at least acknowledge that the code is going to need updates, and at some point there must be a good policy for how it can be done. The alternative is to not have a plan and fail. And then maybe fail again, and again, until eventually it becomes clear.
[https://monax.io/docs/tutorials/solidity/solidity_7_updating_solidity_contracts/]
Name::
* cpt.ethctp'updating,
ethctp'doing.REMOVING
Description::
The HelloSystem contract can be deployed as-is without any problems, but once it’s been deployed it will remain on the chain for good. We need a way to remove it. In Solidity, the command for removing (or suiciding) a contract is this: selfdestruct(addr). The argument here is the address to which any remaining funds should be sent. In order to expose this functionality, we need to put it inside a (implicitly public) function. This is what a selfdestruct function could look like in HelloSystem:
contract HelloSystem {
function remove() {
selfdestruct(msg.sender);
}
}
What this would do is to remove the contract when the remove function is called, and it would return any funds it may have to the caller. Needless to say, this is not ideal. Normally when you add a selfdestruct function you want to restrict the access to it. The simplest way of doing it is to store the address of the contract creator when the contract is deployed, and only allow the creator to call selfdestruct on it. Here is how that could be implemented:
contract HelloSystem {
address owner;
// Constructor
function HelloSystem(){
owner = msg.sender;
}
function remove() {
if (msg.sender == owner){
selfdestruct(owner);
}
}
}
Note that msg.sender is not the same in the constructor as it is in the remove function. The constructor is called when the contract is added, so msg.sender will be the contract creator, but in all other functions it will be the address of the account that is calling it.
Name::
* cpt.ethctp'removing,
ethctp'doing.SERVICE
Name::
* cpt.ethctp'service,
Specific::
As you will see, it is possible to create contracts for voting, crowdfunding, blind auctions, multi-signature wallets and more.
[https://solidity.readthedocs.io/en/v0.4.9/]
===
Think of a “contract” as a program that provides services such as: voting systems, domain
name registries, financial exchanges, crowdfunding platforms, company governance, selfenforcing
contracts and agreements, intellectual property, smart property, and distributed
autonomous organizations.
[http://mc2-umd.github.io/ethereumlab/docs/serpent_tutorial.pdf]
===
Early work on smart contracts has been done by Szabo[1997] and Miller [1997].
Around the 1990s it became clear that algorithmic enforcement of agreements could become a significant force in human cooperation.
Though no specific system was proposed to implement such a system, it was proposed that the future of law would be heavily affected by such systems.
In this light, Ethereum may be seen as a general implementation of such a crypto-law system.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
ethctp.SPECIFIC-DIVISION.service
ethctp.SPECIFIC-DIVISION.5-types-model
Specific::
There are many different ways to classify contracts, but we’re going to use what I call “the five types model”. It is a simple model where contracts are divided up into five basic categories:
1) Database contracts
These are used only as data storage. The only logic they need is functions that allow other contracts to write, update and get data, and some simple way of checking caller permissions (whatever those permissions may be).
2) Controller contracts
These contracts operate on the storage contracts. In a flexible system, both controllers and databases can be replaced by other, similar contracts that share the same public api (although this is not always needed). Controllers can be advanced, and could for example do batched reads/writes, or read from and write to multiple different databases instead of just one.
3) Contract managing contracts (CMCs)
The purpose of these contracts is only to manage other contracts. Their main tasks is to keep track of all the contracts/components of the system, handle the communication between these components, and to make modular design easier. Keeping this functionality separate from normal business logic should be considered good practice, and has a number of positive effects on the system (as we will see later).
4) Application logic contracts (ALCs)
Application logic contracts contains application-specific code. Generally speaking, if the contract utilizes controllers and other contracts to perform application specific tasks it’s an ALC.
5) Utility contracts
These type of contracts usually perform a specific task, and can be called by other contracts without restrictions. It could be a contract that hashes strings using some algorithm, provide random numbers, or other things. They normally don’t need a lot of storage, and often have few or no dependencies.
The rationale for this division will be laid out after we’ve tried to apply it to the fund manager system, as it will be a lot more clear then.
[https://monax.io/docs/tutorials/solidity/solidity_1_the_five_types_model/]
ethctp.code.BINARY (ethctpbnr)
Description::
Contracts live on the blockchain in an Ethereum-specific binary format (EVM bytecode).
However, contracts are typically written in an Ethereum high level language, compiled into byte code using an EVM compiler, and finally uploaded on the blockchain using an Ethereum client.
[https://ethereum-homestead.readthedocs.org/en/latest/contracts-and-transactions/developer-tools.html#the-evm]
Description::
Note that in reality the contract code is written in the low-level EVM code;
[https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-state-transition-function]
===
When Ethereum contracts are compiled down to byte-code the convention is not to represent them as binary, but instead to represent them as a single long hex string like the following:
6060604052600a8060106000396000f360606040526008565b00
This is the compiled byte-code for the following solidity contract:
contract Test {
}
[https://ericscrivner.me/2016/07/lets-write-ethereum-virtual-machine-disassembler/]
Name::
* cpt.ethact'code,
* cpt.ethctp.binary,
* cpt.ethctp.bytecode,
* cpt.ethctpbnr,
* cpt.ethevm'contract,
* cpt.eth'evm-bytecode,
* cpt.ethevm'code,
* cpt.ethevm'codeBinary,
* cpt.EVM-bytecode,
ethctp.code.SOURCE
Name::
* cpt.ethctp.sourcecode,
ethctp.VERIFIED
Description::
Verify and Publish your Solidity Source Code
Step 1 : Enter your Contract Source Code below.
Step 2 : If the Bytecode generated matches the existing Creation Address Bytecode, the contract is then Verified.
Step 3 : Contract Source Code is published online and publicably verifiable by anyone.
NOTES
1. To verify Contracts that accept Constructor arguments, please enter the ABI-encoded Arguments in the last box below.
2. For debugging purposes if it compiles correctly at Browser Solidity, it should also compile correctly here.
3. Contracts that use "imports" will need to have the code concatenated into one file as we do not support "imports" in separate files
[https://etherscan.io/verifyContract]
AddressWpg::
* https://etherscan.io/contractsVerified,
* https://etherchain.org/account_verify/
ethctp.DAO
Description::
Here is just one example: imagine you own a small business with your friends. Lawyers and accountants are expensive, and trusting a single partner to oversee the books can be a source of tension (even an opportunity for fraud). Complying strictly with a system in which more than one partner oversees the books can be trying and is subject to fraud whenever the protocol isn’t followed exactly.
Using a smart contract, ownership in your company and terms for the disbursal of funds can be specified at the outset. The smart contract can be written such that it is only changeable given the approval of a majority of owners. Smart contracts like these will likely be available as open source software, so you won’t even need to hire your own programmer in stead of an accountant/lawyer.
A smart contract like this scales instantly. A couple of teenagers can split revenue from a lemonade stand just as transparently as a sovereign wealth fund can disburse funds to the hundred million citizens who are entitled to it. In both cases the price of this transparency is likely to be fractions of a penny per dollar.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html#dao]
Whole::
* ethereum-dao-dApp,
ethctp.EMPLOYMENT-AGGREMENT
Description::
One example of a smart contract would be an employment agreement: A wants to pay $500 to B to build a website. The contract would work as follows: A puts $500 into the contract, and the funds are locked up. When B finishes the website, B can send a message to the contract asking to unlock the funds. If A agrees, the funds are released. If B decides not to finish the website, B can quit by sending a message to relinquish the funds. If B claims that he finished the website, but A does not agree, then after a 7-day waiting period it’s up to judge J to provide a verdict in A or B’s favor.
[https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/]
ethctp.NAME-REGISTRY
Description::
Name registry, or “namereg” contracts generally lets people associate a name with an user account address. This is an example of such a contract:
contract Users {
// Here we store the names. Make it public to automatically generate an
// accessor function named 'users' that takes a fixed-length string as argument.
mapping (bytes32 => address) public users;
// Register the provided name with the caller address.
// Also, we don't want them to register "" as their name.
function register(bytes32 name) {
if(users[name] == 0 && name != ""){
users[name] = msg.sender;
}
}
// Unregister the provided name with the caller address.
function unregister(bytes32 name) {
if(users[name] != 0 && name != ""){
users[name] = 0x0;
}
}
}
When this contract is called, it will use msg.sender and a provided name as parameters. msg.sender refers to the address of the account that made the transaction. name is a fixed-length string that the sender includes in the transaction data. If the name is not already taken, it will be written into users.
This is a very basic but useful contract. It lets you refer to users by name instead of having to use their public address. It could be used as a basis for almost anything. It could use some more functionality, such as being able to list all the registered users, and maybe also make it possible to get a name by address, and not just address by name, and other things.
[https://monax.io/docs/tutorials/solidity/solidity_3_solidity_language_features/]
ethctp.WILL-MANAGER
CodeEthsol::
contract WillManager {
address public willOwner;
bytes32 public hashOfWill;
function WillManager(){
willOwner = msg.sender;
}
function newWill(string will) {
if (msg.sender != willOwner) throw;
hashOfWill = sha3(will);
}
function checkWill(string willUserIsChecking) constant returns (bool willIsCorrect) {
return (sha3(willUserIsChecking) == hashOfWill);
}
}
ethnet'Wallet (ethwlt)
Name::
* cpt.ethnet'wallet,
* cpt.ethwlt,
Specific::
* Mist-Ethereum-wallet,
* MyEtherWallet,
* Parity-wallet,
* Jaxx-wallet,
ethwlt.Mist-ethereum-wallet (ethwltMst)
Description::
Ethereum wallet is a wallet, Mist is a browser.
===
The Mist Browser includes the Ethereum Wallet. The Ethereum Wallet is the Mist Browser with the browser function disabled. If you plan on using contracts use the Mist, else if you're just holding ETH, use the Ethereum Wallet.
[https://www.reddit.com/r/ethereum/comments/53nifc/confusion_should_i_download_mist_or_ethereum/d7undsl/]
Name::
* cpt.ethwlt.ethereum-wallet,
* cpt.ethwltMst, {2017-04-02}
* cpt.mist-ethereum-wallet,
* cpt.mewlt,
ethwltMst'Data-folder
The data folder for Mist is stored in other places:
Windows %APPDATA%/Roaming/Mist (C:\Users\user\AppData\Roaming\Mist)
MacOSX ~/Library/Application Support/Mist
Linux ~/.config/Mist
[https://github.com/ethereum/mist]
ethwltMst'Updating
For updating simply download the new version and copy it over the old one (keep a backup of the old one if you want to be sure).
[https://github.com/ethereum/mist]
ethwltMst.EVOLUTING
Wallet 0.5.2 (Beta 10)
@frozeman frozeman released this 19 days ago · 69 commits to wallet since this release
This release adds some additional log information to the splash screen and adds a feature to send all ether for an account.
Full list of changes:
Added a send-all functionality to the send page.
Add German (thanks to @ColRad) and Portuguese (@alexvandesande) translation for the wallet!
Added log infos to the splash screen, so users can see what the node is currently doing...
Improved ether display precision on the confirmation screen
Added a check with NTP servers to see if the computer time is correct, if not it shows an error
Increased error timeout
If you should notice that your wallet links lead to a white page, please run the following script in the console:
https://gist.github.com/frozeman/ed41008f4d30900da3e8
This changes all your wallet addresses internally back to lowercase (we introduced that by accident).
[https://github.com/ethereum/mist/releases]
ethwlt.MyEtherWallet
Description::
Open-Source, client-side tool for easily & securely interacting with the Ethereum network.
Created by kvhnuke & tayvano.
[https://www.myetherwallet.com/]
Name::
* cpt.MyEtherWallet,
ethnet'Human
Name::
* cpt.ethhmn,
* cpt.ethhuman,
* cpt.ethhmn,
Specific::
=== GENERIC:
* DEVELOPER,
* USER,
* GITTER-COMMUNITY,
* MEETUP-COMMUNITY,
* REDDIT-COMMUNITY,
* STACK-EXCHANGE-COMMUNITY,
=== INSTANCE:
* Alisie.Mihai,
* Buterin.Vitalic,
* Gerring.Taylor,
* Karapetsas.Lefteris,
* Vessenes.Peter,
* Wilcke.Jeffrey,
* Wood.Gavin,
ethhmn.Gitter-community
Description::
Gitter Rooms
Gitter is our forum of choice for daily chat. It is the virtual coworking space where devs hang out, so it is where you can get quick help and a bit of handholding in needed.
Gitter uses Github accounts, offers Github integration (notification of pull requests etc), private channels, provides markdown formatting, and more.
Most Gitter channels are organised around particular repositories, or generic topics like research or governance. Please choose the appropriate room and keep discussions on topic.
See the full list of gitter rooms for the Ethereum organisation. Below is the list of active public channels:
go-ethereum - about geth (and tools related to the go implementation)
cpp-ethereum - about eth (and tools related to the C++ implementation)
web3.js - about web3.js, Ethereum JavaScript API library
Solidity - The Solidity Contract-Oriented Programming Language
serpent - The Serpent language for contract development
mist - GUI dapp browser, official wallet app
light-client - about light client and the LES protocol
research - Ethereum research
governance - about dev governance
whisper - anonymous datagram publishing
swarm - decentralised content storage and distribution network
EIPs - discussion of Ethereum Improvement Proposals (EIPs)
ethereumjs-lib - a JavaScript library of core Ethereum functions
devp2p - Π?V’s p2p network protocol & framework
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#gitter-rooms]
ethhmn.Reddit
Description::
Reddit
The Ethereum subreddit is the most inclusive Ethereum forum, where most of the community discussion is happening and where core devs are also active. This is your forum of choice for generic discussion of news, media coverage, announcements, brainstorming. In general all things Ethereum relevant to the wider community.
Strictly no price discussion.
Also, this is not the ideal place to ask for hands-on help or post questions you expect there are clear immediate answers to (use Gitter Rooms and Stack Exchange for these, respectively).
Read the Ethereum subreddit rules before posting.
Further specialised subreddits:
/r/EthTrader - Ether trading, price and market
/r/EtherMining - Ether mining discussion
/r/Ethmarket - Marketplace for individuals looking to exchange goods and services for Ether
/r/Ethinvestor - News and prospects for Ethereum investors. Following the long term trends in the Ethereum marketplace.
/r/ethereumism/ - a bit more ism, ostic, ical, ist and tinfoil hats, pyramids and crystal ball type of views - the ethereal side of Ethereum
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/community.html#reddit]
ethhmn.Buterin.Vitalik.1994 (hmnBtnVtk founder)
Description::
I was born in 1994 in Russia and moved to Canada in 2000, where I went to school. I went to the Abelard school in 2008 and entered the University of Waterloo in 2012, but quickly left in order to go on a six-month journey around the world and simultaneously engage in cryptocurrency-related projects on a full-time basis. The result of the journey was the idea behind Ethereum, a concept for a generalized cryptoeconomically secured state machine architecture, for which I continue to serve as Chief Scientist.
My primary academic interest consists of studying and exploring the complicated intersection between information theory, cryptography, sociology, epistemology, politics and economics, where mechanisms such as prediction markets, cryptoeconomic state machines (for the layman: "blockchains"), security deposits, consumer protection and reputation systems, multi-key personal security architectures and sampling-and-fallback scalability games sit at the core.
In general, I am trying to move beyond just being "a cryptocurrency person" and acquiring a more holistic and long-tail perspective of what role technology can play in helping to build more secure and trustworthy systems and reduce inefficiency and waste in society; I find that individuals that identify themselves around a particular solution (eg. cryptocurrency, progressivism, authoritarianism, libertarianism, radical decentralization) are likely to be more susceptible to confirmation biases and generally less interesting than people who identity themselves around a problem, and dedicate themselves to the search for a solution to that problem no matter where the search takes them.
I also enjoy learning languages (started Mandarin a year ago) and exploring interesting places like the one that's the background of this screen.
#informationtheory
#economics
#philosophy
#epistemology
#mechanismdesign
[https://about.me/vitalik_buterin]
Name::
* cpt.Buterin.Vitalik,
* cpt.hmnBtnVtk,
* cpt.hmn.Buterin.Vitalik,
* cpt.hmn.Vitalik-Buterin,
* cpt.Vitalik-Buterin,
ethhmn.Karapetsas.Lefteris
Description::
Lefteris Karapetsas
Developer located in Berlin. University of Tokyo graduate. #emacs user. #ethereum core developer http://lefteris.refu.co,
===
Lefteris is the Technical Lead of slock.it
After graduating from the University of Tokyo, Lefteris has been developing backend software for various companies including Oracle and Acmepacket. He is an all-around tinkerer who loves to takes things apart and put them back together learning how they work in the process.
He has been part of Ethereum as a C++ core developer since November 2014, having worked on Solidity, the ethash algorithm, the core client and the CI system and is now leading the technical side of things towards revolutionizing the IoT world with the use of blockchains in Slock.it
[https://blog.slock.it/why-we-are-building-the-ethereum-framework-for-ubuntu-core-41b53ba685da]
Name::
* cpt.Karapetsas.Lefteris,
* cpt.Lefteris-Karapetsas,
AddressWpg::
Twitter: @lefterisjp
contact: lefteris@slock.it
* http://lefteris.refu.co/
* https://blog.slock.it/a-dao-counter-attack-613548408dd7#.s0ebn5fjx,
ethhmn.Wood.Gavin founder
Description::
Since my childhood economics and game theory have always interested me, even to the point of co-publishing a strategy board game of my own design. When I first read about Bitcoin in 2011, I was largely uninterested, focusing too much on the currency aspect rather than the technology. However, when I revisited it in early 2013, I began to realise new possibilities opening up between the fields of ITC and game theory, and the inevitable social change to which this would lead. A mutual friend made the introduction to Vitalik in late 2014 and Ethereum has dominated my life since.
I coded the first functional implementation of Ethereum and wrote the Yellow Paper, the first formal specification of any blockchain protocol and one of the key ways Ethereum separates itself from other blockchain-based systems. My original ideas for web three date back to early 2013, but my first post on the topic was in April 2014, later followed by a less-techy version.
Prior to Ethereum, I accrued a masters degree and doctorate in computer science. I consulted for Microsoft Reseach on technical aspects of embedded domain-specific languages, designed and implemented the first truly smart lighting controller for one of London's top nightclubs, designed and implemented most of the world's first C++ language workbench, and built the software systems of OxLegal, a smart text contract-editor.
[http://gavwood.com/]
Name::
* cpt.hmn.Wood.Gavin,
* cpt.Gavin-Wood,
ethnet'Organization (ethogn)
Name::
* cpt.ethnet'organization,
* cpt.ethogn,
ethogn.ETHCORE
Description::
Ethcore is the creator of Parity: The worlds fastest ethereum client that integrates directly into your browser.
...
Ethcore is dedicated to helping you get the most out of open source blockchain technology.
We come from a wide variety of backgrounds; computer science, engineering, consulting, finance and law.
We've lived through the expansive growth in capabilities that blockchain has seen over the last few years.
We are the people that brought the world the most advanced blockchain technology to date.
We are the thinkers, makers and coders that can help you realise your blockchain potential.
[https://ethcore.io/index.html]
Name::
* cpt.ethcore,
* cpt.ethcore-ogn,
ethcore'Human
Dr. Gavin Wood, founder of Parity Technologies and lead developer of the acclaimed Parity Ethereum client
[https://ethcore.io/press.html]
ethogn.Slock.it
Description::
Slock.it UG is a German company building the future infrastructure of the sharing economy. Our first product, the Ethereum Computer, brings blockchain technology to the entire home, making it possible to rent access to any compatible smart object and accept payments without intermediaries. We aim for this product and its ecosystem to be funded by a Decentralized Autonomous Organization (DAO), a type of digital company or trust where token holders benefit financially from the revenue of the products they supported - think of it as a Kickstarter on steroids.
The DAO model is free and open source for anyone to reproduce and study, and our white paper can be downloaded here.
Slock.it UG will soon make the Ethereum Computer proposal to the DAO available to the public. Once ready, it will be posted on this website.
[https://slock.it/faq.md]
===
Slock.it brings the benefits of the Blockchain - transparency, security and auditablity - to real-world objects.
Our technology can be embedded in almost any device and the first prototypes are already in the hands of developers.
[https://slock.it/]
Name::
* cpt.ethnet'Slock.it,
* cpt.slock.it,
ethogn.Ethereum-Foundation {2014}
Description::
The Ethereum Foundation is a non-profit organization registered in Switzerland, and has the purpose of managing the funds that were raised from the Ether Sale in order to best serve the Ethereum and decentralized technology ecosystem.
Founded July 2014 in Switzerland, Stiftung Ethereum’s mission is the promotion of developments of new technologies and applications, especially in the fields of new open and decentralized software architectures.
It is the aim that decentralized and open technologies will be developed, nurtured, promoted and maintained. A dominating, but not exclusive, focus is set on the promotion of the development of the Ethereum Protocol and the relevant technology to it as well as the promotion and support of applications using the Ethereum technology or protocol. Stiftung Ethereum will additionally support and advocate for a decentralized Internet in a variety of forms.
[https://ethereum-homestead.readthedocs.org/en/latest/ethereum-ecosystem/foundation.html]
Name::
* cpt.ethfdn,
* cpt.ethereum-foundation,
* cpt.ethnet'Ethereum-Foundation,
* cpt.ethfdn,
ethnet'Evaluation
Nick Szabo ?@NickSzabo4 7m7 minutes ago
Ethereum can solve any problem a computer can solve: but with far greater reliability and security and far less performance and efficiency.
[2016-02-10]
This massive parallelisation of computing across the entire Ethereum network is not done to make computation more efficient. In fact, this process makes computation on Ethereum far slower and more expensive than on a traditional “computer”. Rather, every Ethereum node runs the EVM in order to maintain consensus across the blockchain. Decentralized consensus gives Ethereum extreme levels of fault tolerance, ensures zero downtime, and makes data stored on the blockchain forever unchangeable and censorship-resistant.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
One issue with Bitcoin, being a hardwired protocol, is that you can’t easily introduce many competing currency models on the same platform, and we know how hard it is to create a new network for each new protocol and a system to easily exchange value between networks, hence why softwired platforms like Ethereum are enticing – sure Ether’s issuance algorithm is fixed, but it is trivial to create almost an unlimited number of alternative easily exchangable currency models on the same platform without incurring the cost of creating a brand new network every time. Exciting times!
[https://www.linkedin.com/pulse/crypto-20-musings-bitcoin-money-creation-alex-batlin?]
ethnet'Resource (ethrsc)
Name::
* cpt.ethresource,
* cpt.ethrsc,
AddressWpg::
* http://www.ethereum.org/ Main site,
* ETHDEV: https://ethdev.com
* https://github.com/ethereum,
===
* {2017-03-20} https://medium.com/blockchannel/tools-and-technologies-in-the-ethereum-ecosystem-e5b7e5060eb9,
* https://karl.tech/intro-to-ethereum/
* {2016-06-22} http://cointelegraph.com/news/ethereum-101-from-idea-to-release,
* http://cointelegraph.com/news/ ethereum-to-open-blockchain-research-center-in-russias-silicon-valley,
* yellowpaper: http://gavwood.com/Paper.pdf,
* whitepaper: https://github.com/ethereum/wiki/wiki/White-Paper,
* https://ethereum.gitbooks.io/frontier-guide/content/
* https://github.com/ethereum/wiki/wiki/Glossary,
* https://medium.com/boost-vc/boost-vc-is-now-investing-in-products-built- using-ethereum-79cd72b7bd71,
=== docs
* https://ethereum-homestead.readthedocs.org/en/latest/
* http://ethdocs.org/en/latest/
* https://forum.ethereum.org/
=== developer:
* https://dappsforbeginners.wordpress.com/
=== evaluation:
* http://cointelegraph.com/news/eight-months-since-release-ethereum-is-second-only-to-bitcoin,
ethrsc'EIP (etheip)
Description::
Ethereum Improvement Proposal. EIPs propose and describe changes made to Ethereum Protocol.
People wishing to submit EIPs first should propose their idea as an issue and then formalize it using a PR. After discussion it will be published here. Having an EIP here does not make it a formally accepted standard until its status becomes Active. For a EIP to become Active requires the mutual consent of the community. An EIP is not finalized until it has been implemented and is in use. Those proposing changes should consider that ultimately consent may rest with the consensus of the Ethereum users.
[https://github.com/ethereum/EIPs]
Name::
* cpt.ethnet'EIP,
* cpt.ethnet'Ethereum-Improvement-Proposal,
* cpt.EIP-ethnet,
AddressWpg::
* The EIP (Ethereum Improvement Proposal) system has been updated
- https://www.reddit.com/r/ethereum/comments/5rp8mr/ update_to_eip_ethereum_improvement_proposal_system/
ethnet'DOING
Description::
Doing is any internal and as a whole (=service) doing.
[hmnSgm.2017-02-12]
Name::
* cpt.ethnet'doing,
ethnet'doing.MINING (link)
ethnet'doing.SERVICE (ethsvc)
Description::
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
===
The Ethereum platform itself is featureless or value-agnostic.
Similar to programming languages, it is up to entrepreneurs and developers to decide what it should be used for.
However, it is clear that certain application types benefit more than others from Ethereum’s capabilities.
Specifically, ethereum is suited for applications that automate direct interaction between peers or facilitate coordinated group action across a network.
For instance, applications for coordinating peer-to-peer marketplaces, or the automation of complex financial contracts.
Bitcoin allows for individuals to exchange cash without involving any middlemen like financial institutions, banks, or governments.
Ethereum’s impact may be more far-reaching.
In theory, financial interactions or exchanges of any complexity could be carried out automatically and reliably using code running on Ethereum.
Beyond financial applications, any environments where trust, security, and permanence are important – for instance, asset-registries, voting, governance, and the internet of things – could be massively impacted by the Ethereum platform.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#ethereum-virtual-machine]
Name::
* cpt.ethereum-service,
* cpt.ethnet'service,
* cpt.ethnet'usage,
* cpt.ethsvc,
SPECIFIC
Specific::
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.
[https://en.wikipedia.org/wiki/Ethereum]
ethsvc.GOAL
Description::
The stated purpose of the Ethereum project is to "decentralize the web" by introducing four components as part of its roadmap: static content publication, dynamic messages, trustless transactions and an integrated user-interface.[5]
Each of these services are designed to replace some aspect of the systems currently used in the modern web, but to do so in a fully decentralised and pseudonymous manner.[6]
[https://en.wikipedia.org/wiki/Ethereum]
===
Driving Factors.
There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another.
This may be due to geographical separation, interfacing difficulty, or perhaps the incompatibility, incompetence, unwillingness, expense, uncertainty, inconvenience or corruption of existing legal systems.
By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end.
Dealings in this proposed system would have several attributes not often found in the real world.
The incorruptibility of judgement, often difficult to find, comes naturally from a disinterested algorithmic interpreter.
Transparency, or being able to see exactly how a state or judgement came about through the transaction log and rules or instructional codes, never happens perfectly in humanbased systems since natural language is necessarily vague, information is often lacking, and plain old prejudices are difficult to shake.
Overall, I wish to provide a system such that users can be guaranteed that no matter with which other individuals, systems or organisations they interact, they can do so with absolute confidence in the possible outcomes and how those outcomes might come about.
[http://gavwood.com/Paper.pdf]
Name::
* cpt.ethnet'doing.goal,
* cpt.ethnet'goal,
ethsvc.EXCHANGE-VALUE-TOKEN
Description::
In general, there are three types of applications on top of Ethereum.
The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money.
This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
Finally, there are applications such as online voting and decentralized governance that are not financial at all.
[https://github.com/ethereum/wiki/wiki/White-Paper#applications]
ethsvc.STORAGE
Specific::
* Swarm,
ethsvc.ENS
Description::
ENS is the Ethereum Name Service, a distributed, open, and extensible naming system based on the Ethereum blockchain.
ENS can be used to resolve a wide variety of resources. The initial standard for ENS defines resolution for Ethereum addresses, but the system is extensible by design, allowing more resource types to be resolved in future without the core components of ENS requiring upgrades.
[https://ens.readthedocs.io/en/latest/introduction.html]
Name::
* cpt.ethENS,
* cpt.Ethereum-Name-Service,
ethsvc.Colony
Description::
Whatever you do, join Colony.
Colony makes it easy for people all over the world to build companies together online.
[https://colony.io/]
ethsvc.WEB3
Description::
Many have come to believe that an open, trustless blockchain platform like Ethereum is perfectly suited to serve as the shared “back end” to a decentralized, secure internet - Web 3.0.
An internet where core services like DNS and digital identity are decentralized, and where individuals can engage in economic interactions with each other.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/web3.html]
SPECIFIC
Name::
* ethnet.specific,
* cpt.ethnet.specific,
ethnet.TEST
ethnet.MORDEN
Description::
The Morden testnet has been running since the launch of the Ethereum blockchain (July 2015). At that time, concerns about replay-attacks between Morden and Mainnet were addressed by using a nonce-offset. All accounts on Morden used a starting nonce of 2^20 instead of 0, ensuring that any transaction valid on one chain would not be valid on the other.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
===
Morden
Morden is a name for one of the most popular public Ethereum TestNets. It is the same as the Ethereum network, but ETH on Morden is worth nothing. You can get ETH for free on Morden from many Morden "ETH faucets".
[https://karl.tech/learning-solidity-part-1-deploy-a-contract/]
Name::
* cpt.morden-ethtestnet,
ethnet.ROPSTEN
Description::
Before the current hard forks, there were already discussions about restarting the test network from a new genesis block in order to make full syncing simpler and less resource intensive. And due to the low difficulty of the testnet, the difficulty bomb was already causing noticeable increases in block times, which would continue to grow if unaddressed. So the time is now right to leave Morden behind and start a new test network.
[https://blog.ethereum.org/2016/11/20/from-morden-to-ropsten/]
Name::
* cpt.ropsten-ethtestnet,
ethnet.CLASSIC (ETCnet)
Name::
* cpt.etcnet,
* cpt.ethereum-classic-network,
ethnet.SERENITY
Description::
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015!
Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
Name::
* cpt.ethnet.serenity,
* cpt.ethserenity,
ethnet.METROPOLIS
Description::
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
Name::
* cpt.ethmetropolis,
ethnet.EVOLUTING
Name::
* cpt.ethnet.evoluting,
{time.2016.07}
=== Ethereum’s successful hard fork, Coinbase integration
The partial price and market cap recovery can be traced to Ethereum’s successful hard fork. The fork was agreed upon in response to the DAO hack, which resulted in the theft of a large amount of Ether. A proposed hard fork in the currency, isolating the stolen funds and rendering them without value, was readily agreed to by the Ethereum mining community and subsequently implemented, restoring confidence, and with it, value.
Additionally, cryptocurrency exchange/wallet provider/merchant solution Coinbase recently announced Ethereum integration, solidifying the currency’s place as being respected by the cryptocurrency “establishment.”
[https://cointelegraph.com/news/ethereum-shoots-up-as-bitcoin-drops-below-80-market-dominance]
{time.2015.11}
===
With the widening interest beyond the core Ethereum community, it was time to spread our collective wings to help the rest of the world see the same ideas that many early adopters had. Following a short delay, DEVCON1 was announced to take place in London, England for a week in November 2015. Almost 400 people joined together at this location for an entire week, totaling 80 talks and topics about the Ethereum ecosystem.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2015-07-30}
=== FRONTIER
Version 1.0 of Ethereum aka Frontier was released on July 30th 2015! Development continues towards the versions named Homestead, Metropolis and Serenity (v1.1).
Frontier is aimed at exchangers and miners.
Homestead is aiming for Πapps developers, while Metropolis is aiming for end users with the release of the Mist browser.
Serenity is meant to move from consensus through Proof-of-Work to Proof-of-Stake.
[https://github.com/ethereum/wiki/wiki#frontier]
{time.2014.11}
===
Only two months later, in November 2014, the majority of the Ethereum project team was assembled and descended upon Berlin to participate in the first Ethereum conference: DEVCON0. Although many had spoke via Skype, this was a time when most of the project members met for the first time. At this proto-conference, in a modest but beautiful space, developers took turns standing in front of peers explaining their vision for any given segment of the many protocols that would be necessary to develop “Web3”.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2014.07}
=== ETHER INITIAL ALLOCATION:
Beginning in July 2014, Ethereum distributed the initial allocation of ether via a 42-day public ether presale, netting 31,591 bitcoins, worth $18,439,086 at that time, in exchange for about 60,102,216 ether. The results of the sale were initially used to pay back mounting legal debts and also for the months of developer effort that had yet to be compensated, and to finance the ongoing development of the Ethereum.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/history-of-ethereum.html#the-ethereum-foundation-and-the-ether-presale]
{time.2014.04}
===
By April of 2014, Dr. Gavin Wood published the Ethereum Yellow Paper that would serve as the technical bible and de-facto specification for the Ethereum Virtual Machine (EVM).
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2014-01-25}
===
Ethereum was formally announced on January 25, 2014.
[https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/]
{time.2013}
Many of these took the form of “alt coins” - separate blockchains with cryptocurrencies of their own which improved on the original bitcoin protocol to add new features or capabilities.
In late 2013, Ethereum’s inventor Vitalik Buterin proposed that a single blockchain with the capability to be reprogrammed to perform any arbitrarily complex computation could subsume these many other projects.
[https://ethereum-homestead.readthedocs.io/en/latest/introduction/what-is-ethereum.html]
===
Buterin [2013a] first proposed the kernel of this work in late November, 2013.
Though now evolved in many ways, the key functionality of a blockchain with a Turing-complete language and an effectively unlimited inter-transaction storage capability remains unchanged.
[https://ethereum.github.io/yellowpaper/paper.pdf (e5eff48.2017-03-02)]
Origing::
Ethereum was designed as a smart contract platform. Its origin is actually linked to a critique made by Vitalik Buterin on bitcoin as a very limited smart contract platform.
[https://medium.com/zeppelin-blog/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05#262d]
bcnnet.time.NEM (XEMnet {2015-03-29})
Description::
NEM XEM
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
One of the key features of NEM is that it doesn't require much computing power as other cryptos and has a low entry barrier for developers.
The main point of NEM is to provide cheap and super secure services worldwide.
NEM is fueled by its own cryptocurrency, named XEM.
[https://changelly.com/supported-currencies]
===
NEM (New Economy Movement) was originally conceived as a clone of the well-known Nxt blockchain, but rapidly developed into a completely new project with its own codebase. It has since grown into a thriving community and ecosystem with a market cap of around $45 million, placing it in the top 10 of all cryptocurrencies.
[https://blog.chronobank.io/chronobank-partners-with-nem-to-create-chrononem-wallet-eebdc176351d]
===
Features
- NEM is built 100% from scratch (not a fork of any existing project)
- NEM is built with test-driven development
- NEM uses innovative Proof-of-Importance algorithm: first reputation based blockchain algorithm
- NEM has customizable assets called Mosaics. Editable supply, levies, description, transferability and more.
- NEM has Namespaces to help maintain reputation of Mosaics
- NEM improves different features of POW and POS coins, being more efficient and environmentally friendly
- NEM one minute average block times
- NEM is the first crypto with delegated harvesting
- NEM is the first with localized spam protection
- NEM is the first with Eigentrust peer reputation management
- NEM is the first editable m-of-n multisig with blockchain based alerts
- NEM is the first every P2P network with nodes time syncing in a decentralized manner
- NEM offers encrypted, unencrypted and hex messaging
- NEM is easy to install with a one click installer
- NEM zero monetary inflation (fixed supply, all 9 billion coins released at launch).
- NEM relatively large egalitarian distribution
- NEM will offer a mobile wallet for both iOS and Android (coming soon)
[http://wiki.nem.io/index.php/About:_General]
===
NEM is an advanced, bitcoin 2.0+ system that has been in development since January of 2014. The development team is comprised of professional software engineers and scientists who went to great lengths to study ways to improve existing blockchain platforms and created NEM from scratch to be more secure and easier to develop for than any other platform. Instead of using Proof-of-Work mining, which is wasteful and not eco-friendly, a new concensus algorithm, Proof-of-Importance was developed, which uses low energy and also rewards participation in the economy. NEM was developed using modern software engineering practices such as test-driven development, has over 3,000 unit tests, and was tested on an open network for over 9 months before its release on 2015/3//31.
The currency of NEM is called XEM, but the transfer of XEM is far from the only utility of the NEM blockchain platform. NEM mosaics provide the most advance implementation of digital assets to date and can be associated with blockchain-level domain names. A reputation system and smart contracts/decentralized computing systems are also in development, which will make NEM the most comprehensive block chain platform to date when completed.
[http://mijin.io/en/about-mijin]
Name::
* cpt.bcnnetNEM,
* cpt.nemnet,
* cpt.netNEM,
* cpt.New-Economy-Movement-bcnnet,
* cpt.xemnet,
xemnet'Protocol
xemprl'Implementation-language
Description::
NEM is a global open source project.
It is a peer-to-peer blockchain platform and is written in Java and JavaScript with 100% original source code.
[http://wiki.nem.io/index.php/About:_General]
xemnet'Node
xemnod'Node-server (NIS)
Description::
NEM 2-Tier Architecture
NEM's design architecture consists of two components. One is the Node server or NEM Infrastructure Server (NIS). The other is the NEM Client. The NIS is connected to the p2p network and acts as a gateway for the Client. NEM’s platform is therefore, a two-tier solution, following the convention of the web architecture.The first version of the NEM Client is called the NEM Community Client (NCC).The NCC is basically a client software that includes a wallet. Both the NCC and NIS can be configured to run off the same machine. As it is run from the same machine, both the NCC and the NIS will be exposed to the Internet. A second use case is to separate the NIS from the NCC.
The NIS can thus be configured to act as an additional layer of protection to the NCC thereby making the NCC reasonably protected within its own confines as it can be made not to connect to the Internet. In addition, one can have the option of putting a firewall between the NCC and the NIS, the NCC is therefore two steps away from the Internet. This means that the NCC can be made to work in stealth mode. This type of modular design makes the NCC insulated from external attacks. It is almost impossible to break into the NCC if the NCC is only connected to the NIS through another firewall. If there is any attack on the wallet, it is almost certain that the attack is from within the network rather than from outside the network. Another feature of this architecture is that the NCC acts as a wallet and can be used on any computer, whereas the NIS represents a node on the NEM network and can be hosted from remote locations. Additionally, the client can be loaded onto any computer and a person's wallet can be reloaded as long as this person has her private keys.
The NIS can be placed on a Demilitarized Zone (DMZ) behind a firewall and therefore itself is protected from the Internet. Hence, there exists many options and configurations. This makes NEM's architecture secure.
Subsequent to the NCC, more wallets have been created. These are the mobile wallets (to be released soon), the light-wallet that was created using Javascript, and the nanowallet, which is an augmented and amended version of the light wallet.
The NIS has a full set of APIs. The initial NCC has a webserver with useful APIs. These two layers create a firewall of security in between the wallet where all important information is stored and signed, while the NIS announces transactions.
[http://wiki.nem.io/index.php/NEM_2-Tier_Architecture]
Name::
* cpt.xemnet'NIS,
* cpt.xemnet'NEM-Infrastructure-Server,
* cpt.xemnet'NIS,
xemnet'Blockchain
Description::
A ‘Blockchain’ is sort of like that piece of paper in a checkbook that allows you to keep track of everything. The NEM ‘Blockchain’ keeps track of how much was spent, with whom, on what day, and even keeps track of the exact time. Now imagine if everyone in the world shared a piece of paper like this. It has everyone's spending on it. If you make changes everyone can see it, but you can only make changes if everyone agrees that this change actually happened. Everyone, at any time, can look at it and check to make sure it's right. Now, we all agree that this piece of paper is right. Usually, 'Blockchains' keep track of who owns what money and when it is moved around. In NEM, this is still true - but NEM also keeps track of other kinds of things, which will be talked about at the end of this blog.
[https://blog.nem.io/the-beginners-guide-to-nem/]
xemnet'Consensus-algorithm
Description::
'Proof of Importance' is a way in NEM to make sure that all the computers on a network agree with each other and helps decide who can ‘harvest’. This helps to keep everything safe from hackers and keeps NEM working well. It’s a big part of how we make sure people are telling the truth about the things that our ‘Blockchain’ keeps track of, like how much money a person owns. ‘Proof of Importance’ helps to make sure that every person using NEM can agree on everything and stops people from spending more than they have. It uses mathematical formulas made from information about an account to decide how important a person is to the group.
The more important you are, the better chance you have of getting that free money when you’re ‘Harvesting’! That means people want to be important, so they won’t lie! Once you are important, there are a couple more things that decide just how important you actually are. Your ‘Vested Balance’, who you send money with, how often you send money, and how much you send are all considered when figuring out how important you are. To fake all of these things would take more money than a liar would stand to make. The best part? This means we can always trust an important person.
[https://blog.nem.io/the-beginners-guide-to-nem/]
Name::
* cpt.proof-of-importance-xemnet,
* cpt.xemnet'proof-of-importance,
xembcn'Address
Description::
A NEM address is a base-323 encoded triplet consisting of
- a network byte
- a 160-bit hash of the account’s public key
- a 4 byte checksum
The checksum allows for quick recognition of mistyped addresses. It is possible to send XEM to any valid address even if the address has not previously participated in any transaction. If nobody owns the private key of the account to which the XEM is sent, the XEM is most likely lost forever.
However, you are unlikely to send XEM to an unowned address, because it would have to be generated with the right checksum. This means that the more likely scenario is that the owner lost the key, which caused all the XEM to be lost.
[http://wiki.nem.io/index.php/About:_Addresses]
Name::
* cpt.xemnet'address,
xemnet'Exchange-value-unit.Consensus (XEMevuC)
Description::
NEM (XEM)
$0.034570 (30.59%)
0.00002862 BTC (31.14%)
Rank 6
Currency
Market Cap
$311,128,200
257,544 BTC
Volume (24h)
$9,820,020
8,129 BTC
Circulating Supply
8,999,999,999 XEM
[https://coinmarketcap.com/currencies/nem/] {2017-04-19}
===
NEM XEM
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
One of the key features of NEM is that it doesn't require much computing power as other cryptos and has a low entry barrier for developers.
The main point of NEM is to provide cheap and super secure services worldwide. NEM is fueled by its own cryptocurrency, named XEM.
[https://changelly.com/supported-currencies]
===
What is XEM?
"XEM" is NEM's currency code. It is similar to USD, EUR, CNY, JPY etc.
[https://www.nem.io/faq.html#whatsXem]
Name::
* cpt.XEM,
* cpt.xemcevu,
* cpt.xemcevu,
xemevuC'OgnExchange
Description::
Buy XEM at one of these exchanges
POLONIEX
BTC38
BITCOIN.co.id
Changelly
===
Buy XEM directly with cash
Zaif
BTC38
xemnet'Program
xempgm.Client
Description::
NEM 2-Tier Architecture
NEM's design architecture consists of two components. One is the Node server or NEM Infrastructure Server (NIS). The other is the NEM Client. The NIS is connected to the p2p network and acts as a gateway for the Client. NEM’s platform is therefore, a two-tier solution, following the convention of the web architecture.The first version of the NEM Client is called the NEM Community Client (NCC).The NCC is basically a client software that includes a wallet. Both the NCC and NIS can be configured to run off the same machine. As it is run from the same machine, both the NCC and the NIS will be exposed to the Internet. A second use case is to separate the NIS from the NCC.
Subsequent to the NCC, more wallets have been created. These are the mobile wallets (to be released soon), the light-wallet that was created using Javascript, and the nanowallet, which is an augmented and amended version of the light wallet.
[http://wiki.nem.io/index.php/NEM_2-Tier_Architecture]
xemnet'Organization
xemnet'NEM-Foundation
Description::
In July 2016 the NEM community agreed (consensus of the community with blockchain-based voting) to set up a Company Limited by Guarantee (CLG) in Singapore, NEM.io Foundation Ltd. (“NEM Foundation”) to represent the roof international organisation. This CLG is set up in December 2016 and will lead country/regional chapters which are being registered as local non-profit societies.
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]
Name::
* cpt.NEM-Foundation,
xemnet'Problem
1- If you are syncing but an your machine says something like "NIS is synchronizing. At block 221896, est. 126 days behind. (at block 221896)" and doesn't move and sync but seems stuck, please try to delete your database and start a new chain. You can speed up this process by just downloading a new chain and inserting it manually. Here are some tutorials with step by step instructions. http://blog.nem.io/how-to-delete-your-local-copy-of-the-blockchain/7 http://blog.nem.io/how-to-import-the-database-file-provided-by-developers/4
2- If there is a major problem, you might have to delete all NEM software on the computer and start over from scratch installing. Here is a tutorial for that. http://blog.nem.io/how-to-remove-old-nem-software-versions/12
Generally speaking the installer is the most buggy. Most people that have a problem with the installer find that using the stand alone works. Instructions for the stand alone are here. http://blog.nem.io/nem-tutorial-list/8
If you have your private key backed up, or want to make a new wallet with a pass phrase, the Lightwallet is also very safe and easy to use. http://nem.io/install.html8
At some point NEM will fully transition away from NCC to Lightwallet and mobile apps for iOS and Android and there will no longer be any of these problems.
3- If you are having trouble logging in.
Go to C:\Users\yourname\nem\ncc and delete the ncc.cfg file and the accounts_cache_mainnet.json file.
4. If NIS wont start. Go to C:\Users\yourname\nem and delete the nis.lock file.
5- If you are having a problem with Java, please try to update your Java.
[http://wiki.nem.io/index.php/Tutorial:_Common_Problems]
xemnet'Service
Description::
NEM is a peer to peer platform providing solutions for blockchain multisigns, payments, messaging, naming system, asset making and other services.
[https://changelly.com/supported-currencies]
xemnet'Namespace
Description::
The basic things you need to know about NEM’s recent fork are Namespaces and Mosaics features. The easiest way to appreciate it is the domain and file analogy on the internet. Imagine that a domain address has to be unique in a root (lowest level). Namespace addresses this unique feature. If one creates a namespace, that namespace will appear unique in the NEM ecosystem. For example, if one were to create a namespace called “foo” that namespace cannot be created by a second person. Just like on the internet, a domain can have a sub-domain, namespaces can have sub-namespaces. And it is possible to create multiple sub-namespaces with the same name (example: “foo.bar” and “foo2.bar”, “bar” is the sub-namespace/sub-domain). A namespace and a domain name is the same in this document and shall be used interchangeably. Namespaces can have up to 3 levels, a namespace and its two levels of sub-namespace domains.
[https://blog.nem.io/mosaics-and-namespaces-2/]
===
NEM has a built in system for people to register names called Namespaces. These names can be used to run a business on the blockchain.
[https://blog.nem.io/the-beginners-guide-to-nem/]
xemnet'Mosaic
Description::
The basic things you need to know about NEM’s recent fork are Namespaces and Mosaics features. The easiest way to appreciate it is the domain and file analogy on the internet.
...
A mosaic is like a file hosted on a domain and represents an asset, and like a website and directory, a mosaic can have the same name as other files on other domains. But a total address of a namespace + mosaic will always be unique as the root namespace is unique even if the rest of it isn't.
[https://blog.nem.io/mosaics-and-namespaces-2/]
Significance of Namespaces and Mosaics
Namespaces gives rise to a unique naming convention. Mosaics gives rise to the creation of assets. Some call it a colored coin while others may call it a token. We call it a mosaic it will take on many types of properties when it is full blown (hence we call it a mosaic as it evolves to form the “big picture”) .
Our initial release is a mosaic that has the following properties:
description
Free-text description of the mosaic up to 128 characters, changeable by the owner.
divisibility
Adding this makes a quantity divisible, up to 6 decimal places. A divisibility of 2 means 2 decimal places.
information
Arbitrary byte array that can be in the property, with a size limit; this is the same as “messages” in NEM.
domain name or namespace (required)
Globally unique fully qualified domain name that is registered and owned by the mosaic creator. A top level namespace has a size limit of 16 characters, sub-namespaces have a limit of 64 characters.
name (required)
Name of the mosaic, up to a size limit of 32 characters; must be unique under the domain name.
mutable quantity
The amount of mosaic in circulation. If immutable, it is fixed, otherwise it is dynamic, i.e., more can be created or destroyed later.
transferability
If no, it means it can only be transferred between user and creator. Otherwise, it is freely transferable between third parties.
levy
A levy allows the creator of a mosaic to set a tax on any subsequent transactions of that mosaic. This levy is sent to an account of the creators choosing. Any mosaic or XEM may be used as a levy.
In the future Mosaics might have their feature set expanded to among other things include dividends, reputation, recallability, composability (ability to put assets in assets), issuer covered fees on trades, expansion of the non-transferable white list, levies to be redefinable, variable expirations, smart contracts, storage, and processing power. In addition to discussing these up grades to Mosaics, we have also discussed making Namespaces have transferable names.
[https://blog.nem.io/mosaics-and-namespaces-2/]
bcnnet.time.Dash (DASHnet {2014-01-19})
Description::
What is Dash?
Dash (DASH) is a privacy-centric digital currency with instant transactions. It is based on the Bitcoin software, but it has a two tier network that improves it. Dash allows you to remain anonymous while you make transactions, similar to cash.
With Bitcoin, transactions are published to the blockchain and you can prove who made them or to whom, but with Dash the anonymization technology makes it impossible to trace them. This is important because the blockchain is accessible to anyone with an internet connection – a significant drawback for those don’t wish their transaction history and balances to be publicly available. Dash does this through a mixing protocol utilizing an innovative decentralized network of servers called Masternodes, avoiding the need for a trusted third party that could compromise the integrity of the system.
Dash transactions are almost instantly confirmed by the Masternodes network. This is a great improvement on Bitcoin’s system, where confirmations take much longer because all the work is done by the miners.
For full details please read the Dash whitepaper.
[https://www.dash.org/what-is-dash/]
Name::
* cpt.netCbc.dash,
* cpt.dash-cryptocurrency-net,
* cpt.dashnet,
* cpt.netDash,
===
Dash , which stands for ‘Digital Cash’
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
Generic::
* Blockchain-network-with-builtin-decentralized-governance,
* Exchange-value-unit-blockchain-network,
dashnet'whole.DAO (dashdao)
dashnet'Protocol (dashprl)
dashnet'White-paper (dashwpr)
AddressWpg::
* https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf,
* https://github.com/dashpay/dash/wiki/Whitepaper,
Dash: A PrivacyCentric CryptoCurrency
Evan Duffield evan@dashpay.io
Daniel Diaz daniel@dashpay.io
Abstract
A cryptocurrency based on Bitcoin, the work of Satoshi Nakamoto, with various improvements such as a twotier incentivized network, known as the Masternode network.
Included are other improvements such as Darksend, for increasing fungibility and InstantX which allows instant transaction confirmation without a centralized authority.
1 Introduction
Bitcoin[ 1 ] is a cryptocurrency that has emerged as a popular medium of exchange and is the first digital currency that has attracted a substantial number of users[ 2 ].
Since it’s inception in 2009, Bitcoin has been rapidly growing in mainstream adoption and merchant usage[ 3 ].
A main issue with the acceptance of Bitcoin in pointofsale situations is the time required to wait for the network to confirm the transaction made is valid, alternatively payment companies have created methods to allow vendors to take zeroconfirmation transactions, but these solutions utilize a trusted counterparty to mediate the transaction outside of the protocol.
Bitcoin provides pseudonymous transactions in a public ledger, with a onetoone relationship between sender and receiver.
This provides a permanent record of all transactions that have ever taken place on the network[ 5 ].
Bitcoin is widely known in academic circles to provide a low level of privacy, although with this limitation many people still entrust their financial history to it’s blockchain.
Dash is the first privacycentric cryptographic currency based on the work of Satoshi Nakamoto.
In this paper we propose a series of improvements to Bitcoin resulting in a decentralized, strongly anonymous cryptocurrency, with tamperproof instant transactions and a secondary peertopeer network incentivized to provide services to the Dash Network.
2 Masternode Network
Full nodes are servers running on a p2p network, that allow peers to use them to receive updates about the events on the network.
These nodes require significant amounts of traffic and other resources that carry substantial cost.
As a result, on the Bitcoin network a steady decrease in the amount of these nodes has been observed for some time[ 7 ] and as a result block propagation have been upwards of 40 seconds[ 14].
Many solutions have beenproposed such as a new reward scheme by Microsoft Research[ 4 ] and the Bitnodes incentive program[ 6 ].
imgDashwprFig1.png
Figure 1: Full nodes in the spring of 2014
These nodes are very important to the health of the network.
They provide clients with the ability to synchronize and quick propagation of messages throughout the network.
We propose adding a secondary network, known as the Dash Masternode network.
These nodes will have high availability and provide a required level of service to the network in order to take part in the Masternode Reward Program.
2.1 Masternode Reward Program - Cost and Payments
Much of the reason for the decrease of full nodes on the Bitcoin network, is the lack of incentive to run one.
Over time the cost of running a full node increases as the network gets used more, creating more bandwidth and costing the operator more money.
As the cost rises, operators consolidate their services to be cheaper to run or run a light client, which doesn’t help the network at all.
Masternodes are full nodes, just like in the Bitcoin network, except they must provide a level of service to the network and have a bond of collateral to participate.
Collateral is never forfeit and is safe while the Masternode is operating.
This allows investors to provide a service to the network, earn interest on their investment and reduce the volatility of the currency.
To run a Masternode, the node must store 1000 DASH.
When active, nodes provide services to clients on the network and in return are paid in the form of a dividend.
This allows the users to pay for the services and earn a return on investment. Masternodes are all paid from the same pool of money, approximately 45% [footnote] of the total block reward is dedicated to this program.
Due to the fact that the Masternode rewards program is a fixed percentage and the Masternode network nodes are fluctuating, expected Masternode rewards will vary according to the current total count of active Masternodes.
Payments for a standard day for running a Masternode can be calculated by using the following formula:
(n/t) * r * b * a
Where:
n is the number of Masternodes an operator controls
t is the total number of Masternodes
r is the current block reward (presently averaging about 5 DASH)
b is blocks in an average day. For the Dash network this usually is 576.
a is the average Masternode payment (45% of the average block amount)
Return on investment for running a Masternode can be calculated as
((n/t) * r * b * a * 365) / 1000
Where variables are the same as above.
The cost associated with running a Masternode creates a hard and soft limit of active nodes on the network.
Currently with 5.3 million DASH in circulation, only 5300 nodes could possibly be running on the network.
The soft limit is imposed by the price it costs to acquire a node and the limited liquidity on exchanges due to usage of Dash as a currency and not merely an investment.
2.2 Deterministic Ordering
A special deterministic algorithm is used to create a pseudorandom ordering of the Masternodes.
By using the hash from the proofofwork for each block, security of this functionality will be provided by the mining network.
Pseudo Code, for selecting a Masternode:
For(mastenode in masternodes){
n = masternode.CalculateScore();
if(n > best_score){
best_score = n;
winning_node = masternode;
}}
CMasterNode::CalculateScore(){
n1 = GetProofOfWorkHash(nBlockHeight); // get the hash of this block
n2 = Hash(n1); //hash the POW hash to increase the entropy
n3 = abs(n2 masternode_vin);
return n3;
}
The example code can be extended further to provide rankings of Masternodes also, a “second”, “third”, “fourth” Masternode in the list to be selected.
2.3 Trustless Quorums
Currently the Dash network has ~2400 active Masternodes[ 8 ].
By requiring 1000 DASH collateral to become an active Masternode, we create a system in which no one can control the entire network of Masternodes.
For example, if someone wants to control 50% of the Masternode network, they would have to buy 2,300,000 DASH from the open market.
This would raise the price substantially and it would become impossible to acquire the needed DASH.
With the addition of the Masternode network and the collateral requirements, we can use this secondary network to do highly sensitive tasks in a trustless way, where no single entity can control the outcome.
By selecting N pseudo random Masternodes from the total pool to perform the same task, these nodes can act as an oracle, without having the whole network do the task.
For an example implementation of a trustless quorum see InstantX[ 9 ], which uses quorums to approve transactions and lock the inputs or the proofofservice implementation[ 10].
Another example use for trustless quorums can include utilizing the masternode network as a decentralized oracle for financial markets, making secure decentralized contracts a possibility.
As an example contract, if AAPL is over $300 on Dec 31, 2016 pay public key A, otherwise pay public key B.
2.4 Roles and Proof-Of-Service
Masternodes can provide any number of extra services to the network.
As a proofofconcept, our first implementation included Darksend and InstantX.
By utilizing what we call proofofservice, we can require that these nodes are online, responding and even at the correct block height.
Bad actors could also run Masternodes, but not provide any of the quality service that is required of the rest of the network.
To reduce the possibility of people using the system to their advantage nodes must ping the rest of the network to ensure they remain active.
This work is done by the Masternode network by selecting 2 quorums per block.
Quorum A checks the service of Quorum B each block.
Quorum A are the closest nodes to the current block hash, while Quorum B are the furthest nodes from said hash.
Masternode A (1) checks Masternode B (rank 2300)
Masternode A (2) checks Masternode B (rank 2299)
Masternode A (3) checks Masternode B (rank 2298)
All work done to check the network to prove that nodes are active is done by the Masternode network itself.
Approximately 1% of the network will be checked each block.
This results in the entire network being checked about six times per day.
In order to keep this system trustless, we select nodes randomly via the Quorum system, then we also require a minimum of six violations in order to deactivate a node.
In order to trick this system, an attacker will need to be selected six times in a row.
Otherwise, violations will be cancelled out by the system as other nodes are selected by the quorum system.
Attacker Controlled
Masternodes /
Total Masternodes
| Required Picked
Times In A Row
| Probability of
success (n/t)^r
| DASH Required
|
| 1/2300
| 6
| 6.75e21
| 1000DASH
|
| 10/2300
| 6
| 6.75e15
| 10,000DASH
|
| 100/2300
| 6
| 6.75e09
| 100,000DASH
|
| 500/2300
| 6
| 0.01055%
| 500,000DASH
|
| 1000/2300
| 6
| 0.6755%
| 1,000,000DASH
|
Table 1. The probability of tricking the system representing one individual Masternode as failing proofofservice
Where:
n is the total number of nodes controlled by the attacker
t is the total number of Masternodes in the network
r is the depth of the chain
The selection of Masternodes is pseudo random based on the Quorum system
2.5 Masternode Protocol
The Masternodes are propagated around the network using a series of protocol extensions including a Masternode announce message and Masternode ping message.
These two messages are all that’s needed to make a node active on the network, beyond these there are other messages for executing a proofofservice request, Darksend and InstantX.
Masternodes are originally formed by sending 1000 DASH to a specific address in a wallet that will “activate” the node making it capable of being propagated across the network.
A secondary private key is created that is used for signing all further messages.
The latter key allows the wallet to be completely locked when running in a standalone mode.
A cold mode is made possible by utilizing the secondary private key on two separate machines.
The primary “hot” client signs the 1000 DASH input including the secondary signing private key in the message.
Soon after the “cold” client sees a message including its secondary key and activates as a Masternode.
This allows the “hot” client to be deactivated (client turned off) and leaves no possibility of an attacker gaining access to the 1000 DASH by gaining access to the Masternode after activation.
Upon starting a Masternode sends a “Masternode Announce” message to the network, containing:
Message: (1K DASH Input, Reachable IP Address, Signature, Signature Time, 1K Dash Public Key, Secondary Public Key, Donation Public Key, Donation Percentage)
Every 15 minutes thereafter, a ping message is sent proving the node is still alive.
Message: (1K DASH Input, Signature (using secondary key), Signature Time, Stop?)
After a timetolive has expired the network will remove an inactive node from the network, causing the node to not be used by clients or paid.
Nodes can also ping the network constantly, but if they do not have their ports open, they will eventually be flagged as inactive and not be paid.
2.6 Propagation of the Masternode List
New clients entering the Dash network must be made aware of the currently active Masternodes on the network to be able to utilize their services.
As soon as they join the meshnetwork, a command is sent to their peers asking for the known list of Masternodes.
A cache object is used for clients to record Masternodes and their current status, so when clients restart they will simply load this file rather than asking for the full list of Masternodes.
2.7 Payments via Mining and Enforcement
To ensure that each Masternode is paid it’s fair share of the block reward, the network must enforce that blocks pay the correct Masternode.
If a miner is noncompliant their blocks must be rejected by the network, otherwise cheating will be incentivized.
We propose a strategy where Masternodes form quorums, select a winning Masternode and broadcast their message.
After N messages have been broadcast to select the same target payee, a consensus will be formed and that block in question will be required to pay that Masternode.
When mining on the network, pool software (websites that merge the efforts of individual miners) use the RPC API interface to get information about how to make a block.
To pay the Masternodes this interface must be extended by adding a secondary payee to GetBlockTemplate.
Pools then propagate their successfully mined blocks, with a split payment between themselves and a Masternode.
3 Darksend
We believe it’s important to have a standard trustless implementation for improving the privacy of it’s users in the reference client that provides a high degree of privacy.
Other clients such as electrum, Android and iPhone will also have the same anonymity layer implemented directly and utilize the protocol extensions.
This allows users a common experience anonymizing funds using a well understood system.
Darksend is an improved and extended version of the CoinJoin.
In addition to the core concept of CoinJoin, we employ a series of improvements such as decentralization, strong anonymity by using a chaining approach , denominations and passive aheadoftime mixing.
The greatest challenge when improving privacy and fungibility of a cryptocurrency is doing it in a way that does not obscure the entire blockchain.
In Bitcoin based crypto currencies, one can tell which outputs are unspent and which are not, commonly called UTXO, which stands for unspent transaction output.
This results in a public ledger that allows any user to act as guarantor of the integrity of transactions.
The Bitcoin protocol is designed to function without the participation of trusted counterparties, in their absence, it is critical that auditing capabilities remain readily accessible to the users through the public blockchain.
Our goal is to improve privacy and fungibility without losing these key elements that we believe make a successful currency.
By having a decentralized mixing service within the currency we gain the ability to keep the currency itself perfectly fungible.
Fungibility is an attribute of money, that dictates that all units of a currency should remain equal.
When you receive money within a currency, it shouldn’t come with any history from the previous users of the currency or the users should have an easy way to disassociate themselves from that history, thus keeping all coins equal.
At the same time, any user should be able to act as an auditor to guarantee the financial integrity of the public ledger without compromising others privacy.
To improve the fungibility and keep the integrity of the public blockchain, we propose using an aheadoftime decentralized trustless mixing strategy.
To be effective at keeping the currency fungible, this service is directly built into the currency, easy to use and safe for the average user.
3.1 Tracing Coinjoin By Amounts
A common strategy in existing Bitcoin implementations of Coinjoin is simply merging transactions together.
This exposes the users to various methods of following the the users coins through these joined transaction.
imgDashwprFig2.png
Figure 2: An example Coinjoin transaction with 2 users [11][12]
In this transaction, 0.05BTC was sent through the mixer.
To identify the source of the money, one simply has to add up the values on the right until they match one of the values on the left.
Breaking apart the transaction:
0.05+0.0499+0.0001(fee) = 0.10BTC.
0.0499+0.05940182+0.0001(fee) = 0.10940182BTC.
This gets exponentially more difficult as more users are added to the mixer. However, these
sessions can be retroactively deanonymized at any point in the future.
3.2 Through linking and Forward Linking
In other proposed implementations of Coinjoin, it’s possible that a user anonymizes money then eventually sends change from that transaction to an exchange or other entity that knows the users identity.
This breaks the anonymity and allows the entity to walk backwards through that users transactions.
We call this type of attack “Forward Linking”
imgDashwprFig3.png
Figure 3: Forward Change Linking
In this example, Alice anonymizes 1.2BTC, which goes to 2 outputs, 1BTC and 0.2BTC.
She then spends .7BTC from the 1BTC output, receiving change of 0.3BTC.
That 0.3BTC then goes to an identifiable source, confirming Alice also spent the .7BTC in the prior transaction.
To identify the sender of the anonymous transaction, start at the “exchange” transaction and go backwards in the blockchain till you get to the “Alice sends 0.7BTC anonymously”.
As the exchange, you know it was your user who just recently bought something anonymously, thus breaking the anonymity completely. We call this type of attack “Through Change Linking”.
imgDashwprFig4.png
Figure 4: Through Change Linking
In the second example, Alice buys 1.2 BTC from coinbase, then anonymizes this amount into a 1BTC output. She then spends the 1BTC, receives change in the amount of 0.3BTC and then combines that with her 0.2BTC earlier change.
By combining the change from the anonymous transaction (0.3BTC) and the change she received from the CoinJoin transaction, you can link the entire history before and after, completely breaking the anonymity.
3.3 Improved Privacy and DOS resistance
Darksend uses the fact that a transaction can be formed by multiple parties and made out to multiple parties to merge funds together in a way where they can’t be uncoupled thereafter.
Given that all Darksend transactions are setup for users to pay themselves, the system is highly secure against theft and users coins always remain safe.
Currently to mix using DarkSend requires at least 3 participants.
imgDashwprFig5.png
Figure 5: Three users submit denominated funds into a common transaction. Users pay themselves back in the form of new outputs, which are randomly ordered.
To improve the privacy of the system as a whole we propose using common denominations of 0.1DASH, 1DASH, 10DASH AND 100DASH.
In each mixing session, all users should submit the same denominations as inputs and outputs.
In addition to denominations, fees should be removed from the transactions and charged in bulk in separate, sporadic unlinkable transactions.
To address the possible DOS attacks, we propose all users submit a transaction as collateral to the pool when joining.
This transaction will be made out to themselves and will pay a high fee to miners.
In the case when a user submits a request to the mixing pool, they must provide collateral at the beginning of this exchange. If at any point any user fails to cooperate, by refusing to sign for example, the collateral transaction will automatically be broadcasted.
This will make it expensive to do a sustained attack on the privacy network.
3.4 Passive Anonymization of funds and chaining
Darksend is limited to 1000 DASH per session and requires multiple sessions to thoroughly anonymize significant amounts of money.
To make the user experience easy and make timing attacks very difficult, Darksend runs in a passive mode.
At set intervals, a user’s client will request to join with other clients via a Masternode.
Upon entry into the Masternode, a queueobject is propagated throughout the network detailing the denominations the user is looking to anonymize, but no information that can be used to identify the user.
Each Darksend session can be thought of as an independent event increasing the anonymity of user’s funds.
However each session is limited to three clients, so an observer has a one in three chance of being able to follow a transaction.
To increase the quality of anonymity provided, a chaining approach is employed, which funds are sent through multiple Masternodes, one after another.
| Depth Of The Chain
| Possible Users (n)^r
|
| 2
| 9
|
| 4
| 81
|
| 8
| 6561
|
Table 2. How many users could possibly be involved in N mixing sessions.
3.5 Security Considerations
As transactions are merged, Masternodes can possibly “snoop” on users funds as they pass through.
This is not considered a serious limitation due to the requirement for Masternode’s to hold 1000 DASH and the fact that users utilize random Masternodes that they select to host their joins.
The probability of following a transaction throughout a chaining event can be calculated as follows
Attacker Controlled
Masternodes /
Total Masternodes
| Depth Of The Chain
| Probability of
success (n/t)^r
| DASH Required
|
| 10/1010
| 2
| 9.80e05
| 10,000DASH
|
| 10/1010
| 4
| 9.60e09
| 10,000DASH
|
| 10/1010
| 8
| 9.51e11
| 10,000DASH
|
| 100/1100
| 2
| 8.26e03
| 100,000DASH
|
| 100/1100
| 4
| 6.83e05
| 100,000DASH
|
| 100/1100
| 8
| 4.66e09
| 100,000DASH
|
| 1000/2000
| 2
| 25%
| 1,000,000DASH
|
| 1000/2000
| 4
| 6.25%
| 1,000,000DASH
|
| 1000/2000
| 8
| 0.39%
| 1,000,000DASH
|
| 2000/3000
| 2
| 44.4%
| 2,000,000DASH
|
| 2000/3000
| 4
| 19.75%
| 2,000,000DASH
|
| 2000/3000
| 8
| 3.90%
| 2,000,000DASH
|
Table 3. The probability of follow a Darksend transaction on the network given the attacker controls N Nodes.
Where:
n is the total number of nodes controlled by the attacker
t is the total number of Masternodes in the network
r is the depth of the chain
The selection of Masternodes is random
Considering the limited supply of DASH (5.3 million at the time of writing) and the low liquidity available on the market, it becomes an impossibility to attain a large enough number of Masternodes to succeed at such an attack.
Extending the system by blinding Masternodes to the transactions taking place on their node will also greatly enhance the security of the system.
3.6 Masternode Blinding via Relay System
In section 3.4 we describe the probabilities of following a single transaction through multiple sessions of Darksend mixing.
This can further be addressed by blinding Masternodes, so they can’t see which inputs/outputs belong to which users.
To do this we propose a simple relay system that users can use to protect their identity.
Instead of a user submitting the inputs and outputs directly into the pool, they will pick a random Masternode from the network and request that it relays the inputs/outputs/signatures to the target Masternode. This means that the Masternode will receive N sets of inputs/outputs and N sets of signatures. Each set belongs to one of the users, but the Masternode can’t know which belongs to which.
4 Instant Transactions via InstantX
By utilizing Masternode quorums, users are able to send and receive instant irreversible transactions. Once a quorum has been formed, the inputs of the transaction are locked to only be spendable in a specific transaction, a transaction lock takes about 4 seconds to be set currently on the network.
If consensus is reached on a lock by the Masternode network, all conflicting transactions or conflicting blocks would be rejected thereafter, unless they matched the exact transaction ID of the lock in place.
This will allow vendors to use mobile devices in place of traditional POS systems for real world commerce and users to quickly settle facetoface non commercial transactions as with traditional cash.
This is done without a central authority.
An extensive overview of this feature can be found in the InstantX white paper[ 10].
5 Additional Improvements
5.1 x11
x11 is a widely used hashing algorithm, which takes a different approach, known as algorithm chaining.
x11 consists of all 11 SHA3 contestants[ 13], each hash is calculated then submitted to the next algorithm in the chain.
By utilizing multiple algorithms, the likelihood that an ASIC is created for the currency is minimal until a later part of it’s life cycle.
In the life cycle of Bitcoin, mining began with hobbyists which used CPUs to mine the currency, then shortly after GPU software was created, which quickly replaced the CPUs.
Years after the GPUs cycle, ASICs or Application Specific Integrated Circuits were created, which quickly replaced the GPUs.
Due to the complexity and die size required to create an ASIC for mining x11, we expect that it will take considerably longer than it did in Bitcoin, allowing for hobbyists to take part in the mining for a longer period of time.
We believe this is highly important for good distribution and growth of a cryptocurrency.
Another benefit of the chaining hashing approach is high end CPUs give an average return similar to that of GPUs.
Also GPUs have been reported to run 3050% cooler, with less wattage than the Scrypt algorithm used by most current cryptocurrencies.
5.2 Mining Supply
A different approach to restricting the inflation of mining is taken in Dash, using a 7% reduction of the supply per year.
This is done as opposed to halving implemented by other currencies.
In addition supply each block is directly tied to the amount of miners on the network; more miners result in lower mining rewards.
Production of Dash is scheduled to carry on throughout this century and onto the next, slowly grinding down until finally near the year 2150, production will cease.
imgDashwprFig6.png
Figure 6: Mining Reward Schedule
5 Conclusion
This paper introduces various concepts to improve the design of bitcoin resulting in improved privacy and fungibility for the average user, less price volatility and quicker message propagation throughout the network.
This is all accomplished by utilizing an incentivized twotier model, rather than the existing singletier model in other cryptocurrencies such as Bitcoin.
By utilizing this alternative network design it becomes possible to add many types of services such as decentralized mixing of coins, instant transactions and decentralized oracles using masternode quorums.
dashnet'Blockchain (dashbcn)
dashnet'Exchange-value-unit.Consensus (DASHcevu)
Description::
Dash DASH
Dash is a cryptocurrency previously known as Darkcoin or XCoin.
It uses a coin-mixing service called Darksend that prevents transactions from being traced and adds privacy to the network.
Quick confirmation makes Dash payments an effective way to send money worldwide.
Two-Tier network opens new possibilities to integrate various services unavailable for other currencies.
[https://changelly.com/supported-currencies]
===
Dash (formerly known as Darkcoin) is an open source peer-to-peer cryptocurrency that uses a system called Darksend to add privacy to transactions.[1] It was rebranded from "Darkcoin" to "Dash" on March 25, 2015, a portmanteau of "Digital Cash".[2]
Dash uses a chained hashing algorithm approach called X11 for the proof-of-work. Instead of using the SHA-256 (from well-known Secure Hash Algorithm family) or scrypt it uses 11 rounds of different hashing functions.[3]
With chained hashing, high end CPUs give an average return similar to that of GPUs. Another side effect of the algorithm is that GPUs run at about 30% less electrical power than scrypt and 30% to 50% cooler, putting less stress on the computing setup and ensuring lower energy bills for miners.[4]
[https://en.wikipedia.org/wiki/Dash_%28cryptocurrency%29]
Name::
* cpt.Darkcoin,
* cpt.DASHcevu,
* cpt.dashcevt,
* cpt.mnyDash,
* cpt.mnyDarkcoin,
Generic::
* consensus-token,
dashnet'Governance-system (dashdgbb)
Description::
Governance in a decentralized project is difficult, because by definition there are no central authorities to make decisions for the project.
In Dash, such decisions are made by the network, that is, by the owners of masternodes.
The DGBB system allows masternodes to vote for or against proposals, which can then be implemented (or not) by Dash’s developers. A key example is early in 2016, when Dash’s Core Team submitted a proposal to the network asking whether the blocksize should be increased to 2 MB. Within 24 hours, consensus had been reached to approve this change. Compare this to Bitcoin, where debate on the blocksize has been raging for nearly three years.
[https://www.dash.org/governance/]
===
DDGB consists of three components: Proposals, Votes, and Budgets.
Anyone can submit a Proposal for a small fee.
Shareholders (owners of network Masternodes) cast votes for or against proposals.
Approved Proposals become Budgets.
Budgets are paid directly from the blockchain.
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
Name::
* cpt.Decentralized-Governance-By-Blockchain,
* cpt.DGBB,
Description::
Dash names the system Decentralized Governance by Blockchain (DGBB ) and since DGBB’s release in August 2015 all Dash operations have been under the control of the Dash network via the DGBB system, with new proposals made and funded each month autonomously by the network.
In fact since the inception of this system, the Dash network has funded the promotion of Dash conferences around the world, acquired highvalue property directly from the blockchain (dash.org) and many other projects that were important to the long term success of the ecosystem.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
Description::
Recently, new blockchains equipped with built in governance system tried to cope with this problem. Dash is the forerunner to implement governance system in their blockchain. Dash, who call themselves as the “First Self Governing, Self Funding Protocol”,proposed a decentralized management system based on the masternode voting mechanism in 2015. Dash has been steadily developed using this governance system. Recently the price of Dash surpassed over $100 (March 16th, 2017). A stable governance structure may be the reason for the increased value.
[http://cryptocentral.info/topic/913/boscoin-bos-a-congressional-cryptocurrency-platform-for-trust-contracts/4]
Description::
Governance and Funding[edit]
Dash is the first decentralized autonomous organization powered by a Sybil proof decentralized governance and funding system.[3]
DGBB or Decentralized Governance By Blockchain as it's called is a decentralized process by which the network determines where money is spent.
Each Masternode operator is given the ability to use 1 vote on each governance proposal, which is a completely open and decentralized process.[15]
Community interaction with proposal submitters is done usually through community driven websites, like DashWhale.[16]
These websites allow proposal submitters to provide multiple drafts, then lobby for community support before finally submitting their project to the network for a vote.
After the submitter has enough support, the network will automatically pay out the required funds in the next super block, which happen monthly.
Although, only in use a few months, the funding system has seen growth of it's month revenue, from originally ~$14 thousands in September 2015, to nearly $30 thousands in March 2016.[17]
Eventually the budget system can theoretically scale to $9M per month at a market cap of $500M.[18]
Since it's inception, the project has used the system for important assets like acquiring dash.org,[19] adoption into the Lamassu ATM[20][21] and the Dash N' Drink instant soda machine,[22] along with funding many public events.[23][24][25]
[https://en.wikipedia.org/wiki/Dash_(cryptocurrency)#Governance_and_Funding]
dashdgbb'Funding
Description::
The DGBB also provides a means for Dash to fund its own development. While other projects have to depend on donations or premined endowments, Dash uses 10% of the block reward to fund its own development. Every time a block is mined, 45% of the reward goes to the miner, 45% goes to a masternode, and the remaining 10% is not created until the end of the month. During the month, anybody can make a budget proposal to the network. If that proposal is approved by at least 10% of the masternode network, then at the end of the month a series of "superblocks" will be created. At that time, the block rewards that were not paid out (10% of each block) will be used to fund approved proposals. The network thus funds itself by reserving 10% of the block reward for budget projects.
[https://www.dash.org/governance/]
Name::
* cpt.dash-funding,
* cpt.dashnet'funding,
dashdgbb'Proposal (dashppl)
Description::
During the month, anybody can make a budget proposal to the network. If that proposal is approved by at least 10%* of the masternode network, then at the end of the month a series of "superblocks" will be created. At that time, the block rewards that were not paid out (10% of each block) will be used to fund approved proposals. The network thus funds itself by reserving 10% of the block reward for budget projects.
*The actual calculation is (YES VOTES - NO VOTES) > (Total Number of Masternodes / 10)
[https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=84672534]
Name::
* cpt.dashppl,
dashppl'Structure
Structure::
The following information is required to create a proposal:
proposal-name -- a unique label, 20 characters or less
url -- a proposer-created webpage or forum post containing detailed proposal information
payment-count -- how many cycles the proposal is requesting payment
block-start -- the requested start of proposal payments
dash-address -- the address to receive proposal payments
monthly-payment-dash -- the requested payment amount
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
dashppl.BUDGET
Description::
Budgets
Budgets are proposals which receive 10% of the possible votes (currently about 410 out of 4100) more yes votes than no votes.
Budgets can be nullified at any time if vote totals (cast or re-cast) fall below the approval threshold.
Budgets are processed (paid) in order of yes minus no votes. More popular budgets get payment priority.
Approximately 7500 dash (in 2016) are available for each budget cycle, declining by %7.1 per year.
[https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets]
Name::
* cpt.dash-budget-proposal,
dashnet'Wallet (dashwlt)
Name::
* cpt.dashwlt,
* cpt.dashwallet,
Generic::
* blockchain-wallet,
Specific::
* DashCore-wallet,
* Electrum-wallet,
* Mobile-wallet,
* Hardware-wallet,
* Paper-wallet,
* Online-wallet,
AddressWpg::
* https://dashpay.atlassian.net/wiki/pages/viewpage.action?pageId=1146941,
dashnet.EVOLUTING
dashnet.EVOLUTION (v13)
Description::
In the third major iteration of Dash named Dash Evolution (v13), additional architectural and functional improvements are being developed such as
the addition of a 3rd network tier (T3) comprised of a decentralized API (DAPI) that provides users with trustless remoteaccess via direct HTTP and RPC connections into the Dash network that are serviced by randomly comprised Masternode Quorums,
a decentralized wallet protocol that enables users to buy merchandise from the web in a trustless way (DashPay) without the need to host their own fullnode or use a centralized payment gateway,
a 2ndtier highperformance shardbased filestorage system that provides improved methods for transaction confirmation and doublespend prevention (DashDrive),
Primitives for representing users and accounts as objects to enable users to connect and transact with friends using aliases and rate each other to build trust networks (Social Wallet),
decentralized network administration by Masternode operators (DNA),
a new dynamic query language for use across Dash Evolution components providing an extensible objectbased crosstier communications standard (DSQL),
addition of a historical chain of all signatures used on the Masternode network for use in secure quorum selection (Quorum Chains),
improved Privacy architecture,
automatic instant transactions (AutoIX) and
ratedservices provided by network operators such as fiat converters.
[https://www.dash.org/binaries/evo/DashPaper-v13-v1.pdf]
Name::
* cpt.Dash-Evolution,
bcnnet.time.FairCoop (FAIRnet {2014-01-07})
Cpt-created: 2015.08, 25,
Description::
Faircoin, the Faircoop ecosystem cryptocurrency
FairCoin is the monetary base system for FairCoop.
The key purposes of FairCoin is to be used as a tool for economic redistribution, increasing justice, the empowerment of grassroots groups, the transformation of social and economic relations and the creation of commons.
[https://fair.coop/faircoin/]
Name::
* cpt.bcnnet.FairCoop,
* cpt.FairCoop-network,
* cpt.fairnet,
* cpt.faircoin-network,
fairnet'Protocol
FairCoin V2 white paper {2015.05}
AddressWpg::
* https://chain.fair-coin.org/download/FairCoin2-Draft.pdf,
FairCoin V2 white paper
DRAFT
Document version 1.0
Thomas Kφnig, May 2015
tom@fair-coin.org
FairCoin is the monetary base system for FairCoop The Earth Cooperative for a Fair Economy (see https://fair.coop).
In FairCoop we develop tools and transfer knowledge that enable everybody to participate in a fair global economy.
The existing version of the FairCoin wallet relies on mining and minting technology to secure the block chain.
The problem is that neither mining nor minting can truly be considered fair, because both confer an advantage on the already rich.
Therefore we decided to create a new version of FairCoin which corrects these issues.
With FairCoin2 (in short FC2) we can create block chain-based software that is fair, secure and power-saving.
It is based on cooperation and not on competition.
It is built on the code-base of a recent version of the Bitcoin core client.
This enables us to benefit from the latest developments made by the dedicated Bitcoin developers.
Also the comprehensive infrastructure that already exists around Bitcoin can be adopted for FairCoin with minimal effort.
This document describes the design concepts we have implemented in FairCoin2.
Some knowledge about how Bitcoin works is required to fully understand the contents of this document.
The first paragraphs provide a rather high-level view of the FC2 concept and the further you read the more technical and detailed it becomes.
1 Overview
In contrast to other cryptocurrencies FC2 does not implement any mining or minting (aka. staking) functionality, which are both competitive systems.
Block generation is instead performed by so-called certified validation nodes (in short CVN).
These nodes cooperate to secure the network.
To run a CVN one needs to complete a certification procedure which is called node certification procedure (in short NCP) that is operated by FairCoop (https://fair.coop/node-certificationprocedure/).
The requirements to operate such a node are described in chapter 3.1.
Please note that definition of the NCP is out of the scope of this document and will be defined in a separate document.
In the long run the NCP should be powered by a reputation system.
There is no reward for block creation (no coinbase/stake transaction).
Therefore the money supply does not change over time and is fixed at the time we migrate to FC2.
Nevertheless, the transaction fees go to the respective block creators to compensate their efforts for running a CVN.
Certain chain parameters, e.g. the transaction fee will be dynamically adjustable (without the need of releasing a new wallet version) by democratic community consensus.
The FairCoin team needs the approval (digital signatures) of a high percentage of all the active CVN.
2 Block generation
Block generation takes place in a collaborative way.
All CVN work together to bundle pending transactions into transaction blocks.
These blocks can only be created by CVN every 3 minutes.
Which CVN will generate the next block is determined by its time-weight.
The time-weight describes how much time has passed since a CVN created its last block.
If for example CVN A created a block 50 blocks ago and CVN B created it 55 blocks ago CVN B will be chosen to create the next block in the network.
There can always only be exactly one CVN with the highest timeweight.
If a new CVN joins the network for the first time it will be elected to create the next block.
Between two blocks only one new CVN can join in.
Block generation is performed in 3 phases.
New transactions are accepted during all these phases.
2.1 Transaction accumulation phase
In this phase all nodes relay transactions they receive from other nodes to any node they are currently connected to.
This phase lasts at least 170 sec.
If there are no pending transactions in the network it takes as long as the next transaction hits the network.
In other words, this phase only ends when there is at least 1 pending transaction in the network.
2.2 Time-weight announcement phase
In this phase each CVN determines its own time-weight based on the local block chain information and announces it to all other connected nodes.
Announcement messages are relayed by all nodes just like transactions.
The higher the nodes time-weight the sooner the announce message is sent to the network according to the following simple formula:
delay=10-(10*otw/tn)
Where:
delay is the time in seconds to wait before a CVN sends its own time-weight
otw is the CVN calculated own time-weight
tn is the total number of active nodes
10 is the constant of ten seconds, which is the duration of this phase
This will greatly reduce the amount of announcement packets sent over the network because if a CVN receives and correctly validates a time-weight announcement message from an other node with a higher time-weight it will not send its weight to the network.
Every CVN verifies that each time-weight announcement it receive is correct using the local block chain data (bogus announcements are discarded and a DoS ban score of 50 is proposed).
Time-weight announcements are used to determine the node with the highest time weight that is currently connected to the network.
This phase starts 10 sec. before the actual block target time.
2.3 Block creator election phase
This phase starts right after the Time-weight announcement phase.
Every CVN determines the CVN with the greatest time-weight according to the announcements it received.
It then signs and sends their candidate vote message to the network, which is relayed by every node just like transactions.
This phase has no defined length.
It stops once the elected CVN has received enough vote messages for its own id from over 90% of all active nodes.
This is the point in time when the collaboratively-elected CVN finally creates the next block in the chain containing all pending transactions from the so called “rawmempool”.
Also parts of the signed vote messages are incorporated into the block to prove that optimally 100% but at least 90% of all active connected nodes agreed on the elected CVN.
3 Certified validation nodes (CVN)
The aim of the CVNs is to secure the network by validating all the transactions that had been sent to the network and put them into a transaction block chain.
Blocks are created each 3 minutes (180 sec.).
Transactions are confirmed after they have been added to a block.
If there are no pending transactions no further blocks are created, which will not happen anymore after FairCoin has been widely adopted.
A CVN is a standard FairCoin core client configured with additional information namely certification data issued by FairCoop which “upgrades” it to a CVN.
Every node will be assigned a unique id.
3.1 Requirements for running a CVN:
Every entity running a CVN must agree upon the following technical requirements and must carry the responsibility to full fill these rules.
1. The system must be connected to the Internet all the time (24/7) and the TCP port 46392 must be reachable by all remote nodes from the Internet
2. The system must use a public NTP server to synchronize its system time to, preferably pool.ntp.org to ensure that the system time is always correct
3. The entity must have an account at the FairCoop web site
4. The wallet software must be configured with certification data issued by FairCoop
Further requirements might be defined after public discussion.
But this will be subject to the NCP document.
4 Node certification
But why would we need certification at all?
A decent certification procedure ensures that a high percentage of all CVNs are honest creator nodes.
At the moment the author sees no easy way of ensuring that each node has only one identity without a well established reputation system.
If every node was a creator node a skilled attacker could modify the client software in such a way to create thousands of different identities and could then perform numerous different attacks against the network.
5 Transaction fees
The transaction fees go to the node which created the block.
Transaction fees exist to avoid block chain spam and give block creators a small reward for taking the effort to leave their node running and pass through the certification procedure.
Fees should be dynamically adjustable to satisfy any change in the value of FairCoin.
fairnet'Exchange-value-unit.Consensus (FAIRevuC)
Description::
FairCoin is the monetary base system for FairCoop. We constantly drive development of the FairCoop/FairCoin ecosystem further and shape the individual components to fit our vision: building tools to enable everyone to participate in a fair economy on a global scale.
We decided to create a new version of FairCoin which corrects issues we encountered. The current version of FairCoin relies on PoS (proof-of-stake) which cannot be considered fair, because it confer an advantage on the already rich. Therefore we needed to come up with a new way to secure the network. We call it PoC (proof-of-cooperation). This innovation will finally make FairCoin fair, secure, and sustainable.
The draft we present here is meant to start a discussion on what the new version would look like. Many hours of voluntary work have already been put into building the basic concept and the white paper. The focus of the draft paper is mainly on the technical and implementation side of the FairCoin2 project. Many more aspects besides the technical have to be taken into account and elaborated on.
So, here it is the first draft of the FairCoin V2.0 white paper. Enter the fair dimension of cryptocurrency and download the PDF file now.
[https://fair-coin.org/faircoin2.html]
===
FairCoin (FAIR)
$0.037195 (1.64%)
0.00003150 BTC (0.58%)
Rank 116
Currency
Market Cap
$1,972,825
1,671 BTC
Volume (24h)
$2,277
1.93 BTC
Circulating Supply
53,040,622 FAIR
[https://coinmarketcap.com/currencies/faircoin/] {2017-04-16}
Name::
* cpt.Faircoin,
* cpt.mnyFair,
* cpt.mnyFaircoin,
fairnet'Human
König.Thomas
Thomas-König,
tom@fair-coin.org
bcnnet.time.Emercoin (EMCnet {2013-12-11})
Description::
A World of Blockchain Services
Emercoin's decentralized blockchain is used by a growing number of innovative services. Official services include EMCSSH (PKI management for system admins), EMCLNX (text advertising network), EMCSSL (passwordless website logins), InfoCard (business card / profile management), Magnet (torrent links), EMCTTS (digital timestamps) and EMCDPO (proof of ownership). For more information, see the "Technology" and "Guides" sections of this website.
[http://emercoin.com/getstarted]
===
Emercoin (EMC) - Cryptocurrency with hybrid POS + POW mining.
- Total Supply: Algorithmically increasing at approx. 6% per year (see latest stats).
- POS reward: approx. 6% annual with 30 day coin maturity.
- POW Algorithm: SHA-256.
- Block speed: 10 minute average.
- Initial POW block reward: 5020 EMC, decreasing depending on difficulty.
- POW difficulty is recalculated each block.
- Confirmations for new block: 32
Focused mostly on production of coins by POS as POW difficulty will gradually increase.
Energy-conservative POS mining algorithm is at the core of EMC.
[https://emercoin.com/specifications]
Name::
* cpt.emercoin-network,
* cpt.netEmc,
* cpt.emercoin-network,
* cpt.netEmc,
emcnet'Exchange-value-unit.Consensus (EMCevuC)
Name::
* cpt.EMCevuC,
* cpt.emercoin-token,
* cpt.mnyEmc,
emcevuC'Geting
Description::
EMC is the currency which is used to transact on the Emercoin network and pay network fees for blockchain services. The easiest way to obtain EMC is to buy it on an exchange, however EMC can also be earned through mining or by selling goods and services.
[http://emercoin.com/getstarted]
emcnet'DOING
emcnet'Service
Description::
In addition to being used for the payment of goods and services, Emercoin provides a platform for a wealth of novel applications such as decentralized domain names and an advertising network. How you decide to use Emercoin is really up to your imagination.
[http://emercoin.com/getstarted]
bcnnet.time.Nxt (NXTnet {2013-11-24})
Cpt-created: {2015-08-13}
Description::
Nxt is more than just a digital currency. It’s the infrastructure for a digital economy.
[http://nxt.org/about/what-is-nxt/]
===
Nxt makes sending money as easy as sending an email. But it’s far more than a digital currency. It’s a platform for transactions of all kinds and the foundation of something much bigger than P2P cash.
[http://nxt.org/about/what-is-nxt/]
Name::
* cpt.netNext,
* cpt.netNxt,
* cpt.Nxt-platform,
* cpt.nxtnet,
* cpt.sihNxt,
nxtnet'Blockchain (nxtbcn)
nxtnet'Exchange-value-unit (nxtevu)
Description::
MONETARY SYSTEM
The Nxt Monetary System allows you to create and trade user-defined Tokens called Currencies.
Currencies are a specific class of Asset which have several extra parameters, such as the ability to back them with the NXT crypto-currency to stabilise their value.
Monetary System currencies can be freely traded both within the Nxt system using the decentralized Exchange Booth feature and outside the Nxt core on external exchanges or projects that support the MS Currency system
The Monetary System allows an individual or project that needs a digital currency to quickly create one ‘off the shelf’ and then immediately begin using it, taking advantage of the established Nxt blockchain, software and network.
[https://nxt.org/what-is-nxt/monetary-system/]
nxtevu.Ardor (ARDRevu)
Description::
Ardor ARDR
Ardor is a scalable blockchain platform based on Child Chains, allowing to build cost-savvy and stable decentralized applications for any purposes.
Ardor is powered by the cryptocurrency of the same name, based on the NXT blockchain technology.
[https://changelly.com/supported-currencies]
Name::
* cpt.Ardor-evu,
* cpt.ARDRevu,
AddressWpg::
* https://www.ardorplatform.org/
nxtnet'Exchange-value-unit.Consensus (NXTevuC)
Description::
Next NXT
The developers of Nxt deem it a second-generation cryptocurrency dramatically different from Bitcoin and all the altcoins.
It is written from scratch, based on PoS mechanism and can be considered an eco-friendly coin as it does not require great amounts of hashing power.
Its efficient feature "Transparent Forging" minimizes the transaction time as it determines which server node will generate the next block, so the transaction is sent straight to this node.
[https://changelly.com/supported-currencies]
Name::
* cpt.mnyNext,
* cpt.mnyNxt,
* cpt.nxtmny,
Description::
Nxt (NXT)
$0.020194 (3.77%)
0.00001656 BTC (4.36%)
Rank 36
Currency
Market Cap
$20,173,806
16,539 BTC
Volume (24h)
$305,907
250.79 BTC
Circulating Supply
998,999,983 NXT
Max Supply
1,000,000,000 NXT
[https://coinmarketcap.com/currencies/nxt/] {2017-04-22}
===
Nxt is an open source[5] cryptocurrency and payment network launched in November 2013 by anonymous software developer BCNext.[6] It uses proof-of-stake to reach consensus for transactions - as such there is a static money supply and no mining as with Bitcoin. Nxt is specifically conceived as flexible platform to build applications and financial services around.[7] It has an integrated asset-exchange[8] (comparable to shares), messaging system and marketplace. Users can also create new currencies within the system. The last major release enabled Multisignature capabilities and a plugin-system for the client.[9]
[https://en.wikipedia.org/wiki/Nxt]
nxtevuC.AGGREGATE
Nxt is a scam because all Nxt coins are pre-mined:
First, it's important to note that Nxt is a 100% Proof-of-Stake (PoS) coin.
The only way to implement this form of currency is to issue all available coins in the genesis block.
To do otherwise would force the implementation of some form of Proof-of-Work scheme in order to prevent attacks on the network that "fake" stake.
Since the creator of Nxt wanted a 100% PoS platform, this was not a desirable course of action.
Second, the term "pre-mined" is a misnomer because Nxt coins are not being mined at all.
The original stakeholders in Nxt contributed Bitcoin in order to seed the creation of the 1 billion coins represented in the genesis block, and these coins were distributed among the original stakeholders.
The stakeholders are expected to distribute coins by donating them, using them as "bounties" to pay for work on the coin (software, documentation, translations, support, etc.) that is done by the community.
Even the creator of Nxt (BCNxt ) made an investment.
The coins were not generated from nothing!
Third, the creation of the genesis block was fully public, and all of the original account numbers and their assigned amounts of Nxt are visible: see https://bitcointalk.org/index.php?topic=303898.msg3652710#msg3652710
[http://nxtwiki.org/wiki/FAQ#Nxt_is_a_scam_because_all_Nxt_coins_are_pre-mined]
Why is it called forging instead of mining?
With Bitcoin and many other cryptocurrencies, the act of securing and verifying the blockchain results in new coins being created. With Nxt, however, all possible coins already exist, and accounts earn coins from transaction fees alone. As a result, it was felt that a new word - "forge" - was needed to describe the manner in which coins are earned.
[http://nxtwiki.org/wiki/FAQ#Why_is_it_called_forging_instead_of_mining.3F]
nxtnet'Wallet
Description::
Where is my wallet?
Unlike Bitcoin or other altcoins, there is no local wallet with Nxt. More specifically, the coin uses a "brain wallet", which is to say that wallets are decentralized and kept on the network. When you create an account in Nxt, your secret passphrase is used to create your account number. Once your account number is generated, you can unlock it and access it by using your passphrase on any running Nxt node.
[http://nxtwiki.org/wiki/FAQ#Where_is_my_wallet.3F]
nxtnet'Security
Description::
Improved security. This property also protects the network from the problems of mining power being concentrated in a few big pools or organisations, which renders it vulnerable to a ‘51 percent’ attack. Nxt’s proof-of-stake means that even if one person owns 90 percent of all the coins available, the network remains secure.
[http://nxt.org/about/what-is-nxt/]
nxtnet'Human
nxthmn.BCNext
Description::
BCNext
BCNext is the founder of Nxt and wrote the initial version of Nxt's code. BCNext saw Bitcoin as a failed attempt to create a digital economy and so created Nxt as a platform to build a digital economy upon. He first appeared on Bitcointalk with a post announcing Nxt on 28th September 2013 and was a self-declared Sockpuppet of a long-standing Bitcointalk member. BCNext was involved in the early development of Nxt but their last post was on the 8th November 2013. BCNext then began to communicate through Come-from-Beyond. BCNext left the project once he was satisfied the community had established itself in April/May 2014. Come-from-Beyond now has his notes and planned implementation of the announced and unannounced features of Nxt.
[http://nxtwiki.org/wiki/Glossary#BCNext]
Name::
* cpt.BCNext,
nxthmn.Come-from-Beyond
Description::
Come-from-Beyond
Come-from-Beyond is an important developer for the initial implementation of Nxt and is a continuing forum member and Nxt development contributer. He was originally employed on contract directly by BCNext from the start of Nxt in late 2013. After BCNext stopped posting from the BCNext account, he was the conduit through which BCNext communicated. Come-from-Beyond’s contract came to an end on the 3rd April 2014, the day before the beginning of George Orwell’s book ‘1984’. He now works as freelance developer to complete the ideas BCNext passed on, and to build his own projects on top of the Nxt Platform.
[http://nxtwiki.org/wiki/Glossary#Come-from-Beyond]
nxthmn.FOUNDER
Description::
Founder
Nxt's founders are the 73 people who sent bitcoin to secure an initial stake in Nxt.
All of Nxt's coins were generated on November 25, 2013 and distributed in the genesis block to the founders, based on the amount of bitcoin sent.
[http://nxtwiki.org/wiki/Glossary#Founder]
nxtnet'Organization
nxtogn.Exchange-organization
Specific::
Poloniex
Bter
BTC38
Nxt Multigateway
CCEX
HitBTC
Changelly
Litebit (buy with IDEAL)
nxtogn.NXT-Foundation
NXT Foundation
Mauvestraat 44-4
Amsterdam, MA 1073RM
Netherlands
nxtnet'Doing
Description::
Nxt takes a different approach.
Instead of building on the Bitcoin protocol, Nxt started with a vision of a radical new digital economy and was designed from the ground up to create a platform to realise it.
Not only does it open up new possibilities – everything from digital cash and property ownership records to smart contracts and online transfer of stocks and shares – but it addresses all of the most serious deficiencies in existing cryptocurrencies.
Most altcoins aim to fix one or two of these.
Nxt was developed to allow a sustainable, fair and versatile platform that would benefit everyone.
[http://nxt.org/about/what-is-nxt/]
===
Nxt is an open source[5] cryptocurrency and payment network launched in November 2013 by anonymous software developer BCNext.[6] It uses proof-of-stake to reach consensus for transactions - as such there is a static money supply and no mining as with Bitcoin. Nxt is specifically conceived as flexible platform to build applications and financial services around.[7] It has an integrated asset-exchange[8] (comparable to shares), messaging system and marketplace. Users can also create new currencies within the system. The last major release enabled Multisignature capabilities and a plugin-system for the client.[9]
[https://en.wikipedia.org/wiki/Nxt]
nxtsvc.ASSET-EXCHANGE
Description::
ASSET EXCHANGE
The Nxt Asset Exchange is a peer-to-peer exchange built directly into the Nxt software, allowing secure and fast decentralized trading in Nxt Assets. This eliminates the need to transfer assets or to put trust in an outside agency or business, and as Nxt Assets can be used to represent literally anything (from Bitcoin to coffee beans) there are a wide range of potential investments or trades to be made on the Asset Exchange.
[https://nxt.org/what-is-nxt/asset-exchange/]
nxtsvc.MARKETPLACE
Description::
MARKETPLACE
The Nxt Marketplace feature allows you to list items for sale and make sales on the blockchain.
You do not need to rely on external market sites to conduct your business. Instead, transactions are done between seller and buyer directly.
[https://nxt.org/what-is-nxt/marketplace/]
nxtsvc.STORAGE
Description::
DATA CLOUD
The Nxt Data Cloud is a decentralised data storage system.
In addition to keeping a record of Nxt transactions, the blockchain can also be used to store user-defined data. All forms of data can be uploaded to the Nxt blockchain, providing a secure (and, if desired, permanent) method of storing, retrieving and publishing information. Nxt Messaging makes use of this ability to embed data in the blockchain, and the Data Cloud can be seen as an extension of the Messaging system.
One of the most important features of data storage on the blockchain is that the Nxt blockchain is a permanent and immutable record that provides a tamper-proof time stamp. This allows for legal records (such as contracts) to be embedded in the blockchain, with absolute certainty about the time at which they were created.
[https://nxt.org/what-is-nxt/data-cloud/]
nxtsvc.ALIAS-SYSTEM
Description::
The Alias System feature of Nxt essentially allows one piece of text to be substituted for another, so that keywords or keyphrases can be used to represent other things – names, telephone numbers, physical addresses, web sites, account numbers, email addresses, product SKU codes... almost anything you can think of.
For example, you could ask Nxt to associate "search" with "www.google.com". Once this is done, all you have to do to get to Google is type "nxt:search" into a Nxt-capable browser, and it will translate your request in one for "www.google.com".
Immediate applications are simple: you can create an easy-to-remember alias for your Nxt account number, for example. But since the Alias System is open-ended, it can be used to implement a decentralized DNS system, shopping cart applications, and more.
Creating aliases is
A user sends a transaction that states "ThisText = ThatText"
If the alias is to be changed, just send another transaction with a new definition. Only the account that created an alias can change it.
[http://nxtwiki.org/wiki/Alias_System]
bcnnet.time.Peercoin (PPCnet {2012-08-19})
Cpt-created: {2013-08-24}
Description::
Peercoin seeks to be the most secure cryptocoin at the lowest cost, rewarding all users for strengthening the network by giving them a 1% annual PPC return when minting.
?Built to Last
?The world's first Proof-of-Stake coin.
?Fair Distribution
?No insider pre-sale or instant mining.
?Energy Efficient
?Mint Peercoins on any device.
?Stable and Secure
?Protecting your investment since 2012.
[https://peercoin.net/]
ppcnet'Protocol
ppcprl'White-paper {2012}
AddressWpg::
* https://peercoin.net/assets/paper/peercoin-paper.pdf,
PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake
Sunny King, Scott Nadal
(sunnyking9999@gmail.com, scott.nadal@gmail.com)
August 19th, 2012
Abstract
A peer-to-peer crypto-currency design derived from Satoshi Nakamoto’s Bitcoin.
Proof-of-stake replaces proof-of-work to provide most of the network security.
Under this hybrid design proof-of-work mainly provides initial minting and is largely non-essential in the long run.
Security level of the network is not dependent on energy consumption in the long term thus providing an energy efficient and more cost-competitive peer-to-peer crypto-currency.
Proof-of-stake is based on coin age and generated by each node via a hashing scheme bearing similarity to Bitcoin’s but over limited search space.
Block chain history and transaction settlement are further protected by a centrally broadcasted checkpoint mechanism.
Introduction
Since the creation of Bitcoin (Nakamoto 2008), proof-of-work has been the predominant design of peer-to-peer crypto currency.
The concept of proof-of-work has been the backbone of minting and security model of Nakamoto’s design.
In October 2011, we have realized that, the concept of coin age can facilitate an alternative design known as proof-of-stake, to Bitcoin’s proof-of-work system.
We have since formalized a design where proof-of-stake is used to build the security model of a peer-to-peer crypto currency and part of its minting process, whereas proof-of-work mainly facilitates the initial part of the minting process and gradually reduces its significance.
This design attempts to demonstrate the viability of future peer-to-peer crypto-currencies with no dependency on energy consumption.
We have named the project ppcoin.
Coin Age
The concept of coin age was known to Nakamoto at least as early as 2010 and used in Bitcoin to help prioritize transactions, for example, although it didn’t play much of an critical role in Bitcoin’s security model.
Coin age is simply defined as currency amount times holding period.
In a simple to understand example, if Bob received 10 coins from Alice and held it for 90 days, we say that Bob has accumulated 900 coin-days of coin age.
Additionally, when Bob spent the 10 coins he received from Alice, we say the coin age Bob accumulated with these 10 coins had been consumed (or destroyed).
In order to facilitate the computation of coin age, we introduced a timestamp field into each transaction.
Block timestamp and transaction timestamp related protocols are strengthened to secure the computation of coin age.
Proof-of-Stake
Proof-of-work helped to give birth to Nakamoto’s major breakthrough, however the nature of proof-of-work means that the crypto-currency is dependent on energy consumption, thus introducing significant cost overhead in the operation of such networks, which is borne by the users via a combination of inflation and transaction fees.
As the mint rate slows in Bitcoin network, eventually it could put pressure on raising transaction fees to sustain a preferred level of security.
One naturally asks whether we must maintain energy consumption in order to have a decentralized crypto-currency?
Thus it is an important milestone both theoretically and technologically, to demonstrate that the security of peer-to-peer crypto-currencies does not have to depend on energy consumption.
A concept termed proof-of-stake was discussed among Bitcoin circles as early as 2011.
Roughly speaking, proof-of-stake means a form of proof of ownership of the currency.
Coin age consumed by a transaction can be considered a form of proof-of-stake.
We independently discovered the concept of proof-of-stake and the concept of coin age in October 2011, whereby we realized that proof-of-stake can indeed replace most proof-ofwork’s functions with careful redesign of Bitcoin’s minting and security model.
This is mainly because, similar to proof-of-work, proof-of-stake cannot be easily forged.
Of course, this is one of the critical requirements of monetary systems - difficulty to counterfeit.
Philosophically speaking, money is a form of ‘proof-of-work’ in the past thus should be able to substitute proof-of-work all by itself.
Block Generation under Proof-of-Stake
In our hybrid design, blocks are separated into two different types, proof-of-work blocks and proof-of-stake blocks.
Kernel input
Stake input Stake output (pay to stake owner himself)
Stake input
Figure: Structure of Proof-of-Stake (Coinstake) Transaction
The proof-of-stake in the new type of blocks is a special transaction called coinstake (named after Bitcoin’s special transaction coinbase).
In the coinstake transaction block owner pays himself thereby consuming his coin age, while gaining the privilege of generating a block for the network and minting for proof-of-stake.
The first input of coinstake is called kernel and is required to meet certain hash target protocol, thus making the generation of proof-of-stake blocks a stochastic process similar to proof-ofwork blocks.
However an important difference is that the hashing operation is done over a limited search space (more specifically one hash per unspent wallet-output per second) instead of an unlimited search space as in proof-of-work, thus no significant consumption of energy is involved.
The hash target that stake kernel must meet is a target per unit coin age (coin-day) consumed in the kernel (in contrast to Bitcoin’s proof-of-work target which is a fixed target value applying to every node).
Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol.
For example, if Bob has a wallet-output which accumulated 100 coin-years and expects it to generate a kernel in 2 days, then Alice can roughly expect her 200 coin-year wallet-output to generate a kernel in 1 day.
In our design both proof-of-work hash target and proof-of-stake hash target are adjusted continuously rather than Bitcoin’s two-week adjustment interval, to avoid sudden jump in network generation rate.
Minting based on Proof-of-Stake
A new minting process is introduced for proof-of stake blocks in addition to Bitcoin’s proof-of-work minting.
Proof-of-stake block mints coins based on the consumed coin age in the coinstake transaction.
A mint rate of 1 cent per coin-year consumed is chosen to give rise to a low future inflation rate.
Even though we kept proof-of-work as part of the minting process to facilitate initial minting, it is conceivable that in a pure proof-of-stake system initial minting can be seeded completely in genesis block via a process similar to stock market initial public offer (IPO).
Main Chain Protocol
The protocol for determining which competing block chain wins as main chain has been switched over to use consumed coin age.
Here every transaction in a block contributes its consumed coin age to the score of the block.
The block chain with highest total consumed coin age is chosen as main chain.
This is in contrast to the use of proof-of-work in Bitcoin’s main chain protocol, whereas the total work of the block chain is used to determine main chain.
This design alleviates some of the concerns of Bitcoin’s 51% assumption, where the system is only considered secure when good nodes control at least 51% of network mining power.
First the cost of controlling significant stake might be higher than the cost of acquiring significant mining power, thus raising the cost of attack for such powerful entities.
Also attacker’s coin age is consumed during the attack, which may render it more difficult for the attacker to continue preventing transactions from entering main chain.
Checkpoint: Protection of History
One of the disadvantages of using total consumed coin age to determine main chain is that it lowers the cost of attack on the entire block chain of history.
Even though Bitcoin has relatively strong protection over the history Nakamoto still introduced checkpoints in 2010 as a mechanism to solidify the block chain history, preventing any possible changes to the part of block chain earlier than the checkpoint.
Another concern is that the cost of double-spending attack may have been lowered as well, as attacker may just need to accumulate certain amount of coin age and force reorganization of the block chain.
To make commerce practical under such a system, we decided to introduce an additional form of checkpoints that are broadcasted centrally, at much shorter intervals such as a few times daily, to serve to freeze block chain and finalize transactions.
This new type of checkpoint is broadcasted similar to Bitcoin’s alert system.
Laurie (2011) has argued that Bitcoin has not completely solved the distributed concensus problem as the mechanism for checkpointing is not distributed.
We attempted to design a practical distributed checkpointing protocol but found it difficult to secure against network split attack.
Although the broadcasted checkpointing mechanism is a form of centralization, we consider it acceptable before a distributed solution is available.
Another technical reason entails the use of centrally broadcasted checkpointing.
In order to defend against a type of denial-of-service attack coinstake kernel must be verified before a proof-of-stake block can be accepted into the local database (block tree) of each node.
Due to Bitcoin node’s data model (transaction index specifically) a deadline of checkpointing is needed to ensure all nodes’ capability of verifying connection of each coinstake kernel before accepting a block into the block tree.
Because of the above practical considerations we decided not to modify node’s data model but use central checkpointing instead.
Our solution is to modify the coin age computation to require a minimum age, such as one month, below which the coin age is computed as zero.
Then the central checkpointing is used to ensure all nodes can agree upon past transactions older than one month thus allowing the verification of coinstake kernel connection as a kernel requires non-zero coin age thus must use an output from more than one month ago.
Block Signatures and Duplicate Stake Protocol
Each block must be signed by its owner to prevent the same proof-of-stake from being copied and used by attackers.
A duplicate-stake protocol is designed to defend against an attacker using a single proofof-stake to generate a multitude of blocks as a denial-of-service attack.
Each node collects the (kernel, timestamp) pair of all coinstake transactions it has seen.
If a received block contains a duplicate pair as another previously received block, we ignore such duplicate-stake block until a successor block is received as an orphan block.
Energy Efficiency
When the proof-of-work mint rate approaches zero, there is less and less incentive to mint proof-of-work blocks. Under this long term scenario energy consumption in the network may drop to very low levels as disinterested miners stop mining proof-of-work blocks.
The Bitcoin network faces such risk unless transaction volume/fee rises to high enough levels to sustain the energy consumption.
Under our design even if energy consumption approaches zero the network is still protected by proof-of-stake.
We call a crypto-currency long-term energy-efficient if energy consumption on proof-of-work is allowed to approach zero.
Other Considerations
We modified the proof-of-work mint rate to be not determined by block height (time) but instead determined by difficulty.
When mining difficulty goes up, proof-of-work mint rate is lowered.
A relatively smooth curve is chosen as opposed to Bitcoin’s step functions, to avoid artificially shocking the market.
More specifically, a continuous curve is chosen such that each 16x raise of mining difficulty halves the block mint amount.
Over longer term the proof-of-work mint curve would not be too dissimilar to that of Bitcoin in terms of the inflationary behavior, given the continuation of Moore’s Law.
We consider it wise to follow the traditional observation that the Market favors a low inflation currency over a high-inflation one, despite of significant criticism of Bitcoin from some mainstream economists due to ideological reasons in our opinion.
Babaioff et al. (2011) studied the effect of transaction fee and argued that transaction fee is an incentive to not cooperate between miners.
Under our system this attack is exacerbated so we no longer give transaction fees to block owner.
We decided to destroy transaction fees instead.
This removes the incentive to not acknowledge other minter’s blocks.
It also serves as a deflationary force to counter the inflationary force from the proof-of-stake minting.
We also choose to enforce transaction fees at protocol level to defend against block bloating attack.
During our research we have also discovered a third possibility besides proof-of-work and proof-of-stake, which we termed proof-of-excellence.
Under this system typically a tournament is held periodically to mint coins based on the performance of the tournament participants, mimicking the prizes of real-life tournaments.
Although this system tends to consume energy as well when artificial intelligence excels at the game involved, we still found the concept interesting even under such situation as it provides a somewhat intelligent form of energy consumption.
Conclusion
Upon validation of our design in the Market, we expect proof-of-stake designs to become a potentially more competitive form of peer-to-peer crypto-currency to proof-of-work designs due to the elimination of dependency on energy consumption, thereby achieving lower inflation/lower transaction fees at comparable network security levels.
Acknowledgement
Many thanks to Richard Smith for helping out with testing and various network/fork
related work.
We would like to thank Satoshi Nakamoto and Bitcoin developers whose brilliant
pioneering work opened our minds and made a project like this possible.
ppcnet'Concensous-exval-tokent (PPCevuC)
Description::
PPCoin (code: PPC), also known as Peercoin and Peer-to-Peer Coin is the first known cryptocurrency based on an implementation of a combined proof-of-stake/proof-of-work system.[1]
As of 2 July 2013, one PPCoin had a value of approximately 0.14 USD, giving PPCoin a money supply with a value of $2.9 million USD, making it roughly level with Namecoin as the third largest cryptocurrency.[3][4][5]
Central bank None. The PPCoin peer-to-peer network regulates and distributes through consensus in protocol.[1]
Date of introduction 12 August 2012, 17:57:38 UTC
User(s) International
Inflation Limited release (Geometric series, rate halves every 4 years), there is also 1% inflation due to the proof-of-stake system.[1][2]
Subunit
0.001 mPPC (millicoin)
0.000001 µPPC (microcoin)
0.00000001 Smallest unit
Symbol ?, PPC
Nickname Peercoin, P2PCoin
Plural PPCoin, PPCoins
[http://en.wikipedia.org/wiki/PPCoin]
===
PPCoin:
AKA Peercoin or P2P coin.
An altcoin using the proof of stake mechanism in conjunction with proof of work.
Based on a paper produced by Sunny King and Scott Nadal.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Peercoin (PPC)
$0.836138 (-0.66%)
0.00070832 BTC (-1.28%)
Rank 35
Mineable Currency
Market Cap
$20,078,420
17,009 BTC
Volume (24h)
$257,009
217.72 BTC
Circulating Supply
24,013,285 PPC
[https://coinmarketcap.com/currencies/peercoin/] {2017-04-16}
Name::
* cpt.mny.Peercoin,
* cpt.mny.PPCoin,
* cpt.mny.PPC,
* cpt.peercoin,
* cpt.PPCoin,
bcnnet.time.Ripple (XRPnet {2012})
Cpt-created: 2015-08-12,
Description::
Ripple is a real-time gross settlement system (RTGS), currency exchange and remittance network by Ripple Labs. Also called the Ripple Transaction Protocol (RTXP) or Ripple protocol,[3] it is built upon a distributed open source Internet protocol, consensus ledger and native currency called XRP (ripples). Released in 2012, Ripple purports to enable "secure, instant and nearly free global financial transactions of any size with no chargebacks." It supports tokens representing fiat currency, cryptocurrency, commodity or any other unit of value such as frequent flier miles or mobile minutes.[4][5] At its core, Ripple is based around a shared, public database or ledger,[6] which uses a consensus process that allows for payments, exchanges and remittance in a distributed process.[7] The security of the Ripple consensus algorithm was challenged by rivals in 2014,[8] with Ripple Labs defending the safety of the system.[9] As of 2014, Ripple is the second-largest cryptocurrency by market capitalization,[10][11] after Bitcoin.[12][13][14][15] Currently implemented by companies such as Fidor Bank, the Ripple protocol has been increasingly adopted by banks and payment networks as settlement infrastructure technology,[16] with American Banker explaining that "from banks' perspective, distributed ledgers like the Ripple system have a number of advantages over cryptocurrencies like Bitcoin," including price and security.[17]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
===
Ripple:
A payment network that can be used to transfer any currency (including ad hoc currencies that have been created by users).
The network consists of payment nodes and gateways operated by authorities.
Payments are made using a series of IOUs, and the network is based on trust relationships.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.netXrp,
* cpt.digital-currency-system.ripple, cptIt51.11,
* cpt.ripple-distributed-network, cptIt51.11,
* cpt.ripple-network, cptIt51.11,
* cpt.ripple-system,
* cpt.stmRpl,
* cpt.xrpnet,
Generic::
* blockchain-network,
xrpnet'Node (xrpnod)
xrpnod'UNL
Description::
Unique Node List (UNL): Each server, s, maintains a unique node list, which is a set of other servers that s queries when determining consensus.
Only the votes of the other members of the UNL of s are considered when determining consensus (as opposed to every node on the network).
Thus the UNL represents a subset of the network which when taken collectively, is “trusted” by s to not collude in an attempt to defraud the network.
Note that this definition of “trust” does not require that each individual member of the UNL be trusted (see section 3.2).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
Name::
* cpt.Ripple-UNL,
xrpnod.FAULTY
Description::
We use the term nonfaulty to refer to nodes in the network that behave honestly and without error.
Conversely, a faulty node is one which experiences errors which may be honest (due to data corruption, implementation errors, etc.), or malicious (Byzantine errors).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
Name::
* cpt.xrpnet'malicious-node,
xrpnod.FAULTY.NO
Description::
We use the term nonfaulty to refer to nodes in the network that behave honestly and without error.
Conversely, a faulty node is one which experiences errors which may be honest (due to data corruption, implementation errors, etc.), or malicious (Byzantine errors).
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
xrpnod.SERVER
Description::
Server: A server is any entity running the Ripple Server software (as opposed to the Ripple Client software which only lets a user send and receive funds), which participates in the consensus process.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
xrpnod.server.PROPOSER
Description::
Proposer: Any server can broadcast transactions to be included in the consensus process, and every server attempts to include every valid transaction when a new consensus round starts.
During the consensus process, however, only proposals from servers on the UNL of a server s are considered by s.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
xrpnet'Blockchain (xrpbcn)
Description::
The ledger is a record of the amount of currency in each user’s account and represents the “ground truth” of the network.
The ledger is repeatedly updated with transactions that successfully pass through the consensus process.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
===
At its core, Ripple is based around a shared, public database or ledger that has its contents decided on by consensus.[6] In addition to balances, the ledger holds information about offers to buy or sell currencies and assets, creating the first distributed exchange.[53]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
Name::
* cpt.xrpnet'database,
* cpt.xrpnet'distributed-ledger,
* cpt.xrpnet'public-database,
* cpt.xrpnet'shared-database,
xrpbcn'Consensus-algorithm
Description::
The Ripple Protocol consensus algorithm (RPCA), is applied every few seconds by all nodes, in order to maintain the correctness and agreement of the network.
Once consensus is reached, the current ledger is considered “closed” and becomes the last-closed ledger.
Assuming that the consensus algorithm is successful, and that there is no fork in the network, the last-closed ledger maintained by all nodes in the network will be identical.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
Description::
We begin by defining the components of the Ripple Protocol.
In order to prove correctness, agreement, and utility properties, we first formalize those properties into axioms.
These properties, when grouped together, form the notion of consensus: the state in which nodes in the network reach correct agreement.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
Description::
The strength of a consensus algorithm is usually measured in terms of the fraction of faulty processes it can tolerate.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
xrpbcn.OPEN
Description::
The open ledger is the current operating status of a node (each node maintains its own open ledger).
Transactions initiated by end users of a given server are applied to the open ledger of that server, but transactions are not considered final until they have passed through the consensus process, at which point the open ledger becomes the last-closed ledger.
[https://ripple.com/files/ripple_consensus_whitepaper.pdf]
xrpnet'Exchange-value-unit.Consensus (XRPevuC)
Description::
Ripple XRP
Ripple is a digital currency of Ripple payment network created to support fast and secure financial transactions worldwide. This currency is present uniquely within the system and cannot be mined. It helps avoid counterparty risk and serves as the network’s native asset.
[https://changelly.com/supported-currencies]
===
XRP is the native currency of the Ripple network that only exists within the Ripple system.[82] XRP are currently divisible to 6 decimal places, and the smallest unit is called a drop with 1 million drops equaling 1 XRP.[82] There were 100 billion XRP created at Ripple's inception, with no more allowed to be created according to the protocol's rules.[83] As such, the system was designed so XRP is a scarce asset with decreasing available supply.[83] Not dependent on any third party for redemption, XRP is the only currency in the Ripple network that does not entail counterparty risk, and it is the only native digital asset. The other currencies in the Ripple network are debt instruments (i.e. liabilities), and exist in the form of balances.[2] Users of the Ripple network are not required to use XRP as a store of value or a medium of exchange. Each Ripple account is required, however, to have a small reserve of 20 XRP[84] (US$0.38 as of January 28, 2014[85]). The purpose for this requirement is discussed in the anti-spam section.
XRP distribution
Of the 100 billion created, 20 billion XRP were retained by the creators, who were also the founders of Ripple Labs. The creators gave the remaining 80% of the total to Ripple Labs, with the XRP intended to fund operations.[83] Ripple Labs also had a short-lived 2013 giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid.[86] As of November 30, 2012, 7.2 billion XRP of Ripple Lab's amounts had been distributed,[87] with some of the amount given to charities such as the Computing for Good initiative, which began offering XRP in exchange for time volunteered on research projects.[88] As of March 2015, 67% of Ripple Labs's original 80% was still retained by the company,[83] with Ripple Labs stating that "we will engage in distribution strategies that we expect will result in a stable or strengthening XRP exchange rate against other currencies."[89] The amount of XRP distributed and their movement can be tracked through the Ripple Charts website.[90]
XRP as a bridge currency
One of the specific functions of XRP is as a bridge currency,[73] which can be necessary if no direct exchange is available between two currencies at a specific time,[91] for example when transacting between two rarely traded currency pairs.[81] Within the network’s currency exchange, XRP are traded freely against other currencies, and its market price fluctuates against dollars, euros, yen, bitcoin, etc. Ripple's design focus is as a currency exchange and a distributed-RTGS, as opposed to emphasizing XRP as an alternative currency.[81] In April 2015, Ripple Labs announced that a new feature called autobridging had been added to Ripple, with the intent of making it easier for market makers to transact between rarely traded currency pairs. The feature is also intended to expose more of the network to liquidity and better FX rates.[92]
XRP as an anti-spam measure
When a user conducts a financial transaction in a non-native currency, Ripple charges a transaction fee. The purpose of the fees is to protect against network flooding by making the attacks too expensive for hackers. If Ripple were completely free to access, adversaries could broadcast large amounts of "ledger spam" (i.e. fake accounts) and "transaction spam" (i.e. fake transactions) in an attempt to overload the network. This could cause the size of the ledger to become unmanageable and interfere with the network’s ability to quickly settle legitimate transactions. Thus, to engage in trade, each Ripple account is required to have a small reserve of 20 XRP,[84] (US$0.38 as of January 28, 2014[85]), and a transaction fee starting at .00001 XRP (US$.0000002 as of January 28, 2014[85]) must be spent for each trade. This transaction fee is not collected by anyone; the XRP is destroyed and ceases to exist.[93] The transaction fee rises if the user posts trades at an enormous rate (many thousands per minute), and resettles after a period of inactivity.[58]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
Name::
* cpt.mnyRipple,
* cpt.mnyXrp,
* cpt.ripple-evuC,
* cpt.xrpevuC,
xrpevuC.AGGREGATE
{time.2021forcast}:
If market conditions permit, we expect our company to hold approximately 50 billion XRP by the end of 2021. This schedule is indicative and discretionary.
[https://ripple.com/xrp-portal/ {2017-01-28}]
{time.2017-01-22}:
TOTAL XRP HELD BY RIPPLE 63,139,536,437
TOTAL XRP HELD BY OTHERS 36,856,524,148*
As of January 22nd, 2017
*Total includes business development agreements that are still pending.
xrpnet'Security
Description::
In May 2011 they began developing a digital currency system in which transactions were verified by consensus among members of the network, rather than by the mining process used by Bitcoin, which relies on blockchain ledgers.[21] This new version of the Ripple system[20] was therefore designed to eliminate Bitcoin's reliance on centralized exchanges, use less electricity than Bitcoin, and perform transactions much more quickly than Bitcoin.
...
To maintain security OpenCoin programmed Ripple to rely on a common ledger that is "managed by a network of independent validating servers that constantly compare their transaction records." Servers could belong to anyone, including banks or market makers.[26]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
xrpnet'Human
Description::
Original author(s) Arthur Britto, David Schwartz, Ryan Fugger
Name::
* cpt.ripple'human,
* cpt.xrpnet'human,
Britto.Arthur:
Arthur Britto, for his work on transaction sets,
McCaleb.Jed:
Jed McCaleb, for the original Ripple Protocol consensus concept,
Schwartz.David:
David Schwartz, for his work on the “failure to agree is agreement to defer” aspect of consensus.
xrpnet'Organization
xrpogn.Ripple-Labs
Description::
For its creation and development of the Ripple protocol (RTXP) and the Ripple payment/exchange network, the Massachusetts Institute of Technology (MIT) recognized Ripple Labs as one of 2014's 50 Smartest Companies in the February 2014 edition of MIT Technology Review.[99]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
Name::
* cpt.Ripple-Labs,
xrpogn'Gateway
Description::
Gateways are the businesses that link the Ripple network to the rest of the world.
By becoming a Ripple gateway, existing online financial services, such as payment systems and digital currency exchange, can gain several advantages:
By enabling its users to send and receive value in Ripple, the business increases its value proposition to users.
By accepting payments from the Ripple network, the business increases the number of ways that users can fund accounts at its business, even internationally.
The business can use Ripple-related services as a new source of revenue.
[https://ripple.com/build/gateway-guide/]
Name::
* cpt.Ripple-gateway,
xrpnet.EVOLUTING
{time.2014.12}:
=== Earthport:
By December Ripple Labs began working with global payments service Earthport, combining Ripple's software with Earthport's payment services system. Earthport's clients include banks such as Bank of America and HSBC, and it operates in 65 countries. The partnership marked the first network usage of the Ripple protocol.[45] In December 2014 alone, the XRP price value rose over 200%, helping Ripple surpass litecoin to become the second biggest crypto-currency, and setting Ripple's market cap at close to half a billion.[46]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2014.07}:
=== CODIUS:
In July 2014, Ripple Labs proposed Codius, a project to develop a new smart contract system that is "programming language agnostic."[42]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2014.early}:
=== Fidor-Bank:
The first bank to use Ripple was Fidor Bank in Munich, which announced the partnership in early 2014. Fidor is an online-only bank based in Germany.[44]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013.10}:
=== ZipZap partnership:
In October 2013, Ripple partnered further with ZipZap, with the relationship called a threat to Western Union in the press.[37]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013-09-26}:
=== Ripple Labs Inc:
On September 26, 2013, OpenCoin Inc. changed its name to Ripple Labs Inc.,[25] with Chris Larsen remaining CEO.[35] On the same day the Ripple reference server and client became free software, released as open source under the terms of the ISC License.[2] Ripple Labs continued as the primary contributors of code to the consensus verification system behind Ripple, which can "integrate with banks’ existing networks."[36]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2013-07-01}:
=== XRP-II:
On July 1, 2013, XRP Fund II, LLC (now called simply XRP II)[31] was incorporated as a wholly owned subsidiary of OpenCoin, and headquartered in South Carolina.[31]
The following day, Ripple Labs announced its linking of the Bitcoin and Ripple protocols via the Bitcoin Bridge. The Bitcoin Bridge allows Ripple users to send a payment in any currency to a Bitcoin address
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2012.09}:
=== OpenCoin:
This led to the conception of a new system by Jed McCaleb of eDonkey network,[23] which was designed and built by Arthur Britto and David Schwartz.[24] In May 2011 they began developing a digital currency system in which transactions were verified by consensus among members of the network, rather than by the mining process used by Bitcoin, which relies on blockchain ledgers.[21] This new version of the Ripple system[20] was therefore designed to eliminate Bitcoin's reliance on centralized exchanges, use less electricity than Bitcoin, and perform transactions much more quickly than Bitcoin.[20] Chris Larsen,[21] who had previously founded the lending services companies E-Loan and Prosper, joined the team in August 2012,[23] and together McCaleb and Larsen approached Ryan Fugger with their digital currency idea. After discussions with long-standing members of the Ripple community, Fugger handed over the reins.[21] In September 2012 the team co-founded the corporation OpenCoin,[21] or OpenCoin Inc.[23][25]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
{time.2004}:
=== RipplePay:
The predecessor to the Ripple payment protocol, Ripplepay, was first developed in 2004 by Ryan Fugger,[18][19] a web developer in Vancouver, British Columbia.[20] Fugger conceived of the idea after working on a local exchange trading system in Vancouver, and his intent was to create a monetary system that was decentralized and could effectively allow individuals and communities to create their own money. Fugger's first iteration of this system, RipplePay.com,[21] debuted in 2005 as a financial service to provide secure payment options to members of an online community via a global network.[20][22]
[https://en.wikipedia.org/wiki/Ripple_%28payment_protocol%29]
bcnnet.time.Litecoin (LTCnet {2011-10-07})
Description::
Litecoin is a peer-to-peer Internet currency that enables instant, near-zero cost payments to anyone in the world.
Litecoin is an open source, global payment network that is fully decentralized without any central authorities.
Mathematics secures the network and empowers individuals to control their own finances.
Litecoin features faster transaction confirmation times and improved storage efficiency than the leading math-based currency.
With substantial industry support, trade volume and liquidity, Litecoin is a proven medium of commerce complementary to Bitcoin.
[https://litecoin.org/]
Name::
* cpt.litecoin-network,
* cpt.ltcnet,
ltcnet'Exchange-value-unit.Consensus (LTCevuC)
Cpt-created: 2013-08-24,
Description::
Litecoin is a peer-to-peer Internet currency that enables instant payments to anyone in the world. It is based on the Bitcoin protocol but differs from Bitcoin in that it can be efficiently mined with consumer-grade hardware. Litecoin provides faster transaction confirmations (2.5 minutes on average) and uses a memory-hard, scrypt-based mining proof-of-work algorithm to target the regular computers with GPUs most people already have. The Litecoin network is scheduled to produce 84 million currency units. One of the aims of Litecoin was to provide a mining algorithm that could run at the same time, on the same hardware used to mine Bitcoins. With the rise of specialized ASICs for Bitcoin, Litecoin continues to satisfy these goals. It is unlikely for ASIC mining to be developed for Litecoin until the currency becomes more widely used.
[https://changelly.com/supported-currencies]
===
Litecoin (sign: L; code: LTC) is a peer-to-peer cryptocurrency and open source software project released under the MIT/X11 license.[1] Inspired by and technically nearly identical to Bitcoin (BTC),[2] Litecoin creation and transfer is based on an open source encryption protocol and is not managed by any central authority.[1][3] Litecoin is intended by its developers to improve upon Bitcoin[4] and offers three key differences.[5][6]
Each Litecoin is subdivided into 100,000,000 smaller units, defined by eight decimal places.
Central bank None. The Litecoin peer-to-peer network regulates and distributes through consensus in protocol.
Date of introduction 7 October 2011
User(s) International
Inflation Limited release (geometric series, rate halves every 4 years reaching a final total of 84 million LTC)
Subunit
0.001 mLTC (millicoin)
0.000001 µLTC (microcoin)
0.00000001 Smallest unit
Symbol L
Nickname LTC
Plural Litecoin, litecoins
[http://en.wikipedia.org/wiki/Litecoin]
===
Το Litecoin γεννήθηκε το 2011 (2009 το Bitcoin), από έναν απόφοιτο του ΜΙΤ και πρώην εργαζόμενο της Google – θεωρείται δε ως το «ασήμι» της αγοράς, εάν θεωρηθεί ως ο «χρυσός» το Bitcoin. Συνολικά υπολογίζεται να τοποθετηθούν στην αγορά 21 εκ. Bitcoins έως το 2040, καθώς επίσης 84 εκ. Litecoins – ενώ οι συναλλαγές με το δεύτερο είναι κατά πολύ γρηγορότερες (2,5 λεπτά της ώρας), από ότι με το πρώτο (10 λεπτά).
[http://www.analyst.gr/2013/12/02/4959/]
Name::
* cpt.litecoin-consensus-exval-token, {2017-03-31}
* cpt.LTC-evuC,
* cpt.LTC-token,
* cpt.ltccevt, {2017-03-31}
* cpt.Litecoin,
* cpt.bcnevt.litecoin,
* cpt.mnyLitecoin,
* cpt.mnyLtc,
* cpt.mnyLitecoin,
* cpt.mnyLTC,
bcnnet.time.Namecoin (NMCnet {2011-04-17})
Description::
Namecoin is an experimental open-source technology which improves decentralization, security, censorship resistance, privacy, and speed of certain components of the Internet infrastructure such as DNS and identities.
(For the technically minded, Namecoin is a key/value pair registration and transfer system based on the Bitcoin technology.)
Bitcoin frees money – Namecoin frees DNS, identities, and other technologies.
[https://namecoin.org/]
Name::
* cpt.namecoin-network,
* cpt.nmcnet,
nmcnet'Blockchain (nmcbcn)
nmcnet'Concensus-evt (NMCevuC)
Cpt-created: 2013-08-24,
Description::
Namecoin (NMC)
$0.827300 (-0.32%)
0.00069793 BTC (-1.30%)
Rank 48
Mineable Currency
Market Cap
$12,191,424
10,285 BTC
Volume (24h)
$124,627
105.14 BTC
Circulating Supply
14,736,400 NMC
[https://coinmarketcap.com/currencies/namecoin/ {2017-04-15}]
===
Namecoin (sign: N; code: NMC) is a cryptocurrency which also acts as an alternative, decentralized DNS, which would avoid domain name censorship by making a new top level domain outside of ICANN control, and in turn, make internet censorship much more difficult, as well as reduce downages.[3][4][5][1][2][6][7][8][9]
Namecoin currently uses the .bit domain, and as of July 2013, 78549 .bit domains have been registered.[1][2][7][10][11] bit domains are not currently awarded, hence to resolve domain names, one must have either a copy of the Namecoin "blockchain" (a decentralized ledger storing all transactions and domains), or access to a public DNS server that participates in the Namecoin system.[1][12]
There is a limit of 21 million Namecoins, and each Namecoin is divisible down to 8 decimal places.[1] As of July 2013, one Namecoin costs around 0.45 USD, making Namecoin roughly level with PPCoin as the third largest cryptocurrency, with a money supply valued at around 2.9 million USD.[13][14][15]
[http://en.wikipedia.org/wiki/Namecoin]
===
Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
[https://github.com/ethereum/wiki/wiki/White-Paper]
===
Namecoin:
An altcoin designed to provide an alternative to the traditional domain name system (DNS).
Users can register .bit domains, accessible via proxy servers, by paying with namecoins.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.Namecoin,
* cpt.Namecoin-token,
* cpt.NMC-evuC,
* cpt.NMC-token,
* cpt.nmccevt,
bcnnet.time.Bitcoin (BTCnet {2009-01-03})
Cpt-created: {2012-05-27}
Generic::
* blockchain-network,
btcnet'DESCRIPTON
* btcdefinition,
Description::
Bitcoin
Refers to a protocol, network or a unit of currency.
As a protocol, Bitcoin is a set of rules that every client must follow to accept transactions and have its own transactions accepted by other clients. Also includes a message protocol that allows nodes to connect to each other and exchange transactions and blocks.
As a network, Bitcoin is all the computers that follow the same rules and exchange transactions and blocks between each other.
As a unit, one Bitcoin (BTC, XBT) is defined as 100 million satoshis, the smallest units available in the current transaction format. Bitcoin is not capitalized when speaking about the amount: "I received 0.4 bitcoins."
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#bitcoin]
Description::
Bitcoin represents the culmination of decades of research in cryptography and distributed systems and includes four key innovations brought together in a unique and powerful combination.
Bitcoin consists of:
A decentralized peer-to-peer network (the bitcoin protocol)
A public transaction ledger (the blockchain)
A decentralized mathematical and deterministic currency issuance (distributed mining)
A decentralized transaction verification system (transaction script)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Description::
Bitcoin is two things which share a name: 1) a payment system and 2) a currency. You use the Bitcoin payment system to send bitcoins as currency from one account holder to another. The transfer is instantaneous, carries no necessary fee, works anywhere in the world, and is private.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] 2012-05-27,
Description::
Connect to the world’s first borderless payment network - Bitcoin.
[https://bitpay.com/tour]
Description::
Bitcoin is a decentralized P2P electronic cash system without a central server or trusted parties. Users hold the crypto keys to their own money and transact directly with each other, with the help of the network to check for double-spending.
[http://sourceforge.net/projects/bitcoin/] 2013-03-18
Description::
Just like the Internet, Bitcoin is not a corporation and does not have a CEO.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
Description::
Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is suported with Bitcoind/Bitcoin-Qt v0.7.
[https://en.bitcoin.it/wiki/Network]
Description::
A decentralized peer-to-peer network (the bitcoin protocol)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Description::
Behind the scenes, bitcoin is also the name of the protocol, a network, and a distributed computing innovation.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
btcnet'NAME
Name::
* cpt.bitcoin-ecosystem,
* cpt.bitcoin-Electronic-Cash-System, [Nakamoto 2008]
* cpt.bitcoin-financial-network,
* cpt.bitcoin-network,
* cpt.bitcoin-payment-system,
* cpt.Bitcoin-Peer-to-Peer-Electronic-Cash-System, [Nakamoto]
* cpt.bitcoin-peer-to-peer-network,
* cpt.bitcoin-system,
* cpt.bitcoinland,
* cpt.btcn,
* cpt.btcnet,
* cpt.btcnetwork,
* cpt.btcStm, {2015-08-10}
* cpt.netBtc, {2016-03-25}
* cpt.stmBtc, {2015-08-10}
======
* Bitcoin is the first financial network that exhibits the characteristics of neutrality.
[https://www.cryptocoinsnews.com/bitcoin-evangelist-antonopoulos-in-barcelona-thoughts-on-the-future-of-money/]
btcnet'Attribute.INDEXED (btcatt)
Name::
* cpt.btcattribute.indexed,
* cpt.btcglossary,
* cpt.btcvocabulary,
Specific::
* https://en.bitcoin.it/wiki/Vocabulary,
* Oleg Andreev: https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md,
===
* btcBare_multisig
* btcChild_private_key
* btcChild_public_key
* btcCompressed_public_key
* btcConfirmation_score
* btcData_carrier_transaction
* btcData_pushing_op_code
* btcDNS_seed
* btcEscrow_contract
* btcExtended_key
* btcFree_transaction
* btcHardened_extended_key
* btcHeader
* btcHeader_chain
* btcHeaders_first_sync
* btcHigh_priority_transaction
* btcIBD
* btcInitial_block_download
* btcInternal_byte_order
* btcInventory
* btcMajority_attack
* btcMaster_chain_code
* btcMaster_private_key
* btcMerkle_block
* btcMerkle_root
* btcMessage_header
* btcMiners_fee
* btcMinimum_relay_fee
* btcMultisig
* btcNetwork_magic
* btcnLockTime
* btcNon_data_pushing_op_code
* btcNull_data_transaction
* btcOP_RETURN_transaction
* btcOrphan_block
* btcOutpoint
* btcP2P_protocol_messages
* btcP2PKH_address
* btcP2PKH_output
* btcP2SH_address
* btcP2SH_multisig
* btcP2SH_output
* btcParent_key
* btcParent_private_key
* btcParent_public_key
* btcPayment_protocol
* btcPayment_request
* btcPOWPrivate_extended_keyPrivate_key
* btcPublic_extended_key
* btcBitcoin_Core_RPCs
* btcRaw_transaction
* btcRedeem_script
* btcRedeemScript
* btcRegression_test_mode
* btcRegtest
* btcRelay_fee
* btcRPC_byte_order
* btcSatoshis
* btcScriptPubKey
* btcSig
* btcSequence_number
* btcSerialized_block
* btcSerialized_transaction
* btcSighash
* btcSIGHASH_ALL
* btcSIGHASH_ANYONECANPAY
* btcSIGHASH_NONE
* btcSIGHASH_SINGLE
* btcSignature
* btcSignature_hash
* btcStale_block
* btcStart_string
* btcTransaction_malleability
* btcTransaction_mutability
* btcTxid
* btcWallet_Import_Format
* btcWatch_only_address
* btcWIF
btcatt.Oleg-Adreev
Description::
Glossary is made by Oleg Andreev (oleganza@gmail.com).
Twitter: @oleganza.
Send your thanks here: 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG.
This glossary is released under WTFPL.
Do what you want with it, but I would appreciate if you give full credit in case you republish it.
Please report any mistakes or create pull requests on Github.
Contributors will be listed here. Thanks!
Some unusual terms are frequently used in Bitcoin documentation and discussions like *tx* or *coinbase*.
Or words like *scriptPubKey* were badly chosen and now deserve some extra explanation.
This glossary will help you understand exact meaning of all Bitcoin-related terms.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcglossary.Oleg-Adreev,
* cpt.btcOleg-Adreev-glossary,
btcASIC:
Stands for "application-specific integrated circuit".
In other words, a chip designed to perform a narrow set of tasks (compared to CPU or GPU that perform a wide range of functions).
ASIC typically refers to specialized *mining* chips or the whole machines built on these chips.
Some ASIC manufacturers: Avalon, ASICMiner, Butterfly Labs (BFL) and Cointerra.
btcASICMiner:
A Chinese manufacturer that makes custom mining hardware, sells shares for bitcoins, pays dividends from on-site mining and also ships actual hardware to customers.
btcBitcoin_ruby:
A Bitcoin utilities library in Ruby by Julian Langschaedel.
Used in production on *Coinbase.com*.
btcCasascious_Coins:
Physical collectible coins produced by Mike Caldwell. Each coin contains a *private key* under a tamper-evident hologram. The name "Casascius" is formed from a phrase "call a spade a spade", as a response to a name of Bitcoin itself.
btcCoin:
An informal term that means either 1 bitcoin, or an unspent *transaction output* that can be *spent*.
btcCoinbase.com:
US-based Bitcoin/USD exchange and web wallet service.
btcKey:
Could mean an ECDSA public or private key, or AES symmetric encryption key.
AES is not used in the protocol itself (only to encrypt the ECDSA keys and other sensitive data), so usually the word *key* means an ECDSA key.
When talking about *keys*, people usually mean private keys as public key can always be derived from a private one.
See also Private Key and *Public Key*.
btcMain_Chain:
A part of the blockchain which a node considers the most difficult (see difficulty).
All nodes store all valid blocks, including orphans and recompute the total difficulty when receiving another block.
If the newly arrived block or blocks do not extend existing main chain, but create another one from some previous block, it is called *reorganization*.
btcMiner:
A person, a software or a hardware that performs mining.
btcSecret_key:
Either the *Private Key* or an encryption key used in encrypted *wallets*.
Bitcoin protocol does not use encryption anywhere, so *secret key* typically means a *private key* used for signing transactions.
Incorrect peer-to-peer messages (like sending invalid transactions) may be considered a denial of service attack (see *DoS*).
Valid transactions sending very tiny amounts and/or having low *mining fees* are called Dust by some people.
The protocol itself does not define which transactions are not worth relaying or mining, it's a decision of every individual node.
Any valid transaction in the blockchain must be accepted by the node if it wishes to accept the remaining blocks, so transaction censorship only means increased confirmation delays.
Individual payees may also blacklist certain addresses (refuse to accept payments from some addresses), but that's too easy to work around using *mixing*.
VarInt:
This term may cause confusion as it means different formats in different Bitcoin implementations. See *CompactSize* for details.
btcatt.Coindesk
Description::
CoinDesk is the world leader in news and information on digital currencies such as bitcoin, and its underlying technology – the blockchain.
We cover news and analysis on the trends, price movements, technologies, companies and people in the bitcoin and digital currency world.
[http://www.coindesk.com/about-us/]
Name::
* cpt.btcglossary.Coindesk,
* cpt.btcCoindesk-glossary,
AddressWpg::
[http://www.coindesk.com/information/bitcoin-glossary/]
btcAML:
Anti-Money Laundering techniques are used to stop people converting illegally obtained funds, to appear as though they have been earned legally.
AML mechanisms can be legal or technical in nature.
Regulators frequently apply AML techniques to bitcoin exchanges.
btcASIC:
An Application Specific Integrated Circuit is a silicon chip specifically designed to do a single task.
In the case of bitcoin, they are designed to process SHA-256 hashing problems to mine new bitcoins.
btcASIC_miner:
A piece of equipment containing an ASIC chip, configured to mine for bitcoins.
They can come in the form of boards that plug into a backplane, devices with a USB connector, or standalone devices including all of the necessary software, that connect to a network via a wireless link or ethernet cable.
btcBitcoin_Investment_Trust:
This private, open-ended trust invests exclusively in bitcoins and uses a state-of-the-art protocol to store them safely on behalf of its shareholders.
It provides a way for people to invest in bitcoin without having to purchase and safely store the digital currency themselves.
btcBitcoin_Sentiment_Index, btcBSI:
The Bitcoin Sentiment Index is a measure of whether individuals feel the digital currency's prospects are increasing or decreasing on any given day, and is powered by data collected by Qriously.
btcBitcoin_Market_Potential_Index, btcBMPI:
The Bitcoin Market Potential Index (BMPI) uses a data set to rank the potential utility of bitcoin across 177 countries.
It attempts to show which markets have the greatest potential for bitcoin adoption.
btcBitcoin_Price_Index, btcBPI:
The CoinDesk Bitcoin Price Index represents an average of bitcoin prices across leading global exchanges that meet criteria specified by the BPI.
There is also an API for developers to use.
btcBitPay:
A payment processor for bitcoins, which works with merchants, enabling them to take bitcoins as payment.
btcButtonwood:
A project founded by bitcoin enthusiast Josh Rossi, to form a public outcry bitcoin exchange in New York's Union Square.
Named after the Buttonwood agreement, which formed the basis for the New York Stock Exchange in 1792.
btcCircle:
Circle is an exchange and wallet service, offering users worldwide the chance to store, send, receive and exchange bitcoins.
btcCoin_age:
The age of a coin, defined as the currency amount multiplied by the holding period.
btcDDoS:
A distributed denial of service attack uses large numbers of computers under an attacker’s control to drain the resources of a central target.
They often send small amounts of network traffic across the Internet to tie up computing and bandwidth resources at the target, which prevents it from providing services to legitimate users.
Bitcoin exchanges have sometimes been hit with DDoS attacks.
btcDeflation:
The reduction of prices in an economy over time.
It happens when the supply of a good or service increases faster than the supply of money, or when the supply of money is finite, and decreases.
This leads to more goods or services per unit of currency, meaning that less currency is needed to purchase them.
This carries some downsides.
When people expect prices to fall, it causes them to stop spending and hoard money, in the hope that their money will go further later.
This can depress an economy.
btcEscrow:
The act of holding funds or assets in a third-party account to protect them during an asynchronous transaction.
If Bob wants to send money to Alice in exchange for a file, but they cannot conduct the exchange in person, then how can they trust each other to send the money and file to each other at the same time?
Instead, Bob sends the money to Eve, a trusted party who holds the funds until Bob confirms that he has received the file from Alice.
She then sends Alice the money.
btcFaucent:
A technique used when first launching an altcoin.
A set number of coins are pre-mined, and given away for free, to encourage people to take interest in the coin and begin mining it themselves.
btcFiat_currency:
A currency, conjured out of thin air, which only has value because people say it does.
Constantly under close scrutiny by regulators due to its known application in money laundering and terrorist activities.
Not to be confused with bitcoin.
btcFinCEN:
The Financial Crimes Enforcement Network, an agency within the US Treasury Department.
FinCEN has thus far been the main organization to impose regulations on exchanges trading in bitcoin.
btcFPGA:
A Field Programmable Gate Array is a processing chip that can be configured with custom functions after it has been fabricated.
Think of it as a blank silicon slate on which instructions can be written.
Because FPGAs can be produced en masse and configured after fabrication, manufacturers benefit from economies of scale, making them cheaper than ASIC chips.
However, they are usually far slower.
btcGPU:
Graphical Processing Unit.
A silicon chip specifically designed for the complex mathematical calculations needed to render millions of polygons in modern computer game graphics.
They are also well suited to the cryptographic calculations needed in cryptocurrency mining.
btcInflation:
When the value of money drops over time, causing prices for goods to increase.
The result is a drop in purchasing power.
Effects include less motivation to hoard money, and more motivation to spend it quickly while the prices of goods are still low.
btcKYC:
Know Your Client/Customer rules force financial institutions to vet the people they are doing business with, ensuring that they are legitimate.
btcLeverage, btcMargin_requirement:
In foreign currency trading, leverage multiplies the real funds in your account by a given factor, enabling you to make trades that result in significant profit.
By giving leverage to a trader, the trading exchange is effectively lending them money, in the hope that it will earn back more than it loaned in commission.
Leverage is also known as a margin requirement.
btcLiberty_Reserve:
A centralized digital currency payment processor based in Costa Rica.
It was shut down by the US government, after it was found guilty of money laundering.
btcLiquidity:
The ability to buy and sell an asset easily, with pricing that stays roughly similar between trades.
A suitably large community of buyers and sellers is important for liquidity.
The result of an illiquid market is price volatility, and the inability to easily determine the value of an asset.
btcMargin_call:
The act of calling in a margin requirement.
An exchange will issue a margin call when it feels that a trader does not have sufficient funds to cover a leveraged trading position.
btcMarket_order:
An instruction given to an exchange, asking it to buy or sell an asset at the going market rate.
In a bitcoin exchange, you would place a market order if you simply wanted to buy or sell bitcoins immediately, rather than holding them until a set market condition is triggered to try and make a profit.
btcP2P:
Peer-to-peer.
Decentralized interactions that happen between at least two parties in a highly interconnected network.
An alternative system to a 'hub-and-spoke' arrangement, in which all participants in a transaction deal with each other through a single mediation point.
btcPrimecoin
Developed by Sunny King, Primecoin uses a proof of work system to calculate prime numbers.
btcPSP:
Payment Service Provider.
The PSP offers payment processing services for merchants who wish to accept payments online.
btcPump_and_dump:
Inflating the value of a financial asset that has been produced or acquired cheaply, using aggressive publicity and often misleading statements.
The publicity causes others to acquire the asset, forcing up its value.
When the value is high enough, the perpetrator sells their assets, cashing in and flooding the market, which causes the value to crash.
btcSilk_Road:
An underground online marketplace, generally used for illicit purchases, often with cryptocurrencies such as bitcoin.
Silk Road was shut down in early October 2013 by the FBI after owner Ross Ulbricht was arrested.
Ulbricht was later convicted on money laundering and drug distribution charges.
btcSEPA:
The Single European Payments Area.
A payment integration agreement within the European Union, designed to make it easier to transfer funds between different banks and nations in euros.
btcTOR:
An anonymous routing protocol, used by people wanting to hide their identity online.
btcVolatility:
The measurement of price movements over time for a traded financial asset (including bitcoin).
btcWire_transfer:
Electronically transferring money from one person to another.
Commonly used to send and retrieve fiat currency from bitcoin exchanges.
btcZerocoin:
A protocol designed to make cryptocurrency transactions truly anonymous.
btcnet'Protocol (btcprl)
Name::
* cpt.bitcoin-protocol,
* cpt.btcprotocol,
* cpt.Bitcoin-message-protocol,
* cpt.bitcoin-protocol,
* cpt.btcprl,
NameGreek::
* ενν.μπιτκόιν-πρωτόκολλο,
* ενν.πρωτόκολλο-μπιτκόιν,
Generic::
* blockchain-protocol,
btcprl'White-paper (btcwpr {2008})
Description::
The bitcoin whitepaper was written by ‘Satoshi Nakamoto’ and posted to a Cryptography Mailing list in 2008.
The paper describes the bitcoin protocol in detail, and is well worth a read.
Satoshi Nakamoto followed this by releasing the bitcoin code in 2009.
...
In November 2008, a paper, authored (probably pseudonymously) by Satoshi Nakamoto, was posted on the newly created Bitcoin.org website with the title ‘Bitcoin: A Peer-to-Peer Electronic Cash System’.
The eight-page document described methods of using a peer-to-peer network to generate "a system for electronic transactions without relying on trust" and laid down the working principles of the cryptocurrency.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-whitepaper,
* cpt.btcwpr,
NameGreek::
* ενν.λευκή-βίβλος-του-μπτικόιν,
AddressWpg::
* https://bitcoin.org/bitcoin.pdf,
* http://www.cryptovest.co.uk/resources/Bitcoin%20paper%20Original.pdf,
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto
www.bitcoin.org
{2008-10-31}
Abstract
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing chain of hashbased proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.
The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.
As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers.
The network itself requires minimal structure.
Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
1. Introduction
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.
While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes.
The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services.
With the possibility of reversal, the need for trust spreads.
Merchants must be wary of their customers, hassling them for more information than they would otherwise need.
A certain percentage of fraud is accepted as unavoidable.
These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.
Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.
2. Transactions
We define an electronic coin as a chain of digital signatures.
Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.
A payee can verify the signatures to verify the chain of ownership.
The problem of course is the payee can't verify that one of the owners did not double-spend the coin.
A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending.
After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
We need a way for the payee to know that the previous owners did not sign any earlier transactions.
For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.
The only way to confirm the absence of a transaction is to be aware of all transactions.
In the mint based model, the mint was aware of all transactions and decided which arrived first.
To accomplish this without a trusted party, transactions must be publicly announced[01], and we need a system for participants to agree on a single history of the order in which they were received.
The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
3. Timestamp Server
The solution we propose begins with a timestamp server.
A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post[2-5].
The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.
Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
4. Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash[06], rather than newspaper or Usenet posts.
The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.
The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.
Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work.
As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
The proof-of-work also solves the problem of determining representation in majority decision making.
If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs.
Proof-of-work is essentially one-CPU-one-vote.
The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.
If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.
To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.
We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour.
If they're generated too fast, the difficulty increases.
5. Network
The steps to run the network are as follows:
1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on extending it.
If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.
In that case, they work on the first one they received, but save the other branch in case it becomes longer.
The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
New transaction broadcasts do not necessarily need to reach all nodes.
As long as they reach many nodes, they will get into a block before long.
Block broadcasts are also tolerant of dropped messages.
If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.
6. Incentive
By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.
This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation.
In our case, it is CPU time and electricity that is expended.
The incentive can also be funded with transaction fees.
If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
The incentive may help encourage nodes to stay honest.
If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins.
He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.
7. Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.
To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree.
The interior hashes do not need to be stored.
A block header with no transactions would be about 80 bytes.
If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.
With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
8. Simplified Payment Verification
It is possible to verify payments without running a full network node.
A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.
While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.
Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
9. Combining and Splitting Value
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer.
To allow value to be split and combined, transactions contain multiple inputs and outputs.
Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here.
There is never the need to extract a complete standalone copy of a transaction's history.
10. Privacy
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.
The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.
The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.
This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.
As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.
Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.
The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.
Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker.
Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them.
An attacker can only try to change one of his own transactions to take back money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.
The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem.
Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven.
We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[8]:
Given our assumption that p>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.
With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction.
We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed.
The receiver will be alerted when that happens, but the sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before signing.
This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment.
Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.
Running some results, we can see the probability drop off exponentially with z.
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
12. Conclusion
We have proposed a system for electronic transactions without relying on trust.
We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending.
To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.
The network is robust in its unstructured simplicity.
Nodes work all at once with little coordination.
They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis.
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone.
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.
Any needed rules and incentives can be enforced with this consensus mechanism.
References
[1]. W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
[2]. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.
[3]. S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
[4]. D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital timestamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
[5]. S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.
[6]. A. Back, "Hashcash - a denial of service countermeasure," http://www.hashcash.org/papers/hashcash.pdf, 2002.
[7]. R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
[8]. W. Feller, "An introduction to probability theory and its applications," 1957.
btcprl'Implementation
btcprl'Reference-implementation (link)
btcprl'BIP (Bitcoin-Improvement-Proposals | btcbip)
Description::
People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: economic majority).
[https://github.com/bitcoin/bips#readme]
===
Bitcoin Improvement Proposals.
RFC-like documents modeled after PEPs (Python Enhancement Proposals) discussing different aspects of the protocol and software.
Most interesting BIPs describe *hard fork* changes in the core protocol that require supermajority of Bitcoin users (or, in some cases, only miners) to agree on the change and accept it in an organized manner.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.BIP,
* cpt.Bitcoin-Improvement-Proposals,
* cpt.btcBIP,
* cpt.btcBitcoin-Improvement-Proposals,
* cpt.btcprl'BIP,
* cpt.btcnet'BIP,
NameGreek::
* ενν.Προτάσεις-Βελτίωσης-Bitcoin,
AddressWpg::
* https://github.com/bitcoin/bips#readme,
btcbip'Attribute
Specific::
* Number
* Layer
* Title
* Owner
* Type
* Status
ptcprl'SegWit
Description::
Segwit is a proposal to allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the rest of the data in a transaction, and to allow miners to place those witnesses outside of the traditional block structure.
[https://bitcoincore.org/en/2016/06/24/segwit-next-steps/]
Name::
* cpt.btcnet'SegWit,
* cpt.segwit,
btcprl'Lightning-network
Description::
A quick overview of what the Lightning network is
- A payment layer that makes use of the script language in Bitcoin
- A way to send and spend Bitcoin across nodes instantly and irreversibly
- A layer that builds on the security of the underlying protocol, Bitcoin
[https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d]
===
The lightning network is a highly anticipated second-layer protocol to be rolled out on top of Bitcoin’s blockchain. Cleverly utilizing Bitcoin’s programmable elements (like multisignature and time-locks), lightning users should be able to make a virtually unlimited number of off-chain transactions with instant confirmations and at low cost. This should boost Bitcoin’s micropayment-ability, overall scalability and even privacy.
[https://bitcoinmagazine.com/articles/lightning-network-one-step-closer-to-reality-as-lightning-labs-announces-alpha-release-1484333955]
===
Announcing the Thunder Network Alpha Release
Peter · May 16, 2016 · Leave a Reply
At Blockchain, we’re on a mission to create an open, accessible, and equitable financial future. Since our inception, we have focused on building products that make it easy for everyday people to use bitcoin to store and transfer value all over the world. We make Bitcoin usable and useful. We’ve been able to do that because we develop with a user-focused mandate.
A faster, cheaper, and more functional network would deliver real value to our users, so we were excited by the growth of research into payment channel technology on the bitcoin network and innovative uses of this technology. We were particularly interested in the idea of using smart contracts to build what are basically super-charged payments networks, as outlined in a white paper by the lightning.network team. Last year, we hired a talented engineer, Mats Jerratsch, who had been pioneering innovation in this vertical to work with our engineering team and lead research and development on a network based around these ideas.
Lightning networks have been purely conceptual, research based, and only in test nets and labs – until now. Today, we release the alpha version of our Thunder Network, the first usable implementation of the Lightning network for off chain bitcoin payments that settles back to the main bitcoin blockchain.
We used it internally a few days ago. Click here to learn all about Transaction 0 between Mats and me.
Thunder has the potential to facilitate secure, trustless, and instant payments. It has the ability to unleash the power of microtransactions, to allow the bitcoin network to handle heavy loads, and to increase user privacy. In this Alpha version, we prove that it can be done. From a feature perspective, there is both a node and a wallet (with GUI) present. Even more importantly:
Settlement to the bitcoin blockchain
Scale: According to our tests so far, we can achieve better-than-Visa scale (100,000 TPS) with only a few thousand nodes on the network
Extremely cheap payments: fees will develop naturally, due to the free market in an open and permissionless network and will fundamentally be lower than on-chain payments
Encryption and Authentication: All communications between all nodes and wallets are encrypted using AES-CTR and take place only after completing authentication.
Seed Peers and automatically provide them with network topology using a basic gossip protocol similar to the one used in the bitcoin network, which allows complex routes over multiple hops
Payment Channels can be opened and closed at will, with transactions settling onto the bitcoin blockchain
Payment Debate: Across the route each hop will renegotiate a new status with the next hop, as a payment makes its way through the network with cryptography in place to prevent fraud
Relaying Payments: TN will relay payments over multiple nodes in the network automatically, using encrypted routing. No one knows who made a payment, allowing for more privacy
Settle payments automatically, no manual intervention needed. The settlement will ripple back through the network to provide proof-of-payment
Instant Payments that are irrevocable the moment you see them
Until both CSV and SegWit are implemented on the bitcoin blockchain, transactions are not enforceable at the bitcoin protocol level. So, the current Thunder prototype is best suited for transactions among a trusted network of users. Try this amongst your dev team or amongst your trusted internet friends, but don’t use it for real payments. Remember: this is alpha testing software.
So why release this now? We believe it is critical to get something in the hands of users as soon as possible to gain feedback that will enable us to be ready when the network is. So review it, test it out, open an issue on GitHub, or send us an email. If you want to work on tech like this full time, head here and apply to join our team.
We encourage you to find out more at:
www.blockchain.com/thunder
https://github.com/blockchain/thunder
[https://blog.blockchain.com/2016/05/16/announcing-the-thunder-network-alpha-release/]
Name::
* cpt.bitcoin-lightning-network,
* cpt.bitcoin-thunder-network,
* cpt.btcnet'Lightning-network,
* cpt.lightning-network-of-bitcoin,
AddressWpg::
* {2017-03-26} https://medium.com/@btc_coach/lightning-network-in-action-b18a035c955d#.t0xv3e8mk,
* https://lightning.network/
* https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70#.gtx36kylc,
btcnet'Node (btcnod)
Description::
Node:
A computer connected to the bitcoin network using a client that relays transactions to others (see client).
If you'd like to run a bitcoin node, then bitcoin.org offers a comprehensive guide.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Node, or client, is a computer on the network that speaks Bitcoin message protocol (exchanging transactions and blocks).
There are *full nodes* that are capable of validating the entire blockchain and *lightweight nodes*, with reduced functionality.
Wallet applications that speak to a server are not considered nodes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
A computer connected to the bitcoin network using a client that relays transactions to others (see client). If you'd like to run a bitcoin node, then bitcoin.org offers a comprehensive guide.
[http://www.coindesk.com/information/bitcoin-glossary/#node]
===
A system running a Bitcoin client is called a Bitcoin node.
The Bitcoin network's function is to relay two types of messages: Transactions and blocks.
A transaction is a digitally signed instruction to transfer money between addresses, as described earlier.
A block is: A set of transactions.Apr 7, 2013
Bitcoin part 10: The network « self-evident
[https://self-evident.org/?p=999]
Name::
* cpt.btcnod,
* cpt.btcnode,
* cpt.bitcoin-node,
* cpt.btcnet'node,
NameGreek::
* ενν.κόμβος-μπιτκόιν,
btcnod'Consensus
Description::
When several nodes (usually most nodes on the network) all have the same blocks in their locally-validated best block chain.
[https://bitcoin.org/en/glossary/consensus]
Name::
* cpt.btcconsensus,
NameGreek::
* ενν.μπιτκόιν-συναίνεση,
btcnod.FULL
Description::
A node which implements all of Bitcoin protocol and does not require trusting any external service to validate transactions.
It is able to download and validate the entire *blockchain*.
All full nodes implement the same peer-to-peer messaging protocol to exchange transactions and blocks, but that is not a requirement.
A full node may receive and validate data using any protocol and from any source.
However, the highest security is achieved by being able to communicate as fast as possible with as many nodes as possible.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
A full node is defined as a network-attached bitcoin client application, such as the original bitcoin Core (QT) client or an implementation of the bitcoind framework. A full node has the entire, up-to-date set of blockchain files, and also has port 8333 open, so it is set to listen for incoming requests. This list is very specific, and all of these conditions must be met for it to be a useful full node.
[http://bravenewcoin.com/news/the-decline-in-bitcoins-full-nodes/]
===
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
[https://bitcoin.org/en/full-node#what-is-a-full-node]
===
Each full node in the Bitcoin network independently stores a block chain containing only blocks validated by that node.
[https://bitcoin.org/en/developer-guide#block-chain]
===
The Bitcoin network protocol allows full nodes (peers) to collaboratively maintain a peer-to-peer network for block and transaction exchange.
[https://bitcoin.org/en/developer-guide#term-peer]
Name::
* cpt.bitcoin-full-node,
* cpt.btcfull-node,
* cpt.btcpeer,
* cpt.btcfnd,
AddressWpg::
* https://bitcoin.org/en/full-node,
btcnodFul'Bitcoin-Core (link)
btcnodFul'requirements
Description::
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Desktop or laptop hardware running recent versions of Windows, Mac OS X, or Linux.
50 gigabytes of free disk space
2 gigabytes of memory (RAM)
A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second
An unmetered connection, a connection with high upload limits, or a connection you regularly monitor to ensure it doesn’t exceed its upload limits. It’s common for full nodes on high-speed connections to use 200 gigabytes upload or more a month. Download usage is around 20 gigabytes a month, plus around an additional 40 gigabytes the first time you start your node.
6 hours a day that your full node can be left running. (You can do other things with your computer while running a full node.) More hours would be better, and best of all would be if you can run your node continuously.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
[https://bitcoin.org/en/full-node#minimum-requirements]
btcnod.FULL.NO (lightweight)
Description::
Lightweight client
Comparing to a full node, lightweight node does not store the whole blockchain and thus cannot fully verify any transaction.
There are two kinds of lightweight nodes: those fully trusting an external service to determine wallet balance and validity of transactions (e.g. blockchain.info) and the apps implementing Simplified Payment Verification (SPV).
SPV clients do not need to trust any particular service, but are more vulnerable to a 51% attack than full nodes. See Simplified Payment Verification for more info.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#lightweight-client]
===
A protocol known as “simplified payment verification” (SPV) allows for another class of nodes to exist, called “light nodes”, which download the block headers, verify the proof of work on the block headers, and then download only the “branches” associated with transactions that are relevant to them.
This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
[https://leanpub.com/decentralizedapplicationswithethereum/read_sample]
Name::
* cpt.bitcoin-light-node,
* cpt.btcnod.light,
* cpt.btclightweight-client-node,
* cpt.btclightweight-node,
btcnod.HONEST
Name::
* cpt.btchonest-peer,
btcnod.HONEST.NO
Description::
Take note that for both types of broadcasting, mechanisms are in place to punish misbehaving peers who take up bandwidth and computing resources by sending false information. If a peer gets a banscore above the -banscore=<n> threshold, he will be banned for the number of seconds defined by -bantime=<n>, which is 86,400 by default (24 hours).
[https://bitcoin.org/en/developer-guide#misbehaving-nodes]
Name::
* cpt.btchonestNo-peer,
* cpt.btcmalicious-node,
* cpt.btcmisbehaving-node,
* cpt.btcuntrustworthy-peer,
btcnod.MINER
Description::
The bitcoin network is driven by what are called miners, specialized computers that run the bitcoin software. In exchange, the people who run these miners are automatically paid in bitcoin. That’s their immediate incentive. But they also have an interest in expanding the network and keeping it running smoothly. Otherwise, those payments will dry up.
...
As Hearn pointed out, two Chinese operations control about 50 percent of the network’s mining power, and they’re reluctant to adopt the larger block size. “[They] refuse to switch to any competing product, as they perceive doing so as ‘disloyalty’—and they’re terrified of doing anything that might make the news of a ‘split’ and cause investor panic,” he wrote. “They have chosen instead to ignore the problem and hope it goes away.”
[http://www.wired.com/2016/02/the-schism-over-bitcoin-is-how-bitcoin-is-supposed-to-work/]
===
The process of finding a valid block is called mining whereas nodes that participate in that process are called miners.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcminer-node,
* cpt.btcnet'miner,
btcnodMnr'Mining (btcmng)
Description::
Mining infrastructure is the backbone of bitcoin. Anyone who contributes computing power to help process transactions on the network is rewarded with the chance to "mine" bitcoin.
In plain English, in return for helping keep the network up and running, they have the chance of being given a newly created piece of the digital currency.
[https://www.weforum.org/agenda/2016/06/these-photos-show-you-inside-an-icelandic-bitcoin-mine?]
===
Τα bitcoin δημιουργούνται μέσω μιας διαδικασίας που ονομάζεται «εξόρυξη» (mining), η οποία αφορά τον ανταγωνισμό για εύρεση λύσεων σε ένα μαθηματικό πρόβλημα κατά την επεξεργασία των συναλλαγών bitcoin.
Κάθε συμμετέχων στο δίκτυο bitcoin (ο καθένας δηλαδή με τη χρήση μιας συσκευής που τρέχει τη πλήρη στοίβα πρωτοκόλλου bitcoin) μπορεί να λειτουργήσει ως εξορύκτης (miner), χρησιμοποιώντας την επεξεργαστική ισχύ του υπολογιστή του για να επαληθεύει και να καταγράφει τις συναλλαγές.
Κάθε 10 λεπτά, κατά μέσο όρο, είναι σε θέση κάποιος να επικυρώσει τις συναλλαγές των τελευταίων 10 λεπτών και να ανταμειφθεί με ολοκαίνουργια bitcoin.
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
===
A decentralized mathematical and deterministic currency issuance (distributed mining)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Name::
* cpt.bitcoin-mining,
* cpt.btccevt'creating,
* cpt.btccevt'issuance,
* cpt.btccevt'mining,
* cpt.netBtc'currency-issuance,
* cpt.btccevt'mining,
* cpt.btcmining,
* cpt.netBtc'mining,
NameGreek::
* ενν.εξόρυξη-μπιτκόιν,
btcnodMnr'CLOUD-MINING
Name::
* cpt.bitcoin-clound-mining,
* cpt.btcclound-mining,
AddressWpg::
* {2016-07-02} https://cointelegraph.com/news/ hashocean-scam-victims-sign-petitions-to-fbi-hackers-to-reveal-more-scams,
“The website HashOcean.com is off-line and took with them millions of dollars from approximately 700,000 users worldwide. Since there are neither regulating institutions nor reliable sources of information, we have decided to open this channel to all users and supporters of cloud mining - people who believe in a transparent mining process. We created this petition to be able to ask the FBI and other similar institutions to trace those in charge of www.HashOcean.com - Cloud Mining. 700,000 users want their money back and the supporters of Cloud Mining deserve a reliable mining process.
If you lost money with www.HashOcean.com - Cloud Mining or you are simply a cryptocurrency supporter, please help us to raise awareness and get specialist help to trace the people responsible for HashOcean.com. Please sign the petition and forward to as many people as possible in all social medias. Let΄s unite and raise awareness as soon as possible.”
btcnod.SEED
Description::
Seed Nodes
Nodes whose IP addresses are included in the Bitcoin client for use during a new installation when the normal bootstrapping process through IRC wasn't possible.
[https://en.bitcoin.it/wiki/Vocabulary#Seed_Nodes]
Name::
* cpt.bitcoin-seed-node,
* cpt.btcseed-node,
btcnet'Blockchain (btcbcn)
Description::
The blockchain is a record of all transactions that have occured in the Bitcoin system and is shared by every node in it.
Its main purpose is to infer a list of all unspent transaction outputs and their spending conditions.
The novelty of Bitcoin lies, among other things, in how the blockchain is structured in order to guarantee chronological ordering of transactions and prevent double-spending in a distributed network.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcbcn,
* cpt.btcnet'blockchain,
* cpt.bitcoin-global-database,
* cpt.blockchain.bitcoin,
* cpt.btcbcn, 2015-09-13,
* cpt.btcbc, 2015-09-03,
* cpt.btcblockchain,
* cpt.btcblockchain,
* cpt.bitcoin-block-chain,
NameGreek::
* ενν.μπιτκόιν-μπλοκτσέιν,
* ενν.μπλοκτσέιν-του-μπικόιν,
* ενν.παγκόσμιο-μπιτκόιν-μπλοκτσέιν,
* ενν.παγκόσμιο-μπλοκτσέιν-του-μπικόιν,
Generic::
* Blockchain,
Description::
Blockchain:
The full list of blocks that have been mined since the beginning of the bitcoin cryptocurrency.
The blockchain is designed so that each block contains a hash drawing on the blocks that came before it.
This is designed to make it more tamperproof.
To add further confusion, there is a company called Blockchain, which has a very popular blockchain explorer and bitcoin wallet.
[http://www.coindesk.com/information/bitcoin-glossary/]
Description::
A block chain is a transaction database shared by all nodes participating in a system based on the Bitcoin protocol. A full copy of a currency's block chain contains every transaction ever executed in the currency. With this information, one can find out how much value belonged to each address at any point in history.
Every block contains a hash of the previous block. This has the effect of creating a chain of blocks from the genesis block to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. Each block is also computationally impractical to modify once it has been in the chain for a while because every block after it would also have to be regenerated. These properties are what make double-spending of bitcoins very difficult. The block chain is the main innovation of Bitcoin.
Honest generators only build onto a block (by referencing it in blocks they create) if it is the latest block in the longest valid chain. "Length" is calculated as total combined difficulty of that chain, not number of blocks, though this distinction is only important in the context of a few potential attacks. A chain is valid if all of the blocks and transactions within it are valid, and only if it starts with the genesis block.
For any block on the chain, there is only one path to the genesis block. Coming from the genesis block, however, there can be forks. One-block forks are created from time to time when two blocks are created just a few seconds apart. When that happens, generating nodes build onto whichever one of the blocks they received first. Whichever block ends up being included in the next block becomes part of the main chain because that chain is longer. More serious forks have occurred after fixing bugs that required backward-incompatible changes.
Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.
These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.
Because a block can only reference one previous block, it is impossible for two forked chains to merge.
It's possible to use the block chain algorithm for non-financial purposes: see Alternative chain.
The block chain is broadcast to all nodes on the networking using a flood protocol: see Block chain download.
[https://en.bitcoin.it/wiki/Block_chain]
Description::
6) The mined block is added to the "blockchain", a big, unbreakable ledger that lives on the bitcoin network and serves as a record of all transactions.
[http://www.economist.com/blogs/graphicdetail/2015/01/daily-chart-3]
Description::
A public transaction ledger (the blockchain)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Description::
Blockchain is the system that bitcoin inventors devised. To understand how blockchain works requires dedicated study, but non-specialists might think of it as a publicly viewable spreadsheet that records every bitcoin transaction — who sent how much to whom (it's possible to remain fairly anonymous). Every few minutes, a "block" of new rows is added. But old blocks on the chain can't be edited. They're locked tight by theoretically unbreakable computer code.
See the most-read stories this hour >>
At least thousands of specially set up computers store a copy of the blockchain, so messing with records would require the herculean feat of infecting them all. Anyone can set up one of these computers, which work together to find inconsistencies and prevent fraud like double-spending. The people and businesses around the world who have set up these computers collect fees in exchange for authorizing transactions.
Finding applications for blockchain is wide-open territory right now. Factom, an organization in Austin, Texas, proposes using it to verify and lock down the records on mortgage contracts, with the aim of preventing some of the abuses of the mortgage meltdown, where signatures were faked and mortgage contracts went missing.
[http://www.latimes.com/business/la-fi-cutting-edge-blockchain-20150809-story.html]
Description::
Blockchain:
A public ledger of all confirmed transactions in a form of a tree of all valid *blocks* (including *orphans*).
Most of the time, "blockchain" means the *main chain*, a single most *difficult* chain of blocks.
Blockchain is updated by *mining* blocks with new transactions.
*Unconfirmed transactions* are not part of the blockchain.
If some clients disagree on which chain is main or which blocks are valid, a *fork* happens.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcbcn'Block (btcblk)
Name::
* cpt.btc'block,
* cpt.btcblk,
* cpt.btcblock,
* cpt.btcBlock-Of-Transactions,
* cpt.btcnet'block,
* cpt.bitcoin-block,
* cpt.btcnet'blockchain'Block-of-transactions,
Whole::
* btc-blockchain,
Generic::
* file,
Description::
A data structure that consists of a *block header* and a *merkle tree* of transactions.
Each block (except for *genesis block*) references one previous block thus forming a tree called the *blockchain*.
Block can be though of as a group of transactions with a timestamp and a *proof-of-work* attached.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
One or more transactions prefaced by a block header and protected by proof of work.
Blocks are the data stored on the block chain.
[https://bitcoin.org/en/glossary/block]
===
Data is permanently recorded in the Bitcoin network through files called blocks.
A block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks. They could be thought of like the individual pages of a city recorder's recordbook (where changes to title to real estate are recorded) or a stock transaction ledger. New blocks are added to the end of the record (known as the block chain), and can never be changed or removed once written (although some software will remove them if they are orphaned). Each block memorializes what took place in the minutes before it was created.
[https://en.bitcoin.it/wiki/Block]
btcblk'PART
Description::
Each block is composed of a header and a payload.
The header stores the current block header version (nVersion), a reference to the previous block (HashPrevBlock), the root node of the Merkle tree (HashMerkleRoot), a timestamp (nTime), a target value (nBits) and a nonce (nNonce).
Finally, the payload stores the number of transactions (#vtx ) and the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
* nVersion int(4 bytes) Block format version (currently 2).
* HashPrevBlock uint256(32 bytes) Hash of previous block header SHA2562 (nV ersion|| . . . ||nNonce).
* HashMerkleRoot uint256 (32 bytes) Top hash of the Merkle tree built from all transactions.
* nTime unsigned int (4 bytes) Timestamp in UNIX-format of approximate block creation time.
* nBits unsigned int (4 bytes) Target T for the proof of work problem in compact format. Full target value is derived as: T = 0xh2h3h4h5h6h7 * 2 8*(0xh0h1-3)
* nNonce unsigned int (4 bytes) Nonce allowing variations for solving the proof of work problem.
* #vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
btcblk'part.HEADER (80B)
Description::
Each block is composed of a header and a payload.
The header stores the current block header version (nVersion), a reference to the previous block (HashPrevBlock), the root node of the Merkle tree (HashMerkleRoot), a timestamp (nTime), a target value (nBits) and a nonce (nNonce).
Finally, the payload stores the number of transactions (#vtx ) and the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
1) nVersion int(4 bytes) Block format version (currently 2).
2) HashPrevBlock uint256(32 bytes) Hash of previous block header SHA256^2 (nV ersion|| . . . ||nNonce).
3) HashMerkleRoot uint256 (32 bytes) Top hash of the Merkle tree built from all transactions.
4) nTime unsigned int (4 bytes) Timestamp in UNIX-format of approximate block creation time.
5) nBits unsigned int (4 bytes) Target T for the proof of work problem in compact format. Full target value is derived as: T = 0xh2h3h4h5h6h7 * 2 8*(0xh0h1-3)
6) nNonce unsigned int (4 bytes) Nonce allowing variations for solving the proof of work problem.
* #vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
A data structure containing a previous block hash, a hash of a merkle tree of transactions, a timestamp, a *difficulty* and a *nonce*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work.
[https://bitcoin.org/en/glossary/block-header]
Name::
* cpt.btcblk'header,
* cpt.btcblk-header,
* cpt.btcblock-header,
nVersion (4B)
Description::
The version field stores the version number of the block format.
Ever since BIP0034 [5] is in place, the block format version is 2 and blocks of any other version are neither relayed nor mined.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcnVersion,
HashPrevBlock (32B)
Description::
This field stores the reference to the previous block, computed as a hash over the block header as depicted in Fig. 3.1.
Figure 3.1. Block Reference Computation
A double-SHA256 hash is calculated over the concatenation of all elements in the previous block header:
SHA2562 (nVersion||HashPrevBlock||HashMerkleRoot||nTime||nBits||nNonce) (4)
The reference functions as a chaining link in the blockchain. By including a reference to the previous block, a chronological order on blocks, and thus transactions as well, is imposed.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcblk'HashPrevBlock,
* cpt.btcHashPrevBlock,
HashMerkleRoot (32B)
Description::
Merkle root:
Every transaction has a hash associated with it.
In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root.
In other words, the Merkle root is the hash of all the hashes of all the transactions in the block.
The Merkle root is included in the block header.
With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and Merkle tree -- downloading the entire block chain is unnecessary.
This feature is currently not used in Bitcoin, but it will be in the future.
[https://en.bitcoin.it/wiki/Vocabulary#Merkle_root]
===
Merkle Root
The root node of a merkle tree, a descendant of all the hashed pairs in the tree.
Block headers must include a valid merkle root descended from all transactions in that block.
[https://bitcoin.org/en/glossary/merkle-root]
===
This field stores the root of the Merkle hash tree.
It is used to provide integrity of all transactions included in the block and is computed according to the scheme described in Sect. 2.2.
The parameters used for computing the tree are double-SHA256 as the hashing algorithm and raw transactions as the data blocks (see Table 3.2 and 3.4).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcblk'merkle-root,
* cpt.btcHashMerkleRoot,
* cpt.btcMerkle-root,
Merkle-Tree
Description::
Merkle Tree
A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root.
In Bitcoin, the leaves are almost always transactions from a single block.
[https://bitcoin.org/en/glossary/merkle-tree]
===
Merkle_Tree:
Merkle tree is an abstract data structure that organizes a list of data items in a tree of their hashes (like in Git, Mercurial or ZFS).
In Bitcoin the merkle tree is used only to organize transactions within a block (the block header contains only one hash of a tree) so that full nodes may prune fully spent transactions to save disk space.
*SPV* clients store only block headers and validate transactions if they are provided with a list of all intermediate hashes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcMerkle-tree,
* cpt.Merkle-hash-tree-btcnet,
* cpt.Merkle-tree-btcnet,
nBits (4B)
Description::
The target is the threshold below which a block header hash must be in order for the block to valid, and nBits is the encoded form of the target threshold as it appears in the block header.
[https://bitcoin.org/en/glossary/nbits]
Name::
* cpt.btcnBits,
* cpt.btctarget,
* cpt.btctarget-threshold,
==
NameGreek::
* ενν.στόχος-δυσκολίας-μπικόιν,
Description::
A 256-bit number that puts an upper limit for a block header hash to be valid.
The lower the target is, the higher the *difficulty* to find a valid hash.
The maximum (easiest) target is 0x00000000FFFF0000000000000000000000000000000000000000000000000000.
The difficulty and the target are adjusted every 2016 blocks (approx. 2 weeks) to keep interval between the blocks close to 10 minutes.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The target is the threshold below which a block header hash must be in order for the block to valid, and nBits is the encoded form of the target threshold as it appears in the block header.
[https://bitcoin.org/en/glossary/nbits]
Difficulty
Description::
Difficulty is a measure of how difficult it is to find a new block compared to the easiest it can ever be.
By definition, it is a maximum *target* divided by the current target.
Difficulty is used in two Bitcoin rules:
1) every block must be meet difficulty target to ensure 10 minute interval between blocks and
2) transactions are considered confirmed only when belonging to a *main chain* which is the one with the biggest cumulative difficulty of all blocks.
As of July 27, 2014 the difficulty is 18 736 441 558 and grows by 3-5% every two weeks.
See also *Target*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The contents of the block are then hashed with an incrementing random number (called a “nonce”) until the resulting output contains a certain number of leading zeroes.
The network dynamically adjusts the requisite number of leading zeroes (or the “difficulty”) so that a block is mined every 10 minutes on average.
Because the results of hashing algorithms are unpredictable, finding a valid hash which the rest of the network will accept requires both luck and CPU power.
[https://media.consensys.net/time-sure-does-fly-ed4518792679#.rjkzhxgwo]
===
What is the formula for difficulty?
difficulty = difficulty_1_target / current_target
(target is a 256 bit number)
difficulty_1_target can be different for various ways to measure difficulty. Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff"). The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").
[https://en.bitcoin.it/wiki/Difficulty#What_is_the_formula_for_difficulty.3F]
===
This number determines how difficult it is to hash a new block.
It is related to the maximum allowed number in a given numerical portion of a transaction block’s hash.
The lower the number, the more difficult it is to produce a hash value that fits it.
Difficulty varies based on the amount of computing power used by miners on the bitcoin network.
If large numbers of miners leave a network, the difficulty would decrease.
Thus far, however, bitcoin’s growing popularity has attracted more computing power to the network, meaning that the difficulty has increased.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-difficulty,
* cpt.btcdifficulty,
* cpt.btcNetwork-difficulty,
NameGreek::
* ενν.δυσκολία-μπικόιν,
nNonce (4B)
Description::
Nonce:
Stands for "number used once".
A 32-bit number in a *block header* which is iterated during a search for proof-of-work.
Each time the nonce is changed, the *hash* of the block header is recalculated.
If nonce overflows before valid proof-of-work is found, an *extra nonce* is incremented and placed in the *coinbase* script.
Alternatively, one may change a merkle tree of transactions or a timestamp.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Nonce:
A random string of data used as an input when hashing a transaction block.
A nonce is used to try and produce a digest that fits the numerical parameters set by the bitcoin difficulty.
A different nonce will be used with each hashing attempt, meaning that billions of nonces are generated when attempting to hash each transaction block.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
The nonce field contains arbitrary data and is used as a source of randomness for solving the proof of work problem.
However, since it is fairly small in size with 4 bytes, it does not necessarily provide sufficient variation for finding a solution.
Therefore, other sources exist and will be addressed in more detail in Sect. 5.2.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcnNonce,
* cpt.btcNonce,
header-chain
Description::
A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain
[https://bitcoin.org/en/glossary/header-chain]
Name::
* cpt.btcheader-chain,
best header chain
Description::
A chain of block headers with each header linking to the header that preceded it; the most-difficult-to-recreate chain is the best header chain
[https://bitcoin.org/en/glossary/header-chain]
Name::
* cpt.btcbest-header-chain,
btcblk'part.PAYLOAD
Description::
Each block is composed of a header and a payload.
Finally, the payload stores
- the number of transactions (#vtx ) and
- the vector of transactions (vtx ) included in the block.
Field name Type(Size) Description
* #vtx VarInt (1-9 bytes) Number of transaction entries in vtx.
* vtx[ ] Transaction (Variable) Vector of transactions.
Table 3.1. Block Structure
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcblk'payload,
btcblk'number-of-transaction-entries
btcblk'vector-of-transactions
btcblk'Proof-of-work (link)
btcblk'Reward
Description::
Together, the transaction fees and block subsidy are called the block reward.
A coinbase transaction is invalid if it tries to spend more value than is available from the block reward.
[https://bitcoin.org/en/developer-reference#serialized-blocks]
Name::
* cpt.bitcoin-block-reward,
* cpt.bitcoin-reward,
* cpt.btcBlock-Reward,
* cpt.btcBlock-Miner-Reward,
* cpt.btcreward,
AddressWpg::
* http://www.bitcoinblockhalf.com/
Description::
Together, the transaction fees and block subsidy are called the block reward.
A coinbase transaction is invalid if it tries to spend more value than is available from the block reward.
[https://bitcoin.org/en/developer-reference#serialized-blocks]
===
The amount that miners may claim as a reward for creating a block. Equal to the sum of the block subsidy (newly available satoshis) plus the transactions fees paid by transactions included in the block.
[https://bitcoin.org/en/glossary/block-reward]
===
Bitcoin Block Reward Halving Countdown
Reward-Drop ETA date: 11 Jul 2016 22:03:04
The Bitcoin block mining reward halves every 210,000 blocks, the coin reward will decrease from 25 to 12.5 coins.
Total Bitcoins in circulation: 15,443,050
Total Bitcoins to ever be produced: 21,000,000
Percentage of total Bitcoins mined: 73.54%
Total Bitcoins left to mine: 5,556,950
Total Bitcoins left to mine until next blockhalf: 306,950
Bitcoin price (USD): $431.25
Market capitilzation (USD): $6,659,815,312.50
Bitcoins generated per day: 3,600
Bitcoin inflation rate per annum: 8.88%
Bitcoin inflation rate per annum at next block halving event: 4.09%
Bitcoin inflation per day (USD): $1,552,500
Bitcoin inflation until next blockhalf event based on current price (USD): $132,372,188
Total blocks: 407,722
Blocks until mining reward is halved: 12,278
Approximate block generation time: 10.00 minutes
Approximate blocks generated per day: 144
Difficulty: 178,678,307,672
Hash rate: 1.39 Exahashes/s
[http://www.bitcoinblockhalf.com/] {2016-04-17}
===
The reward given to a miner which has successfully hashed a transaction block.
This can be a mixture of coins and transaction fees, depending on the policy used by the cryptocurrency in question, and whether all of the coins have already been successfully mined.
Bitcoin currently awards 25 bitcoins for each block.
The block reward halves when a certain number of blocks have been mined.
In bitcoin’s case, the threshold is every 210,000 blocks.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Reward:
Amount of newly generated bitcoins that a *miner* may claim in a new block.
The first transaction in the block allows miner to claim currently allowed reward as well as all *transaction fees* from all transactions in the block.
Reward is *halved* every 210 000 blocks, approximately every 4 years.
As of July 27, 2014 the reward is 25 BTC (the first halving occurred in December 2012).
For security reasons, rewards cannot be *spent* before 100 blocks built on top of the current block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcblkrwd'Transaction-fee (link)
btcblkrwd'Subsidy
Description::
All blocks with a block height less than 6,930,000 are entitled to receive a block subsidy of newly created bitcoin value, which also should be spent in the coinbase transaction. (The block subsidy started at 50 bitcoins and is being halved every 210,000 blocks—approximately once every four years. As of November 2014, it’s 25 bitcoins.)
Together, the transaction fees and block subsidy are called the block reward.
A coinbase transaction is invalid if it tries to spend more value than is available from the block reward.
[https://bitcoin.org/en/developer-reference#serialized-blocks]
Name::
* cpt.btcblk'subsidy,
* cpt.btcBlock-subsidy,
AddressWpg::
* http://www.bitcoinblockhalf.com/
btcblkrwd'Halving
Description::
Halving:
Refers to reducing *reward* every 210 000 blocks (approximately every 4 years).
Since the *genesis block* to a block 209999 in December 2012 the reward was 50 BTC.
Till 2016 it will be 25 BTC, then 12.5 BTC and so on till 1 *satoshi* around 2140 after which point no more bitcoins will ever be created.
Due to reward halving, the total supply of bitcoins is limited: only about 2100 trillion *satoshis* will ever be created.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-reward-halving,
* cpt.btchalving,
btcblkrwd.VIRGIN-BITCOIN
Description::
Virgin bitcoin
The reward for generating a block that has not yet been spent, a state which might increase the ability to transact anonymously.
[https://en.bitcoin.it/wiki/Vocabulary#Virgin_bitcoin]
Name::
* cpt.btcvirgin-bitcoin,
btcblk'Hash
Name::
* cpt.bitcoin-block-hash,
* cpt.bitcoin-hash-of-block,
* cpt.btchash-of-block,
Hash-of-previous-block (link)
Checkpoint
Description::
Checkpoint:
A hash of a block before which the *BitcoinQT* client downloads blocks without verifying digital signatures for performance reasons.
A checkpoint usually refers to a very deep block (at least several days old) when it's clear to everyone that that block is accepted by the overwhelming majority of users and *reorganization* will not happen past that point.
It also helps protecting most of the history from a *51% attack*.
Since checkpoints affect how the *main chain* is determined, they are part of the protocol and must be recognized by alternative clients (although, the risk of reorganization past the checkpoint would be incredibly low).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-checkpoint,
* cpt.btccheckpoin,
btcblk'Size
Description::
This isn’t the first time bitcoin community members attempted to change the block size limit. Originally, there was no block size limit. The current limit was introduced early on to protect the system against “spam transactions.” At the time, it wasn’t a big deal since few people were using bitcoin. The one megabyte limit was like a 500 MPH speed limit. It was completely non-binding. But the system has grown a lot since then. Although it’s not yet bumping up against the hard constraint—it averaged around 117,500 transactions per day over the last month—many believe the block size limit will become binding in the very near future.
...
There’s a related concern that bigger block sizes will require more bandwidth, which would preclude some smaller players from competing in the mining race. Opponents claim this, too, would result in a more centralized system.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
Description::
BitPay Supports Increase in Bitcoin Block Size Limit
Posted on August 23, 2015Author Gautham
BitPay Supports Increase in Bitcoin Block Size Limit.
BitPay, the largest bitcoin payment processor has sided with Gavin Andresen’s court by showing its support towards incorporation of BIP 101. In other words, BitPay in one of their blog posts mentioned that the company supports the move to increase bitcoin block size from 1 MB to 8 MB (which is known as BIP 101).
Bitcoin XT has been a topic of serious debate among the bitcoin community for a while now. The debate has ranged ever since Gavin Andresen, the Chief Scientist at Bitcoin Foundation and Mike Hearn proposed Bitcoin XT a few months ago.
The Bitcoin XT proposal was later changed to incorporate a few changes after receiving inputs from members of the bitcoin community. While there are few who are in favor of a 7MB increase in the bitcoin block size, there are others who are opposed to this idea. The bitcoin block size limit is currently 1 MB, which Bitcoin XT proposed to change to 8 MB. Gavin Andresen and Mike Hearn finally launched a Bitcoin XT fork few days ago. The launch didn’t go will with many bitcoin based entities who are also part of the club.
The bitcoin network has experienced rapid growth since its inception in 2009. At the current rate of growth, the bitcoin network with 1 MB block size limit will be left obsolete by 2017.
BitPay has put forward a sensible argument as to why BIP 101 has to be incorporated while expressing its support towards its integration into bitcoin core client. Contrary to the opinions of a few people, BitPay believes that the integration of BIP 101 will not compromise the integrity of the Bitcoin network. BIP 101 will instead protect the decentralized nature of the bitcoin network. BitPay sees the current argument against integration of BIP 101 to be favoring a centralized group of developers, which if continued will compromise the decentralized nature of the bitcoin network. Increased block size limit will prevent big mining companies from running a full bitcoin node, thereby preserving the decentralized nature of bitcoin.
To summarize in the words of Stephen Pair, the CEO and co-founder of BitPay — BIP 101 will safeguard bitcoin’s decentralized nature while providing reliable, immediate path towards greater network throughput and BitPay supports merging BIP 101 into Bitcoin Core.
[http://www.newsbtc.com/2015/08/23/bitpay-supports-increase-in-bitcoin-block-size-limit/]
Description::
A spat between developers may split the digital currency
The project approaches a "fork" in the road
Aug 18th 2015 | Business and finance
"FEDERAL Reserve deeply split. Renegade group of board members to create separate American dollar.” Such a headline seems highly unlikely, but this in essence is happening in the land of bitcoin, the digital currency. On August 15th two of bitcoin’s five main developers released a competing version, or “fork”, of the software that powers the currency—a move, some fear, that may split bitcoin.
The dispute is predictably arcane. The bone of contention is the size of a “block”, a batch of bitcoin transactions into which these are assembled before they are processed. Satoshi Nakamoto, the elusive creator of bitcoin who went offline in 2011, limited their size to 1Mb. That is enough to handle about 300,000 transactions per day—suitable for a currency used mainly by crypto-geeks, as bitcoin once was, but nowhere near enough to rival conventional payment systems. The likes of Visa and MasterCard can process tens of thousands of payments per second if needed.
Related topics
Bitcoins
By how much and when to increase this limit has long been a matter of a heated debate within the bitcoin community. One camp wants to set the number much higher and do it soon. Otherwise, they argue, the system could crash as it runs out of capacity as early as next year. Transactions could take hours to confirm and fees could rocket, warns Mike Hearn, a leading bitcoin developer. “Bitcoin would survive,” he wrote in a blog post in May, “but it would have lost critical momentum.”
The other side, led by the other three main bitcoin developers, frets that increasing the block size hastily would lead to centralisation and turn bitcoin into more of a conventional payment system. This matters to bitcoin purists, who laud the currency’s decentralised approach of running a currency. The system currently relies on thousands of independent “nodes”, computers spread across the world that check whether blocks of transactions are valid and keep tabs on who owns which bitcoins. Increasing the size of these blocks would make the system so unwieldy as to dissuade nodes from participating, so hastening a worrying recent decline in participants.
How Bitcoin works
The dispute is as ideological as it is technical. The bitcoin community has a process to settle such controversies, but it is by design slow and produces decisions only when everybody is happy. Frustrated that the discussion has kept dragging on, Mr Hearn and Gavin Andresen, one of the dissenting developers, decided to press the issue by organising a referendum of sorts: they have called on “miners”, specialised nodes that assemble the blocks and mint new bitcoin, to install their new version, called “Bitcoin XT”.
Once at least 75% of the blocks are processed by Bitcoin XT, but no earlier than January, it will upgrade to a block size of a maximum of 8Mb (and double that limit every two years). The nodes that then still run the old “Bitcoin Core” software would find themselves excluded from the system.
Predictably, the move has increased the temperature of the debate. On discussion sites such as Reddit, moderators have censored mentions of Bitcoin XT because they see it as an effort to undermine the bitcoin community. Comments purportedly made by Mr Nakamoto warning that a fork would lead him to “declare bitcoin a failed project” have been widely dismissed as a hoax.
Despite all the sound and fury, such an outcome is still unlikely. Like spatting doves and hawks at an old-fashioned central bank, the two sides will probably agree on some compromise; two fun-sounding “Bitcoin Scalability Workshops” have been scheduled for later this year.
Even if miners get to make the decision, this would probably not lead to a bitcoin split. Once it becomes clear which version is likely to prevail, all miners will have an incentive to jump on the winning bandwagon. Already, 8% of them have joined the dissident XT faction, a rapid take-up. Whether such a majority rule is the best way to run the highly complex bitcoin system, however, is an entirely different question.
[http://www.economist.com/news/business-and-finance/21661404-spat-between-developers-may-split-digital-currency-forking-hell]
btcblk'Blocktime
Description::
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes.
[https://en.bitcoin.it/wiki/Target]
Name::
* cpt.bitcoin-block-interval,
btcblk'Validation-rule
Description::
The block validation rules that full nodes follow to stay in consensus with other nodes.
[https://bitcoin.org/en/glossary/consensus-rules]
Name::
* cpt.btcconsensus-rule,
* cpt.btcconsensus-rules,
* cpt.btcvalidation-rule,
btcblk'DOING
btcdng.CREATING
Description::
Mining:
The act of generating new bitcoins by solving cryptographic problems using computing hardware.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Mining adds new blocks to the block chain, making transaction history hard to modify.
[https://bitcoin.org/en/developer-guide#mining]
===
Central to Bitcoin’s architecture is a public ledger called the blockchain, which stores all processed transactions in chronological order.
Transactions are processed by a loosely organized network of miners in a process called mining (see Sect. 5.2).
In it the miner creates a block with a set of unprocessed transactions and attempts to solve a proof of work puzzle (see Sect. 2.1).
Once a valid solution has been found, the block including the solution is published throughout the network and accepted into the blockchain.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Mining:
A process of finding valid *hashes* of a block header by iterating millions of variants of block headers (using *nonce* and *extra nonce*) in order to find a hash lower than the *target* (see also *difficulty*).
The process needs to determine a single global history of all transactions (grouped in blocks).
Mining consumes time and electricity and nowadays the difficulty is so big, that energy-wise it's not even profitable to mine using video graphics cards.
Mining is paid for by *transaction fees* and by block *rewards* (newly generated coins, hence the term "mining").
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcblk'adding,
* cpt.btcblk'creating,
* cpt.btcblk'processing,
* cpt.btcmining,
* cpt.bitcoin-block-creation,
* cpt.bitcoin-hashing-a-block,
* cpt.bitcoin-to-hash-a-block,
Doing::
As described in [9], mining nodes perform the following
steps in an endless loop:
1) Collect all broadcasted transactions and validate whether they satisfy the miner’s
self-defined policy. Typically, a transaction includes a transaction fee that functions
as an incentive for the miner to include it in the block. However, if it does
not, then it is up to the miner to decide whether or not to include it.
2) Verify all transactions that are to be included in the block. Transactions are
verified as described in Sect. 4.2 and it is checked whether their inputs have been
previously spent.
3) Select the most recent block on the longest path in the blockchain, i.e. the path
that involves most accumulated computational effort, and insert the hash of the
block header into the new block.
4) Solve the proof of work problem as described below and broadcast the solution.
Should another node solve the proof of work problem before, then the block is
first validated, meaning the proof of work solution is checked and all transactions
included in the block are verified. If it passes these controls then the cycle is
repeated. Note that if there are transactions that have not been included in the
new block then they are saved and included in the next cycle.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
btcmining'Mining-pool
Description::
Mining_Pool:
A service that allows separate owners of mining hardware to split the reward proportionally to submitted work.
Since probability of finding a valid block hash is proportional to miner's *hashrate*, small individual miners may work for months before finding a big per-block reward.
Mining pools allow more steady stream of smaller income.
Pool owner determines the block contents and distributes ranges of *nonce* values between its workers.
Normally, mining pools are centralized.
P2Pool is a fully decentralized pool.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Pool:
A collection of mining clients which collectively mine a block, and then split the reward between them.
Mining pools are a useful way to increase your probability of successfully mining a block as the difficulty rises.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-mining-pool,
* cpt.btcmining-pool,
NameGreek::
* ενν.ομάδα-εξόρυξης-μπιτκόιν,
btcmining.POOLED
Description::
Pooled mining, where the miner pools resources with other miners to find blocks more often, with the proceeds being shared among the pool miners in rough correlation to the amount of hashing power they each contributed, allowing the miner to receive small payments with a lower variance (shorter time between payments).
[https://bitcoin.org/en/developer-guide#mining]
Name::
* cpt.btcpooled-mining,
btcmining.SOLO
Description::
Solo mining, where the miner attempts to generate new blocks on his own, with the proceeds from the block reward and transaction fees going entirely to himself, allowing him to receive large payments with a higher variance (longer time between payments)
[https://bitcoin.org/en/developer-guide#mining]
Name::
* cpt.btcsolo-mining,
btcdng.REORGANIZATION
Description::
Reorg, Reorganization:
An event in the *node* when one or more blocks in the *main chain* become *orphaned*.
Usually, newly received blocks are extending existing main chain.
Sometimes (4-6 times a week) a couple of blocks of the same *height* are produced almost simultaneously and for a short period of time some nodes may see one block as a tip of the main chain which will be eventually replaced by a more difficult block(s).
Each transaction in the orphaned blocks either becomes invalid (if already included in the main chain block) or becomes *unconfirmed* and moved to the *mempool*.
In case of a major bug or a *51% attack*, reorganization may involve reorganizing more than one block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Reorganize
A block chain reorganize (or reorg) happens when one chain becomes longer than the one you are currently working on.
All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated.
Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks.
The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again.
If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.
[https://en.bitcoin.it/wiki/Vocabulary#Reorganize]
Name::
* cpt.bitcoin-reorganization,
* cpt.btcreorg,
* cpt.btcreorganization,
SPECIFIC
Name::
* btcblk.specific,
btcblk.EXAMPLE
Example::
An example header in hex (2-hex-digits = 1 byte, (ff)16=(11111111)2=(255)10):
02000000 ............................................ Block version: 2
b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of previous block's header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root
24d95a54 ............................................. Unix time: 1415239972
30c31b18 ............................................. Target: 0x1bc330 * 256**(0x18-3)
fe9f0864 ............................................... Nonce
btcblk.GENESIS (btcblk0)
Description::
Genesis block
A genesis block is the first block of a block chain.
Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1.
The genesis block is almost always hardcoded into the software.
It is a special case in that it does not reference a previous block, and for Bitcoin and almost all of its derivatives, it produces an unspendable subsidy.
[https://en.bitcoin.it/wiki/Genesis_block]
===
Genesis_Block:
A very first block in the blockchain with hard-coded contents and a all-zero reference to a previous block.
Genesis block was released on 3rd of January 2009 with a newspaper quote in its coinbase:
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" as a proof that there are no secretly pre-mined blocks to overtake the blockchain in the future.
The message ironically refers to a reason for Bitcoin existence: a constant inflation of money supply by governments and banks.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Block Height 0 Blocks at depth 0 in the bitcoin blockchain
Summary
Height 0 (Main chain)
Hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Previous Block 0000000000000000000000000000000000000000000000000000000000000000
Next Blocks 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
Time 2009-01-03 18:15:05
Difficulty 1
Bits 486604799
Number Of Transactions 1
Output Total 50 BTC
Estimated Transaction Volume 0 BTC
Size 0.285 KB
Version 1
Merkle Root 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Nonce 2083236893
Block Reward 50 BTC
Transaction Fees 0 BTC
[https://blockchain.info/block-height/0]
Name::
* cpt.Bitcoin-genesis-block,
* cpt.btcblk.genesis,
* cpt.btcGenesis-Block,
* cpt.btcBlock-0,
btcblk.BLOCK1 (btcblk1)
Description::
Block Height 1 Blocks at depth 1 in the bitcoin blockchain
Summary
Height 1 (Main chain)
Hash 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
Previous Block 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Next Blocks 000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd
Time 2009-01-09 02:54:25
Difficulty 1
Bits 486604799
Number Of Transactions 1
Output Total 50 BTC
Estimated Transaction Volume 0 BTC
Size 0.215 KB
Version 1
Merkle Root 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
Nonce 2573394689
Block Reward 50 BTC
Transaction Fees 0 BTC
[https://blockchain.info/block-height/1]
Name::
* cpt.btcblk1,
* cpt.btcBlock-1,
btcblk.ORPHAN
Description::
Orphan Block
An orphan block is a block which has no known parent in the currently-longest block chain.
Not to be confused with a Stale Block (which has a known parent, but is no longer part of the longest chain).
[https://en.bitcoin.it/wiki/Vocabulary#Orphan_Block]
===
Orphan_block:
A block which is not a part of the valid blockchain, but which was instead part of a fork that was discarded.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Orphan block (a block whose previous (parent) hash field points to an unknown block, meaning the orphan can’t be validated)
[https://bitcoin.org/en/glossary/stale-block]
===
A valid block that is no longer a part of a *main chain*.
Usually happens when two or more blocks of the same *height* are produced at the same time.
When one of them becomes a part of the main chain, others are considered "orphaned".
Orphans also may happen when the blockchain is *forked* due to an attack (see *51% attack*) or a bug.
Then a chain of several blocks may become abandoned.
Usually a transaction is included in all blocks of the same height, so its *confirmation* is not delayed and there is no *double spend*. See also *Fork*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcorphan-Block,
* cpt.btcOrphan,
* cpt.btcOrphaned-block,
btcblk.RAW
Description::
A complete block in its binary format—the same format used to calculate total block byte size; often represented using hexadecimal.
[https://bitcoin.org/en/glossary/serialized-block]
Name::
* cpt.btcBinary-block,
* cpt.btcRaw-block,
* cpt.btcSerialized-block,
btcblk.STALE
Description::
Blocks which were successfully mined but which aren’t included on the current best block chain, likely because some other block at the same height had its chain extended first.
Not To Be Confused With Orphan block (a block whose previous (parent) hash field points to an unknown block, meaning the orphan can’t be validated)
[https://bitcoin.org/en/glossary/stale-block]
===
Stale:
When a bitcoin block is successfully hashed, any others attempting to hash it may as well stop, because it is now ‘stale'.
They would simply be repeating work that someone else has already done, for no reward.
The term is also used in mining pools to describe a share of a hashing job that has already been completed.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.btcStale-block,
btcblk.VALID
Name::
* cpt.btcvalid-block,
btcbcn'Block-explorer
Description::
A block chain browser (also called "block explorer") is a program or web site that lets users search and navigate a block chain. Uses include:
- checking address balances
- tracking coin transfer histories
- watching for transaction acceptance
- monitoring the network hash rate and other statistics
Block chain browsers typically provide:
- a list of a chain's recent blocks
- transactions in a given block
- links to the previous and next transaction involving each input and output
- a list of all transactions involving a given address
- current and historical address balances
- a way to search for blocks, transactions, and addresses
[https://en.bitcoin.it/wiki/Block_chain_browser]
Name::
* cpt.bitcoin-block-explorer,
* cpt.bitcoin-explorer,
* cpt.bitcoin-browser,
* cpt.btcblk'explorer,
* cpt.btcblkexr,
* cpt.btcblock-explorer,
* cpt.btcbrowser,
* cpt.btcnet'explorer,
Specific::
* https://blockexplorer.com/
* https://blockchain.info/
* https://blockchain.info/block-height/0,
* BlockH0 https://blockchain.info/block-height/0,
* https://blockchain.info/address/3LpiaPt5To7876GRm3W4hGoZ6npr8cDwYG,
btcbcn'Consensus-algorithm
Description::
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
Check if the previous block referenced by the block exists and is valid.
Check that the timestamp of the block is greater than that of the previous block[2] and less than 2 hours into the future
Check that the proof of work on the block is valid.
Let S[0] be the state at the end of the previous block.
Suppose TX is the block's transaction list with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) If any application returns an error, exit and return false.
Return true, and register S[n] as the state at the end of this block.
Essentially, each transaction in the block must provide a valid state transition from what was the canonical state before the transaction was executed to some new state. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The one validity condition present in the above list that is not found in other systems is the requirement for "proof of work". The precise condition is that the double-SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2187. The purpose of this is to make block creation computationally "hard", thereby preventing sybil attackers from remaking the entire blockchain in their favor. Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches.
At the current target of ~2187, the network must make an average of ~269 tries before a valid block is found; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a "transaction fee". Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
Send 100 BTC to a merchant in exchange for some product (preferably a rapid-delivery digital good)
Wait for the delivery of the product
Produce another transaction sending the same 100 BTC to himself
Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus "confirming" it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not "point" to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, "51% attack").
[https://github.com/ethereum/wiki/wiki/White-Paper]
Name::
* cpt.bitcoin-consensus-algorithm,
* cpt.btcconsensus-algorithm,
Description::
A proof of work is a cryptographic puzzle used to ensure that a party has performed a certain amount of work.
In particular, the Bitcoin mining process (see Sect. 5.2) incorporates a proof of work system based on Adam Back’s Hashcash [3].
It has two basic properties - firstly, it ensures that the party providing the proof of work has invested a predefined amount of effort in order to create the proof and secondly, that the proof is efficiently verifiable.
Typically, finding a solution to a proof of work puzzle is a probabilistic process with a success probability depending on the predefined difficulty.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
btcbcn'consensus-rule
Description::
The block validation rules that full nodes follow to stay in consensus with other nodes.
[https://bitcoin.org/en/glossary/consensus-rules]
Name::
* cpt.btcconsensus-rule,
* cpt.btcconsensus-rules,
* cpt.btcvalidation-rule,
Specific::
* current-consensus-rules,
* previous-consensus-rules,
btcbcncsa'Proof-of-work (PoW)
Description::
A hash below a target value which can only be obtained, on average, by performing a certain amount of brute force work—therefore demonstrating proof of work.
[https://bitcoin.org/en/glossary/proof-of-work]
Name::
* cpt.btcPOW,
* cpt.btcproof-of-work,
* cpt.btcnet'proof-of-work,
Description::
Proof_of_Work_(PoW):
A number that is provably hard to compute.
That is, it takes measurable amount of time and/or computational power (energy) to produce.
In Bitcoin it is a hash of a block header.
A block is considered valid only if its hash is lower than the current *target* (roughly, starts with a certain amount of zero bits). Each block refers to a previous block thus accumulating previous proof-of-work and forming a *blockchain*.
Proof-of-work is not the only requirement, but an important one to make sure that it is economically infeasible to produce an alternative history of transactions with the same accumulated work. Each client can independently consider the most difficult chain of valid blocks as the "true" history of transactions, without need to trust any source that provides the blocks.
Note that owning a very large amount of computational power does not override other rules enforced by every client. Ill-formed blocks or blocks containing invalid transactions are rejected no matter how difficult they were to produce.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Description::
A proof of work is a piece of data which was difficult (costly, time-consuming) to produce so as to satisfy certain requirements. It must be trivial to check whether data satisfies said requirements. Producing a proof of work can be a random process with low probability, so that a lot of trial and error is required on average before a valid proof of work is generated. Bitcoin uses the Hashcash proof of work.
One application of this idea is using hashcash as a method to preventing email spam, requiring a proof of work on the email's contents (including the To address), on every email. Legitimate emails will be able to do the work to generate the proof easily (not much work is required for a single email), but mass spam emailers will have difficulty generating the required proofs (which would require huge computational resources).
Hashcash proofs of work are used in Bitcoin for block generation. Proofs of work that are tied to the data of each block are required for the blocks to be accepted. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes. Due to the very low probability of successful generation, this makes it unpredictable which worker computer in the network will be able to generate the next block.
For a block to be valid it must hash to a value less than the current target; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a chain of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.
The most widely used proof-of-work scheme is SHA-256, which was introduced by Bitcoin. Some other hashing algorithms that are used for proof-of-work include scrypt, Blake-256, CryptoNight,[1] HEFTY1, Quark, SHA-3, scrypt-jane, scrypt-n, and combinations.
[https://en.bitcoin.it/wiki/Proof_of_work]
btcbcn'Address (btcads)
Description::
Bitcoin-address is THE-PUBLIC-NAME of some-bitcoin-tokens[1].
Looks like 3EtZT5fEQ9Atf73UMnyRUXsbWqcNeQ6rXy.
The-owner of these[1] bitcoins has a-sectret-private-key with which s|he can-spent these[1] bitcoin-tokens.
Wallets manage the-addresses and its corresponding private-keys.
Anyone who owns bitcoin-tokens can-send bitcoin-tokens to any address.
[hmnSgm.2017-04-09]
Name::
* cpt.bitcoin-address,
* cpt.btcaddress,
* cpt.btcads,
* cpt.btcnet'address,
* cpt.btcpayment-address,
NameGreek::
* ενν.διεύθυνση-Bitcoin,
Description::
A bitcoin address looks like 1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV.
It consists of a string of letters and numbers.
It’s really an encoded base58check version of a public key 160-bit hash.
Just like you ask others to send an email to your email address, you would ask others to send you bitcoins to one of your bitcoin addresses.
[https://github.com/bitcoinbook/bitcoinbook/blob/develop/glossary.asciidoc]
Description::
Bob provides the pubkey hash to Alice.
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an address version number, the hash, and an error-detection checksum to catch typos.
The address can be transmitted through any medium, including one-way mediums which prevent the spender from communicating with the receiver, and it can be further encoded into another format, such as a QR code containing a bitcoin: URI.
[https://bitcoin.org/en/developer-guide#transactions]
Description::
Bitcoin address is a Base58Check representation of a Hash160 of a *public key* with a version byte 0x00 which maps to a prefix "1".
Typically represented as text (ex. 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG) or as a QR code.
A more recent variant of an address is a *P2SH* address: a hash of a spending script with a version byte 0x05 which maps to a prefix "3" (ex. 3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8).
Another variant of an address is not a hash, but a raw private key representation (e.g. 5KQntKuhYWSRXNqp2yhdXzjekYAR7US3MT1715Mbv5CyUKV6hVe). It is rarely used, only for importing/exporting private keys or printing them on *paper wallets*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Description::
A bitcoin address is used to receive and send transactions on the bitcoin network.
It contains a string of alphanumeric characters, but can also be represented as a scannable QR code.
A bitcoin address is also the public key in the pair of keys used by bitcoin holders to digitally sign transactions (see Public key).
[http://www.coindesk.com/information/bitcoin-glossary/]
Description::
addresses (hashed public keys)
[https://bitcoin.org/en/developer-guide#transaction-fees-and-change]
Description::
To each Bitcoin wallet is associated one or many matching pairs of a Bitcoin address and a private key (they consist of a string of numbers and letters).
The Bitcoin address is someone’s identification in the network, and each address is associated with a balance of funds denominated in Bitcoins.
The private key can be thought of as the password which allows users to have access to the funds associated
with the matching public address.
To put it simply: the Bitcoin address is like a person’s email address while the private key is like the password.
When we say that someone owns Bitcoins, what we mean is that he is in possession of a private key which corresponds to the public address to which those Bitcoins are associated.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
Description::
A Bitcoin address is a unique, 27-34 alphanumeric characters long identifier that can be used as a destination for Bitcoin payments.
There are currently two different types of Bitcoin addresses in existence, Pay-to-PubkeyHash and Pay-to-ScriptHash, which are used in conjunction with their corresponding transaction type.
In the following both will be described in detail.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Description::
A 20-byte hash formatted using base58check to produce either a P2PKH or P2SH Bitcoin address. Currently the most common way users exchange payment information.
[https://bitcoin.org/en/glossary/address]
Description::
A Bitcoin address, or simply address, is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
An example of a Bitcoin address is 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.
[https://en.bitcoin.it/wiki/Address]
Description::
Address validation
A bitcoin address includes a four byte checksum, which means addresses can be validated without talking to any servers.
The bitcoin-address module (GitHub: shtylman / bitcoin-address, npm: bitcoin-address) by Roman Shtylman implements the algorithm: a double SHA-256 digest of the 21 bytes before the checksum is calculated to validate the address.
var btcAddr = require('bitcoin-address');
btcAddr.validate('1Gtov23WTQPbj4c6dMaXnXxbvFKc87Lutb');
// true
Addresses are encoded with base 58, so Roman’s module includes his own decoding library.
He also uses Node Buffer objects to work with the decoded data.
Node’s crypto core module is used to create SHA-256 hashes.
[http://dailyjs.com/2013/08/23/bitcoins/]
Description::
A bitcoin address is an identifier (account number), starting with 1 or 3 and containing 27-34 alphanumeric Latin characters (except 0, O, I, l).
An address can be also represented as a QR-code, is anonymous, and does not contain information about the owner.
It can be obtained for free, using, for example, bitcoin software.
[https://en.wikipedia.org/wiki/Bitcoin_network]
Description::
Address:
A bitcoin address is used to receive and send transactions on the bitcoin network.
It contains a string of alphanumeric characters, but can also be represented as a scannable QR code.
A bitcoin address is also the public key in the pair of keys used by bitcoin holders to digitally sign transactions (see Public key).
[http://www.coindesk.com/information/bitcoin-glossary/]
===
This is wrong.
A-bitcoin-address is-not a-public-key, it derives from a-public-key.
[hmnSgm.2017-04-08]
AddressWpg::
* https://github.com/shtylman/bitcoin-address,
* https://npmjs.org/package/bitcoin-address,
btcads'QR-code
Description::
QR_code:
A two-dimensional graphical block containing a monochromatic pattern representing a sequence of data.
QR codes are designed to be scanned by cameras, including those found in mobile phones, and are frequently used to encode bitcoin addresses.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-QR-code,
* cpt.btcQR-code,
btcads'Private-key
Description::
The bitcoin private key is just a number.
You can pick your private keys randomly using just a coin, pencil, and paper: toss a coin 256 times and you have the binary digits of a random private key you can use in a bitcoin wallet.
The public key can then be generated from the private key.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch04.asciidoc#private-keys]
Name::
* cpt.bitcoin-private-key,
* cpt.btcaddress'private-key,
* cpt.btcnet'private-key,
* cpt.btcprivate-key,
Description::
The private portion of a keypair which can create signatures that other people can verify using the public key.
[https://bitcoin.org/en/glossary/private-key]
===
When we say that someone owns Bitcoins, what we mean is that he is in possession of a private key which corresponds to the public address to which those Bitcoins are associated.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
===
A private key in the context of bitcoin is a secret number that allows bitcoins to be spent.
Every bitcoin address has a matching private key, which is usually saved in the wallet file of the person who owns the balance but can be also stored using other means and methods.
The private key is mathematically related to the bitcoin address, and is designed so that the bitcoin address can be calculated from the private key but, importantly, the reverse cannot be done.
[https://en.wikipedia.org/wiki/Bitcoin_network]
===
private keys should not be stored on web servers,
[https://bitcoin.org/en/developer-guide#requesting-payments]
===
Private_Key_(Privkey):
A 256-bit number used in *ECDSA* algorithm to create transaction *signatures* in order to prove ownership of certain amount of bitcoins.
Can also be used in arbitrary *elliptic curve arithmetic* operations.
Private keys are stored within *wallet* applications and are usually encrypted with a pass phrase.
Private keys may be completely random (see *Key Pool*) or generated from a single secret number ("seed").
See also *Deterministic Wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcads'Public-key
Description::
Bob must first generate a private/public key pair before Alice can create the first transaction.
Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve; secp256k1 private keys are 256 bits of random data.
A copy of that data is deterministically transformed into an secp256k1 public key.
Because the transformation can be reliably repeated later, the public key does not need to be stored.
[https://bitcoin.org/en/developer-guide#transactions]
===
Public_Key_(Pubkey):
A 2D point on an elliptic curve secp256k1 that is produced by multiplying a predefined "generator" point by a *private key*.
Usually it is represented by a pair of 256-bit numbers ("uncompressed public key"), but can also be compressed to just one 256-bit number (at the slight expense of CPU time to decode an uncompressed number). A special hash of a public key is called *address*.
Typical Bitcoin transactions contain public keys or addresses in the output scripts and *signatures* in the input scripts.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-public-key,
* cpt.btcpublic-key,
* cpt.btcaddress'public-key,
* cpt.btcnet'public-key,
* cpt.btcwlt'public-key,
btcads'Version-number
Description::
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an address version number, the hash, and an error-detection checksum to catch typos.
[https://bitcoin.org/en/developer-guide#transactions]
btcads'Public-key-hash
Description::
The public key (pubkey) is then cryptographically hashed.
This pubkey hash can also be reliably repeated later, so it also does not need to be stored.
The hash shortens and obfuscates the public key, making manual transcription easier and providing security against unanticipated problems which might allow reconstruction of private keys from public key data at some later point.
[https://bitcoin.org/en/developer-guide#transactions]
Name::
* cpt.btcpubkey-hash,
* cpt.btcpublic-key-hash,
* cpt.public-key-hash-of-bitcoin,
btcads'Hash160
Description::
Hash160:
SHA-256 hashed with RIPEMD-160.
It is used to produce an *address* because it makes a smaller hash (20 bytes vs 32 bytes) than SHA-256, but still uses SHA-256 internally for security.
BTCHash160() in CoreBitcoin, Hash160() in BitcoinQT.
It is also available in scripts as OP_HASH160.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btchash160,
btcads'Error-detection-checksum
Description::
DESCRIPTION:
Address validation
A bitcoin address includes a four byte checksum, which means addresses can be validated without talking to any servers.
The bitcoin-address module (GitHub: shtylman / bitcoin-address, npm: bitcoin-address) by Roman Shtylman implements the algorithm: a double SHA-256 digest of the 21 bytes before the checksum is calculated to validate the address.
var btcAddr = require('bitcoin-address');
btcAddr.validate('1Gtov23WTQPbj4c6dMaXnXxbvFKc87Lutb');
// true
Addresses are encoded with base 58, so Roman’s module includes his own decoding library.
He also uses Node Buffer objects to work with the decoded data.
Node’s crypto core module is used to create SHA-256 hashes.
[http://dailyjs.com/2013/08/23/bitcoins/]
===
Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an address version number, the hash, and an error-detection checksum to catch typos.
[https://bitcoin.org/en/developer-guide#transactions]
btcads'Base58
Description::
A compact human-readable encoding for binary data invented by Satoshi Nakamoto to make more user-friendly addresses.
It consists of alphanumeric characters, but does not allow "0", "O", "I", "l" characters that look the same in some fonts and could be used to create visually identical looking addresses.
Lowercase "o" and "1" are allowed.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.Base58-of-Bitcoin,
* cpt.btcBase58,
btcads'Base58check
Description::
The method used in Bitcoin for converting 160-bit hashes into P2PKH and P2SH addresses.
Also used in other parts of Bitcoin, such as encoding private keys for backup in WIP format.
Not the same as other base58 implementations.
[https://bitcoin.org/en/glossary/base58check]
===
Base58Check:
A variant of Base58 encoding that appends first 4 bytes of Hash256 of the encoded data to that data before converting to Base58.
It is used in addresses to detect typing errors.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.Base58check-of-Bitcoin,
* cpt.btcBase58check,
* cpt.btcBitcoin-Address-Encoding,
btcads'Taint-analysis
Description::
Taint:
An analysis of how closely related two addresses are when they have both held a particular bitcoin.
A taint analysis could be used to determine how many steps it took for bitcoins to move from an address known for stolen coins, to the current address.
Name::
* cpt.bitcoin-taint-analysis,
* cpt.btctaint-analysis,
btcads'DOING
btcads'Creating
Description::
Wallet-programs create bitcoin-addresses for free.
btcads'Changing
Description::
Using a separate address for each incoming payment makes it trivial to determine which customers have paid their payment requests.
Your applications need only track the association between a particular payment request and the address used in it, and then scan the block chain for transactions matching that address.
[https://bitcoin.org/en/developer-guide#requesting-payments]
Name::
* cpt.bitcoin-key-reuse,
* cpt.btcads'changing,
* cpt.btcads'reusing,
* cpt.btckey-reuse,
Description::
Avoiding Key Reuse
In a transaction, the spender and receiver each reveal to each other all public keys or addresses used in the transaction. This allows either person to use the public block chain to track past and future transactions involving the other person’s same public keys or addresses.
If the same public key is reused often, as happens when people use Bitcoin addresses (hashed public keys) as static payment addresses, other people can easily track the receiving and spending habits of that person, including how many satoshis they control in known addresses.
It doesn’t have to be that way.
If each public key is used exactly twice—once to receive a payment and once to spend that payment—the user can gain a significant amount of financial privacy.
Even better, using new public keys or unique addresses when accepting payments or creating change outputs can be combined with other techniques discussed later, such as CoinJoin or merge avoidance, to make it extremely difficult to use the block chain by itself to reliably track how users receive and spend their satoshis.
Avoiding key reuse can also provide security against attacks which might allow reconstruction of private keys from public keys (hypothesized) or from signature comparisons (possible today under certain circumstances described below, with more general attacks hypothesized).
Unique (non-reused) P2PKH and P2SH addresses protect against the first type of attack by keeping ECDSA public keys hidden (hashed) until the first time satoshis sent to those addresses are spent, so attacks are effectively useless unless they can reconstruct private keys in less than the hour or two it takes for a transaction to be well protected by the block chain.
Unique (non-reused) private keys protect against the second type of attack by only generating one signature per private key, so attackers never get a subsequent signature to use in comparison-based attacks. Existing comparison-based attacks are only practical today when insufficient entropy is used in signing or when the entropy used is exposed by some means, such as a side-channel attack.
So, for both privacy and security, we encourage you to build your applications to avoid public key reuse and, when possible, to discourage users from reusing addresses. If your application needs to provide a fixed URI to which payments should be sent, please see the bitcoin: URI section below.
[https://bitcoin.org/en/developer-guide#avoiding-key-reuse]
AddressWpg::
* http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/
btcads.MULTISIG
Description::
Multisig:
Multi-signature addresses allow multiple parties to partially seed an address with a public key.
When someone wants to spend some of the bitcoins, they need some of these people to sign their transaction in addition to themselves.
The needed number of signatures is agreed at the start when people create the address.
Services using multi-signature addresses have a much greater resistance to theft.
Read more about Multisig here.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-multisig-address,
* cpt.btcmultisig-address,
btcads.P2SH
Description::
A Bitcoin payment address comprising a hashed script, allowing the spender to create a standard pubkey script that Pays To Script Hash (P2SH).
The script can be almost any valid pubkey script.
[https://bitcoin.org/en/glossary/p2sh-address]
Name::
* cpt.btcaddress.P2SH,
* cpt.btcP2SH,
* cpt.btcPay-To-Script-Hash,
btcads.VANITY
Description::
Vanity_address:
A bitcoin address with a desirable pattern, such as a name.
Name::
* cpt.bitcoin-vanity-address,
* cpt.btcvanity-address,
btcbcn'Transaction (btctx)
Description::
A chunk of binary data that describes how bitcoins are moved from one owner to another.
Transactions are stored in the *blockchain*.
Every transaction (except for *coinbase* transactions) has a reference to one or more previous transactions (*inputs*) and one or more rules on how to spend these bitcoins further (*outputs*).
See *Transaction Input* and *Transaction Output* for more info.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Bitcoins are the equivalent of Internet cash. You can send bitcoins over the Internet directly to anyone with no middle man. Like cash, Bitcoin transactions are irreversible. Bitcoins are traded worldwide.
[https://www.bitstamp.net/help/what-is-bitcoin/]
===
How do bitcoin transactions work?
Jan 9th 2015, 15:03 BY THE DATA TEAM
Even Satoshi Nakamoto, the elusive creator of bitcoin, admitted that his invention is hard to explain–because there is nothing you can compare it to. Here is how a bitcoin transaction is processed:
1) Payers initiate a bitcoin payment using "wallet" software.
2) This and other pending transactions are broadcast on the global bitcoin network.
3) Once every ten minutes or so, "miners", specialised computers (or groups of computers) on this network, collect a few hundred transactions and combine them in a "block".
4) In order to mine a block and validate the transaction, miners compete to solve a difficult mathematical equation (a "hash function"). The miner that solves the equation first further processes the block and broadcasts this "proof-of-work" to the bitcoin network.
5) The other miners check the proof-of-work and the validity of the transactions. If they approve, the winning miner gets a reward of 25 newly minted bitcoin (about $6,900 at current prices), which is the incentive for miners to provide computing power. Adjusting the difficulty of the puzzle ensures that the supply of new bitcoins remains steady.
6) The mined block is added to the "blockchain", a big, unbreakable ledger that lives on the bitcoin network and serves as a record of all transactions.
7) The payee can use his wallet software to see whether the bitcoin have arrived.
[http://www.economist.com/blogs/graphicdetail/2015/01/daily-chart-3]
Name::
* cpt.btcnet'blockchain-transaction,
* cpt.btcnet'transaction,
* cpt.bitcoin-transaction,
* cpt.btctransaction,
* cpt.btctrn,
* cpt.btctrn,
* cpt.btctx,
* cpt.btctransaction-record,
NameGreek::
* ενν.συναλλαγή-μπιτκόιν,
Whole::
* btc-block,
* btc-blockchain,
btctx'part.VERSION (4B)
Description::
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
nVersion / int (4 bytes) / Transaction format version (currently 1).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Each transaction is prefixed by a four-byte transaction version number which tells Bitcoin peers and miners which set of rules to use to validate it. This lets developers create new rules for future transactions without invalidating previous transactions.
===
Transaction version numbers will be a better way to specify exactly what rues should be used to validate a transaction; transactions with old version numbers will be validated under the old rules, transactions with new version numbers will always be validated under the new rules before being relayed or included in mined blocks. To avoid being in the minority fork of a block chain split, transactions with new version numbers appearing in blocks will only be validated using the new rules when a super-majority of the network (as expressed by block version numbers in the last N blocks) supports the new feature.
A transaction's version number is part of it's hash (transaction ID) and is part of the signature hash, so cannot be changed by an attacker. However, software using new transaction features will need to make sure that transactions have the correct version number before asking users to provide signatures or telling users that the transaction has been properly signed, etc.
[https://gist.github.com/gavinandresen/2355445]
Name::
* cpt.btctx'version,
===
* cpt.btctx'version,
* cpt.btcnVersion,
* cpt.btctransaction-version-number,
btctx'part.INPUT
Description::
An input
- references an output in a previous transaction — a transaction ID (the hash of the transaction data) and output index — and
- provides a script, known as the scriptSig, that satifies the output script conditions.
[http://joncave.co.uk/2014/08/bitcoin-sighash-single/]
===
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Transaction_Input:
A part of a transaction that contains
- a reference to a previous transaction's *output*
- and a *script* that can prove ownership of that output.
The script usually contains a *signature* and thus called *scriptSig*.
Inputs spend previous outputs completely.
So if one needs to pay only a portion of some previous output, the transaction should include extra *change* output that sends the remaining portion back to its owner (on the same or different address).
*Coinbase* transactions contain only one input with a zeroed reference to a previous transaction and an arbitrary data in place of script.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Each transaction has at least one input and one output. Each input spends the satoshis paid to a previous output.
[https://bitcoin.org/en/developer-guide#transactions]
===
An input in a transaction which contains four fields:
- an outpoint,
- a signature script, and
- a sequence number.
The outpoint references a previous output and the signature script allows spending it.
[https://bitcoin.org/en/glossary/input]
===
Each transaction spends the satoshis previously received in one or more earlier transactions, so the input of one transaction is the output of a previous transaction.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
===
Input:
The part of a bitcoin transaction denoting where the bitcoin payment has come from.
Typically, this will be a bitcoin address, unless the transaction is a generation transaction, meaning that the bitcoin has been freshly mined (see Coinbase).
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-transaction-input,
* cpt.btcInput,
* cpt.btctx'input,
* cpt.btcTransaction-Input,
* cpt.btcTxin,
btctxinpt'part.OUTPOINT (32B+4B)
Description::
The data structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout).
[https://bitcoin.org/en/glossary/outpoint]
===
Outpoint (the combination of a txid with a vout used to identify a specific output)
[https://bitcoin.org/en/glossary/txid]
Name::
* cpt.btctxinpt'outpoint,
* cpt.btcoutpoint,
* cpt.btctx'outpoint
Name::
* cpt.btctx'id,
==
* cpt.btctxinpt'txid,
* cpt.btcTransaction-Identifier,
* cpt.btcTxid,
* cpt.btctx'id,
btctxinpt'vout (4B)
Description::
An input uses a transaction identifier (txid) and an output index number (often called “vout” for output vector) to identify a particular output to be spent.
[https://bitcoin.org/en/developer-guide#transactions]
Name::
* cpt.btcoutput-index-number,
* cpt.btcoutput-vector,
btctxinpt'part.SEQUENCE-NUMBER
Description::
Part of all transactions.
A number intended to allow unconfirmed time-locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction
[https://bitcoin.org/en/glossary/sequence-number]
===
Sequence:
A 32-bit unsigned integer in a transaction input used to replace older version of a transaction by a newer one.
Only used when *locktime* is not zero.
Transaction is not considered valid until the sequence number is 0xFFFFFFFF.
By default, the sequence is 0xFFFFFFFF.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btctxinpt'sequence-number,
* cpt.btcsequence-number,
* cpt.btctx'sequence-number
btctxinpt'part.SIGNATURE-SCRIPT (link)
btctxinpt'Coinbase
Description::
A special field used as the sole input for coinbase transactions.
The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.
[https://bitcoin.org/en/glossary/coinbase]
===
Coinbase:
An input script of a transaction that generates new bitcoins. Or a name of that transaction itself ("coinbase transaction"). Coinbase transaction does not spend any existing transactions, but contains exactly one input which may contain any data in its script. *Genesis block* transaction contains a reference to The Times article from January 3rd 2009 to prove that more blocks were not created before that date. Some *mining pools* put their names in the coinbase transactions (so everyone can estimate how much *hashrate* each pool produces).
Coinbase is also used to vote on a protocol change (e.g. *P2SH*). Miners vote by putting some agreed-upon marker in the coinbase to see how many support the change. If a majority of miners support it and expect non-mining users to accept it, then they simply start enforcing new rule. Minority then should either continue with a forked blockchain (thus producing an *altcoin*) or accept new rule.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-coinbase,
* cpt.btccoinbase,
btctxinpt'Hash-type
Description::
Hash_Type_(hashtype):
A single byte appended to a transaction *signature* in the *transaction input* which describes how the transaction should be hashed in order to verify that signature.
There are three types affecting outputs:
ALL (default), SINGLE, NONE and one optional modifier ANYONECANPAY affecting the inputs (can be combined with either of the first three).
ALL requires all outputs to be hashed (thus, all outputs are signed).
SINGLE clears all output scripts but the one with the same index as the input in question.
NONE clears all outputs thus allowing changing them at will.
ANYONECANPAY removes all inputs except the current one (allows anyone to contribute independently).
The actual behavior is more subtle than this overview, you should check the actual source code for more comments.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btchash-type,
* cpt.btchashtype,
btctx'part.OUTPUT (btctxout)
Description::
An output in a transaction which contains two fields:
- a value field for transferring zero or more satoshis and
- a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.
[https://bitcoin.org/en/glossary/output]
Name::
* cpt.bitcoin-transaction-output,
* cpt.btcOutput,
* cpt.btcTransaction-Output,
* cpt.btctx'output,
* cpt.btcTxOut,
Description::
Each transaction has at least one input and one output.
Each input spends the satoshis paid to a previous output.
Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it.
When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis waiting in one or more UTXOs.
[https://bitcoin.org/en/developer-guide#transactions]
Description::
A single transaction can create multiple outputs, as would be the case when sending to multiple addresses, but each output of a particular transaction can only be used as an input once in the block chain.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
Description::
The destination address for a bitcoin transaction.
There can be multiple outputs for a single transaction.
[http://www.coindesk.com/information/bitcoin-glossary/]
Description::
Transaction_Output:
An output contains an amount to be sent and a *script* that allows further spending.
The script typically contains a *public key* (or an *address*, a hash of a public key) and a signature verification *opcode*.
Only an owner of a corresponding *private key* is able to create another transaction that sends that amount further to someone else.
In every transaction, the sum of output-amounts must be equal or less than a sum of all input amounts.
See also *Change*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btctxout'part.PUBKEY|OUTPUT-SCRIPT (link)
btctxout.CHANGE
Description::
An output in a transaction which returns satoshis to the spender, thus preventing too much of the input value from going to transaction fees.
[https://bitcoin.org/en/glossary/change-address]
Name::
* cpt.btcChange,
* cpt.btcChange-Output,
NameGreek::
* ενν.επιστροφή-μπιτκόιν,
* ενν.ρέστα-μπιτκόιν,
Description::
Change outputs are regular outputs which spend the surplus satoshis from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash or P2SH script hash as was used in the UTXO, but for the reasons described in the next subsection, it is highly recommended that change outputs be sent to a new P2PKH or P2SH address.
[https://bitcoin.org/en/developer-guide#transaction-fees-and-change]
===
Change:
Informal name for a portion of a *transaction output* that is returned to a sender as a "change" after spending that output.
Since *transaction outputs* cannot be partially spent, one can spend 1 BTC out of 3 BTC output only be creating two new outputs: a "payment" output with 1 BTC sent to a payee address, and a "change" output with remaining 2 BTC (minus *transaction fees*) sent to the payer's addresses.
*BitcoinQT* always uses new address from a *key pool* for a better privacy.
*Blockchain.info* sends to a default address in the wallet.
A common mistake when working with a *paper wallet* or a *brain wallet* is to make a change transaction to a different address and then accidentally delete it.
E.g. when importing a private key in a temporary BitcoinQT wallet, making a transaction and then deleting the temporary wallet.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btctxout.DUST
Description::
Dust:
A transaction output that is smaller than a typically fee required to spend it. This is not a strict part of the protocol, as any amount more than zero is valid. BitcoinQT refuses to mine or relay "dust" transactions to avoid uselessly increasing the size of unspent transaction outputs (UTXO) index. See also discussion about *UTXO*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcdust-transaction-output,
btctxout.MULTISIG
Description::
M-of-N-Multisig, Multisig-Output:
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
Name::
* cpt.btcm-of-n-multisig,
* cpt.btcmultisig-output,
btctxout.SPENT
Description::
Used as input in another transaction.
[hmnSgm.2017-02-18]
===
Because each output of a particular transaction can only be spent once, the outputs of all transactions included in the block chain can be categorized as either Unspent Transaction Outputs (UTXOs) or spent transaction outputs.
[https://bitcoin.org/en/developer-guide#block-chain-overview]
===
#idBtc1Spent_Output#
A transaction *output* can be spent only once: when another valid transaction makes a reference to this output from its own input.
When another transaction attempts to spend the same output, it will be rejected by the nodes already seeing the first transaction.
Blockchain as a *proof-of-work* scheme allows every node to agree on which transaction was indeed the first one.
The whole transaction is considered spent when all its outputs are spent.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcSpent-Transaction-Output,
btctxout.SPENT.NO (unspent UTXO)
Description::
An Unspent Transaction Output (UTXO) that can be spent as an input in a new transaction.
[https://bitcoin.org/en/glossary/unspent-transaction-output]
Name::
* cpt.bitcoin-Unspent-Transaction-Output,
* cpt.btctx'UTXO,
* cpt.btctxout.UTXO,
* cpt.btcUnspent-Transaction-Output,
* cpt.btcUTXO,
UTXO-SET
Description::
UTXO_Set:
A collection of *Unspent Transaction Outputs*.
Typically used in discussions on optimizing an ever-growing index of *transaction outputs* that are not yet *spent*.
The index is important to efficiently validate newly created transactions.
Even if the rate of the new transactions remains constant, the time required to locate and verify unspent outputs grows.
Possible technical solutions include more efficient indexing algorithms and a more performant hardware.
*BitcoinQT*, for example, keeps only an index of outputs matching user's keys and scans the entire blockchain when validating other transactions.
A developer of one web wallet service mentioned that they maintain the entire index of UTXO and its size was around 100 Gb when the blockchain itself was only 8 Gb.
Some people seek social methods to solve the problem.
For instance, by refusing to *relay* or *mine* transactions that are considered *dust* (containing outputs smaller than a *transaction fee* required to mine/relay them).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-Unspent-Transaction-Output-Set,
* cpt.btctx'UTXO-set,
* cpt.btctxout.UTXO-set,
* cpt.btcUnspent-Transaction-Output-set,
* cpt.btcUTXO-set,
btctx'part.LOCKTIME (4Bytes)
Description::
Part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
[https://bitcoin.org/en/glossary/locktime]
===
One thing all signature hash types sign is the transaction’s locktime. (Called nLockTime in the Bitcoin Core source code.) The locktime indicates the earliest time a transaction can be added to the block chain.
Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.
If any of the signers change their mind, they can create a new non-locktime transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an input to the locktime transaction. This makes the locktime transaction invalid if the new transaction is added to the block chain before the time lock expires.
[https://bitcoin.org/en/developer-guide#locktime-and-sequence-number]
===
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
Lock_Time_(locktime):
A 32-bit field in a *transaction* that means either a block *height* at which the transaction becomes valid, or a UNIX timestamp.
Zero means transaction is valid in any block.
A number less than 500000000 is interpreted as a block number (the limit will be hit after year 11000), otherwise a timestamp.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btctx'locktime,
* cpt.btcLocktime,
* cpt.btcnLockTime,
btctx'Fee
Description::
Fees are relatively unimportant at the moment since “miners” who successfully process a block of transactions are rewarded with newly created bitcoin. However, fees will become more important in the future because the amount of new bitcoin issued to a successful miner is cut in half roughly every four years. If increasing the block size lowers the transaction fees miners can expect to receive, one would expect fewer miners competing to process transactions as the block reward decreases over time. The bitcoin system would become more centralized as a result.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
===
Transaction_Fee:
Also known as "miners' fee", an amount that an author of transaction pays to a miner who will include the transaction in a block.
The fee is expressed as difference between the sum of all *input* amounts and a sum of all *output* amounts.
Unlike traditional payment systems, miners do not explicitly require fees and most miners allow free transactions.
All miners are competing between each other for the fees and all transactions are competing for a place in a block.
There are soft rules encoded in most clients that define minimum fees per kilobyte to relay or mine a transaction (mostly to prevent *DoS* and *spam*).
Typically, the fee affects the priority of a transaction.
As of July 27, 2014 average fee per block is below 0.1 BTC.
See also *Reward*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
The amount remaining when the value of all outputs in a transaction are subtracted from all inputs in a transaction; the fee is paid to the miner who includes that transaction in a block.
[https://bitcoin.org/en/glossary/transaction-fee]
===
A small fee imposed on some transactions sent across the bitcoin network.
The transaction fee is awarded to the miner that successfully hashes the block containing the relevant transaction.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many transactions are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.
The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.
Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.
It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.
[https://en.bitcoin.it/wiki/Transaction_fees]
Name::
* cpt.btctx'fee,
* cpt.btcfee,
* cpt.btcTransaction-Fee,
* cpt.btcMiner-Fee,
* cpt.btcMiners-Fee,
* cpt.bitcoin-transaction-fee,
NameGreek::
* ενν.τέλη-μπικόιν-συναλλαγής,
* ενν.χρέωση-μπικόιν-συναλλαγής,
AddressWpg::
* http://cointelegraph.com/news/bitcoins-transaction-fees-skyrocket-as-the-bitcoin-halving-looms,
Having almost tripled since last summer, Bitcoin transaction fees continue to grow. {2016-05-15}
* New Service Finds Optimum Bitcoin Transaction Fee,
{time.2017-02-18}
Now, the average fee to have a transaction included in the next six blocks or roughly one hour is $0.37, higher than many card processors’ fees.
[https://cointelegraph.com/news/bitcoin-fork-soon-bitcoin-unlimited-surges-past-segwit-core-blocks-drop-below-75]
btctx'Format.Binary
Description::
All transactions, including the coinbase transaction, are encoded into blocks in binary rawtransaction format.
[https://bitcoin.org/en/developer-guide#transaction-data]
Name::
* cpt.btcxt'binary-format,
* cpt.btcxt'raw-format,
===
* cpt.btcTransaction-format,
* cpt.btcrawtransaction-format,
btctx'Script-language (btcstl)
Description::
Bitcoin uses a scripting system for transactions.
Forth-like, Script is simple, stack-based, and processed from left to right.
It is purposefully not Turing-complete, with no loops.
[https://en.bitcoin.it/wiki/Script]
===
The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete.
Statelessness ensures that once a transaction is added to the block chain, there is no condition which renders it permanently unspendable.
Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model.
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
===
A decentralized transaction verification system (transaction script)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
The scripting language is stack-based, this means that each data, input or output is put on a stack of other data.
[https://docs.google.com/document/d/1D_gi_7Sf9sOyAHG25cMpOO4xtLq3iJUtjRwcZXFLv1E/edit]
===
Pubkey scripts and signature scripts combine secp256k1 pubkeys and signatures with conditional logic, creating a programmable authorization mechanism.
[https://bitcoin.org/en/developer-guide#transactions]
Name::
* cpt.btcstl,
* cpt.btctx'script-language,
* cpt.bitcoin-scripting-system,
===
* cpt.bitcoin-script-language,
* cpt.btcscripting-language,
* cpt.btctransaction-script,
* cpt.btcnet'transaction-script,
btcstl'Script
Description::
Script is code written with the-bitcoin-script-language.
[hmnSgm.2017-04-06]
Name::
* cpt.bitcoin-script,
* cpt.btcscript,
* cpt.btcstl'script,
NameGreek::
* ενν.σενάριο-μπιτκόιν,
Description::
Script:
A compact turing-incomplete programming language used in transaction *inputs* and *outputs*.
Scripts are interpreted by a Forth-like stack machine: each operation manipulates data on the stack.
Most scripts follow the standard pattern and verify the digital *signature* provided in the transaction *input* against a *public key* provided in the previous transaction's *output*.
Both signatures and public keys are provided using scripts.
Scripts may contain complex conditions, but can never change amounts being transferred.
Amount is stored in a separate field in a *transaction output*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcstl'script'Opcode
Description::
Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
[https://bitcoin.org/en/glossary/op-code]
===
Opcode:
8-bit code of a *script* operation.
Codes from 0x01 to 0x4B (decimal 75) are interpreted as a length of data to be pushed on the stack of the interpreter (data bytes follow the opcode).
Other codes are either do something interesting, or disabled and cause transaction verification to fail, or do nothing (reserved for future use).
See also *Script*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-opcode,
* cpt.btctx'Op-Code,
* cpt.btcopcode,
* cpt.btcop-code,
AddressWpg::
* https://en.bitcoin.it/wiki/Script,
btcOP_CHECKSIG:
btcOP_DUP:
btcOP_EQUALVERIFY:
btcOP_HASH160:
btcstl'script.Pubkey-script (output)
Name::
* cpt.bitcoin-output-script,
* cpt.btcoutput-script,
* cpt.btcpubkey-script,
* cpt.btcscriptOutput,
* cpt.btcScriptPubKey,
* cpt.btctxotp'pubkey-script,
Whole::
* bitcoin-transaction's-output,
Description::
The output also has an amount in satoshis which it pays to a conditional pubkey script.
Anyone who can satisfy the conditions of that pubkey script can spend up to the amount of satoshis paid to it.
[https://bitcoin.org/en/developer-guide#transactions]
===
A script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent.
Data for fulfilling the conditions can be provided in a signature script.
Called a scriptPubKey in code.
[https://bitcoin.org/en/glossary/pubkey-script]
===
scriptPubKey:
Original name in *bitcoind* for a transaction *output* script.
Typically, output scripts contain *public keys* (or their hashes; see *Address*) that allow only owner of a corresponding *private key* to redeem the bitcoins in the output.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Description::
Pubkey
Pubkey outputs are a simplified form of the P2PKH pubkey script, but they aren’t as secure as P2PKH, so they generally aren’t used in new transactions anymore.
Pubkey script: <pubkey> OP_CHECKSIG
Signature script: <sig>
[https://bitcoin.org/en/developer-guide#pubkey]
btcscriptPubKey.multisig
Description::
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
Name::
* cpt.btcM-of-N-Multisig,
* cpt.btcmultisig,
* cpt.btcMultisig-Output,
btcscriptSig'secp256k1-signature
Description::
Signature, ECDSA Signature
A value related to a public key which could only have reasonably been created by someone who has the private key that created that public key. Used in Bitcoin to authorize spending satoshis previously sent to a public key.
[https://bitcoin.org/en/glossary/signature]
Name::
* cpt.btcscriptSig'sig,
* cpt.btcscriptSig'signature,
* cpt.btcsecp256k1-signature,
* cpt.btcstl'sig,
* cpt.btcECDSA-signature,
btcstl'secp256k1_signature
btcscriptSig.P2PKH-address
Description::
In a P2PKH transaction, the signature script contains an secp256k1 signature (sig) and full public key (pubkey), creating the following concatenation:
<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
Name::
* cpt.btcscriptSig.P2PKH,
btcstl'script.P2PKH
Description::
Pay To Public Key Hash (P2PKH)
P2PKH is the most common form of pubkey script used to send a transaction to one or multiple Bitcoin addresses.
Pubkey script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Signature script: <sig> <pubkey>
[https://bitcoin.org/en/developer-guide#standard-transactions]
btcstl'script.P2SH
Description::
Pay To Script Hash (P2SH)
P2SH is used to send a transaction to a script hash.
Each of the standard pubkey scripts can be used as a P2SH redeem script, but in practice only the multisig pubkey script makes sense until more transaction types are made standard.
Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Signature script: <sig> [sig] [sig...] <redeemScript>
[https://bitcoin.org/en/developer-guide#pay-to-script-hash-p2sh]
===
Pay_to_Script_Hash:
A type of the *script* and *address* that allows sending bitcoins to arbitrary complex scripts using a compact hash of that script.
This allows payer to pay much smaller *transaction fees* and not wait very long for a *non-standard* transaction to get included in the blockchain.
Then the actual script matching the hash must be provided by the payee when redeeming the funds.
P2SH addresses are encoded in *Base58Check* just like regular public keys and start with number "3".
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcstl'script.Multisig
Description::
Multisig
Although P2SH multisig is now generally used for multisig transactions, this base script can be used to require multiple signatures before a UTXO can be spent.
In multisig pubkey scripts, called m-of-n, m is the minimum number of signatures which must match a public key; n is the number of public keys being provided. Both m and n should be opcodes OP_1 through OP_16, corresponding to the number desired.
Because of an off-by-one error in the original Bitcoin implementation which must be preserved for compatibility, OP_CHECKMULTISIG consumes one more value from the stack than indicated by m, so the list of secp256k1 signatures in the signature script must be prefaced with an extra value (OP_0) which will be consumed but not used.
The signature script must provide signatures in the same order as the corresponding public keys appear in the pubkey script or redeem script. See the description in OP_CHECKMULTISIG for details.
Pubkey script: <m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> [B sig] [C sig...]
Although it’s not a separate transaction type, this is a P2SH multisig with 2-of-3:
Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Redeem script: <OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> <C sig> <redeemScript>
[https://bitcoin.org/en/developer-guide#multisig]
btcstl'script.Null-data
Description::
Null Data
Null data transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. It is preferable to use null data transactions over transactions that bloat the UTXO database because they cannot be automatically pruned; however, it is usually even more preferable to store data outside transactions if possible.
Consensus rules allow null data outputs up to the maximum allowed pubkey script size of 10,000 bytes provided they follow all other consensus rules, such as not having any data pushes larger than 520 bytes.
Bitcoin Core 0.9.x to 0.10.x will, by default, relay and mine null data transactions with up to 40 bytes in a single data push and only one null data output that pays exactly 0 satoshis:
Pubkey Script: OP_RETURN <0 to 40 bytes of data>
(Null data scripts cannot be spent, so there's no signature script.)
Bitcoin Core 0.11.x increases this default to 80 bytes, with the other rules remaining the same.
Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis.
The -datacarriersize Bitcoin Core configuration option allows you to set the maximum number of bytes in null data outputs that you will relay or mine.
[https://bitcoin.org/en/developer-guide#null-data]
btcstl'Evaluation
Description::
However, the scripting language as implemented in Bitcoin has several important limitations:
Lack of Turing-completeness - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code.
Value-blindness -
there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B.
This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.
However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.
Lack of state -
UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties).
It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement.
Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.
Blockchain-blindness -
UTXO are blind to certain blockchain data such as the nonce and previous block hash.
This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness.
[https://github.com/ethereum/wiki/wiki/White-Paper#scripting]
btcstl'Execution
Description::
To test whether the transaction is valid, signature script and pubkey script operations are executed one item at a time, starting with Bob’s signature script and continuing to the end of Alice’s pubkey script.
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
===
scriptIpt: <Sig> <PubKey>
scriptOpt: OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
Name::
* cpt.btcspt'execution,
* cpt.btcspt'validation,
* cpt.btcspt'verification,
DOING:
1. CODE: <Sig> STACK: <Sig>
The signature (from Bob’s signature script) is added (pushed) to an empty stack. Because it’s just data, nothing is done except adding it to the stack.
2. CODE: <PubKey> STACK: <PubKey><Sig>
The public key (also from the signature script) is pushed on top of the signature.
3. CODE: OP_DUP STACK: <PubKey><PubKey><Sig>
From Alice’s pubkey script, the OP_DUP operation is executed. OP_DUP pushes onto the stack a copy of the data currently at the top of it—in this case creating a copy of the public key Bob provided.
4. CODE: OP_HASH160 STACK: <PubKeyHash><PubKey><Sig>
The operation executed next, OP_HASH160, pushes onto the stack a hash of the data currently on top of it—in this case, Bob’s public key. This creates a hash of Bob’s public key.
5. CODE: <PubKeyHash> STACK: <PubKeyHash><PubKeyHash><PubKey><Sig>
Alice’s pubkey script then pushes the pubkey hash that Bob gave her for the first transaction. At this point, there should be two copies of Bob’s pubkey hash at the top of the stack.
6. CODE: OP_EQUALVERIFY STACK: <PubKey><Sig>
Now it gets interesting: Alice’s pubkey script executes OP_EQUALVERIFY.
OP_EQUALVERIFY is equivalent to executing OP_EQUAL followed by OP_VERIFY (not shown).
OP_EQUAL (not shown) checks the two values at the top of the stack; in this case, it checks whether the pubkey hash generated from the full public key Bob provided equals the pubkey hash Alice provided when she created transaction #1.
OP_EQUAL pops (removes from the top of the stack) the two values it compared, and replaces them with the result of that comparison: zero (false) or one (true).
OP_VERIFY (not shown) checks the value at the top of the stack.
If the value is false it immediately terminates evaluation and the transaction validation fails.
Otherwise it pops the true value off the stack.
7. CODE: OP_CHECKSIG STACK: true
Finally, Alice’s pubkey script executes OP_CHECKSIG, which checks the signature Bob provided against the now-authenticated public key he also provided.
If the signature matches the public key and was generated using all of the data required to be signed, OP_CHECKSIG pushes the value true onto the top of the stack.
If false is not at the top of the stack after the pubkey script has been evaluated, the transaction is valid (provided there are no other problems with it).
[https://bitcoin.org/en/developer-guide#p2pkh-script-validation]
btctx'Priority
Description::
Priority
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A transaction fee will affect priority.
[https://en.bitcoin.it/wiki/Vocabulary#Priority]
Name::
* cpt.btcpriority,
btctx'Visibility
Description::
Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block.
All transactions are visible in the block chain, and can be viewed with a hex editor.
A block chain browser is a site where every transaction included within the block chain can be viewed in human-readable terms.
This is useful for seeing the technical details of transactions in action and for verifying payments.
[https://en.bitcoin.it/wiki/Transaction]
btctx'DOING
btctx'Confirmation
Description::
Confirmation means that a transaction has been processed by the network and is highly unlikely to be reversed.
Transactions receive a confirmation when they are included in a block and for each subsequent block.
Even a single confirmation can be considered secure for low value transactions, although for larger amounts like 1000 US$, it makes sense to wait for 6 confirmations or more.
Each confirmation exponentially decreases the risk of a reversed transaction.
[https://bitcoin.org/en/vocabulary#confirmation]
===
Unconfirmed transactions aren't secure
Transactions don't start out as irreversible. Instead, they get a confirmation score that indicates how hard it is to reverse them (see table). Each confirmation takes between a few seconds and 90 minutes, with 10 minutes being the average. If the transaction pays too low a fee or is otherwise atypical, getting the first confirmation can take much longer.
Confirmations Lightweight wallets Bitcoin Core
0 Only safe if you trust the person paying you
1 Somewhat reliable Mostly reliable
3 Mostly reliable Highly reliable
6 Minimum recommendation for high-value bitcoin transfers
30 Recommendation during emergencies to allow human intervention
[https://bitcoin.org/en/you-need-to-know#instant]
===
Confirmation:
The act of hashing a bitcoin transaction successfully into a transaction block, and cementing its validity.
A single confirmation will take around 10 minutes, which is the average length of time for a transaction block to be hashed.
However, some more sensitive or larger transactions may require multiple confirmations, meaning that more blocks must be hashed and added to the blockchain after the transaction’s block has been hashed.
Each time another block is added to the blockchain after the transaction’s block, the transaction is confirmed again.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-transaction-confirmation,
* cpt.btcconfirmation,
* cpt.btctransaction-confirmation,
NameGreek::
* ενν.επιβεβαίωση-συναλλαγής-μπιτκόιν,
SPECIFIC
Name::
* btctx.specific,
* cpt.btctx.specific,
btctx.AGGREGATE
btctx.aggregate.SECOND
With Thunder, a transaction is so fast that the network can process 100,000 transactions per second. On average, Visa handles 2,000 transactions per second and the Visa network is capable of processing 56,000 transactions per second.
To put this into perspective, Blockchain wallet users are on track to make 40 million transactions this year, or around 1.3 transaction per second. Quite impressive, but let’s be honest. While there are many other wallets out there, given that Blockchain is the most popular wallet maker, bitcoin transaction volume is very far behind Visa. Reason of this lies in the fact that bitcoin transactions have been too cumbersome. So I’m convinced projects like Thunder are part of the solution.
[http://techcrunch.com/2016/05/16/blockchain-open-sources-thunder-network-paving-the-way-for-instant-bitcoin-transactions/?ncid=rss]
btctx.BINARY (raw)
Description::
Serialized Transaction, Raw Transaction
Complete transactions in their binary format; often represented using hexadecimal.
Sometimes called raw format because of the various Bitcoin Core commands with “raw” in their names.
[https://bitcoin.org/en/glossary/serialized-transaction]
===
All transactions, including the coinbase transaction, are encoded into blocks in binary rawtransaction format.
The rawtransaction format is hashed to create the transaction identifier (txid).
[https://bitcoin.org/en/developer-guide#transaction-data]
Name::
* cpt.btctx.binary,
* cpt.btctx.hexadecimal,
* cpt.btctx.raw,
* cpt.btcbinary-transaction-format,
* cpt.btcSerialized-Transaction,
* cpt.btcRaw-Transaction,
* cpt.btcRaw-Transaction-format,
btctx.COINBASE (new bitcoin)
Description::
In principle, there are two types of transactions, coinbase transactions and regular transactions.
Coinbase transactions are special transactions in which new Bitcoins are introduced into the system.
They are included in every block as the very first transaction and are meant as a reward for solving a proof of work puzzle.
Regular transactions, on the other hand, are used to transfer existing Bitcoins amongst different users.
From an architectural point of view, a coinbase transaction can be seen as a special case of a regular transaction.
For this reason, the structure of a regular transaction will be discussed first, followed by the differences between coinbase and regular transactions.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
===
The first transaction in a block.
Always created by a miner, it includes a single coinbase.
[https://bitcoin.org/en/glossary/coinbase-transaction]
===
Coinbase transactions can only be created by Bitcoin miners and they’re an exception to many of the rules listed below.
[https://bitcoin.org/en/developer-guide#transactions]
===
Coinbase:
Another name for the input used in a bitcoin’s generation transaction.
When a bitcoin is mined, it doesn't come from another bitcoin user, but is generated as a reward for the miner.
That reward is recorded as a transaction, but instead of another user's bitcoin address, some arbitrary data is used as the input.
Coinbase is also the name of a bitcoin wallet service that also offers payment processing services for merchants and acts as an intermediary for purchasing bitcoins from exchanges.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-coinbase-transaction,
* cpt.btctx.coinbase,
* cpt.btccoinbase-transaction,
* cpt.btcgeneration-transaction,
* cpt.btctx.generation,
btctxCnbs'Extra-nonce
Description::
Extra_nonce:
A number placed in *coinbase* script and incremented by a miner each time the *nonce* 32-bit integer overflows.
This is not the required way to continue mining when nonce overflows, one can also change the *merkle tree* of transactions or change a public key used for collecting a block *reward*.
See also *nonce*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-extra-nonce,
* cpt.btcextra-nonce,
btctxCnbs'UTXO
Description::
UTXO:
The UTXO of a coinbase transaction has the special condition that it cannot be spent (used as an input) for at least 100 blocks.
This temporarily prevents a miner from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork.
[https://bitcoin.org/en/developer-guide#transaction-data]
Generic::
* bitcoin-UTXO,
btctx.COINBASE.NO (regular)
Description::
In principle, there are two types of transactions, coinbase transactions and regular transactions.
Coinbase transactions are special transactions in which new Bitcoins are introduced into the system.
They are included in every block as the very first transaction and are meant as a reward for solving a proof of work puzzle.
Regular transactions, on the other hand, are used to transfer existing Bitcoins amongst different users.
From an architectural point of view, a coinbase transaction can be seen as a special case of a regular transaction.
For this reason, the structure of a regular transaction will be discussed first, followed by the differences between coinbase and regular transactions.
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
Name::
* cpt.btcregular-transaction,
* cpt.btctx.regular,
Part::
Every transaction consists of
- a transaction version (nVersion),
- a vector of inputs (vin) and
- a vector of outputs (vout), both preceded by their count, and
- a transaction inclusion date (nLockTime).
[https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf]
btctx.CONFIRMED
Description::
Confirmed_Transaction:
Transaction that has been included in the blockchain.
Probability of transaction being rejected is measured in a number of confirmations.
See *Confirmation Number*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Confirmation Score: A score indicating the number of blocks on the best block chain that would need to be modified to remove or modify a particular transaction.
A confirmed transaction has a confirmation score of one or higher.
[https://bitcoin.org/en/glossary/confirmation-score]
Name::
* cpt.btcConfirmed-transaction,
Confirmation-Number
Description::
Confirmation_Number:
Confirmation number is a measure of probability that transaction could be rejected from the *main chain*.
"Zero confirmations" means that transaction is *unconfirmed* (not in any block yet).
One confirmation means that the transaction is included in the latest block in the main chain.
Two confirmations means the transaction is included in the block right before the latest one.
And so on.
Probability of transaction being reversed (*"double spent"*) is diminishing exponentially with more blocks added "on top" of it.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcconfirmation-number,
* cpt.btctx'confirmation-number,
Zero-confirmation-transaction
Description::
Zero_confirmation_transaction:
A transaction in which the merchant is happy to provide a product or service before the bitcoin’s transmission has been confirmed by a miner and added to the blockchain.
It can carry a risk of double spending.
Name::
* cpt.bitcoin-Zero-confirmation-transaction:
* cpt.btcZero-confirmation-transaction:
btctx.CONFIRMED.NO
Description::
Unconfirmed_Transaction:
Transaction that is not included in any block.
Also known as "0-confirmation" transaction.
Unconfirmed transactions are *relayed* by the nodes and stay in their *mempools*.
Unconfirmed transaction stays in the pool until the node decides to throw it away, finds it in the blockchain, or includes it in the blockchain itself (if it's a miner).
See also *Confirmation Number*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btc0-confirmation-transaction,
* cpt.btcUnconfirmed-transaction,
* cpt.btczero-confirmation-transaction,
btctx.CONTRACT
Description::
Contracts are transactions which use the decentralized Bitcoin system to enforce financial agreements.
Bitcoin contracts can often be crafted to minimize dependency on outside agents, such as the court system, which significantly decreases the risk of dealing with unknown entities in financial transactions.
[https://bitcoin.org/en/developer-guide#contracts]
Name::
* cpt.btccontract,
* cpt.bitcoin-contract,
btctx.DUST
Description::
Dust transaction
A transaction for an extremely small amount of bitcoins, which offers little financial value, but takes up space in the blockchain.
The bitcoin developer team has taken efforts to eliminate dust transactions by increasing the minimum transaction amount that will be relayed by the network.
[http://www.coindesk.com/information/bitcoin-glossary/#dusttransaction]
Name::
* cpt.btcDust-Transaction,
btctx.HIGH-PRIORITY
Description::
Transactions that don’t have to pay a transaction fee because their inputs have been idle long enough to accumulated large amounts of priority.
Note: miners choose whether to accept free transactions.
[https://bitcoin.org/en/glossary/high-priority-transaction]
Name::
* cpt.btcHigh-Priority-Transaction,
* cpt.btcFree-Tx,
btctx.MULTISIG
Description::
M-of-N Multisig, Multisig Output
A pubkey script that provides n number of pubkeys and requires the corresponding signature script provide m minimum number signatures corresponding to the provided pubkeys.
[https://bitcoin.org/en/glossary/multisig]
===
M_of_N_Multi_signature_Transaction:
A transaction that can be spent using M signatures when N public keys are required (M is less or equal to N).
Multi-signature transactions that only contain one *OP_CHECKMULTISIG* opcode and N is 3, 2 or 1 are considered standard.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btctx.multisig,
* cpt.btcM-of-N-Multi-signature-Transaction,
* cpt.btcMultisig-transaction,
btctx.P2PKH
Name::
* cpt.btcPay-To-Public-Key-Hash-transaction,
* cpt.btcP2PKH-transaction,
btctx.P2SH
Description::
Pubkey scripts are created by spenders who have little interest what that script does. Receivers do care about the script conditions and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and there was no standard way to communicate them between programs prior to widespread implementation of the BIP70 Payment Protocol discussed later.
To solve these problems, pay-to-script-hash (P2SH) transactions were created in 2012 to let a spender create a pubkey script containing a hash of a second script, the redeem script.
[https://bitcoin.org/en/developer-guide#p2sh-scripts]
Name::
* cpt.btctx.P2SH,
* cpt.btcPay-To-Script-Hash-transaction,
btctx.RELAYING
Description::
Relaying_Transactions:
Connected Bitcoin *nodes* relay new transactions between each other on best effort basis in order to send them to the *mining* nodes.
Some transactions may not be relayed by all nodes.
E.g. *non-standard* transactions, or transactions without a minimum *fee*.
Bitcoin message protocol is not the only way to send the transaction.
One may also send it directly to a miner, or mine it yourself, or send it directly to the payee and make them to relay or mine it.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcSigned-transaction,
btctx.SIGNED
Name::
* cpt.btcSigned-transaction,
btctx.SIGNED.NO
Name::
* cpt.btcSignedNo-transaction,
* cpt.btcUnsigned-transaction,
btctx.STANDARD
Description::
After the discovery of several dangerous bugs in early versions of Bitcoin, a test was added which only accepted transactions from the network if their pubkey scripts and signature scripts matched a small set of believed-to-be-safe templates, and if the rest of the transaction didn’t violate another small set of rules enforcing good network behavior.
This is the IsStandard() test, and transactions which pass it are called standard transactions.
[https://bitcoin.org/en/developer-guide#standard-transactions]
===
As of Bitcoin Core 0.9.3, standard transactions must also meet the following conditions:
The transaction must be finalized: either its locktime must be in the past (or less than or equal to the current block height), or all of its sequence numbers must be 0xffffffff.
The transaction must be smaller than 100,000 bytes. That’s around 200 times larger than a typical single-input, single-output P2PKH transaction.
Each of the transaction’s signature scripts must be smaller than 1,650 bytes. That’s large enough to allow 15-of-15 multisig transactions in P2SH using compressed public keys.
Bare (non-P2SH) multisig transactions which require more than 3 public keys are currently non-standard.
The transaction’s signature script must only push data to the script evaluation stack. It cannot push new opcodes, with the exception of opcodes which solely push data to the stack.
The transaction must not include any outputs which receive fewer than 1/3 as many satoshis as it would take to spend it in a typical input. That’s currently 546 satoshis for a P2PKH or P2SH output on a Bitcoin Core node with the default relay fee. Exception: standard null data outputs must receive zero satoshis.
[https://bitcoin.org/en/developer-guide#non-standard-transactions]
===
Some transactions are considered *standard*, meaning they are relayed and mined by most *nodes*.
More complex transactions could be buggy or cause DoS attacks on the network, so they are considered *non-standard* and not relayed or mined by most nodes.
Both standard and non-standard transactions are valid and once included in the blockchain, will be recognized by all nodes.
Standard transactions are:
1) sending to a *public key*,
2) sending to an *address*,
3) sending to a P2SH address,
4) sending to *M-of-N multi-signature transaction* where N is 3 or less.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcStandard-transaction,
btctx.STANDARD.NO
Description::
Non_standard_Transaction:
Any valid transaction that is not *standard*.
Non-standard transactions are not relayed or mined by default *BitcoinQT* nodes (but are relayed and mined on *testnet*).
However, if anyone puts such transaction in a block, it will be accepted by all nodes.
In practice it means that unusual transactions will take more time to get included in the blockchain.
If some kind of non-standard transaction becomes useful and popular, it may get named standard and adopted by users (like it ).
See also Standard Transaction.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-non-standard-transaction,
* cpt.btcnon-standard-transaction,
* cpt.btcStandardNo-transaction,
btctx.VALID
Name::
* cpt.btcvalid-transaction,
btcbcn'Hashrate (btchhrt )
Description::
The hash rate is the measuring unit of the processing power of the Bitcoin network.
The Bitcoin network must make intensive mathematical operations for security purposes.
When the network reached a hash rate of 10 Th/s, it meant it could make 10 trillion calculations per second.
[https://bitcoin.org/en/vocabulary#hash-rate]
Name::
* cpt.btchashing-power,
* cpt.btchashrate,
* cpt.btcmny'hashing-power,
* cpt.btcnet'Hashing-power,
* cpt.hash-rate-btcnet,
Time::
3.39-Exahash {2017-01-24}
Description::
Hashrate:
A measure of mining hardware performance expressed in hashes per second (GH/s).
As of July 27, 2014 the hash rate of all Bitcoin mining nodes combined is around 135 799 000 GH/s.
For comparison, AMD Radeon graphics cards produce from 0.2 to 0.8 GH/s depending on model.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Hash (Rate) ~ A hash is the output of a hash function and, as it relates to Bitcoin, the Hash Rate is the speed at which a compute is completing an operation in the Bitcoin code.
A higher hash rate is better when mining as it increases your opportunity of finding the next block and receiving the reward.
[http://bitcoinsimplified.org/definitions/]
btchhrt'Resource
Bitcoin’s Network Hash Rate Has Doubled Since October
Jan 23, 20174:20 PM EST by Kyle Torpey
Bitcoin’s mining difficulty increased by 16.6 percent over the weekend, signaling that the network’s overall hash rate has also increased by a similar amount over the past two weeks. The network’s total estimated hash rate has essentially doubled since the middle of October. A large chunk of this increase has taken place over the past month, where the hash rate has increased by more than 50 percent.
The network hash rate is the total amount of computing power pointed at the Bitcoin network.
Pools That Saw Their Share of Total Hashing Power Increase
It’s difficult to know where exactly this new hashing power is being deployed, but it is possible to see the differences in mining pools’ shares of the overall hash rate.
When comparing the most recently completed difficulty period with a run of 2016 blocks from the middle of October, GBMiners is the pool that saw the largest amount of growth. GBMiners enjoyed an increase of 62 blocks compared to the total set of 2016 blocks from October. Recently, it was found that GBMiners is connected to a Ponzi scheme disguised as a bitcoin cloud mining operation in India.
Since October, BTC.TOP has grown from nothing to roughly 3 percent of the network hash rate. Batpool also emerged during this period of time to grab a little over 1 percent of the network. Not much is known about either of these China-based pools, other than the fact that ltc1btc.com Founder and CEO Jiang Zhuo’er is behind BTC.TOP and does not much care for Bitcoin Core’s Segregated Witness improvement.
Both GBMiners and BTC.TOP signal support for Bitcoin Unlimited as opposed to Bitcoin Core. Bitcoin Unlimited is software that intends to replace Bitcoin’s 1 MB block size limit with the concept of emergent consensus. At this time, it is unclear if this new digital currency network would be a new version of Bitcoin or an altcoin.
In terms of pools signaling for Bitcoin Core’s Segregated Witness improvement, Bitfury saw the largest amount of growth. The mining pool saw an increase of just under 3 percent between the middle of October and the most recently completed difficulty period.
Pools That Saw Their Share of Total Hashing Power Decrease
If the above mining pools are mining more blocks, then that means someone else must be mining fewer blocks.
No miner saw a bigger drop in their share of the network since October than BTCC. BTCC now mines about 35 percent less blocks than they did in October.
No other pool came close to BTCC in terms of a loss in their share of the network hash rate, but ViaBTC and Slush Pool also saw notable declines. These two pools are mining about 25 percent less than the number of blocks they were mining in October.
The two largest mining pools on the network, Antpool and F2Pool, mined roughly 5 percent fewer blocks when their numbers were combined.
Although never the largest pools on the network, Bitcoin.com, GoGreenLight and Kano CKPool all saw sizable declines.
Hash Rate Continuing to Increase
Although the last difficulty period saw a rather massive increase of 16.6 percent, it appears that hash rate is continuing to be added to the network. At 118 blocks into the current difficulty period, there has already been another estimated 15.25 percent increase in the network hash rate.
Judging from the rapidly increasing hash rate, it appears multiple mining pools are receiving shipments of new hardware. While some predicted Bitcoin could crash and burn as a result of the halving event over the summer, the mining pools were correct in predicting a more positive outcome.
As Bitcoin’s total hash rate increases, it becomes more difficult for a motivated adversary to pull off an effective attack on the network.
Kyle Torpey by Kyle Torpey
Kyle Torpey is a freelance writer and researcher who has been following Bitcoin since 2011. His work has been featured on VICE Motherboard, Business Insider, NASDAQ, RT’s Keiser Report, and many other media outlets. You can follow @kyletorpey on Twitter.
[https://bitcoinmagazine.com/articles/bitcoins-network-hash-rate-has-doubled-october/]
btchhrt.PETAHASH/SEC (1000^5)
Name::
* cpt.btcpetahash,
btchhrt.EXAHASH/SEC (1000^6)
Name::
* cpt.btcexahash,
btcbcn'Crypto (btccrpt)
Name::
* cpt.bitcoin-crypto,
* cpt.btccrypto,
btccrpt'Hash-function
Description::
Hash-Function:
Bitcoin protocol mostly uses two cryptographic hash functions: SHA-256 and RIPEMD-160.
First one is almost exclusively used in the two round hashing (*Hash256*), while the latter one is only used in computing an *address* (see also *Hash160*).
*Scripts* may use not only Hash256 and Hash160, but also SHA-1, SHA-256 and RIPEMD-160.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-hash-function,
* cpt.btchash-function,
Generic::
* cryptographic-hash-function,
btccrpt'To-hash
Description::
To_hash:
To compute a hash function of some data.
If hash function is not mentioned explicitly, it is the one defined by the context.
For instance, "to hash a transaction" means to compute Hash256 of binary representation of a transaction.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-hashing,
* cpt.bitcoin-to-hash,
* cpt.btchashing,
* cpt.btcto-hash,
btccrpt'Hash256
Description::
The-output of two executions of the-hash-function SHA-256.
[hmnSgm.2017-04-08]
===
Hash, Hash256:
When not speaking about arbitrary hash functions, Hash refers to two rounds of SHA-256.
That is, you should compute a SHA-256 hash of your data and then another SHA-256 hash of that hash.
It is used in *block header* hashing, *transaction* hashing, making a *merkle tree* of transactions, or computing a checksum of an *address*.
Known as BTCHash256() in CoreBitcoin, Hash() in BitcoinQT.
It is also available in scripts as OP_HASH256.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
SHA-256d is also known as Double SHA-256 hash algorithm.
It is a cryptographic hash, first proposed by Ferguson and Schneier in the book “Practical Cryptography”.
Bitcoin is one such cryptocurrency that utilizes the SHA-256d hashing algorithm.
The SHA-256d hash is achieved by applying the regular SHA-256 hash twice, by first applying SHA-256 hash to the data and then once again to the resulting hash.
Many of the early released cryptocurrencies uses the SHA-256d algorithm such as: Bitcoin, Freicoin, Namecoin and Peercoin.
[https://cryptojunction.com/questions/question/what-is-the-difference-between-the-sha256d-and-sha256-hashing-algorithm]
Name::
* cpt.btchash,
* cpt.btchash256,
SHA-256
Description::
SHA-2 includes significant changes from its predecessor, SHA-1.
The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.
[https://en.wikipedia.org/wiki/SHA-2]
===
SHA-256:
The cryptographic function used as the basis for bitcoin’s proof of work system.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
The most widely used proof-of-work schemes are based on SHA-256, which was introduced by bitcoin, and scrypt, which is used by currencies such as Litecoin.
[https://en.wikipedia.org/wiki/Cryptocurrency]
Name::
* cpt.bitcoin-SHA-256,
* cpt.btcSHA-256,
btccrpt'Signature
Description::
Signature:
A sequence of bytes that proves that a piece of data is acknowledged by a person holding a certain *public key*.
Bitcoin uses ECDSA for signing transactions.
Amounts of bitcoins are sent through a chain of transactions: from one to another.
Every transaction must provide a signature matching a public key defined in the previous transaction.
This way only a proper owner a secret *private key* associated with a given public key can spend bitcoins further.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Signature:
A digital digest produced by hashing private and public keys together to prove that a bitcoin transaction came from a particular address.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-signature,
* cpt.btcsignature,
btccrpt'Elliptic-Curve-Arithmetic
Description::
Elliptic_Curve_Arithmetic:
A set of mathematical operations defined on a group of points on a 2D elliptic curve.
Bitcoin protocol uses predefined curve secp256k1.
Here's the simplest possible explanation of the operations: you can add and subtract points and multiply them by an integer.
Dividing by an integer is computationally infeasible (otherwise cryptographic signatures won't work).
The private key is a 256-bit integer and the public key is a product of a predefined point G ("generator") by that integer: A = G * a.
Associativity law allows implementing interesting cryptographic schemes like Diffie-Hellman key exchange (ECDH): two parties with private keys *a* and *b* may exchange their public keys *A* and *B* to compute a shared secret point C: C = A * b = B * a because (G * a) * b == (G * b) * a.
Then this point C can be used as an AES encryption key to protect their communication channel.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcElliptic-Curve-Arithmetic,
btccrpt'CompactSize
Description::
CompactSize:
Original name of a variable-length integer format used in transaction and block serialization.
Also known as "Satoshi's encoding".
It uses 1, 3, 5 or 9 bytes to represent any 64-bit unsigned integer.
Values lower than 253 are represented with 1 byte.
Bytes 253, 254 and 255 indicate 16-, 32- or 64-bit integer that follows.
Smaller numbers can be presented differently.
In *bitcoin-ruby* it is called "var_int", in *Bitcoinj* it is VarInt.
*BitcoinQT* also has even more compact representation called VarInt which is not compatible with CompactSize and used in block storage.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btccompactSize,
* cpt.btcSatshi's-encoding,
btcbcn'Evaluation
Description::
However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin.
[https://github.com/ethereum/wiki/wiki/White-Paper]
Name::
* cpt.bitcoin-blockchain-evaluation,
btcbcn'Doing
Maintainance::
The block chain is collaboratively maintained by anonymous peers on the network, so Bitcoin requires that each block prove a significant amount of work was invested in its creation to ensure that untrustworthy peers who want to modify past blocks have to work harder than honest peers who only want to add new blocks to the block chain.
[https://bitcoin.org/en/developer-guide#proof-of-work]
btcbcn'Synchronizing
Description::
Synchronizing the block chain by downloading each block from a peer and then validating it.
[https://bitcoin.org/en/glossary/blocks-first-sync]
Name::
* cpt.bitcoin-locks-first-sync,
* cpt.btcBlocks-First-Sync,
btcbcn'doing.FORK
Description::
The creation of an alternative ongoing version of the blockchain, typically because one set of miners begins hashing a different set of transaction blocks from another.
It can be caused maliciously, by a group of miners gaining too much control over the network (see 51% attack), accidentally, thanks to a bug in the system, or intentionally, when a core development team decides to introduce substantial new features into a new version of a client.
A fork is successful if it becomes the longest version of the blockchain, as defined by difficulty.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Fork:
Refers either to
- a fork of a source code (see *Altcoin*) or,
- more often, to a split of the blockchain when two different parts of the network see different *main chains*.
In a sense, fork occurs every time two blocks of the same *height* are created at the same time.
Both blocks always have the different hashes (and therefore different *difficulty*), so when a node sees both of them, it will always choose the most difficult one.
However, before both blocks arrive to a majority of nodes, two parts of the network will see different blocks as tips of the main chain.
Term *fork* or *hard fork* also refers to a change of the protocol that may lead to a split of the network (by design or because of a bug).
On March 11 2013 a smaller half of the network running version 0.7 of *bitcoind* could not include a large (>900 Kb) block at height 225430 created by a miner running newer version 0.8.
The block could not be included because of the bug in v0.7 which was fixed in v0.8.
Since the majority of computing power did not have a problem, it continued to build a chain on top of a problematic block.
When the issue was noticed, majority of 0.8 miners agreed to abandon 24 blocks incompatible with 0.7 miners and mine on top of 0.7 chain.
Except for one double spend experiment against OKPay, all transactions during the fork were properly included in both sides of the blockchain.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcfork,
btcbcn'fork.HARD
Description::
A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.
[https://bitcoin.org/en/glossary/hard-fork]
===
Hard fork:
Some people use the term hard fork to stress that changing Bitcoin protocol requires overwhelming majority to agree with it, or some noticeable part of the economy will continue with original blockchain following the old rules.
See *Fork* and *Soft Fork* for further discussion.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btchard-fork,
* cpt.btcHard-Forking-Change,
btcnet'Exchange-value-unit.Consensus (BTCevuC)
Description::
Bitcoin-BTC is the-consensus-exval-token of the-bitcoin-network.
[hmnSgm-2017-04-04]
Name::
* cpt.bitcoin-consensus-exval-token, {2017-03-31}
* cpt.btccevt, {2017-03-31}
===
* cpt.bitcoin-currency,
* cpt.bitcoin-token,
* cpt.bitcoin-value, {2017-04-11}
* cpt.btc,
* cpt.BTC-evuC,
* cpt.BTC-token,
* cpt.btcc,
* cpt.btcevtkn,
* cpt.mnyBtc,
* cpt.bitcoin,
* cpt.btcc,
* cpt.btcc,
* cpt.BTC, 2012-07-12,
* cpt.btcMny,
* cpt.currency.bitcoin, 2012-07-12,
* cpt.mnyBtc,
* cpt.mnyBtc,
* cpt.netBtc'currency,
* cpt.XBT,
===
BTC:
The most popular informal currency code for 1 Bitcoin (defined as 100 000 000 *Satoshis*).
See also *XBT* and *Bit*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
XBT:
Informal currency code for 1 Bitcoin (defined as 100 000 000 *Satoshis*).
Some people proposed using it for 0.01 Bitcoin to avoid confusion with *BTC*.
There were rumors that Bloomberg tests XBT as a ticker for 1 Bitcoin, but currently there is only ticker XBTFUND for SecondMarket's Bitcoin Investment Trust.
See also *BTC*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
NameGreek::
* ενν.μπικόιν-αξία,
* ενν.μπικόιν-νόμισμα,
Generic::
* consensus-exval-token,
* global-digital-currency,
Description::
2) The currency units used on this payment system have a market price, based purely on supply and demand.
Currently one bitcoin is worth about $12 USD, and there are a couple dozen exchanges around the world which enable conversion between normal government currencies and bitcoins.
The currency unit can be divided to eight decimal places (so you can send someone 0.00000001 bitcoins).
There are about 10 million bitcoins currently in existence (as of Sept. 2012) and there will never be more than 21 million in existence.
They are released in blocks of 50 bitcoins at a time every ten minutes and this amount gets cut in half every four years (thus creating the limit of 21 million coins).
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
Description::
Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] 2012-05-27,
Description::
Bitcoin is one of the first implementations of a concept called crypto-currency, which was first described in 1998 by Wei Dai on the cypherpunks mailing list. Building upon the notion that money is any object, or any sort of record, accepted as payment for goods and services and repayment of debts in a given country or socio-economic context, Bitcoin is designed around the idea of using cryptography to control the creation and transfer of money, rather than relying on central authorities.
[http://bitcoin.org/about.html]
btcevuC'adoption
Description::
How extensively is Bitcoin used? Well, around the world there are somewhere between 100,000 and 1,000,000 users, some of whom use it frequently and some who use it only on occasion. Several million dollars worth are transferred per day, but it is impossible to know for what purpose. In the last 24 hours, about 30,000 transactions occurred, or over one thousand transactions per hour. Since Bitcoins are exchanged back and forth with standard government currencies, the volume of this trading is about $100,000-$500,000 worth per day. Usage is increasing rapidly around the world, a chart of transactions can be found here: http://blockchain.info/charts/n-transactions?showDataPoints=false×pan=all&show_header=true&daysAverageString=7&scale=0&address= and more basic economic stats can be found here: http://bitcoinwatch.com/
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
Name::
* cpt.btccevt'acceptance,
* cpt.btccevt'usage,
* cpt.btcacceptance,
* cpt.btcadoption,
* cpt.btcusage,
AddressWpg::
* https://cointelegraph.com/news/ around-the-world-in-18-months-using-only-bitcoins-felix-weiss-big-adventure,
* http://cointelegraph.com/news/bitcoin-gambling-is-exploding,
* https://weacceptbitcoin.gr/
* http://cointelegraph.com/news/venezuela-economy-bitcoin,
* http://techcrunch.com/2016/03/16/why-latin-american-economies-are-turning-to-bitcoin/
btcevuC'Distribution
Description::
So, as of Dec. 3., using a price of $1,000 (which is basically where we are now), and assuming 12 million Bitcoins in circulation, here's the breakdown: 47 individuals own 28.9% of the approximately 12 million Bitcoins in existence so far. Another 880 own 21.5%, meaning 927 people control half of the entire market cap of the digital currency. Another 10,000 individuals control about a quarter. And the rest of us (around a million of us) get the crumbs (500,000 are out of circulation, whether through government seizure or people losing their passwords).
[http://www.businessinsider.com/927-people-own-half-of-the-bitcoins-2013-12]
btcevuC'Exchange-rate
Description::
Bitcoin is attractive because, unlike the fiat system, its value as an independent currency solely depends on its market demand.
[https://cointelegraph.com/news/cloud-miner-on-trends-making-bitcoin-attractive-now-japan-litecoin-dwindling-fiat]
Name::
* cpt.bitcoin-exchange-rate,
* cpt.bitcoin-price,
* cpt.bitcoin-rate,
* cpt.btc'price,
* cpt.btccevt'value,
* cpt.btcprice,
* cpt.btcrate,
* cpt.btcvalue,
Generic::
* exchange-rate-of-bcnevuC,
AddressWpg::
* BitPay: https://bitpay.com/bitcoin-exchange-rates,
* https://bitcoinaverage.com/en/bitcoin-price/btc-to-usd,
btcrate.PAST
Name::
* cpt.btcrate.histroical,
btcrate.PRESENT
Name::
* cpt.btcrate.live,
* cpt.btcrate.real-time,
btcrate.FUTURE
Name::
* cpt.btcrate.future,
btcrate.EVOLUTING
{time.2017-01-01}:
=== 997.75$
[https://www.bitstamp.net/]
{time.2016-01-04}:
=== 443.36$
[https://www.bitstamp.net/]
{time.2015-01-05}:
=== 277.59$
[https://www.bitstamp.net/]
{time.2014-08-19}:
=== 451$
Επεσε κατά 120 δολάρια η τιμή του Bitcoin μέσα σε μια εβδομάδα
Οι αναλυτές αναμένουν περαιτέρω μείωση για το ψηφιακό νόμισμα
ΔΗΜΟΣΙΕΥΣΗ: 08:55
Επεσε κατά 120 δολάρια η τιμή του Bitcoin μέσα σε μια εβδομάδα
Πτώση 120 δολαρίων κατέγραψε η τιμή του Bitcoin μέσα σε μια εβδομάδα με τους αναλυτές να αναμένουν πως η τιμή του ψηφιακού νομίσματος θα μειωθεί περαιτέρω, καθώς γίνεται διαρκώς όλο και λιγότερο ευαίσθητο στα «καλά νέα».
Συγκεκριμένα, σύμφωνα με την πλατφόρμα CoinDesk η αξία διαπραγμάτευσης του Bitcoin υποχώρησε σήμερα Τρίτη στα 451 δολάρια από 571 δολάρια πριν από μία εβδομάδα, ενώ χθες βρέθηκε να διαπραγματεύεται ακόμη και στα 309 δολάρια στη βουλγαρική πλατφόρμα συναλλαγών Bitcoin BTC-e.
Οι ειδικοί αποδίδουν τις απώλειες του Bitcoin στις προσπάθειες κάποιων traders να καλύψουν τις θέσεις τους, πιέζοντας περαιτέρω τις τιμές. Σε κάθε περίπτωση η πτώση της τιμής του ψηφιακού νομίσματος συνδέεται και με την μεγαλύτερη εποπτεία που έχει υπάρξει στις πλατφόρμες διαπραγμάτευσης του.
Με δεδομένο ότι τα εικονικά νομίσματα βρέθηκαν στο προσκήνιο της δημοσιότητας τον προηγούμενο Φεβρουάριο λόγω της κατάρρευσης κάποιων πλατφόρμων διαπραγμάτευσης οι κεντρικές τράπεζες διεθνώς απεύθυναν συστάσεις στους επενδυτές – καταναλωτές για τους πιθανούς κινδύνους. Το ίδιο έπραξε και η Τράπεζα της Ελλάδος υιοθετώντας σχετικές επισημάνσεις της Ευρωπαϊκής Αρχής Τραπεζών.
[http://www.tovima.gr/finance/article/?aid=623940]
{time.2014-01-06}:
=== 849.39$
[https://www.bitstamp.net/]
{time.2013-01-07}:
=== 13.69$
[https://www.bitstamp.net/]
{time.2013}:
The price of Bitcoins – based on little more than the hope the system will become a substantial means of exchange – has been yo-yoing.
It was below $7 a year ago and reached $266 in April before dropping below $80.
It has been called “a modern tulip mania but without the pretty flowers”.
[http://www.ft.com/intl/cms/s/0/51b78cb6-e40e-11e2-91a3-00144feabdc0.html, 2013-07-05]
===
Bitcoins have been in the headlines recently due to the massive volatility of their exchange rate.
When they were first introduced in 2009, they were essentially worthless, trading for just five cents per bitcoin in July 2010.
This year, however, they rocketed up in value to a high of $230 per bitcoin in April before plunging back to their current rate of exchange.
Some have attributed the rise to concerns about the ongoing euro crisis in Europe.
[http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account-a-917525.html, 2013-08-20]
{time.2012.05}:
=== 5$
In May 2012, 1 BTC traded at around $5.00 USD.
Taking into account the total number of Bitcoins in circulation, the market capitalization of the Bitcoin network stands at over 45 million USD.[51]
{time.2010.07}:
=== 0.05$
Bitcoins have been in the headlines recently due to the massive volatility of their exchange rate.
When they were first introduced in 2009, they were essentially worthless, trading for just five cents per bitcoin in July 2010.
This year, however, they rocketed up in value to a high of $230 per bitcoin in April before plunging back to their current rate of exchange.
Some have attributed the rise to concerns about the ongoing euro crisis in Europe.
[http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account-a-917525.html, 2013-08-20]
btcevuC'ATM
Cpt-created: {2014-01-07}
Description::
Bitcoin_ATM
A bitcoin ATM is a physical machine that allows a customer to buy bitcoin with cash.
There are many manufacturers, some of which enable users to sell bitcoin for cash.
They are also sometimes called 'BTMs' or 'Bitcoin AVMS'.
CoinDesk maintains a worldwide map of operational bitcoin atm machines and a list of manufacturers.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-ATM,
* cpt.bitcoin-AVMS,
* cpt.btcATM,
* cpt.BTM,
H Ελλάδα αποκτάει το πρώτο της Bitcoin ATM
Είναι πλέον και επίσημο! Η Ελλάδα έχει από σήμερα το πρώτο της Bitcoin ATM σε λειτουργία!
Το Bitcoin ATM βρίσκεται στην Αθήνα και συγκεκριμένα στην ΙΩΑΝΝΟΥ ΘΗΒΑΙΟΥ 20 , ΑΧΑΡΝΑΙ, ΤΚ: 13673 στο βιβλιοπωλείο ΟΡΙΖΟΝΤΕΣ.
Το ΑΤΜ είναι το Satoshi 1 της εταιρίας Genesis (https://bitcoinatm.com ) και λειτουργεί σε συνεργασία με το Ελληνικό Bitcoin ανταλλακτήριο bitcoinsgreece. Όπως αναφέρουν στο forum του BitcoinNews.gr έχουν δημιουργήσει ένα ημερολόγιο λειτουργίας του ΑΤΜ με φωτογραφίες ενώ και στο Bitcointalk έχει δημιουργηθεί νήμα συζήτησης Το Bitcoin ATM είναι one way Fiat>Bitcoin δηλαδή μπορείς μόνο να αγοράσεις και όχι να πουλήσεις Bitcoin.
To μηχάνημα ήδη έχει μπει στην λίστα του Bitcoin ATM radar coinatmradar
[http://www.insomnia.gr/_/articles/διάφορα/internet/h-ελλάδα-αποκτάει-το-πρώτο-της-bitcoin-atm-r9602, 2015-06-25]
Get your Bitcoin in cash: World's second Bitcoin ATM to open in Hong Kong
By Naomi Ng for CNN
January 7, 2014 -- Updated 0305 GMT (1105 HKT)
This file photo shows users waiting in line to use the world's first real Bitcoin ATM in Vancouver, Canada on October 29, 2013.
Hong Kong (CNN) -- The world's second Bitcoin ATM is due to land in Hong Kong by the end of this month, according to U.S. based software company Robocoin.
The machine, available for sale to individual operators such as banks and private entrepreneurs, allows users to buy or sell Bitcoin in just a few minutes.
The process should be much faster than setting up an account on an exchange or via mobile apps and computers which could take a few days for account verification.
The advent of Bitcoin ATMs is seen as a step towards bringing the digital currency into the real world.
"It removes all the pain and barriers of entry to buying Bitcoin on an online exchange," said Robocoin chief executive Jordan Kelley.
"Our goal as a company is to make the acquisition truly grandma friendly," he added.
READ: What is Bitcoin?
Indian government warns against Bitcion Bitcoin: Money of the future? Pay for a trip to space with Bitcoin
The virtual currency has generated lots of media attention in China where investors have helped drive the price up to dramatic highs above $1,000.
"I think we're going to unleash the power of Bitcoin. It opens a virtual money portal where people can send money to and from," said Kelley.
This is how it works:
Customers must choose to either buy or sell Bitcoin.
Let's say you want to make a withdrawal from your Bitcoin wallet. After choosing an amount of cash you'd like to withdraw, the software installed in the ATM generates a code which you have to scan with your smartphone.
Simultaneously, the machine also produces a receipt.
Following a confirmation from the Bitcoin network to your phone, you can then scan the code on the receipt at the kiosk, which then prompts the ATM to spit out the allotted amount of cash.
The machine is also equipped with a hand scanner that creates a biometric authenticated identity as an anti-money laundering measure.
Casper Cheng Tsz Chun, a Hong Kong Bitcoin enthusiast, said the ATM would work a bit like a vending machine "for buying and selling virtual goods (Bitcoin) instead of physical goods like a can of soda."
READ: 8 things you can buy with bitcoins right now
Robocoin's first Bitcoin ATM launched in Vancouver in October, and after a month of operation, transactions have totaled 1 million Canadian Dollars ($942,000) in total transactions, according to the company.
Kelley said the company has already sold 50 ATMs to other operators worldwide but they are not yet in operation.
The company said it chose Hong Kong as the next place to launch its cash machine for the virtual currency because it "responds well to technological innovation."
Kelley declined to disclose where the ATM would be located.
I think we're going to unleash the power of Bitcoin
Jordan Kelley, Robocoin CEO
Not every government in Asia is ready for a Bitcoin ATM.
Taiwan's Financial Supervisory Commission (FSC) and Central Bank released a joint statement on their website on Monday stating it does not recognize Bitcoin as an accepted form of currency.
The installation of Robocoin Bitcoin ATMs will be prohibited said Tseng Ming-chung, FSC chairman in an interview with Taiwan's Central News Agency.
"Bitcoin is not real currency and banks cannot receive or provide it. Installing ATMs require the authorization of the FSC, but it will not be approved, thus it is 'impossible' for Bitcoin ATMs to enter or appear in Taiwan," Central News Agency reported.
The statement also warned institutions against the risk of investing in Bitcoin because of the extremely volatile price.
China's central bank issued new rules in December that prohibited financial institutions from dealing in the digital currency. While it did not outlaw individuals from owning Bitcoin, it specifies that it is not to be considered a currency.
Despite the setback, Robocoin's chief executive said he still firmly believes China will come to accept Bitcoin.
"Citizens around the world love Bitcoin. The Chinese are very pragmatic in their approach, they just want to make sure they have a very good understanding of the market and the usage," he said.
Kelley revealed that Robocoin has begun talks with several operators in China that are reaching out to the government and local regulators to "educate" them about the value and potential of the Bitcoin market.
[http://edition.cnn.com/2014/01/06/business/bitcoin-atm-hong-kong/index.html]
btcevuC'DOING
btcevuC'Double-spending
Description::
Double_spending:
The act of spending bitcoins twice.
It happens when someone makes a transaction using bitcoins, and then makes a second purchase from someone else, using the same bitcoins.
They then convince the rest of the network to confirm only one of the transactions by hashing it in a block.
Double spending is not easy to do, thanks to the way that the bitcoin network operates, but it is nevertheless a risk run by those accepting zero-confirmation transactions.
[http://www.coindesk.com/information/bitcoin-glossary/]
btcevuC'Mixing
Description::
Mixing:
A process of exchanging coins with other persons in order to increase privacy of one's history.
Sometimes it is associated with money laundering, but strictly speaking it is orthogonal to laundering.
In traditional banking, a bank protects customer's privacy by hiding transactions from all 3rd parties.
In Bitcoin any merchant may do a statistical analysis of one's entire payment history and determine, for instance, how many bitcoins one owns.
While it's still possible to implement KYC (Know You Customer) rules on a level of every merchant, mixing allows to to separate information about one's history between the merchants.
Most important use cases for mixing are:
1) receiving a salary as a single big monthly payment and then spending it in small transactions ("cafe sees thousands of dollars when you pay just $4");
2) making a single payment and revealing connection of many small private spendings ("car dealer sees how much you are addicted to coffee").
In both cases your employer, a cafe and a car dealer may comply with KYC/AML laws and report your identity and transferred amounts, but neither of them need to know about each other.
Mixing bitcoins after receiving a salary and mixing them before making a big payment solves this privacy problem.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-mixing,
* cpt.btcmixing,
Description::
Mixing_service:
A service that mixes your bitcoins with someone else's, sending you back bitcoins with different inputs and outputs from the ones that you sent to it.
A mixing service (also known as a tumbler) preserves your privacy because it stops people tracing a particular bitcoin to you.
It also has the potential to be used for money laundering.
[http://www.coindesk.com/information/bitcoin-glossary/]
btcevuC.AGGREGATE
{time.2017-04-15}
Circulating Supply
16,274,987 BTC
Max Supply
21,000,000 BTC
[https://coinmarketcap.com/currencies/bitcoin/]
Description::
The protocol also halves the rate at which new bitcoins are created every four years, and limits the total number of bitcoins that will be created to a fixed total of 21 million coins. The result is that the number of bitcoins in circulation closely follows an easily predictable curve that reaches 21 million by the year 2140. Due to bitcoin’s diminishing rate of issuance, over the long term, the bitcoin currency is deflationary. Furthermore, bitcoin cannot be inflated by "printing" new money above and beyond the expected issuance rate.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
Το πρωτόκολλο επίσης μειώνει στο μισό, κάθε τέσσερα χρόνια, το ρυθμό με τον οποίο τα νέα bitcoin δημιουργούνται, ενώ ταυτόχρονα περιορίζει τον συνολικό αριθμό των bitcoin που θα δημιουργηθούν σε συνολικά 21 εκατομμύρια νομίσματα.
Το αποτέλεσμα είναι ότι ο αριθμός των bitcoin σε κυκλοφορία ακολουθεί πιστά μια εύκολα προβλέψιμη καμπύλη που φτάνει τα 21 εκατομμύρια μέχρι το έτος 2140.
Λόγω του φθίνοντος ποσοστού έκδοσης bitcoin, μακροπρόθεσμα, το bitcoin νόμισμα είναι αποπληθωριστικό.
Επιπλέον, το bitcoin δεν μπορεί να πληθωριστεί από «εκτύπωση» νέου χρήματος πάνω από τον αναμενόμενο ρυθμό έκδοσης.
[Mastering Bitcoin, Adonopoulos, https://www.bitcoinbook.info/translations/el/book.pdf]
===
Καθώς το bitcoin είναι δομημένο με τις φαντασιώσεις περί χρυσού, το αυτό ισχύει και για την ποσότητά του. O χρυσός πέρα από γυαλιστερός είναι και σχετικά σπάνιος και αυτή η σπανιότητά του, τον κάνει πολύτιμο και άρα επιθυμητό μέσο συναλλαγής και συσσώρευσης της αξίας. Έτσι και το bitcoin λοιπόν έπρεπε να γίνει σπάνιο. Από τον τρόπο που είναι δομημένο το bitcoin, υπάρχει δυνατότητα να παραχθούν μόλις 21 εκ bitcoins. Είναι αυτή η παραγωγή μια first come first serve περίπτωση? Όχι φυσικά. Τα αστέρια που σχεδίασαν τα bitcoins έφτιαξαν μια παραβολική καμπύλη σύμφωνα με την οποία, όσο περισσότερα bitcoins παράγονται, τόσο πιο δύσκολο θα γίνεται να παραχθούν τα επόμενα. Αυτό το κόλπο στην ουσία εγγυάται τη σπανιότητα του νομίσματος.
[http://www.techiechan.com/?p=1954]
btcevuC.Market-cap
Market-Cap:
{time.2017-01-01}: 15,702,359,119.12 USD
btcevuC.SUBUNIT
Description::
Denominations of Bitcoin value, usually measured in fractions of a bitcoin but sometimes measured in multiples of a satoshi.
One bitcoin equals 100,000,000 satoshis.
[https://bitcoin.org/en/glossary/denominations]
===
As the value of the unit of 1 BTC grew too large to be useful for day to day transactions, people started dealing in smaller units, such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).
[https://en.bitcoin.it/wiki/Myths]
Name::
* cpt.bitcoin-denomination,
* cpt.btccevt.subunit,
* cpt.btcdenomination,
btcevuC.unit.cBTC 1/100
Name::
* cpt.btccBTC,
* cpt.bitcenti,
* cpt.centibitcoin,
btcevuC.unit.mBTC 1/1,000
Name::
* cpt.btcmBTC,
* cpt.mBTC,
* cpt.millibitcoin,
btcevuC.unit.μBTC 1/1,000,000
Description::
Bit:
Name of a Bitcoin denomination equal to 100 *satoshis* (1 millionth of 1 *BTC*).
In 2014 several companies including Bitpay and Coinbase, and various wallet apps adopted *bit* to display bitcoin amounts.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitbitcoin,
* cpt.btcμBTC,
* cpt.btcuBTC,
* cpt.microbitcoin,
* cpt.btcbit,
* cpt.1-millionth-of-a-bitcoin,
* cpt.one-Mike, nickname,
btcevuC.unit.SATOSHI 1/100,000,000
Description::
There are a maximum of 2,099,999,997,690,000 Bitcoin elements (called satoshis), which are currently most commonly measured in units of 100,000,000 known as BTC.
Stated another way, no more than 21 million BTC can ever be created.
[https://en.bitcoin.it/wiki/Bitcoin]
===
A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.Aug 30, 2011
terminology - What is a 'Satoshi'? - Bitcoin Stack Exchange
bitcoin.stackexchange.com/questions/114/what-is-a-satoshi
===
Satoshi:
The first name of the Bitcoin's creator Satoshi Nakamoto and also the name of the smallest unit used in transactions.
1 bitcoin (BTC) is equal to 100 million satoshis.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcsatoshi,
* cpt.mnySatoshi,
* cpt.satoshi,
btcnet'Program (btcpgm)
Description::
Bitcoin is also the name of the open source software which enables the use of this currency.
[http://bitcoin.org/] 2012-05-27,
Name::
* cpt.bitcoin-software,
* cpt.btcprogram,
* cpt.btcsoftware,
===
* cpt.btcs,
btcpgm.bitcoinj
Description::
Bitcoinj:
A Java implementation of a full Bitcoin node by Mike Hearn.
Also includes *SPV* implementation among other features.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
What is bitcoinj?
bitcoinj is a library for working with the Bitcoin protocol.
It can maintain a wallet, send/receive transactions without needing a local copy of Bitcoin Core and has many other advanced features. It's implemented in Java but can be used from any JVM compatible language: examples in Python and JavaScript are included.
It comes with full documentation and many large, well known Bitcoin apps and services are built on it.
Features
Highly optimised lightweight simplified payment verification (SPV) mode. In this mode, only a small part of the block chain is downloaded, making bitcoinj suitable for usage on constrained devices like smartphones or cheap virtual private servers.
Experimental full verification mode, which does the same verification work as Bitcoin Core. In this mode, the unspent transaction output set (UTXO set) is calculated and, thanks to a PostgreSQL store, can be indexed into a database allowing for fast lookup of balance by address.
A wallet class with encryption, fee calculation, multi-signing, deterministic key derivation, pluggable coin selection/coin control, extensions support and event listeners that let you stay up to date with changes in your balance.
Support for micropayment channels that let you set up a multi-signature contract between client and server, and then negotiate on the channel, allowing fast micropayments that avoid miner fees.
Provides both async and thread-per-connection for network IO, allowing you to choose between scalability and blocking-only features like SOCKS/Tor proxying.
Easily implement apps that use Bitcoin's contracts features.
A simple GUI wallet app that you can use as the basis for your own apps. Watch or read a tutorial on how to customise it and build a native installer that does not require Java.
Command line tools for working with wallet and chain files, the payment protocol, the network and more.
Strong Bitcoin standards support.
A friendly and helpful community!
[http://bitcoinj.github.io/]
Name::
* cpt.bitcoinj,
AddressWpg::
* http://bitcoinj.github.io/
btcpgm.CLIENT
Description::
Client
A software program running on a desktop or laptop computer, or mobile device.
It connects to the bitcoin network and forwards transactions.
It may also include a bitcoin wallet (see node).
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-client-program,
* cpt.btcclient,
NameGreek::
* ενν.μπιτκόιν-λογισμικό-πελάτη,
* ενν.μπιτκόιν-πρόγραμα-πελάτη,
* ενν.μπιτκόιν-πελάτης,
Specific::
* full-client,
* lightweight-client,
* web-client,
btcpgm.Full-client
Description::
A full client, or "full node," is a client that stores the entire history of bitcoin transactions (every transaction by every user, ever), manages the users' wallets, and can initiate transactions directly on the bitcoin network.
This is similar to a standalone email server, in that it handles all aspects of the protocol without relying on any other servers or third-party services.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Name::
* cpt.btcFull-client-program,
* cpt.bitcoin-full-client,
NameGreek::
* ενν.μπιτκόιν-πλήρης-πελάτης,
Whole::
* full-client-node,
btcpgm.Lightweight-client
Description::
A lightweight client stores the user’s wallet but relies on third-party–owned servers for access to the bitcoin transactions and network.
The light client does not store a full copy of all transactions and therefore must trust the third-party servers for transaction validation.
This is similar to a standalone email client that connects to a mail server for access to a mailbox, in that it relies on a third party for interactions with the network.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Name::
* cpt.bitcoin-light-client,
* cpt.bitcoin-SPV-client,
* cpt.btclight-client,
* cpt.btclightweight-client,
* cpt.btcThin-client,
NameGreek::
* ενν.μπιτκόιν-ελαφρύς-πελάτης,
Bloom-filter
Description::
A filter used primarily by SPV clients to request only matching transactions and merkle blocks from full nodes.
[https://bitcoin.org/en/glossary/bloom-filter]
Name::
* cpt.bitcoin-bloom-filter,
* cpt.btcBloom-filter,
Limitation
Description::
This gets us pretty far, but Bitcoin-style light clients do have their limitations. One particular limitation is that, while they can prove the inclusion of transactions, they cannot prove anything about the current state (eg. digital asset holdings, name registrations, the status of financial contracts, etc). How many bitcoins do you have right now? A Bitcoin light client can use a protocol involving querying multiple nodes and trusting that at least one of them will notify you of any particular transaction spending from your addresses, and this will get you quite far for that use case, but for other more complex applications it isn’t nearly enough; the precise nature of the effect of a transaction can depend on the effect of several previous transactions, which themselves depend on previous transactions, and so ultimately you would have to authenticate every single transaction in the entire chain.
[https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ Buterin.Vitalik]
SPV-method
Description::
A method for verifying particular transactions were included in a block without downloading the entire block.
The method is used by some lightweight Bitcoin clients.
[https://bitcoin.org/en/glossary/simplified-payment-verification]
===
SPV:
Simplified Payment Verification.
A feature of the Bitcoin protocol that enables nodes to verify payments without downloading the full blockchain.
Instead, they need only download block headers.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Simplified_Payment_Verification_(SPV):
A scheme to validate transactions without storing the whole blockchain (only block headers) and without trusting any external service.
Every transaction must be present with all its parent and sibling hashes in a *merkle tree* up to the root.
SPV client trusts the most *difficult* chain of block headers and can validate if the transaction indeed belongs to a certain block header.
Since SPV does not validate all transactions, a *51% attack* may not only cause a *double spend* (like with *full nodes*), but also make a completely invalid payment with bitcoins created from nowhere.
However, this kind of attack is very costly and probably more expensive than a product in question.
*Bitcoinj* library implements SPV functionality.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btcSPV,
* cpt.btcSimplified-Payment-Verification
btcpgm.Web-client
Description::
Web clients are accessed through a web browser and store the user’s wallet on a server owned by a third party. This is similar to webmail in that it relies entirely on a third-party server.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
Name::
* cpt.bitcoin-web-client-program,
* cpt.btcweb-client-program,
btcpgm.Mobile-client
Description::
Mobile clients for smartphones, such as those based on the Android system, can either operate as full clients, lightweight clients, or web clients. Some mobile clients are synchronized with a web or desktop client, providing a multiplatform wallet across multiple devices but with a common source of funds.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch01.asciidoc]
Name::
* cpt.bitcoin-mobile-client-program,
* cpt.btcmobile-client-program,
btcpgm.BITCOIN-XT
Description::
Bitcoin XT is a fork of Bitcoin Core, the reference client for the bitcoin network. In mid-2015, the concept achieved significant attention within the bitcoin community amid a contentious debate among core developers over increasing the blockchain size cap.[1] The current reference implementation for bitcoin contains a computational bottleneck.[2][3] This averages to a daily maximum of around 300,000 transactions.[4]
It was proposed that the block chain size increase to eight megabyte, i.e. and from then onwards to automatically increase it exponentially, doubling every two years. The proposal did not gain the necessary support to go into effect on the Bitcoin network by early 2016, the earliest possible switchover date. Its use has been in steady decline from March 2016 onwards.
[https://en.wikipedia.org/wiki/Bitcoin_XT]
===
The approach taken by Hearn and Andresen clearly indicates their commitment to a decentralized system
Fears over excessive centralization are warranted. After all, decentralization is a big part of bitcoin’s value proposition. But the amount of centralization being considered at the moment still seems vastly more decentralized than traditional payment systems.
Indeed, the approach taken by Hearn and Andresen clearly indicates their commitment to a decentralized system. BitcoinXT will continue to enforce the existing blocksize limit until the protocol is so widely adopted that it is used to process at least 75% of all blocks added to the blockchain. If (and only if) that occurs—but no earlier than January—BitcoinXT will increase the limit to eight megabytes and double that limit every two years thereafter.
The commitment to gradual change based on consensus observed with the issuance of BitcoinXT is incredible, but perhaps not surprising. It reflects the core values held by bitcoin supporters. And it is also a hallmark of well-functioning self-governing systems. It bodes well for bitcoin’s future.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
Name::
* cpt.bitcoinXT,
AddressWpg::
* https://bitcoinxt.software/
btcpgm.Bitcoin-Core (btcbcr|btcbqt)
conceptIt1010.1#
Description::
BitcoinQT:
Bitcoin implementation based on original code by *Satoshi Nakamoto*.
Includes a graphical interface for Windows, OS X and Linux (using QT) and a command-line executable *bitcoind* that is typically used on servers.
It is considered a *reference implementation* as it's the most used *full node* implementation, especially among *miners*.
Other implementations must be bug-for-bug compatible with it to avoid being *forked*. BitcoinQT uses OpenSSL for its ECDSA operations which has its own quirks that became a part of the standard (e.g. non-canonically encoded public keys are accepted by OpenSSL without an error, so other implementations must do the same).
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md#bitcoinqt]
===
Once installed, you’ll have access to three programs: bitcoind, bitcoin-qt, and bitcoin-cli.
[https://bitcoin.org/en/developer-examples]
===
Bitcoin_Core:
New name of *BitcoinQT* since release of version 0.9 on March 19, 2014.
Not to confuse with *CoreBitcoin*, an Objective-C implementation published in August 2013.
See also *Bitcore*, a JavaScript implementation for Node.js by Bitpay.
Description::
Reference_Implementation:
BitcoinQT (or *bitcoind*) is the most used *full node* implementation, so it is considered a reference for other implementations.
If an alternative implementation is not compatible with BitcoinQT it may be *forked*, that is it will not see the same *main chain* as the rest of the network running *BitcoinQT*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.Bitcoin-core,
* cpt.bitcoin-reference-implementation,
* cpt.BitcoinQT,
* cpt.btcbcr,
* cpt.btcBitcoin-Core,
* cpt.btcBitcoinQT,
* cpt.btcbqt,
* cpt.btcpgm.Bitcoin-Core, {2014-03-19 v0.9}
* cpt.btcreference-implementation,
* cpt.btcSatoshi-client,
NameGreek::
* ενν.μπιτκόιν-πυρήνας,
* ενν.υλοποίηση-αναφοράς-μπιτκόιν,
AddressWpg::
* https://github.com/bitcoin/bitcoin,
* https://bitcoin.org/en/download,
btcbcr'application-directory
Description::
All three programs get settings from bitcoin.conf in the Bitcoin application directory:
Windows: %APPDATA%\Bitcoin\
OSX: $HOME/Library/Application Support/Bitcoin/
Linux: $HOME/.bitcoin/
[https://bitcoin.org/en/developer-examples]
Name::
* cpt.btcdirectory,
btcbcr'bitcoin.conf
Name::
* cpt.btcbitcoin.conf,
You should also make the bitcoin.conf file only readable to its owner. On Linux, Mac OSX, and other Unix-like systems, this can be accomplished by running the following command in the Bitcoin application directory:
chmod 0600 bitcoin.conf
[https://bitcoin.org/en/developer-examples]
btcrpcpassword:
To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work:
rpcpassword=change_this_to_a_long_random_password
[https://bitcoin.org/en/developer-examples]
btcbcr'Bitcoin-cli
Description::
bitcoin-cli allows you to send RPC commands to bitcoind from the command line. For example, bitcoin-cli help
[https://bitcoin.org/en/developer-examples]
Name::
* cpt.btcbitcoincli,
* cpt.btcbitcoin-cli,
btcbcr'Bitcoin-qt
Description::
bitcoin-qt provides a combination full Bitcoin peer and wallet frontend. From the Help menu, you can access a console where you can enter the RPC commands used throughout this document.
[https://bitcoin.org/en/developer-examples]
Name::
* cpt.btcbitcoin-qt,
btcbcr'Internal-byte-order
Description::
The standard order in which hash digests are displayed as strings—the same format used in serialized blocks and transactions.
Not To Be Confused With
RPC byte order (where the byte order is reversed)
[https://bitcoin.org/en/glossary/internal-byte-order]
Name::
* cpt.Internal-Byte-Order,
btcbcr'RPC
Description::
Bitcoin Core provides a remote procedure call (RPC) interface for various administrative tasks, wallet operations, and queries about network and block chain data.
[https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs]
Name::
* cpt.btcRpc,
* cpt.btcRPC,
* cpt.btcRemoteProcedureCall,
btcbcrrpc'Byte-order
Description::
* A hash digest displayed with the byte order reversed; used in Bitcoin Core RPCs, many block explorers, and other software.
[https://bitcoin.org/en/glossary/rpc-byte-order]
Name::
* cpt.btcRPC-Byte-Order,
Example::
internal-byte-order: 5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc820000000000000000
rpc-byte-order: 000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254
Note: hex representation uses two characters to display each byte of data, which is why the reversed string looks somewhat mangled.
The rational for the reversal is unknown, but it likely stems from Bitcoin’s use of hash digests (which are byte arrays in C++) as integers for the purpose of determining whether the hash is below the network target. Whatever the reason for reversing header hashes, the reversal also extends to other hashes used in RPCs, such as TXIDs and merkle roots.
Off-site documentation such as the Bitcoin Wiki tends to use the terms big endian and little endian as shown in the table below, but they aren’t always consistent. Worse, these two different ways of representing a hash digest can confuse anyone who looks at the Bitcoin Core source code and finds a so-called “big endian” value being stored in a little-endian data type.
[https://bitcoin.org/en/developer-reference#hash-byte-order]
btcbcr.EVOLUTING
btcbcr.0-14-0.2017-03-07
Today marks the official release of Bitcoin Core 0.14.0, the fourteenth generation of Bitcoin’s original software client launched by Satoshi Nakamoto eight years ago.
Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by nearly 100 contributors over a six-month period.
[https://bitcoinmagazine.com/articles/bitcoin-core-0140-released-whats-new/]
btcbcr.0-13-2.2017-01-03 - Bitcoin Core version 0.13.2 released
btcbcr.0-13-1.2016-10-27 - Bitcoin Core version 0.13.1 released
btcbcr.0-13-0.2016-08-23:
Bitcoin Core version 0.13.0 released
btcbcr.0-12-0.2016-02-23:
Bitcoin Core version 0.12.0 released
23 February 2016
Bitcoin Core version 0.12.0 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.12.0/
This is a new major version release, bringing new features and other improvements.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
[https://bitcoin.org/en/release/v0.12.0]
btcbcr.0-11-0.2015-07-12:
Bitcoin Core version 0.11.0 released
- https://bitcoin.org/en/release/v0.11.0
- 2015.Jul.12
Bitcoin Core version 0.10.2 released
- https://bitcoin.org/en/release/v0.10.2
- 2015.May.19
Bitcoin Core version 0.10.1 released
- https://bitcoin.org/en/release/v0.10.1
- 2015.Apr.27
btcbcr.0-10-0.2015-02-16:
Bitcoin Core version 0.10.0 released
- https://bitcoin.org/en/release/v0.10.0
- 2015.Feb.16
Bitcoin Core version 0.9.3 released
- https://bitcoin.org/en/release/v0.9.3
- 2014.Sep.27
Bitcoin Core version 0.9.2.1 released
- https://bitcoin.org/en/release/v0.9.2.1
- 2014.Jun.19
Bitcoin Core version 0.9.2 released
- https://bitcoin.org/en/release/v0.9.2
- 2014.Jun.16
Bitcoin Core version 0.9.1 released
- https://bitcoin.org/en/release/v0.9.1
- 2014.Apr.08
btcbcr.0-9-0.2014-03-19:
Bitcoin Core version 0.9.0 released
- https://bitcoin.org/en/release/v0.9.0
- 2014.Mar.19
Bitcoin-Qt version 0.8.6 released
- https://bitcoin.org/en/release/v0.8.6
- 2013.Dec.09
Bitcoin-Qt version 0.8.5 released
- https://bitcoin.org/en/release/v0.8.5
- 2013.Sep.13
Bitcoin-Qt version 0.8.4 released
- https://bitcoin.org/en/release/v0.8.4
- 2013.Sep.03
Bitcoin-Qt version 0.8.3 released
- https://bitcoin.org/en/release/v0.8.3
- 2013.Jun.25
Bitcoin-Qt version 0.8.2 released
- https://bitcoin.org/en/release/v0.8.2
- 2013.May.29
Bitcoin-Qt version 0.8.1 released
- https://bitcoin.org/en/release/v0.8.1
- 2013.Mar.18
Bitcoin-Qt version 0.8.0 released
- https://bitcoin.org/en/release/v0.8.0
- 2013.Feb.19
Bitcoin-Qt version 0.7.2 released
- https://bitcoin.org/en/release/v0.7.2
- 2012.Dec.14
Bitcoin-Qt version 0.7.1 released
- https://bitcoin.org/en/release/v0.7.1
- 2012.Oct.19
Bitcoin-Qt version 0.7.0 released
- https://bitcoin.org/en/release/v0.7.0
- 2012.Sep.17
Bitcoin-Qt version 0.6.3 released
- https://bitcoin.org/en/release/v0.6.3
- 2012.Jun.25
Bitcoin-Qt version 0.6.2 released
- https://bitcoin.org/en/release/v0.6.2
- 2012.May.08
Bitcoin-Qt version 0.6.1 released
- https://bitcoin.org/en/release/v0.6.1
- 2012.May.04
Bitcoin-Qt version 0.6.0 released
- https://bitcoin.org/en/release/v0.6.0
- 2012.Mar.30
Bitcoin-Qt version 0.5.3.1 released
- https://bitcoin.org/en/release/v0.5.3.1
- 2012.Mar.16
Bitcoin-Qt version 0.5.3 released
- https://bitcoin.org/en/release/v0.5.3
- 2012.Mar.14
Bitcoin-Qt version 0.5.2 released
- https://bitcoin.org/en/release/v0.5.2
- 2012.Jan.09
Bitcoin-Qt version 0.5.1 released
- https://bitcoin.org/en/release/v0.5.1
- 2011.Dec.15
Bitcoin-Qt version 0.5.0 released
- https://bitcoin.org/en/release/v0.5.0
- 2011.Nov.21
Bitcoin version 0.4.0 released
- https://bitcoin.org/en/release/v0.4.0
- 2011.Sep.23
Bitcoin version 0.3.24 released
- https://bitcoin.org/en/release/v0.3.24
- 2011.Jul.08
Bitcoin version 0.3.23 released
- https://bitcoin.org/en/release/v0.3.23
- 2011.Jun.14
Bitcoin version 0.3.22 released
- https://bitcoin.org/en/release/v0.3.22
- 2011.Jun.05
Bitcoin version 0.3.21 released
- https://bitcoin.org/en/release/v0.3.21
- 2011.Apr.27
btcnet'Wallet (btcwlt)
Description::
Bitcoin-wallet is ANY ENTITY used to manage ownership of bitcoins.
BTCs are-not-stored in the-wallets, they are-stored in the-blochain.
A-bitcoin-wallet STORES the-cryptographic-keys that define the-ownership of bitcoins.
[hmnSgm.2017-04-04]
===
'wallet' could be a file, a program, a web-service.
[hmnSgm.2015-09.07]
Name::
* cpt.bitcoin-wallet,
* cpt.btcwallet,
* cpt.btcwlt,
NameGreek::
* ενν.πορτοφόλι-μπικόιν,
Generic::
* blockchain-wallet,
Description::
Bitcoin wallets at their core are a collection of private keys. These collections are stored digitally in a file, or can even be physically stored on pieces of paper.
[https://bitcoin.org/en/developer-guide#wallet-files]
Description::
The so-called wallet is a simple data file that contains a set of Bitcoin (or insert your preferred currency here) addresses. That's all you need to keep your Ecoins with you. The block chain is copied to every single client has a list of every single transaction and balance for your given currency, e.g. Bitcoin. The security of the wallet depends on the security of your computer or smartphone.
[http://www.coindesk.com/how-to-create-a-brain-wallet/]
Description::
A Bitcoin wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
Wallet files store private keys and (optionally) other information related to transactions for the wallet program.
[https://bitcoin.org/en/developer-guide#wallets]
Description::
When a person joins the Bitcoin network, we typically mean that he has procured himself a Bitcoin wallet.
A Bitcoin wallet is the interface through which users will access the Bitcoin network and, more importantly, be able to utilize the Bitcoins that they own.
It can be procured for free as
- a software on a computer,
- a browser extension,
- an application on a mobile device or
- a simple web page which would look much like an online banking portal.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
Description::
Wallet:
An application or a service that helps keeping private keys for signing transactions.
Wallet does not keep bitcoins themselves (they are recorded in *blockchain*).
"Storing bitcoins" usually means storing the keys.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Description::
Users send bitcoins, the units of currency, by broadcasting digitally signed messages to the network using bitcoin wallet software
[https://en.wikipedia.org/wiki/Bitcoin_network]
Description::
Bitcoin users manage their bitcoin addresses by using a digital wallet. Wallets let users send bitcoins, request payment, calculate the total balance of addresses in use, generate new addresses as needed. Many wallets include precautions to keep the private keys secret, for example by encrypting the wallet data with a password or by requiring two-factor authenticated logins.
Bitcoin wallets provide the following functionality:[10]
Storage of bitcoin addresses and corresponding public/private keys on user's computer in a wallet.dat file
Conducting transactions of obtaining and transferring bitcoins (BTC), also without connection to the Internet
Provide information about the balance in BTC at all available addresses, prior transactions, spare keys
Bitcoin wallets have been implemented as stand-alone software applications, web applications, and even printed documents or memorized passphrases.
[https://en.wikipedia.org/wiki/Bitcoin_network]
===
Since Bitcoin is open-source, any computer programmer with the right skills can create a bitcoin wallet. A Bitcoin wallet is like an email account, they are typically free to install, and you can send and receive money.
Some wallets have more features than others, and some wallets are more designed for advanced users. Some wallets store your bitcoins locally on the computer or mobile phone, and some wallets store your bitcoins in the cloud, where they can be accessed from anywhere.
A wallet that holds bitcoins only is considered an Advanced wallet, or Expert wallet, regardless of the complexity of the interface. Because Bitcoin is new, the volatility risk of holding only bitcoins is more significant than the technical risk of using the software.
Wallets in the Intermediate category allow you to store your local currency in the wallet, as well as bitcoins. This reduces the volatility risk to the user.
[http://lovebitcoins.org/getStarted.html]
Description::
Wallet:
A method of storing bitcoins for later use.
A wallet holds the private keys associated with bitcoin addresses.
The blockchain is the record of the bitcoin amounts associated with those addresses.
[http://www.coindesk.com/information/bitcoin-glossary/]
Description::
1) The payment system itself is revolutionary – nothing like it has ever been done. The system is decentralized, so there is no “server farm” or corporate office which controls payments. Transactions occur “peer to peer” just like file-sharing. To use the system, you can either download the client software (which runs on your computer and stores money locally) or you can use an “ewallet” which is a website run by a 3rd party which holds the funds for you (simpler, but introduces counter-party risk if the 3rd party is not trustworthy).
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
btcwlt'Storage-medium
Description::
Το πρώτο «χρηματοκιβώτιο» για bitcoins
Δευτέρα, 13 Ιανουαρίου 2014 12:13 UPD:12:13
REUTERS/JIM URQUHART
Τα online «πορτοφόλια» που χρησιμοποιούνται για την αποθήκευση bitcoins θεωρούνται όλο και λιγότερο ασφαλή, καθώς είναι τρωτά σε κυβερνοεπιθέσεις.
Μία υπηρεσία για αποθήκευση καταθέσεων στο ψηφιακό νόμισμα, bitcoin, ξεκίνησε τη λειτουργία της στο Λονδίνο.
Σύμφωνα με δημοσίευμα του BBC, το Elliptic Vault χρησιμοποιεί τεχνικές «deep cold storage», όπου κωδικοποιημένα «κλειδιά» για bitcoins αποθηκεύονται σε servers οι οποίοι βρίσκονται σε ασφαλές σημείο και είναι αποκομμένοι από το Διαδίκτυο. Υπάρχουν πολλαπλά αντίγραφα των «κλειδιών», που προστατεύονται τόσο από ψηφιακά, όσο και από «φυσικά» συστήματα προστασίας. Στα εν λόγω αντίγραφα έχουν πρόσβαση μόνο ανώτερα στελέχη της εταιρείας. Οι δημιουργοί του ισχυρίζονται πως πρόκειται για μια παγκόσμια πρωτιά, με στόχο την παροχή ασφαλείας στους κατόχους bitcoins.
Σημειώνεται ότι τα online «πορτοφόλια» που χρησιμοποιούνται για την αποθήκευση bitcoins θεωρούνται όλο και λιγότερο ασφαλή, καθώς είναι τρωτά σε κυβερνοεπιθέσεις ενώ πολλοί χρήστες έχουν αναφέρει περιστατικά όπου χάθηκαν κατά λάθος τεράστια ποσά Χαρακτηριστικό παράδειγμα είναι η περίπτωση του Τζέιμς Χάουελς, ο οποίος πέταξε έναν σκληρό δίσκο στον οποίο είχε ξεχάσει ότι υπήρχαν από παλιά αποθηκευμένα bitcoins αξίας (σήμερα) εκατομμυρίων δολαρίων.
Δεν υπάρχει τρόπος ανάκτησης κλεμμένων bitcoins, ενώ οι συναλλαγές είναι μη αναστρέψιμες. Επίσης δεν υπάρχει κάποιος τρόπος ασφάλισής τους, όπως θα συνέβαινε σε μία «συμβατική» τράπεζα με κανονικά λεφτά.
«Ένας από τους κύριους προβληματισμούς που έχουν οι άνθρωποι με τα bitcoins είναι ότι είναι δύσκολο να τα αποθηκεύσουν με ασφάλεια» είπε στο BBC ο Τομ Ρόμπινσον, συνιδρυτής του Elliptic Vault. «Το να τους παρέχουμε αυτή την ασφάλεια φαινόταν το προφανές βήμα» πρόσθεσε.
Κατά τον Ρόμπινσον, ήταν δύσκολο να βρεθεί κάποια ασφαλιστική εταιρεία η οποία να υποστηρίξει το εγχείρημα, καθώς η σχετική βιομηχανία παρουσιάζεται πολύ συντηρητική και δεν «κατανοεί» ακόμα το bitcoin, ενώ επηρεάζεται και από την αρνητική δημοσιότητα πάνω στο ζήτημα. Ωστόσο, όπως επισημαίνει, η κατάσταση έχει βελτιωθεί από τότε που έκλεισε η online αγορά ναρκωτικών και άλλων παράνομων εμπορευμάτων, Silk Road.
[http://www.naftemporiki.gr/story/752249]
Name::
* cpt.bitcoin-wallet-storage,
* cpt.btcnet'storage,
* cpt.btcwlt'storage,
btcwlt'Key-pool
Description::
Key_Pool:
Some wallet applications that create new private keys randomly keep a pool of unused pre-generated keys (BitcoinQT keeps 100 keys by default).
When a new key is needed for *change* address or a new payment request, the application provides the oldest key from the pool and replaces it with a fresh one.
The purpose of the pool is to ensure that recently used keys are always already backed up on external storage.
Without a key pool you could create a new key, receive a payment on its address and then have your hard disk died before backing up this key.
A key pool guarantees that this key was already backed up several days before being used.
*Deterministic wallets* do not use a key pool because they need to back up a single secret key.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.btckey-pool,
btcwlt'Doing
btcwltdng.SERVICE
Name::
* cpt.btcnet'wallet-service,
* cpt.btcwallet-service,
SPECIFIC
Name::
* btcwlt.specific,
* cpt.btcwlt.specific,
Specific::
* hardware-wallet
* paper-wallet,
* prgram-wallet,
AddressWpg::
* https://bitcoin.org/en/choose-your-wallet,
Specific::
Within these two categories [hot|cold] of Bitcoin wallets there are other subcategories.
These include web wallets, desktop wallets installed on
your computer, hierarchical deterministic (“HD”) wallets, multiplesignature
(“multi-sig”) wallets, light wallets, paper wallets, and
wallets that require two-factor authentication (“2FA”).
These wallet characteristics are not mutually exclusive. For example,
you can have a web wallet that uses the multi-sig system or twofactor
authentication. You’ll find that some of the recommended
wallets appear in more than one category below.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
btcwlt.BRAIN
Description::
Brain_wallet:
Brain wallet is a concept of storing *private keys* as a memorable phrase without any digital or paper trace.
Either a single key is used for a single address, or a *deterministic wallet* derived from a single key.
If done properly, a brain wallet greatly reduces the risk of theft because it is completely deniable: no one could say which or how much bitcoins you own as there are no actual wallet files to be found anywhere.
However, it is the most error-prone method as one can simply forget the secret phrase, or make it too simple for anyone to brute force and steal all the funds.
Additional risks are added by a complex wallet software.
E.g. BitcoinQT always sends *change* amount to a new address.
If a private key is imported temporarily to spend 1% of the funds and then the wallet is deleted, the remaining 99% will be lost forever as they are moved as a change to a completely new address.
This already happened to a number of people.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-brain-wallet,
* cpt.btcwlt.brain,
AddressWpg::
* https://brainwallet.io/
Brainwallet.org:
Utility based on bitcoinjs to craft transactions by hand, convert *private keys* to addresses and work with a *brain wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcwlt.PAPER
Description::
Store the-keys on paper.
Name::
* cpt.bitcoin-paper-wallet,
* cpt.btcPaper-wallet,
* cpt.btcwlt.paper,
Description::
Paper_wallet:
A printed sheet containing one or more public bitcoin addresses and their corresponding private keys.
Often used to store bitcoins securely, instead of using software wallets, which can be corrupted, or web wallets, which can be hacked or simply disappear.
A useful form of cold bitcoin storage.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Paper_Wallet:
A form of *cold storage* where a *private key* for Bitcoin *address* is printed on a piece of paper (with or without encryption) and then all traces of the key are removed from the computer where it was generated.
To redeem bitcoins, a key must be imported in the wallet application so it can sign a transaction.
See also *Casascius Coins*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
AddressWpg::
* https://blog.bitaccess.co/how-to-send-bitcoin-from-paper-wallet/
btcwlt.PROGRAM (btcwtp)
Description::
Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis.
[https://bitcoin.org/en/developer-guide#wallets]
Name::
* cpt.bitcoin-wallet-program,
* cpt.btcnet'wallet-program,
* cpt.btcwallet-application,
* cpt.btcwallet-program,
* cpt.btcwallet-software,
* cpt.btcwtp,
btcwtp'doing
Description::
This leaves us with three necessary, but separable, parts of a wallet system: a public key distribution program, a signing program, and a networked program.
In the subsections below, we will describe common combinations of these parts.
[https://bitcoin.org/en/developer-guide#wallet-programs]
===
What if I receive a bitcoin when my computer is powered off?
This works fine. The bitcoins will appear next time you start your wallet application. Bitcoins are not actually received by the software on your computer, they are appended to a public ledger that is shared between all the devices on the network. If you are sent bitcoins when your wallet client program is not running and you later launch it, it will download blocks and catch up with any transactions it did not already know about, and the bitcoins will eventually appear as if they were just received in real time. Your wallet is only needed when you wish to spend bitcoins.
[https://bitcoin.org/en/faq#what-if-i-receive-a-bitcoin-when-my-computer-is-powered-off]
SPECIFIC
Specific::
* full-service-wallet-program,
btcwtp.computer.DESKTOP
Name::
* cpt.bitcoin-mobile-wallet,
* cpt.btcdesktop-wallet,
btcwtp.computer.MOBILE
Description::
Most mobile wallets support scanning bitcoin: URIs encoded in a QR code, and almost all wallets can display them for accepting payment.
While also handy for online orders, QR Codes are especially useful for in-person purchases.
[https://bitcoin.org/en/developer-guide#requesting-payments]
Name::
* cpt.bitcoin-mobile-wallet,
* cpt.btcmobile-wallet,
btcwtp.FULL-SERVICE
Description::
The simplest wallet is a program which performs all three functions: it generates private keys, derives the corresponding public keys, helps distribute those public keys as necessary, monitors for outputs spent to those public keys, creates and signs transactions spending those outputs, and broadcasts the signed transactions.
As of this writing, almost all popular wallets can be used as full-service wallets.
The main advantage of full-service wallets is that they are easy to use. A single program does everything the user needs to receive and spend satoshis.
The main disadvantage of full-service wallets is that they store the private keys on a device connected to the Internet. The compromise of such devices is a common occurrence, and an Internet connection makes it easy to transmit private keys from a compromised device to an attacker.
To help protect against theft, many wallet programs offer users the option of encrypting the wallet files which contain the private keys. This protects the private keys when they aren’t being used, but it cannot protect against an attack designed to capture the encryption key or to read the decrypted keys from memory.
[https://bitcoin.org/en/developer-guide#full-service-wallets]
Part::
Several full-service wallets programs will also operate as two separate wallets:
one program instance acting as a signing-only wallet (often called an “offline wallet”) and the other program instance acting as the networked wallet (often called an “online wallet” or “watching-only wallet”).
[https://bitcoin.org/en/developer-guide#offline-wallets]
btcwtp.MYCELIUM
Description::
Mycelium Bitcoin Wallet
2,413
Mycelium Developers Finance
PEGI 3 PEGI 3
You don't have any devices
With the Mycelium Bitcoin Wallet you can send and receive Bitcoins using your mobile phone.
The unparalleled cold storage functionality allows you to 100% secure your funds until you are ready to spend them: http://youtu.be/jV-29RFU6xA
see also our promotional video "Mycelia in Wonderland" at https://www.youtube.com/watch?v=2_h9ZZwhwBg
- 100% control over your private keys, they never leave your device unless you export them
- No block chain download, install and run in seconds
- HD enabled - manage multiple accounts and never reuse addresses (Bip32, Bip44)
- Ultra fast connection to the Bitcoin network through our super nodes
- Watch-only addresses & private key import for secure cold-storage integration
- Secure your wallet with a PIN
- Compatible with other bitcoin services through bitcoin: uri handling
- Support for Bip38 Keys
- Find other people to trade Bitcoins with
Please always make sure you have backups of your private keys!
This application's source is published at https://github.com/mycelium-com/wallet
We need your feedback. If you have a suggestion or a bug to report open an issue at https://github.com/mycelium-com/wallet/issues
More features:
- Master seed based - make one backup and be safe for ever. (Bip39)
- 100% control over your private keys, they never leave your device unless you export them
- No block-chain download - install and run in seconds
- For enhanced privacy and availability you can connect to our super nodes via a tor hidden-service ( .onion address)
- Watch-only addresses (single key or HD) for a secure cold-storage integration
- Private key (single or xPriv) import
- Directly spend from paper wallets (single key, xPriv or master seed)
- Trezor enabled - directly spend from trezor-secured accounts.
- Mycelium Entropy compatible Shamir-Secret-Shared 2-out-of-3 keys spending
- Secure your wallet with a PIN
- Compatible with other bitcoin services through bitcoin: uri handling
- Encrypted PDF backup and restore of single key accounts
- Send and receive by specifying an amount in Fiat and switch between fiat and BTC while entering the amount
- Address book for commonly used addresses
- Transaction history with full transaction details.
- Share your bitcoin address using NFC, Twitter, Facebook, email and more.
- BIP70 payment request compatible
- Integration with service cashila.com to send money via SEPA
- Support for BitID Authentication
- Deterministic signatures for Bitcoin transactions (RFC6979)
Explanation for permission requests:
- Location - used to update LocalTrader location - only when user manually updates it.
- Camera/Microphone - Scan QR codes.
[https://play.google.com/store/apps/details?id=com.mycelium.wallet]
Name::
* cpt.Mycelium,
mycelium.EVOLUTING
{time.2016-07-23}
Mycelium, one of the world’s first and top rated software wallets, will integrate with Dash which will come into effect in October to allow Mycelium users to buy, sell and hold Dash, whose unique characteristics include extremely low fees, advanced encryption, instant transactions, and optional payment privacy through pool mixing technology.
Dash is like digital cash managed by a self funded, self governed organization comprised of over 15,000 users who move half a million dollars across the network every 24 hours. It can be spent instantly online and at merchants and service providers worldwide with transactions verified by miners and its system protected by 4,000 master nodes across the world. Its in-built governance and funding system allows projects to be proposed and voted on by the community, and if approved, paid for directly from the Blockchain.
The partnership is a testimony to the Dash system’s ability to make agreements with traditional corporations and keep its commitments while being a DAO.
[https://cointelegraph.com/news/dash-considered-alternative-to-bitcoin-integrates-into-mycelium]
btcwtp.OFFLINE
Description::
Several full-service wallets programs will also operate as two separate wallets: one program instance acting as a signing-only wallet (often called an “offline wallet”) and the other program instance acting as the networked wallet (often called an “online wallet” or “watching-only wallet”).
The offline wallet is so named because it is intended to be run on a device which does not connect to any network, greatly reducing the number of attack vectors. If this is the case, it is usually up to the user to handle all data transfer using removable media such as USB drives. The user’s workflow is something like:
(Offline) Disable all network connections on a device and install the wallet software. Start the wallet software in offline mode to create the parent private and public keys. Copy the parent public key to removable media.
(Online) Install the wallet software on another device, this one connected to the Internet, and import the parent public key from the removable media. As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the output details and save the unsigned transaction generated by the wallet to removable media.
(Offline) Open the unsigned transaction in the offline instance, review the output details to make sure they spend the correct amount to the correct address. This prevents malware on the online wallet from tricking the user into signing a transaction which pays an attacker. After review, sign the transaction and save it to removable media.
(Online) Open the signed transaction in the online instance so it can broadcast it to the peer-to-peer network.
The primary advantage of offline wallets is their possibility for greatly improved security over full-service wallets. As long as the offline wallet is not compromised (or flawed) and the user reviews all outgoing transactions before signing, the user’s satoshis are safe even if the online wallet is compromised.
The primary disadvantage of offline wallets is hassle. For maximum security, they require the user dedicate a device to only offline tasks. The offline device must be booted up whenever funds are to be spent, and the user must physically copy data from the online device to the offline device and back.
[https://bitcoin.org/en/developer-guide#signing-only-wallets]
Name::
* cpt.btcOffline-wallet-program,
* cpt.btcsigning-only-wallet,
Description::
To increase security, private keys can be generated and stored by a separate wallet program operating in a more secure environment. These signing-only wallets work in conjunction with a networked wallet which interacts with the peer-to-peer network.
... The following subsections describe the two most common variants of signing-only wallets: offline wallets and hardware wallets.
[https://bitcoin.org/en/developer-guide#signing-only-wallets]
btcwtp.os.ANDROID
Name::
* cpt.btcandroid-wallet,
btcwtp.os.iOS
Name::
* cpt.btcios-wallet,
btcwtp.os.LINUX
Name::
* cpt.btclinux-wallet,
btcwtp.os.WINDOWS
Name::
* cpt.btcwindows-wallet,
btcwtp.WEB
Description::
A-bitcoin-web-wallet is a-wallet-program that utilizes the-browser-program.
It could store the-keys online or locally.
[hmnSgm.2017-04-04]
Name::
* cpt.bitcoin-web-wallet,
* cpt.btcwlt.web,
* cpt.btcwtp.web,
Description::
web-wallet:
A web service providing wallet functionality: ability to store, send and receive bitcoins.
User has to trust counter-party to keep their bitcoins securely and ready to redeem at any time.
It is very easy to build your own web wallet, so most of them were prone to hacks or outright fraud.
The most secure and respected web wallet is *Blockchain.info*.
Online exchanges also provide wallet functionality, so they can also be considered web wallets.
It is not recommended to store large amounts of bitcoins in a web wallet.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcwlt.HARDWARE
Name::
* cpt.bitcoin-hardware-wallet,
* cpt.btcHardware-wallet,
Generic::
* Bitcoin-signing-only-wallet-program,
Description::
A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
They have major advantages over standard software wallets:
private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext
immune to computer viruses that steal from software wallets
can be used securely and interactively, as opposed to a paper wallet which must be imported to software at some point
much of the time, the software is open source, allowing a user to validate the entire operation of the device
This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.
[https://en.bitcoin.it/wiki/Hardware_wallet]
===
Hardware wallets are devices dedicated to running a signing-only wallet. Their dedication lets them eliminate many of the vulnerabilities present in operating systems designed for general use, allowing them to safely communicate directly with other devices so users don’t need to transfer data manually. The user’s workflow is something like:
(Hardware) Create parent private and public keys. Connect hardware wallet to a networked device so it can get the parent public key.
(Networked) As you would with a full-service wallet, distribute public keys to receive payment. When ready to spend satoshis, fill in the transaction details, connect the hardware wallet, and click Spend. The networked wallet will automatically send the transaction details to the hardware wallet.
(Hardware) Review the transaction details on the hardware wallet’s screen. Some hardware wallets may prompt for a passphrase or PIN number. The hardware wallet signs the transaction and uploads it to the networked wallet.
(Networked) The networked wallet receives the signed transaction from the hardware wallet and broadcasts it to the network.
The primary advantage of hardware wallets is their possibility for greatly improved security over full-service wallets with much less hassle than offline wallets.
The primary disadvantage of hardware wallets is their hassle. Even though the hassle is less than that of offline wallets, the user must still purchase a hardware wallet device and carry it with them whenever they need to make a transaction using the signing-only wallet.
An additional (hopefully temporary) disadvantage is that, as of this writing, very few popular wallet programs support hardware wallets—although almost all popular wallet programs have announced their intention to support at least one model of hardware wallet.
[https://bitcoin.org/en/developer-guide#hardware-wallets]
btcwlt.HD (Hierarchical-Deterministic)
Description::
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy.
Wallets using the HD protocol are called HD wallets.
[https://bitcoin.org/en/glossary/hd-protocol]
===
Deterministic_Wallet:
A collective term for different ways to generate a sequence of *private keys* and/or *public keys*. Deterministic wallet does not need a *Key Pool*.
The simplest form of a deterministic wallet is based on hashing a secret string concatenated with a key number.
For each number the resulting hash is used as a private key (public key is derived from it).
More complex scheme uses *elliptic curve arithmetic* to derive sequences of public and private keys separately which allows generating new *addresses* for every payment request without storing private keys on a web server.
More information on Bitcoin Wiki.
See also *Wallet*.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-HD-wallet,
* cpt.btcHD-wallet,
* cpt.deterministic-wallet-of-btcnet,
btcwltHd'HD-protocoll
Description::
The hierarchical deterministic key creation and transfer protocol (HD protocol) greatly simplifies wallet backups, eliminates the need for repeated communication between multiple programs using the same wallet, permits creation of child accounts which can operate independently, gives each parent account the ability to monitor or control its children even if the child account is compromised, and divides each account into full-access and restricted-access parts so untrusted users or programs can be allowed to receive or monitor payments without being able to spend them.
[https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation]
===
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy. Wallets using the HD protocol are called HD wallets.
[https://bitcoin.org/en/glossary/hd-protocol]
Name::
* cpt.btcHD-protocol,
* cpt.btcBIP32,
AddressWpg::
* https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki,
btcwltHd'chain-code
Description::
In HD wallets, 256 bits of entropy added to the public and private keys to help them generate secure child keys; the master chain code is usually derived from a seed along with the master private key
[https://bitcoin.org/en/glossary/chain-code]
Name::
* cpt.btcChain-Code,
* cpt.btcHD-Wallet-Chain-Code
btcwltHd'child-key
Description::
In HD wallets, a key derived from a parent key.
The key can be either a private key or a public key, and the key derivation may also require a chain code.
[https://bitcoin.org/en/glossary/child-key]
Name::
* cpt.btcChild-Key,
* cpt.btcHD-Wallet-Child-Key
btcwltHd'parent-key
Description::
In HD wallets, a key used to derive child keys. The key can be either a private key or a public key, and the key derivation may also require a chain code.
[https://bitcoin.org/en/glossary/parent-key]
Name::
* cpt.btcParent-Key,
* cpt.btcHD-Wallet-Parent-Key,
btcwltHd'Root-seed
Description::
A potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.
[https://bitcoin.org/en/glossary/hd-wallet-seed]
Name::
* cpt.btcHD-Wallet-Seed,
* cpt.btcRoot-Seed,
btcwlt.ONLINE (hot)
Description::
Wallets can be divided into two categories: hot and cold.
The difference between these is the location where the private keys are stored.
If the keys are stored on a computer connected to a network (like a laptop, desktop, or mobile device) the wallet is considered “hot” since the funds are within reach for you to use, but also for malware and cyber-criminals to steal.
If the private keys are stored on an offline device (like a laptop with disabled networking components, or a piece of paper) then it is considered “cold” since there is no way to gain access to the keys without having them physically in your hands.
[http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf]
Name::
* cpt.btchot-wallet,
* cpt.btcnetworked-wallet,
* cpt.btcwallet.hot,
btcwlt.ONLINE.NO (cold | offline)
Description::
Due to the risk of computers and USB drives being infected with bitcoin-stealing malware, most Bitcoin experts recommend storing your bitcoins offline. This is often referred to as “cold storage.”
[http://bitcoinconsultant.net/coinpro/]
===
btcCold_Storage:
A collective term for various security measures to reduce the risk of remote access to the private keys. It could be a normal computer disconnected from the internet, or a dedicated hardware wallet, or a USB stick with a wallet file, or a *paper wallet*.
Name::
* cpt.btccold-storage,
* cpt.btccold-wallet,
* cpt.btcwallet.cold,
btcnet'Problem
Name::
* cpt.bitcoin-problem,
* cpt.btcpbm,
* cpt.btcproblem,
btcnet'Security (btcscrt)
Description::
Two basic questions for anyone accepting digital money are:
- Can I trust the money is authentic and not counterfeit?
- Can I be sure that no one else can claim that this money belongs to them and not me? (Aka the “double-spend” problem.)
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
8 November 2013 Last updated at 16:22 GMT Share this pageEmailPrint
ShareFacebookTwitter
Major Bitcoin theft from website, claims owner
Bitcoins
Bitcoins are becoming more popular as a method of payment online
Continue reading the main story
Related Stories
What is Bitcoin? Watch
Bitcoin 'at risk' of network attack
Man cashes in on $22 Bitcoin stash
A man who ran an online "wallet service" for storing Bitcoins has claimed hackers stole virtual currency from his site worth more than one million Australian dollars.
The Australian man said 4,100 Bitcoins (US$1.04m, £650,000) were taken in two separate attacks.
He said he would not report the theft to police as Bitcoin transactions are virtually impossible to trace.
This has led some users to speculate whether it was an "inside job".
In a radio interview with ABC News the man, who only used his online name TradeFortress, denied being involved.
The Bitcoin virtual currency is increasingly used to pay for things online.
According to the Sydney Morning Herald, the theft occurred on 26 October but users were only alerted this week via a message he posted on the wallet service's website.
"I know this doesn't mean much, but I'm sorry, and saying that I'm very sad that this has happened is an understatement.
"Please don't store Bitcoins on an internet-connected device, regardless if it is your own or a service's."
Bitcoin is the most well known of a handful of virtual currencies. The currencies are developed through a computer process called "mining" and can be traded on exchanges or privately between users.
[http://www.bbc.co.uk/news/technology-24871444]
Name::
* cpt.bitcoin-security,
* cpt.btcsecurity,
{time.2015}
=== Former Mt Gox chief arrested in Japan
Japanese police have arrested Mark Karpelθs, the head of the bankrupt Japan-based bitcoin exchange Mt Gox, who is alleged to have manipulated the computer system to inflate his account.
[FINANCIAL TIMES, Saturday August 01 2015, BREAKING NEWS]
btcpbm'LBC
Description::
What is LBC?
The "Large Bitcoin Collider" (LBC - a homage to LHC) is a distributed effort to find at least one collision of private Bitcoin keys by creating addresses to private keys in the 2160 range. These are checked against the list of known BTC addresses with funds on them. In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.
[https://lbc.cryptoguru.org/about]
btcpbm'Privacy
Description::
The concept of privacy is best defined as the amount of control you have over your information. This control not only includes the power to hide or conceal your personal information, but also the power to reveal it to the public.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
Name::
* cpt.btcprivacy,
btcpbm'Protection
Description::
Transparency Requires Protection
Bitcoin is by default a transparent system, in which every piece of information is available to the public. As such, every Bitcoin user requires some level of protection. Anyone with substantial wealth in Bitcoin would not want to advertise their funds to every person they transact with, for obvious reasons. But every time you spend just a tiny portion of your Bitcoin wallet, you reveal your wealth to the other party. Doing that on the Internet is like flashing large stacks of cash in a dark back alley. It is not advisable! A criminal might see how much you have, and decide to come after it. Distributing your wealth between several wallets and using a different address for each transaction is a common practice that prevents others from knowing how much Bitcoin you have.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
Name::
* cpt.btcprotection,
btcpbm'Transparency
Description::
Transparency Requires Protection
Bitcoin is by default a transparent system, in which every piece of information is available to the public. As such, every Bitcoin user requires some level of protection. Anyone with substantial wealth in Bitcoin would not want to advertise their funds to every person they transact with, for obvious reasons. But every time you spend just a tiny portion of your Bitcoin wallet, you reveal your wealth to the other party. Doing that on the Internet is like flashing large stacks of cash in a dark back alley. It is not advisable! A criminal might see how much you have, and decide to come after it. Distributing your wealth between several wallets and using a different address for each transaction is a common practice that prevents others from knowing how much Bitcoin you have.
[https://www.expressvpn.com/internet-privacy/bitcoin-anonymity/]
Name::
* cpt.btctransparency,
btcpbm'Double-spend
Name::
* cpt.bitcoin-double-spend,
Description::
A fraudulent attempt to spend the same *transaction output* twice.
There are two major ways to perform a double spend:
reverting an unconfirmed transaction by making another one which has a higher chance of being included in a block (only works with merchants accepting zero-confirmation transactions) or
by mining a parallel blockchain with a second transaction to overtake the chain where the first transaction was included.
Bitcoin proof-of-work scheme makes a probabilistic guarantee of difficulty to double spend transactions included in the *blockchain*.
The deeper transaction is recorded in the blockchain, the more expensive it is to "reverse" it.
See also 51% attack.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
btcpbm'51-percent-attack
Description::
A condition in which more than half the computing power on a cryptocurrency network is controlled by a single miner or group of miners.
That amount of power theoretically makes them the authority on the network.
This means that every client on the network believes the attacker’s hashed transaction block.
This gives them control over the network, including the power to:
Issue a transaction that conflicts with someone else's.
Stop someone else's transaction from being confirmed.
Spend the same coins multiple times.
Prevent other miners from mining valid blocks.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
51percent_Attack:
Also known as >50% attack or a *double spend* attack.
An attacker can make a payment, wait till the merchant accepts some number of *confirmations* and provides the service, then starts mining a parallel chain of blocks starting with a block before the transaction.
This parallel blockchain then includes another transaction that spends the same *outputs* on some other address.
When the parallel chain becomes more *difficult*, it is considered a *main chain* by all nodes and the original transaction becomes invalid.
Having more than a half of total *hashrate* guarantees possibility to overtake chain of any length, hence the name of an attack (strictly speaking, it is "more than 50%", not 51%).
Also, even 40% of hashrate allows making a double spend, but the chances are less than 100% and are diminishing exponentially with the number of confirmations that the merchant requires.
This attack is considered theoretical as owning more than 50% of hashrate might be much more expensive than any gain from a *double spend*.
Another variant of an attack is to disrupt the network by mining empty blocks, censoring all transactions.
An attack can be mitigated by blacklisting blocks that most of "honest" miners consider abnormal.
Under normal conditions, miners and mining pools do not censor blocks and transactions as it may diminish trust in Bitcoin and thus their own investments.
51% attack is also mitigated by using *checkpoints* that prevent *reorganization* past the certain block.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-51-percent-attack,
* cpt.btc51-percent-attack,
btcpbm'Denial-of-service
Description::
Denial_of_Service:
Is a form of attack on the network.
Bitcoin *nodes* punish certain behavior of other nodes by banning their IP addresses for 24 hours to avoid DoS.
Also, some theoretical attacks like *51% attack* may be used for network-wide DoS.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-denial-of-service,
* cpt.btndenial-of-service,
* cpt.btnDoS,
btcnet'Human (btchmn)
Name::
* cpt.btchmn,
* cpt.btchuman,
* cpt.btccommunity,
AddressWpg::
* http://themonetaryfuture.blogspot.gr/2016/05/how-i-met-satoshi.html,
* http://www.drcraigwright.net/
* https://bitcointalk.org/
* https://bitcoin.org/en/community,
* http://motherboard.vice.com/blog/who-is-satoshi-nakamoto-the-creator-of-bitcoin,
Specific::
* Nakamoto.Satoshi,
* Gavin Andresen
* Hal Finney
* Mark Karpeles
* Nick Szabo
* Amir Taaki
* Winklevoss twins
* Antonopoulos.Andreas,
btchmn.MINER
Description::
blocks are created by users known as "miners" who use specialized software or equipment designed specifically to create blocks.
[https://en.wikipedia.org/wiki/Block_chain_%28database%29]
Name::
* cpt.bitcoin-miner,
* cpt.btcminer,
NameGreek::
* ενν.εξορύκτης-μπικόιν,
btchmn.RECEIVER
Name::
* cpt.btcreceiver,
btchmn.SPENDER
Name::
* cpt.btcspender,
btchmn.Antonopoulos.Andreas
Description::
Andreas M. Antonopoulos
Public Speaker | Author | Coder | Entrepreneur | Commentator
Author of “Mastering Bitcoin” by O’Reilly Media
MasteringBitcoin
Follow @aantonop on Twitter
Andreas M. Antonopoulos is a technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in bitcoin. As an engaging public speaker, teacher and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.
Andreas literally grew up with the Internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in Computer Science, Data Communications and Distributed Systems from University College London (UCL), recently ranked in the world’s top 10 universities. After moving to the US Andreas co-founded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers and cloud computing. More than 200 of his articles on security, cloud computing and data centers have been published in print and syndicated worldwide. He holds 2 patents in networking and security.
In 1990, Andreas started teaching on various IT topics in private, professional and academic environments. Andreas honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than four hundred speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a Masters Degree in Digital Currency. In this role, he helped to developed the curriculum and co-taught the Introduction to Digital Currencies course, offered as a MOOC (massively open online course), through the University.
As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open-source projects. He serves as an advisor to several bitcoin and crypto-currency companies. He is a widely published author of articles and blog posts on bitcoin, is a permanent host on the popular Let’s Talk Bitcoin Podcast, and a frequent speaker at technology and security conferences worldwide.
[http://antonopoulos.com/]
Name::
* cpt.hmn.Antonopoulos.Andreas,
* cpt.Andreas-Antonopoulos,
* cpt.Antonopoulos.Andreas,
AddressWpg::
* https://antonopoulos.com/
* https://github.com/aantonop/bitcoinbook/blob/develop/book.asciidoc,
btchmn.Back.Adam
Description::
Adam Back, Ph.D.
President
Having worked on e-cash protocols since 1995, Adam is an applied cryptographer and inventor of the hashcash proof-of-work and decentralized mining used in Bitcoin. In addition to implementing credlib, he was an e-cash consultant to Nokia and later to Credentica (acquired by Microsoft). Adam was an architect and cryptographer at Zero-Knowledge Systems working on its Freedom network, a precursor to Tor. He has also consulted for leading security companies, including oneID, Vmware and QWcap. Most recently, Adam co-founded Picorp, which was acquired by EMC and where he was CSO of the company’s consumer division, Decho. Adam holds a Ph.D. in distributed systems and computer science from the University of Exeter.
[https://www.blockstream.com/team/]
Name::
* cpt.hmn.Back.Adam,
* cpt.Adam-Back,
* cpt.Back.Adam,
btchmn.Nakamoto.Satoshi (btchmnSnt)
Description::
Satoshi Nakamoto is the name used by the unknown person or persons who designed bitcoin and created its original reference implementation. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double spending problem for digital currency. They were active in the development of bitcoin up until December 2010.
[https://en.wikipedia.org/wiki/Satoshi_Nakamoto] {2017-05-06}
Name::
* cpt.bcnhmn.Nakamoto.Satoshi,
* cpt.btchmn.Nakamoto.Satoshi,
* cpt.btchmnSnt,
* cpt.btchmn.Satoshi-Nakamoto,
* cpt.hmn.Nakamoto.Satoshi,
* cpt.Satoshi-Nakamoto,
* cpt.Nakamoto.Satoshi,
Description::
Blockchain technology is the technological basis of Bitcoin, first described by its mysterious author Satoshi Nakamoto in his white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”, published in 2008.
[https://ethereum-homestead.readthedocs.org/en/latest/introduction/what-is-ethereum.html#a-next-generation-blockchain]
===
In November 2008, a paper, authored (probably pseudonymously) by Satoshi Nakamoto, was posted on the newly created Bitcoin.org website with the title ‘Bitcoin: A Peer-to-Peer Electronic Cash System’.
The eight-page document described methods of using a peer-to-peer network to generate "a system for electronic transactions without relying on trust" and laid down the working principles of the cryptocurrency.
[http://www.coindesk.com/information/bitcoin-glossary/]
===
Satoshi left the project in late 2010 without revealing much about himself.
[https://bitcoin.org/en/faq#who-created-bitcoin]
===
A pseudonym of an author of initial Bitcoin implementation.
There are multitude of speculations on who and how many people worked on Bitcoin, of which nationality or age, but no one has any evidence to say anything definitive on that matter.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
===
Satoshi_Nakamoto:
The name used by the original inventor of the Bitcoin protocol, who withdrew from the project at the end of 2010.
[http://www.coindesk.com/information/bitcoin-glossary/]
btcnet'Organization (btcogn)
Name::
* cpt.btcogn,
* cpt.bitcoin-system-organization,
* cpt.btcogn,
btcogn.BITCOIN-FOUNDATION
Name::
* cpt.bitcoin-foundation,
Σύλληψη ενός εκ των «πρωτοπόρων» του Bitcoin
Τετάρτη, 29 Ιανουαρίου 2014 16:06 UPD:16:11
REUTERS/LUCAS JACKSON
Ο αντιπρόεδρος του Ιδρύματος Bitcoin Τσάρλι Σρεμ κατά την έξοδό του από το Ομοσπονδιακό δικαστήριο του Μανχάταν στη Νέα Υόρκη.
Για ξέπλυμα χρημάτων συνελήφθη την Κυριακή στο αεροδρόμιο Κένεντι της Νέας Υόρκης ο 24χρονος Τσάρλι Σρεμ, ένας εκ των πλέον επιφανών υποστηρικτών της καθιέρωσης του διαδικτυακού νομίσματος, Bitcoin.
Ο Σρεμ συνελήφθη κατόπιν έρευνας της αμερικανικής υπηρεσίας Δίωξης Ναρκωτικών (DEA), καθώς κατηγορείται ότι, μαζί με συνεργό του, χρησιμοποίησαν bitcoins για να «ξεπλύνουν» χρήματα από πωλήσεις ναρκωτικών που σχετίζονταν με τη διαβόητη online αγορά Silk Road (η λειτουργία του τερματίστηκε κατόπιν επέμβασης των αρχών τον Οκτώβριο).
Σημειώνεται ότι ο Σρεμ ήταν αντιπρόεδρος του Ιδρύματος Bitcoin (Bitcoin Foundation), που έχει ως στόχο την καθιέρωση/ ευρεία αποδοχή του διαδικτυακού νομίσματος, και διευθύνων σύμβουλος, συνιδρυτής και επιβλέπων του ανταλλακτηρίου BitInstant.com.
Όπως έγινε γνωστό την Τρίτη, ο Σρεμ παραιτήθηκε από τη θέση του ως αντιπροέδρου του ιδρύματος μετά τη σύλληψή του.
Επίσης, συνελήφθη και ο 52χρονος Ρόμπερτ Φαϊέλα, (BTCKing) στη Φλόριντα.
Ειδικότερα, ο Σρεμ κατηγορείται ότι επέτρεψε στον Φαϊέλα να χρησιμοποιήσει το BitInstant για να αγοράσει μεγάλα ποσά bitcoins (αξίας ενός εκατ. δολαρίων), για να τα πουλήσει σε χρήστες του Silk Road που επιθυμούσαν να αγοράσουν ναρκωτικά. Σύμφωνα με τις αρχές, ο Σρεμ ήξερε ότι τα bitcoins προορίζονταν για αυτή τη χρήση.
EURONEWS
Η.Π.Α: Συνελήφθησαν δύο άτομα που ξέπλεναν χρήματα χρησιμοποιώντας bitcoin
Εκπρόσωπος του Bitcoin Foundation εξέφρασε την έκπληξη του ιδρύματος από την εξέλιξη της υπόθεσης, διαχωρίζοντας τη θέση του από τις συγκεκριμένες δραστηριότητες.
Το BitInstant ήταν ένα από τα μεγαλύτερα ανταλλακτήρια bitcoins στο Ίντερνετ, ωστόσο η πρόσβαση σε αυτό δεν ήταν δυνατή για κάποιο χρονικό διάστημα, όπως δήλωσε στο BBC ο Μάικ Χιρν, στέλεχος του συμβουλίου του Bitcoin Foundation.
[http://www.naftemporiki.gr/story/758439]
btcogn.SERVICE
Name::
* cpt.btcnet'service,
* cpt.bitcoin-service,
* cpt.btcService-organization,
* cpt.ognBtcsvc,
Specific::
* http://bitcoinconsultant.net/trade/
btcogn.EXCHANGE (btcognX)
Description::
Exchange:
A central resource for exchanging different forms of money and other assets.
Bitcoin exchanges are typically used to exchange the cryptocurrency for other, typically fiat, currencies.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.bitcoin-exchange,
* cpt.btcexchange,
SPECIFIC
Specific::
* https://bitcoinsgreece.com/
* https://www.mtgox.com/
Popular Bitcoin Currency Exchanges
(New York) BitInstant
- Cash Deposit (USA, Russia, Brazil)
(New York) BitFloor.com
- Cash Deposits (Chase, Wells Fargo)
- ING person2person
- Wire Transfer
(London) Intersango.com
- ACH
- Dwolla
- Wire Transfer
(Tokyo) MtGox.com
- Cash Deposit (BitInstant)
- Dwolla
- Wire Transfer
(Slovenia) BitStamp.net
- Cash Deposit (BitInstant)
- SEPA Transfer
- Wire Transfer
(Atlanta) CampBX.com
- Check, Money Order
- Dwolla
- Wire Transfer
(NSW, Australia) CryptoXChange.com
- Cash Deposit (BitInstant)
- Dwolla
- Bank Transfer
(Moscow) BTC-e.com
- Cash Deposit (BitInstant)
- SEPA Transfer
- Wire Transfer
(Hadera, Israel) Bitcoil.co.il
- Bank Transfer
(Fujian, China) BTCChina.com
[http://lovebitcoins.org/exchange.html]
btcognX.Mt.Gox
Description::
Mt.Gox:
One of the first bitcoin exchanges, and at one time the most popular.
Mt.Gox has since gone into administration.
Based in Japan, the exchange was started by Jed McCaleb in 2010.
Read the latest Mt.Gox news.
[http://www.coindesk.com/information/bitcoin-glossary/]
Name::
* cpt.btcMt.Gox,
btcogn.CLOUD-MINING
Description::
Most Bitcoin Cloud Mining Companies are Scams
Like the heading says, most cloud mining contracts are scams. Why? Because it’s easy for companies to take peoples’ money, and then not pay out. A company can claim to be a cloud mining company without any proof of actually owning any hardware.
So remember: 99% of cloud mining companies are scams.
Which Companies Are Not Scams?
There is only one cloud mining company we are willing to recommend on this site: Genesis Mining.
Just because it is not a scam, however, does not mean that you will make a profit by using it.
[https://www.hobbymining.com/bitcoin-cloud-mining/]
Name::
* cpt.bitcoin-cloud-mining,
* cpt.btccloud-mining,
btcogn.MINING-POOL
Description::
What is a Mining Pool?
Mining, once done on the average home computer, is now mostly done in large, specialized warehouses. These warehouses usually direct their hashing power towards mining pools. What is a mining pool? Here’s the definition from Buy Bitcoin Worldwide:
Mining pools are groups of cooperating miners who agree to share block rewards in proportion to their contributed mining hashing power. While mining pools are desirable to the average miner as they smooth out rewards and make them more predictable, they unfortunately concentrate power to the mining pool’s owner. Miners can, however, choose to redirect their hashing power to a different mining pool at anytime.
While we can see which mining pools are the largest, it’s important to understand that the hash power pointed towards a mining pool isn’t necessarily owned by the mining pool itself. There are a few cases, like with BitFury and KnCMiner, where the company itself runs the mining operation but doesn’t run a mining pool.
Bitcoin miners can switch mining pools easily by routing their hash power to a different pool. The market share of pools is constantly changing. To make the list of top 10 miners, we looked at blocks found over the past 6 months using data from BlockTrail. The size of mining pools is constantly changing. We will do our best to keep this posted up-to-date. Note that if you cloud mine then you don’t need to select a pool; the cloud mining company does this automatically.
[https://www.hobbymining.com/bitcoin-mining-pools/]
Name::
* cpt.bitcoin-mining-pool,
* cpt.btcmining-pool,
btcogn.WALLET
ognBtc.Blocktrail
Description::
A Powerful Bitcoin Wallet
Blocktrail is a Bitcoin wallet that puts you in full control of your Bitcoin
[https://www.blocktrail.com/]
btcogn.MERCHANT
Name::
* cpt.bitcoin-merchant,
* cpt.bitcoin-shopping-organization,
* cpt.btcmerchant,
Specific::
* bitit https://bitit.gift/
Purse
Description::
Purse is a marketplace that connects shoppers with unused gift cards.
Shoppers pay with bitcoins at a huge discount, and Earners liquidate gift cards.
[https://purse.io/]
Name::
* cpt.btcpurse,
AddressWpg::
* https://purse.io/
btcogn.EXCHANGE
Description::
Digital currency exchangers (DCEs) or Bitcoin exchanges are businesses that allow customers to trade digital currencies for other assets, such as conventional fiat money, or different digital currencies.[1] They can be market makers that typically take the bid/ask spreads as transaction commissions for their services or simply charge fees as a matching platform.[1]
DCEs may be brick-and-mortar businesses, exchanging traditional payment methods and digital currencies, or strictly online businesses, exchanging electronically transferred money and digital currencies.[2] Most digital currency exchanges operate outside of Western countries, avoiding regulatory oversight and complicating prosecutions, but DCEs often handle Western fiat currencies, sometimes maintaining bank accounts in several countries to facilitate deposits in various national currencies.[3][4] They may accept credit card payments, wire transfers, postal money orders, or other forms of payment in exchange for digital currencies, and many can convert digital currency balances into anonymous prepaid cards which can be used to withdraw funds from ATMs worldwide.[3][4]
Some digital currencies are backed by real-world commodities such as gold.[5]
Creators of digital currencies are often independent of the DCEs that trade the currency.[4] In one type of system, digital currency providers, or DCPs, are businesses that keep and administer accounts for their customers, but generally do not issue digital currency to those customers directly.[2][6] Customers buy or sell digital currency from DCEs, who transfer the digital currency into or out of the customer's DCP account.[6] Some DCEs are subsidiaries of DCP, but many are legally independent businesses.[2] The denomination of funds kept in DCP accounts may be of a real or fictitious currency.[6]
https://en.wikipedia.org/wiki/Digital_currency_exchanger
===
The easiest way to obtain bitcoins is to receive them from another person. This can be done as an in-person trade, or you can accept bitcoins for your business using some business tools.
It is also easy to buy bitcoins at a currency exchange. There are many online currency exchanges that let you buy and sell bitcoins for US Dollars, Euros, Pounds, and many other currencies.
You can fund your exchange account with a cash deposit or electronic funds transfer. To learn more about cash deposits, visit BitInstant.com.
[http://lovebitcoins.org/exchange.html]
Name::
* cpt.bitcoin-exchange-ogn,
* cpt.btcmny'exchanger,
* cpt.btcnet'exchange,
* cpt.bitcoin-exchange,
* cpt.bitcoin-marketplace,
* cpt.bitcoin-exchange,
NameGreek::
* ενν.ανταλλακτήριο-μπιτκόιν,
btcogn.PAYMENT-PROCESSOR
Name::
* cpt.bitcoin-internet-payment-system,
* cpt.bitcoin-payment-processor,
* cpt.bitcoin-transaction-service,
Specific::
* https://bips.me/
* https://bitpay.com/
btcnet'Evaluation (btceln)
Name::
* cpt.btceln,
* cpt.btcevaluation,
* cpt.btcnet'evaluation,
Evaluation::
The current debate centers on a perceived tradeoff between the ability to process a growing number of transactions, on the one hand, and maintaining a highly decentralized mechanism for processing transactions on the other.
[http://www.forbes.com/sites/realspin/2015/09/08/new-bitcoin-development-spurs-unnecessary-fear-of-centralization/]
Evaluation::
5. Could you speculate on what the future may hold for bitcoin specifically and digital currencies generally?
First it’s important to recognize that most “digital currencies” are not really digital currencies at all, because they are pegged to standard currencies. Credits in your Paypal account are really just USD-backed; they are not a unique currency themselves. Other “digital currencies” such as Facebook Credits, can be created out of nothing and without limit, so they are not serious money (ironically, the USD is more like Facebook Credits than Bitcoin, because both USD and Facebook Credits can be created out of thin air, whereas Bitcoin cannot be).
So Bitcoin is the first, what should be called “true” digital currency. It is a scarce, digital commodity with properties that make it perfect for use as money, and so it is used for this purpose.
As the world starts to realize the benefits of a real digital currency, it will become used in countless ways. It will become as ubiquitous as email (and for the very same reason – email made the cost of written communication near-zero and Bitcoin makes the cost of monetary communication near-zero). Really, there is no reason it should cost $45 to send a “wire transfer” of money between two people. The bank is just changing digital numbers in a digital database – why does it cost $45 and take 3 days? It’s absurd, and Bitcoin finally offers a real alternative.
Bitcoin is an invention which people will look back upon and say, “wow, that was obviously needed,” just as we look back on the internet today. And, like the internet, Bitcoin will change the way people interact and do business around the world. But, it’s a process that takes years, and it’s only just getting started.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
btcnet'Advantage (pro)
Name::
* cpt.btcnet'benefit,
* cpt.btcadvantage,
* cpt.btcpro,
* cpt.bitcoin-favorable-factor,
* cpt.bitcoin-pro,
Specific::
* cheap micropayments,
* fast transactions,
* global interoperability, international currency,
* trustless (you don’t have to trust anyone)
* Bitcoins cannot be counterfeited,
the benefits of Bitcoin - fast transactions, global interoperability, cheap micropayments
[http://cointelegraph.com/news/bitcoin-in-africa-could-leapfrog-just-like-cellular-phones-replaced-landline]
2. What are the major advantages of bitcoin? How does bitcoin differ from other international payment systems like PayPal?
Advantages include:
1. Zero fee to transfer money
2. Transfers are instant. No holiday or weekend delays.
3. Works globally, no territory restrictions
4. Enables the storage and transfer of wealth with zero counter-party risk (ie – you don’t have to trust anyone)
5. Excellent hedge against monetary debasement (inflation)
6. Any amount can be sent (perfect for microtransactions under a penny, for example)
7. Zero chargeback risk (this means, once a merchant receives Bitcoin, there is no risk of a payment reversal or fraud. The funds are immediately “good”)
8. Ability to move around capital controls (for example, to get money out of China or Argentina)
9. Anyone can accept and use Bitcoin.
10. Open-source, continually upgradable. Anyone can adapt and improve the software and build with it.
How does this differ from PayPal? PayPal doesn’t share any of the above advantages, except perhaps for number 2. It’s important to realize that PayPal is just a payment system for US dollars using the traditional banking infrastructure, while Bitcoin is a payment system for its own currency unit: bitcoins, and is entirely separate from the traditional banking infrastructure.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
BITCOIN IS BETTER THAN REGULAR CURRENCIESSome of the reasons Bitcoin is better than regular currencies:
Bitcoin is an international currency.
Bitcoin can be spent all over the world.
Bitcoins cannot be counterfeited.
There is no printing technology that will ever be able to fool the bitcoin network.
Bitcoin cannot be devalued.
Only 21 million bitcoins will ever be issued. Unlike regular currencies, since Bitcoin is not controlled by any government or bank, the raising of a debt ceiling and quantitative easing can not devalue bitcoins.
[https://www.bitstamp.net/help/what-is-bitcoin/]
Use Bitcoins instead of PayPal
Not linked to your bank account
No central authority telling you what you can and cannot do with your money
Available in any country
Your account can never be seized or closed
Use Bitcoins for Remittance
Eliminate the high fees
No minimum or maximum amount
Available in any country
Use Bitcoins instead of Debit or Credit Cards
Not linked to your bank account
No risk of identity theft
No chance of overdraft fees or overlimit fees
No monthly fees or annual fees
Use Bitcoins instead of Online Banking
Deposits are available within minutes
No International Boundaries: send and receive anywhere in the world for no additional fees
Unlimited Access: have full control of your money, 24 hours/day, 7 days/week, from anywhere in the world
[http://lovebitcoins.org/introduction1.html]
btcnet'Disadvantage (con)
Name::
* cpt.bitcoin-cons,
* cpt.bitcoin-problem,
* cpt.bitcoin-issue,
3. What are the major liabilities of bitcoin? Is it associated with any major security problems?
Disadvantages include:
1. Steep learning curve
2. Requires personal responsibility (if you delete your wallet without making backups, your money is gone).
3. Value fluctuates and is relatively volatile (no guarantee that the price tomorrow will be the same as today).
Regarding security problems – this is an important point. All of the “bitcoin hacks” and security breaches to date have not been against Bitcoin itself, but rather against various companies and individuals who did not secure things properly. Consider a bank that leaves its doors and vault unlocked at night… it will find a theft has occurred in the morning. This doesn’t mean the US dollar was hacked, or that banking as an institution is necessarily at fault, but simply that one specific bank screwed up. The same is true with Bitcoin.
Frankly, it is very easy to lose your bitcoins if you are foolish, and it is very easy to never lose them if you are smart. The system requires some personal responsibility and due diligence. Because there is no company behind Bitcoin itself, there is no tech support you can call (this is the same with cash or bars of gold – if you lose them, they are gone, and nobody can get them back for you).
4. Is bitcoin commonly used to facilitate illegal transactions? Is it, as it has been characterized, a currency of crime?
Bitcoin, like any money, can be used for illegal transactions. Because of its private, secure nature, it is impossible to know the extent to which it is used for such purposes (just like we don’t know how much cash is used for illicit activity, but we all know that it happens).
Certainly the media has characterized Bitcoin as a “currency of crime”, because A) they don’t understand it and B) crime makes a good news story. Bitcoin is a highly powerful technology (like fire, or automobiles, or the internet itself) and thus it carries risk and danger. It can be used for good or evil – Bitcoin is morally agnostic, it’s just a tool. Now, to be sure, it’s a very good tool , and this means criminals will love to use it, just as good people will love to use it.
Likely for the foreseeable future, US dollar cash will remain the preferred currency of crime.
[http://keepyourassets.net/2012/09/27/bitcoin-the-first-five-questions/]
BITCOIN RISKS Do not invest anything in Bitcoin you can not afford to lose. Investing in Bitcoin or any other currency is not without risk. For example, any of the following could happen to Bitcoin:
Another crypto-currency might surpass Bitcoin
Several have already tried and failed.
A weakness in the encryption might be discovered
This is the same encryption used in online banking. Like banking systems, if a flaw is found in a particular algorithm, the Bitcoin client can be upgraded to use different encryption algorithms.
Governments might try to ban or regulate Bitcoin
This would be similar to the government banning the Internet because of illegal uses. Banning the Internet is unlikely because it would place the government and its people at a strategic communications disadvantage. Banning bitcoins, is similarly unlikely as it would place the government and its people at a strategic economic disadvantage.
An unfixable flaw might be discovered in the Bitcoin protocol
People have been trying to find a flaw for over two years.
[https://www.bitstamp.net/help/what-is-bitcoin/]
quantity
The Economic Problem is entirely separate. Whereas the Security Problem may wreck BTC, if BTC is not wrecked and takes over a large macro-economy (as people abandon government issued money for BTC), it is BTC that will wreck the economy. Why? Because it is designed to mimic the Gold Standard – the monetary system that caused one depression after the other, from the 19th Century until 1929, and which was replaced because capitalism cannot breathe under a fixed quantity of money.
Mr Nakamoto, BTC’s creator (whoever he, she or they may be) used ‘built-in scarcity’ in order to ensure that BTC would grow in value relative to the dollar, the euro, the yen etc. and thus attract ‘disciples’ to the BTC community. Unwittingly, however, Nakamoto was reinventing a deflationary currency by simulating a Gold Standard through the BTC algorithm. So, if the Security Problem does not shoot down BTC first, and BTC or something similar ‘takes over the world of money’, we are on our way to re-engineering the crashes of 1884,1890,1896,1901,1907 and 1929…
[http://yanisvaroufakis.eu/2014/03/13/on-bitcoins-potential-qa-on-what-bitcoin-can-and-cannot-offer-a-troubled-world/]
btcnet'performance
Description::
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [1] however they never actually use more than about a third of this even during peak shopping periods. [2]
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [3]
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.
[https://en.bitcoin.it/wiki/Scalability], 2015-09-04,
btcnet'Relation-to-gold
Description::
BITCOIN IS BETTER THAN GOLDFor thousands of years, gold has been one of the safest stores of value. Many people hold gold to reduce their fiat risk. Bitcoin has many advantages over gold:
Gold is not divisible
You can not easily cut up gold to give people small amounts. Bitcoin is easily divisible to 8 decimal places.
Gold is not instantly assayable
You can’t instantly tell if gold is pure. You can instantly prove you have real bitcoins.
Gold is not instantly weighable
You need a scale to weigh gold. You can instantly prove how many bitcoins you have.
Gold is not transmittable over the Internet
Sending gold notes has counterparty risk. Bitcoins are easily sent on the Internet.
Gold can be outlawed and confiscated
The US government can and has in the past made it illegal to own gold. You can memorize your Bitcoin private key.
[https://www.bitstamp.net/help/what-is-bitcoin/]
btcnet'Law (btclaw)
Description::
The legal status of bitcoin varies substantially from country to country and is still undefined or changing in many of them.
While some countries have explicitly allowed its use and trade, others have banned or severely restricted it.
Likewise, various government agencies, departments, and courts have classified bitcoins differently.
While this article provides the legal status of bitcoin, regulations and bans that apply to this cryptocurrency likely extend to similar systems as well.
Steven Strauss, a Harvard public policy professor, suggested that governments could outlaw bitcoin in April 2013,[1] and this possibility was mentioned again in a July 2013 regulatory filing made by a bitcoin investment vehicle.[2]
However, the vast majority of nations have not done so as of 2014.
Bitcoin is illegal in Bangladesh,[3] Bolivia,[4] Ecuador,[5] Kyrgyzstan,[6] Russia,[7] and Vietnam.[8]
It has also been reported illegal in Indonesia.[9]
[https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country]
Name::
* cpt.btclaw,
* cpt.bitcoin-law,
* cpt.bitcoin-legal-status,
AddressWpg::
* https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country,
Description::
Bitcoins are illegal because they're not legal tender
In March 2013, the U.S. Financial Crimes Enforcement Network issues a new set of guidelines on "de-centralized virtual currency", clearly targeting Bitcoin. Under the new guidelines, "a user of virtual currency is not a Money Services Businesses (MSB) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and record keeping regulations." [2] Miners, when mining bitcoins for their own personal use, aren't required to register as a MSB or Money Transmitter. [3]
In general, there are a number of currencies in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital currency like Bitcoin, BerkShares, game currencies like WoW gold, or Linden dollars, is not illegal.
[https://en.bitcoin.it/wiki/Myths]
Description::
Bitcoins will be shut down by the government just like Liberty Dollars were
Liberty Dollars started as a commercial venture to establish an alternative US currency, including physical banknotes and coins, backed by precious metals. This, in and of itself, is not illegal. They were prosecuted under counterfeiting laws because the silver coins allegedly resembled US currency.
Bitcoins do not resemble the currency of the US or of any other nation in any way, shape, or form. The word "dollar" is not attached to them in any way. The "$" symbol is not used in any way.
Bitcoins have no representational similarity whatsoever to US dollars.
Of course, actually 'shutting down' Liberty Dollars was as easy as arresting the head of the company and seizing the offices and the precious metals used as backing. The decentralized Bitcoin, with no leader, no servers, no office, and no tangible asset backing, does not have the same vulnerability.
[https://en.bitcoin.it/wiki/Myths]
btclaw'LEGAL
Specific::
* Australia Yes[10]
* Belgium Yes[12]
* Brazil Yes[14] Bitcoin is regulated under a 2013 law that discusses both mobile payment systems and electronic currencies.[14]
* Canada Yes[15] Bitcoin is regulated under anti-money laundering and counter-terrorist financing laws in Canada.[16]
* Colombia Yes[18]
* Croatia Yes[19]
* Czech Republic Yes[20]
* Cyprus Yes[21]
* Denmark Yes[22]
* France Yes[23]
* Germany Yes[24]
* Hong Kong Yes[25]
* Israel Yes[31]
* Italy Yes[32]
* Japan Yes[33]
* Jordan Yes The government of Jordan has issued a warning discouraging the use of bitcoin and other similar systems.[34]
* Lebanon Yes The government of Lebanon has issued a warning discouraging the use of bitcoin and other similar systems.[34]
* New Zealand Yes[35]
* Norway Yes[36]
* Poland Yes[37]
* Singapore Yes[41]
* Slovenia Yes[42]
* South Korea Yes[43] While not illegal in the country, Korean authorities will prosecute illegal activity involving bitcoin[44] and have indicted at least one individual for purchasing drugs with bitcoin.[45]
* Spain Yes[46]
* Switzerland Yes[47] Bitcoin businesses in Switzerland are subject to anti-money laundering regulations and in some instances may need to obtain a banking license.[47]
Sweden Yes[48]
* Turkey Yes[52]
* United Kingdom Yes[53]
* United States Yes
btclaw'RESTRICTED
Specific::
* China (PRC) Restricted[17] Financial institutions cannot use or involve themselves with bitcoins.[17]
* Iceland Restricted[26] According to a 2014 opinion from the Central Bank of Iceland "there is no authorization to purchase foreign currency from financial institutions in Iceland or to transfer foreign currency across borders on the basis of transactions with virtual currency. For this reason alone, transactions with virtual currency are subject to restrictions in Iceland."[26] This does not stop[27] businesses in Iceland from mining bitcoins.[28]
* Taiwan Restricted[7] Bitcoin ATMs are banned here[7] although through a convoluted process, bitcoins can be purchased at some convenience stores kiosks that also sell train tickets and allow paying bills.[49]
btclaw'ILLEGAL
Specific::
* Argentina,
* Bangladesh,
* Bolivia,
* Ecuador,
* Indonesia,
* Kyrgyzstan,
* Russia,
* Thailand,
* Vietnam,
Description::
Bitcoin is illegal in
* Bangladesh,[3]
* Bolivia,[4]
* Ecuador,[5]
* Indonesia
* Kyrgyzstan,[6]
* Russia,[7] and
* Vietnam.[8] It has also been reported illegal in Indonesia.[9]
[https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country]
btcnet'Relation-to-PayPal
Difference between PayPal and Bitcoin international money transfer. (self.Bitcoin)
2016-02-23 19 hours ago ap? mouwe
I sent 100 euro via PayPal to a friend in Mexico today, and he received 1827.09 pesos (91.98 euro, 8% costs). It will take him 3-4 days to withdraw from PayPal to his Mexican bank account.
I also sent him 100 euro worth of bitcoin. I bought the bitcoin at www.bitonic.nl (Dutch exchange), sent it to him, and he withdrew with www.bitso.com (Mexican exchange). He received 1957.87 pesos (98.56 euro, 1.4% costs) and it took 45 minutes (waiting for 4 confirmations).
Adios PayPal !
[https://www.reddit.com/r/Bitcoin/comments/472ppl/difference_between_paypal_and_bitcoin/]
btcnet'Resource (btcrsc)
Name::
* cpt.bitcoin-resource,
* cpt.btcresource,
* cpt.btcrsc,
AddressWpg::
* http://bitcoin.org/
* https://en.bitcoin.it/wiki/Main_Page,
* http://sourceforge.net/projects/bitcoin/
* https://github.com/bitcoin-dot-org/bitcoin.org,
* https://github.com/minium/Bitcoin-Spec/blob/master/Bitcoin.pdf,
===
* http://davidederosa.com/basic-blockchain-programming/
===
* {2017-05-11} https://cointelegraph.com/news/australia-will-recognize-bitcoin-as-money-and-protect-bitcoin-businesses-no-taxes,
* Top 10 Moments in Bitcoin History - Bitcoin.com https://www.youtube.com/watch?v=KplwstaZ_4M,
* https://www.weusecoins.com/
* Bitcoin Is Officially a Commodity, According to U.S. Regulator
The Commodity Futures Trading Commission makes its mark.
http://www.bloomberg.com/news/articles/2015-09-17/bitcoin-is-officially-a-commodity-according-to-u-s-regulator,
* http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/
* Nik Custodio Dec 12, 2013, Explain Bitcoin Like I’m Five:
https://medium.com/@nik5ter/explain-bitcoin-like-im-five-73b4257ac833,
* https://twitter.com/topnewsbitcoin,
* http://www.techiechan.com/?p=1954,
* http://www.spiegel.de/international/business/germany-declares-bitcoins-to-be-a-unit-of-account- a-917525.html,
* http://bitcoinmagazine.com/
* http://lovebitcoins.org/
* http://bitcoin.stackexchange.com/
* https://www.weusecoins.com/en/
* http://bitcoincharts.com/
* https://localbitcoins.com/
* https://bitcointalk.org/
* http://dailyjs.com/2013/08/23/bitcoins/
* https://npmjs.org/package/bitcoin,
* http://www.coindesk.com/information/bitcoin-glossary/
* http://greece.greekreporter.com/2015/04/01/ yanis-varoufakis-greece-will-adopt-the-bitcoin-if-eurogroup-doesnt-give-us-a-deal/
===
* china: http://money.cnn.com/2013/11/18/investing/bitcoin-china/index.html,
Book::
* Adonopoulos: mastering bitcoin https://github.com/aantonop/bitcoinbook,
- https://github.com/bitcoinbook/bitcoinbook/tree/develop,
- In Greek: http://synagonism.net/dirMiwMcs/dirTchInf/book-Mastering-Bitcoin.html,
Tutorial::
* https://bitcoin.org/en/developer-guide,
* https://bitcoin.org/en/developer-reference,
* https://bitcoin.org/en/developer-glossary,
* http://www.givebtc.org/GiveBTC_-_Handbook_for_Non_Profits.pdf,
btcnet'DOING
btcsvc.NOTARIZATION
Description::
Blockchain notarization is an effective way to record marriage contracts, wills, birth certificates, child care contracts, land titles and business deals, among many other records. The security of the blockchain protects the document permanently, ensures its easy access, and proves its authenticity and ownership anytime you need it.
[https://bitnation.co/notary/]
Name::
* cpt.bitcoin-notarization,
* cpt.btcnotarization,
btcsvc.PAYMENT
btcsvc.payment.city
Αυτή είναι η ελβετική πόλη που πληρώνεις με bitcoin
Δημοσιεύθηκε: 14 Μαϊου 2016, 18:15 , Τελευταία Ενημέρωση: 14/05/2016, 16:18
Με το ψηφιακό νόμισμα, bitcoin, θα μπορούν να πληρώνουν τους λογαριασμούς του κάτοικοι στην πόλη Zug της Ελβετίας καθώς ξεκινά η εφαρμογή του εν λόγω πιλτικού προγράμματος από την 1η Ιουλίου. ο δήμαρχος της πόλης Dolfi M?ller ελπίζει πως με αυτό τον τρόπο θα προσελκύσει περισσότερες οικονομικές επιχειρήσεις και τεχνολογικές εταιρείες ώστε να εγκατασταθούν στην περιοχή. Για την ιστορία, έχουν γίνει και παρόμοιες προσπάθειες και σε άλλες χώρες χωρίς όμως άκρως ικανοποιητικά αποτελέσματα.
«Το πιλοτικό πρόγραμμα της κυβέρνησης της πόλης αρχικά βάζει 200 φράγκα όριο για τις δημόσιες συναλλαγές. Στα τέλη του 2016 θα γίνει και η αξιολόγηση του προγράμματος. Τότε ... το δημοτικό συμβούλιο θα αποφασίσει εάν το bitcoin και τα περισσότερα άλλα ψηφιακά νομίσματα μπορούν να γίνουν αποδεκτά ως τρόπος πληρωμής και σε άλλες υπηρεσίες στο μέλλον» αναφέρει χαρακτηριστικά η ανακοίνωση.
[http://www.sofokleousin.gr/archives/297034.html?utm_source=dlvr.it&utm_medium=twitter]
btcsvc.payment.tuition
Description::
Πληρωμές διδάκτρων με Bitcoins στο Πανεπιστήμιο της Λευκωσίας
Παρασκευή, 22 Νοεμβρίου 2013 14:41 UPD:14:45
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το πρώτο πανεπιστήμιο στον κόσμο το οποίο θα δέχεται πληρωμές διδάκτρων και άλλων τελών με bitcoins θα αποτελέσει το Πανεπιστήμιο της Λευκωσίας, όπως ανακοινώθηκε.
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το Πανεπιστήμιο της Λευκωσίας (UNic) αποτελεί το μεγαλύτερο ιδιωτικό πανεπιστήμιο στην Κύπρο και ένα από τα μεγαλύτερα αγγλόφωνα πανεπιστήμια στη Μεσόγειο. Πέρα από τις πληρωμές, οι φοιτητές του θα έχουν τη δυνατότητα σπουδών και πάνω στο ίδιο το αντικείμενο, στο πλαίσιο του MSc Degree in Digital Currency, το οποίο είναι σχεδιασμένο για να βοηθήσει τον κάθε ενδιαφερόμενο, από τον χώρο των επιχειρήσεων ή της δημόσιας διοίκησης να καταλάβει καλύτερα τα τεχνικά χαρακτηριστικά του διαδικτυακού νομίσματος, το οποίο «πιθανότατα θα αλληλεπιδράσει με τα υπάρχοντα χρηματοοικονομικά συστήματα», καθώς και θα εξετάζει τις ευκαιρίες για καινοτομία που συνεπάγονται τα συστήματα ψηφιακών συναλλαγμάτων.
«Γνωρίζουμε ότι το ψηφιακό συνάλλαγμα αποτελεί μία αναπόφευκτη τεχνική εξέλιξη η οποία θα οδηγήσει σε σημαντικές καινοτομίες στο online εμπόριο, τα οικονομικά συστήματα, τις διεθνείς πληρωμές και εμβάσματα και την παγκόσμια οικονομική ανάπτυξη. Το ψηφιακό συνάλλαγμα θα δημιουργήσει πιο αποτελεσματικές υπηρεσίες και θα λειτουργήσει ως μηχανισμός για την εξάπλωση των οικονομικών υπηρεσιών σε τομείς του κόσμου που δεν έχουν μεγάλη τραπεζική υποστήριξη» δήλωσε ο Δρ. Χρήστος Βλάχος, μέλος του συμβουλίου του Πανεπιστημίου.
«Θεωρούμε πρέπον να υιοθετήσουμε ψηφιακό συνάλλαγμα ως μία μέθοδο πληρωμών σε όλα τα ιδρύματά μας, σε όλες τις πόλεις και χώρες όπου λειτουργούμε» πρόσθεσε.
Το εν λόγω Master θα διδάσκεται στην αγγλική γλώσσα, τόσο στο campus όσο και online, με τα μαθήματα να ξεκινούν την άνοιξη του 2014. Επίσης, αξίζει να σημειωθεί ότι το UNic προτείνει στην κυπριακή κυβέρνηση την δημιουργία ενός εκτενούς πλαισίου λειτουργίας με σκοπό την εξέλιξη της Κύπρου σε ένα «κέντρο» για εμπόριο, διαχείριση και τραπεζικές συναλλαγές που αφορούν σε Bitcoins.
[http://www.naftemporiki.gr/story/733285]
Name::
* cpt.tuition-payment-with-bitcoin,
btcsvc.VOTING
Name::
* cpt.btcsvc.voting,
btcsvc.SecureVote
AddressWpg::
* http://demo.xo1.io/index.html,
XO.1
Aussie start-up to delay bitcoin transactions through anchoring 1.5bn votes to the Bitcoin blockchain over 24 hours starting 16:00, March 6 (GMT)
Stress-test of SecureVote will use 4% of bitcoin network capacity over 24 hours and delay some transactions by over 30 minutes – transaction backlog will take a maximum of 24 hours to clear
Sydney (March 5, 2017):
Australian secure voting start-up XO.1 announced a planned stress-test of their SecureVote application on March 6 GMT, which is planned to use more than 4% of the Bitcoin transaction network verification capacity.
This stress-test will process the equivalent of 1.5 billion electronic votes, verified on the Bitcoin blockchain network, over 24 hours, and during peak periods will delay some transactions by up to 30 minutes.
Co-founder and Chief Technology Officer of XO.1, Max Kaye, explained that the intent of the stresstest was to ensure the scalability and reliability of XO.1’s proprietary verification layer, and apologised for any inconvenience caused to bitcoin users.
“We’re building the world’s most secure voting technology, and while there aren’t currently any elections which would require 1.5bn votes, to prove the reliability and scalability of this technology we made the decision to conduct a stress-test a multitude of times larger than our expected first use cases,” said Mr Kaye.
“Unfortunately, this will cause disruption to some bitcoin users as we will be paying a fee to prioritise
the processing of our transactions. At the network’s anticipated peak processing times, we’ll delay
some transactions by up to 30 minutes, and create a backlog of transactions that will take a maximum of 24 hours to clear.”
SecureVote is the world’s first high-throughput commercially viable secure, verifiable, auditable, and scalable internet voting system, with voting delivered via smart-phone app and local electronic voting machines.
XO.1’s proprietary Copperfield algorithm enables verification of the vote and the vote count without compromising the privacy of the vote itself.
The start-up, which has received $500,000 of early-stage funding to date, is expecting to reach market with a product by the end of 2017.
“A number of technological advances in the past ten years have made this product possible – primarily the development of the blockchain, which ensures we have an immutable record of votes cast, once they’ve been verified,” said Mr Kaye.
“We’ll shortly be commencing another funding round which will allow us to quickly scale and capitalise on our early lead in the space,” concluded Mr Kaye.
Track the progress of the XO.1 SecureVote stress test on the demo at http://demo.xo1.io/index.html
- - Ends - -
Media contact:
Shane Allison | shane@xo1.io |+61 402 219 963
[https://xo1.io/stress-test-pr.pdf]
btcnet.MAINET
Description::
The original and main network for Bitcoin transactions, where satoshis have real economic value.
[https://bitcoin.org/en/glossary/mainnet]
===
Main Bitcoin network and its blockchain.
The term is mostly used in comparison to testnet.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-mainnet,
* cpt.btcMainnet,
* cpt.btcBitcoin-Main-Network,
btcnet.REGTEST
Description::
A local testing environment in which developers can almost instantly generate blocks on demand for testing events, and can create private satoshis with no real-world value.
[https://bitcoin.org/en/glossary/regression-test-mode]
Name::
* cpt.btcRegtest,
* cpt.btcRegression-Test-Mode,
btcnet.TESTNET
Description::
A global testing environment in which developers can obtain and spend satoshis that have no real-world value on a network that is very similar to the Bitcoin mainnet.
[https://bitcoin.org/en/glossary/testnet]
===
Testnet:
A set of parameters used for testing a Bitcoin network.
Testnet is like *mainnet*, but has a different genesis block (it was reset several times, the latest testnet is *testnet3*).
Testnet uses slightly different *address* format to avoid confusion with main Bitcoin addresses and all nodes are relaying and mining non-standard transactions.
[https://github.com/oleganza/bitcoin-papers/blob/master/BitcoinGlossary.md]
Name::
* cpt.bitcoin-testnet,
* cpt.btcTestnet,
* cpt.btcTesting-Network,
btctestnet'use
Description::
To use testnet, use the argument -testnet with bitcoin-cli, bitcoind or bitcoin-qt or add testnet=1 to your bitcoin.conf file as described earlier. To get free satoshis for testing, use Piotr Piasecki’s testnet faucet. Testnet is a public resource provided for free by members of the community, so please don’t abuse it.
[https://bitcoin.org/en/developer-examples#testnet]
btcnet.TESTNET3
Description::
Testnet3:
The latest version of *testnet* with another genesis block.
Name::
* cpt.bitcoin-testnet3,
* cpt.btcTestnet3,
btcnet.EVOLUTING
Name::
* cpt.bitcoin.evolution,
* cpt.btcevolution,
{time.2016.bitcoin, bitcoin2016}:
=== halfing: 11 Jul 2016 22:03:04
The Bitcoin block mining reward halves every 210,000 blocks, the coin reward will decrease from 25 to 12.5 coins.
[http://www.bitcoinblockhalf.com/]
{time.2015, bitcoin2015}:
=== {2015}
The major story from 2015 is undoubtedly the increasing focus on bitcoin's underlying technology, commonly referred to as blockchain or distributed ledger technology (DLT). Many parties, from government authorities to financial institutions, began to examine potential applications of DLT for securities transaction settlement and other use cases.
[http://www.coindesk.com/state-of-bitcoin-blockchain-2016/]
=== {2015-03-31} fraud:
On March 31, 2015, two now-former agents from the Drug Enforcement Administration and the U.S. Secret Service were charged with wire fraud, money laundering and other offenses for allegedly stealing bitcoin during the federal investigation of Silk Road, an underground illicit black market federal prosecutors shut down in 2013.[41]
[https://en.wikipedia.org/wiki/Cryptocurrency]
{time.2014, bitcoin2014}:
=== {2014.02}: Mt.Gox:
In February 2014, cryptocurrency made national headlines due to the world's largest bitcoin exchange, Mt. Gox, declaring bankruptcy. The company stated that it had lost nearly $473 million of their customer's bitcoins likely due to theft. This was equivalent to approximately 750,000 bitcoins, or about 7% of all the bitcoins in existence. Due to this crisis, among other news, the price of a bitcoin fell from a high of about $1,160 in December to under $400 in February.[40]
[https://en.wikipedia.org/wiki/Cryptocurrency]
{time.2013, bitcoin2013}:
=== VALUE:
At the end of August 2013, the value of all bitcoins in circulation exceeded US$ 1.5 billion with millions of dollars worth of bitcoins exchanged daily.
[https://bitcoin.org/en/faq#is-bitcoin-really-used-by-people]
=== {2013-12-05} CHINA
FINANCIAL TIMES
Thursday December 05 2013
BREAKING NEWS
Beijing bans banks from Bitcoin deals
China has taken a tough line against Bitcoin, ruling that it is a virtual product, not a currency, and barring the country’s financial institutions from doing any kind of business in it.
Surging Chinese demand has been one of the main drivers of Bitcoin’s 5000 per cent appreciation this year. The notice from Chinese financial regulators, published on Thursday, is the first official policy ruling from Beijing about the virtual currency.
=== {2013-11-22} University-of-Nicosia
Πληρωμές διδάκτρων με Bitcoins στο Πανεπιστήμιο της Λευκωσίας
Παρασκευή, 22 Νοεμβρίου 2013 14:41 UPD:14:45
Η είδηση κάνει το γύρο του κόσμου, καθώς το κυπριακό πανεπιστήμιο παράλληλα παρέχει και τη δυνατότητα για σπουδές διαδικτυακού συναλλάγματος, με σκοπό την καλύτερη κατανόηση του νέου φαινομένου.
Το πρώτο πανεπιστήμιο στον κόσμο το οποίο θα δέχεται πληρωμές διδάκτρων και άλλων τελών με bitcoins θα αποτελέσει το Πανεπιστήμιο της Λευκωσίας, όπως ανακοινώθηκε.
[http://www.naftemporiki.gr/story/733285]
=== {2013-10-26}: CHINA GBL:
GBL, a Chinese bitcoin trading platform, suddenly shut down on October 26, 2013. Subscribers, unable to login, lost up to $5 million worth of bitcoin.[37][38][39]
{time.2011}:
Satoshi Nakamoto withdrew from the public in April of 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind bitcoin is still unknown. However, neither Satoshi Nakamoto nor anyone else exerts control over the bitcoin system, which operates based on fully transparent mathematical principles. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
{time.2009}:
=== Started on Januar 3, 2009, the Bitcoin peer-to-peer network has grown very quickly.
[http://subs.emis.de/LNI/Proceedings/Proceedings208/51.pdf]
{time.2008}:
Bitcoin was invented in 2008 with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System," written under the alias of Satoshi Nakamoto. Nakamoto combined several prior inventions such as b-money and HashCash to create a completely decentralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. The key innovation was to use a distributed computation system (called a "proof-of-work" algorithm) to conduct a global "election" every 10 minutes, allowing the decentralized network to arrive at consensus about the state of transactions. This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse.
[https://github.com/aantonop/bitcoinbook/blob/develop/ch01.asciidoc]
===
εμφάνισή του το 2008 (δημιουργός του είναι ένας ανώνυμος προγραμματιστής, συλλογικά γνωστός πλέον με το ψευδώνυμο Σατόσι Νακαμότο)
[http://www.naftemporiki.gr/story/731436]
btcnet.HARDFORK
Description::
A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.
Any alteration to bitcoin which changes the block structure (including block hash), difficulty rules, or increases the set of valid transactions is a hardfork. However, some of these changes can be implemented by having the new transaction appear to older clients as a pay-to-anybody transaction (of a special form), and getting the miners to agree to reject blocks including the pay-to-anybody transaction unless the transaction validates under the new rules. This is known as a softfork, and how P2SH was added to Bitcoin.
[https://en.bitcoin.it/wiki/Hardfork]
Name::
* cpt.btcnet.hardfork,
btcnet.SOFTFORK
Description::
A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible. This kind of fork requires only a majority of the miners upgrading to enforce the new rules.
New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules. This is how P2SH was added to Bitcoin.
[https://en.bitcoin.it/wiki/Softfork]
Name::
* cpt.btcnet.softfork,
bcnnet.Aeternity (AEnet)
Description::
æternity is a new type of open-source, public, Blockchain-based distributed computing platform that innovates and expands upon existing platforms such as Bitcoin, Ethereum, and Augur. Real-world data can interface with smart contracts through decentralized oracles[1].True scalability and trust-less Turing-complete state channels sets æternity apart from all other Blockchain 2.0 projects.
It provides a decentralised virtual machine which can execute scripts using an international network of public nodes all connected to the Blockchain and through state channels. æternity also provides a value token called "aeon", which can be transferred between participants and is used to compensate participant nodes for computations performed. aeon, is used to pay for space and computation time on the Virtual-Machine and prevents spam on the network while allocating resources (Storage & Computaion time) proportionally to the incentive offered by the request.
[https://en.wikipedia.org/wiki/AEternity] {2017-05-19}
Name::
* cpt.aenet,
* cpt.aeternity-network,
aenet'Program
aenet'Smart-contract
Description::
Despite how on-chain state settlement is limited to the transfer of Aeon, æternity still features a Turing-complete virtual machine that can run “smart contracts”. Contracts on æternity are strictly agreements that distribute funds according to some rules. This stands in stark contrast to the entity-like contracts of e.g. Ethereum. Two of the more notable practical differences are that, by default, only the involved parties know about a given contract and only parties that have an open state channel can create a valid contract. If the parties agree to a contract, they sign it and keep copies for future reference. It is only submitted to the blockchain if its outcome is disputed, in which case the code is only ever stored as part of the submitted transaction, never in any other state. If this happens, the blockchain distributes the tokens according to the contract and closes the channel.
[https://github.com/aeternity/wiki/wiki/Aeternity-Contracts#smart-contracts]
Name::
* cpt.aenet'smart-contract,
* cpt.smart-contract-of-aenet,
bcnnet.Akasha
Description::
A Next-Generation Social Media Network
Powered by the Ethereum world computer
Embedded into the Inter-Planetary File System
[http://akasha.world/]
===
What can I do with AKASHA?
You can publish, share and vote for entries, similar to Medium and other modern publishing platforms, with the difference that your content is actually published over a decentralized network rather than on our servers.
Moreover, the votes are bundled with ETH micro transactions so if your content is good you’ll make ETH from it – in a way, mining with your mind.
[http://akasha.world/]
Name::
* cpt.akasha-network,
bcnnet.BOScoin (BOSnet)
Cpt-created: {2017-03-22}
Description::
BOScoin is a congressional decentralized cryptocurrency platform for “Trust Contracts”.
BOScoin is a cryptocurrency that utilizes the blockchain and numerous new technologies to solve persistent issues in decentralized systems.
1. Trust Contracts are securely executable contracts based on a decidable programming framework called Owlchain, which consists of the Web Ontology Language and the Timed Automata Language. Trust Contracts aim to overcome the issues regarding non-decidable smart contracts by using a more contained and comprehensible programming framework which provides secure and decidable transactions of contracts.
2. The Congress Network is the decision making body in the BOScoin network which improves governance issues arising in decentralized organizations and helps the system continuously evolve into a more robust ecosystem.
[https://www.boscoin.io/]
Name::
* cpt.BOScoin-network,
* cpt.bosnet,
Generic::
* Blockchain-network-with-builtin-decentralized-governance,
* program-blockchain-network,
bosnet'Protocol (bosprl)
bosprl'White-paper.2017-02-02
Name::
* bosnet'white_paper,
* bosprl'white_paper,
* cpt.boswpr,
AddressWpg::
* https://boscoin.io/wp-content/themes/boscoin/src/pdf/BOScoin.pdf,
* https://www.boscoin.io/wordpress/wp-content/themes/boscoin/src/pdf/boscoinwhitepaperv20170202.pdf,
The BOScoin White Paper
Initial Version: 20161101 / Current Version: 20170202
Han-Kyul Park, Changki Park, Yezune Choi, Jake Hyunduk Choi
BOScoin is a congressional decentralized cryptocurrency platform for Trust Contracts
Abstract
BOScoin is a cryptocurrency that utilizes the blockchain and numerous new technologies to solve persistent issues in decentralized systems.
(1) Trust Contracts are securely executable contracts based on a decidable programming framework called Owlchain, which consists of the Web Ontology Language and the Timed Automata Language.
Trust Contracts aim to overcome the issues regarding non-decidable smart contracts by using a more contained and comprehensible programming framework which provides secure and decidable transactions of contracts.
(2) The Congress Network is the decision making body in the BOScoin network which improves governance issues arising in decentralized organizations and helps the system continuously evolve into a more robust ecosystem.
1. Introduction
a. Background
The blockchain was first conceptualized in Satoshi Nakamoto’s white paper “Bitcoin: A Peer-to-Peer Electronic Cash System” in 2008( 1 ).
The technology was implemented the following year as the central technology behind Bitcoin.
Bitcoin uses blockchain technology as a financial transaction ledger where individuals publicly record transfers of currency.
Bitcoin was the first of its kind to use the blockchain to successfully solve the double spending problem.
Despite the absence of a centralized administrator, Bitcoin has successfully supported over 180 million peer-to-peer transactions and now has a market capitalization of more than 10 billion dollars.
Following the success of Bitcoin, there have been numerous systems leveraging blockchain technology.
There are hundreds of competing cryptocurrencies and according to a recent IBM report, more than 90% of banks are investing in blockchain technology( 2 ).
Although currency transactions are the most common applications of the blockchain technology, some groups are also attempting to transfer other digital assets, such as financial products and services, logistics information, property ownership, identity etc.
The cryptocurrency Ethereum gained a lot of traction in 2016 and aims to provide smart contracts on the blockchain: “a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create ‘contracts’ that can be used to encode arbitrary state transition functions." ( 3 )
The goal is to allow users to write any kind of program (or contract) onto the blockchain.
Similar to Bitcoin, Ethereum uses the blockchain and a consensus mechanism to ensure that if a malicious node attempts to forge the content of the contract, the forged contract will eventually be removed from the blockchain.
Bitcoin ensures the integrity of the amount of Bitcoin being transferred between accounts, Ethereum must similarly ensure the integrity of the contract being executed.
Smart contracts have the potential to be a paradigm shift in the development of decentralized applications.
Programs that are not held on a centralized server, yet can run the same logic anywhere.
Smart contracts can be used to develop: decentralized marketplaces, currency exchange platforms, and projects like Golem( 4 ) which aim to create a decentralized worldwide super-computer.
However the freedom and flexibility provided by the turing-complete language which Ethereum is based on is the cause for several serious problems.
We believe that using a turing-complete language may be inappropriate for writing smart contracts as they are inherently undecidable( 5 ).
Due to this undecidability issue, a smart contract based on a Turing-complete language will make it difficult to know what a smart contract will do before running it.
Ethereum attempts to overcome this issue by applying a price for computational work (gas), however the inherent issue of the language used to program and execute smart contracts has inevitably led to a series of security vulnerabilities( 6 ) and outright failed projects such as The DAO( 7 ).
b. Proposal
Trust Contracts.
BOScoin’s approach to the problem is to apply a domain-specific language which can be read easily by the average user and can demonstrate mathematically that the smart contract’s implementation is computationally decidable.
Thus, with BOScoin we aim to develop a platform for Trust Contracts: securely executable contracts based on Owlchain technology.
Additionally, through BOScoin we attempt to solve a number of commonly recurring issues related to cryptocurrencies.
Governance Issues.
Decentralized systems lack a systematic decision making process.
There have been several cases in the cryptocurrency space, where the decision making process has been persistently inefficient.
BOScoin constitutes a governance system whereby node operators referred to as the Congress Network can participate in creating and voting on proposals in order to continuously improve the software and ecosystem.
BOScoin sets aside a large public budget called the Commons Budget which is distributed to proposals that pass a vote in Congress improving the autonomy as well as fairness of the overall system.
Anti-centralizing Consensus Algorithm.
Cryptocurrencies like Bitcoin, that only use a proof-of-work(PoW) type consensus protocol, are affected by issues arising from the non-separation of economic and political incentives.
By buying up more mining hardware, a user can attain more control of the blockchain(political) and also increase their mining income(economic).
BOScoin overcomes this issue by using a consensus
mechanism(explained in more detail below) that separates economic incentives from political ones.
Attaining either political power or economical wealth requires an investment into the system.
A user can either acquire more votes by increasing the number of nodes(one operational node equals one congressional vote) or a user can invest in freezing and confirmation rewards(rewards relative to the amount of coins locked away in a node) to maximize mining income.
Additionally, the consensus protocol used is also more energy efficient and faster.
Application Ecosystem.
Decentralized currencies in many cases tend to become speculative islands with limited real applications.
As we believe the value of a currency is intrinsically tied to how useful it is, the BOScoin team will release the coin with two ready-made apps that use BOScoin.
The applications Stardaq and Delicracy have already been built and will not only increase the transactional value of the coin, but will also help acquire new users.
imgBoswprFig1.png
Fig 1. Comparison of Cryptocurrencies
2. Trust Contracts
a. Overview
BOScoin aims to use the Owlchain technology which consists of the Web Ontology Language(OWL)( 8 ) and Timed Automata Language(TAL). This architecture is designed to expand expressive power while retaining decidability to support secure and precise execution of contracts. These Owlchain based contracts on the BOScoin blockchain are called Trust Contracts.
imgBoswprFig2.png
Fig 2. Comparison of Blockchain-based Contracts
b. Background
There are two primary approaches to developing contracts on the blockchain.
One is through using a flexible programming language on a virtual machine, the other is to use a slightly less flexible but decidable domain-specific language.
Unlike cryptocurrencies based on virtual machines, as the inference engine is based on the semantic web technology, it is possible to infer information from the code before the contract is run.
The contract is decidable and the outcome of the contract clearly known.
This is a key concept in building a secure and sustainable currency with contract features.
Although Ethereum attempted to solve this issue by using market mechanisms and applying a price to complexity, we believe that the more restrictive OWL and TAL approach will provide a more secure environment for contracts on the blockchain.
c. Development
Building upon standard Web technologies such HTML, HTTP, RDF and OWL which were used to serve web pages, these technologies can be extended to share information in a way that can be predictably read by computers.
Both OWL and RDF can be used to create unambiguous structured data taxonomies.
Using these characteristics Ian Grigg proposed the concept of the Ricardian Contracts; contracts which are linked to every aspect of a payment system.( 9 )
Despite, both OWL and RDF displaying similar characteristics, no RDF standards currently supports P-time completeness.
Using reasoners, tools that infer logical consequences from a set of previously asserted facts or axioms, certain versions of the OWL standard promise P-time complexity.
This means the amount of time it takes to run a contract can be pre-determined.
This feature is a key reason why OWL was selected as the language to build Trust Contracts.
OWL DL(description logic) is a sublanguage of OWL, “designed to provide the maximum expressiveness possible while retaining computational completeness.”( 10 )
OWL DL operates on a large dictionary of predefined vocabularies and taxonomies like the ISO20022 specification.
As transactions take place on the blockchain and other BOScoin specific features will not be provided by the OWL dictionaries.
These vocabularies and taxonomies need to be called from outside the contract.
To solve this technical issue, we propose to create a designated namespace domain on the blockchain which can call non-standard primitive types(taxonomies) from the contract.
Non-standard primitive types will be added conservatively in order to sustain the OWL’s decidability and taxonomic complexity features.
imgBoswprFig3.png
Fig 3. BOScoin Transfer Example
Another issue with regards to Turing-complete contracts on blockchains is that Turing-complete languages are difficult to read by non-technical people.
If ‘code were law’, the code should be comprehensible to all the parties involved.
Currently, currencies using Turing-complete languages for contracts can only be audited by those that can read code.
By using the OWL standard and mapping the syntax to languages like SDLang(11), we aim to allow anyone to read and precisely comprehend what a contract is meant to do.
imgBoswprFig4.png
Fig 4. Trust Contract Example
The Timed Automata Language concept is based on Andrychowicz’s paper, ‘Modeling Bitcoin Contracts by Timed Automata’(12).
TAL will be used to model the programming logic used in a Trust Contract.
The HTML and Javascript pairing is similar to OWL and TAL.
OWL provides the structure of the data and TAL acts as an operator.
Operators in programming languages are constructs that do a certain function, such as adding, subtracting and comparisons.
OWL provides the information, and TAL tells the computer what to do with the data.
TAL is slightly different to other programming languages as there is a global time factor.
This means contracts can be tested for how long they take beforehand.
By running automated tests on all the different possible outcomes beforehand, we can promise a platform with bug-free contracts on the blockchain.
The details of the above concepts are further explored in the technical paper.
3. Consensus Algorithm
a. Overview
The consensus algorithm is core to any blockchain based currency or system.
The algorithm attempts to answer the question, ‘how can we prove with confidence that all distributed databases hold the same set of information?’
In response to this question, BOScoin uses a Modified Federated Byzantine Agreement(mFBA) consensus algorithm based on Stellar’s Consensus Protocol(FBA).( 13 )
imgBoswprFig5.png
Fig 5. Comparison of Consensus Algorithms
Mazieres defines key features of the federated Byzantine Agreement Protocol: (14)
* Decentralized control.
Anyone is able to participate and no central authority dictates whose approval is required for consensus.
* Low latency.
In practice, nodes can reach consensus at timescales humans expect for web or payment transactions—i.e., a few seconds at most.
* Flexible trust.
Users have the freedom to trust any combination of parties they see fit.
For example, a small non-profit may play a key role in keeping much larger institutions honest.
* Asymptotic security.
Safety rests on digital signatures and hash families whose parameters can realistically be tuned to protect against adversaries with unimaginably vast computing power.
* Governance Features.
Voting and features that are related to operating the congress are additional features embedded into the protocol.
b. Federate Byzantine Agreement Consensus Algorithm( 15 )
Bitcoin’s consensus mechanism and the traditional Byzantine agreement based protocols require a unanimous agreement by all participants of the network.
However, the federated Byzantine agreement(FBA) does not require an unanimous agreement by all participants and additionally each node can chooe which nodes to trust.
This results in faster transactions without losing integrity of the financial network and allowing for organic growth of the network.
FBA implemented this type of non-unanimous consensus mechanism by grouping nodes into teams (also known as a Quorums).
When a transaction is made, the information is sent to all those in the group.
Rather than waiting for the whole network to agree on the state of the data, if a node hears the same message from a sufficient number of trusted nodes, the node assumes the information is correct.
The overlapping of nodes, or loose federation of nodes, results in different nodes that have different sets of teams to agree on the same transactions.
This leads to a system-wide consensus, without requiring unanimous agreement for each transaction block.
In situations where nodes are in disagreement over a fraudulent transaction, there is a ballot system embedded into the system to overcome such issues.
Further technical details regarding FBA can be found in Stellar’s consensus protocol paper.
c. How is the modified federated Byzantine agreement(mFBA) algorithm different?
In addition to FBA, the BOScoin consensus protocol also applies a Proof of Stake feature for the maintenance of the governance system.
Users can freeze coins in units of 10,000 BOS within a node and forgo liquidity in return for newly issued BOScoin(similar to interest on savings) based on the total number of frozen coin in the node.
The frozen coins in the node then act as both an economic incentive to operate a node as well as collateral for the security and integrity of the information held in the node’s blockchain.
According to the pre-set rules, if the node is discovered to have forged the blockchain on the node, the frozen coins are forfeited to the Commons Budget.
4. Congress Network
a. Overview
The Congress Network is the decision-making body for BOScoin consisting of individual fully-synchronized node operators.
Although people refer to cryptocurrencies as decentralized and autonomous, in many cases, this is not true.
Both the code and the information on the blockchain are vulnerable to influence.
In order to overcome these issues, BOScoin proposes a decision-making body called the Congress Network to fully decentralize and automate the system.
Development of the source-code, forks, and even marketing resources can be allocated from within the system.
b. Congress Network Roles
i. Congress members
You will be regarded as a Congress member if you meet the following criteria:
* Run a fully-synchronized node at stable network speeds
* Freeze at least one unit (one frozen unit is 10,000 BOS)
* Participate in voting
Anyone can become a Congress member.
A node could be a server or a personal computer that a Congress member runs.
The node can be located at home or a remote location, as long as network speeds are stable.
Congress Members have the choice to either invest in increasing their political influence through running more nodes or increasing their economic return through increasing the BOScoin frozen.
ii. Users
Users are the beneficiaries of the BOScoin system.
They will interact with the BOScoin Network in three ways: by initiating transactions, submitting proposals and earning interest on BOScoins (coin freezing).
These interactions are displayed in the figure below.
imgBoswprFig6.png
Fig 6. Interactions Between the Congress Network and User Network
c. Network Interactions
i. Transactions
When a transaction of digital assets is requested by a user, the request is sent to the Congress Network.
For a simple transfer of BOScoin, when a node confirms the block –roughly every 5 seconds– the user’s transactions will be confirmed, and the BOScoin will be transferred to another wallet.
For more complex Trust Contracts, the pre-defined logic/procedures will also be carried out.
In the initial stage of BOScoin, transaction fees will be fixed at 0.01 BOS.
The fixed transaction rate can later be adjusted by the Congress Network through the voting process.
Transaction fees act as an economic incentive for node operators and also as a defence mechanism against DoS attacks.
ii. Proposals
Proposals are Commons Budget spending plans that are submitted to the Congress Network.
When a proposal is made, the ‘net percentage point difference’ between the positive and negative votes must exceed 10% for the proposal to be passed.
When the proposal is passed, the requested coins will be sent to the proposer.
Under some conditions, such as when the size of the proposal is large, the system can define a contract that requires a report on how the coins were spent.
iii. Coin Freezing
Coin Freezing is a Proof of Stake concept where if a user locks-in their coins and in return they will receive interest based on the number of coins frozen and the length of time the coins are stored.
This interest is called the Freezing Reward.
Users can freeze coins in units, which are sets of 10,000 BOS.
Frozen coins are used as collateral in case of attempted forgery of the blockchain.
If a node attempts to forge the blockchain, a portion of the frozen coins are confiscated and sent to the Commons Budget.
Additionally the system requires two weeks prior notice to unfreeze coins, as a mechanism to promote price stability.
d. Reward System
Within the Congress Network, there is a unique incentive mechanism. Congress members can either choose to maximize financial rewards, by freezing BOScoin in one node or increase their voting power by running multiple nodes (one node equals one vote).
This deliberate division incentivises the separation of economic motives from decision-making motives similar to the separation of economic and political power concept.
Bitcoin suffers from the hash power centralization issue, due to its reliance on a Proof of Work consensus protocol.
A small number of major miners can easily buy up large amounts of mining hardware, which allows them to influence changes in code and even threaten the integrity of the blockchain.
By separating the incentives of those that wish to optimize financial gain, the barriers to entry to participate in the governance process is comparatively lower than a system that equates decision making power with financial rewards.
There are three ways for Congress Members to receive BOScoin rewards: the freezing reward, confirmation rewards, and transaction fees.
* Freezing Reward:
Congress Members receive the same amount of interest as normal wallet users when coins are frozen.
Starting from the first year, a total of 27,400 BOS is distributed equally to each unit of frozen BOScoins.
This freezing reward is issued every 720 blocks(roughly one hour).
The total amount that is distributed decreases by 10% year on year over 69 years.
* Confirmation Reward:
Confirmation rewards are given to a node when a block is confirmed.
This reward is crucial in providing a financial incentive to operate a node and the reward is directly linked to the number of Frozen Units in a node.
Similar to the block reward in Bitcoin, as the number of participating nodes increases, the probability of winning the confirmation reward decreases.
The reward is issued relative to the proportion of frozen units held while initially sustaining a system average of 24.5 BOScoins.
confirmation reward = 24.5 x (Number of Frozen Units / Average of Total System Frozen Units)
Initially the block confirmation reward starts at 24.5 BOScoins per block, and it will decreased by 5% year on year over roughly 141 years.
* Transaction Fee:
The transaction fee is a fixed 0.01 BOScoins.
Congress Nodes receive 70% of the collected transactions fee in a block, and 30% is sent to the Commons Budget.
Transaction fees can be adjusted through the Congress.
e. Decision Making Process
The idea of an integrated decision-making process within the currency was inspired by Dash( 16 ) coin where the masternodes( 17 ) vote to make decisions.
In BOScoin decisions are made by submitting proposals and voting on proposals, and then financing the proposals through the transfer of funds from the Commons Budget.
Anyone can make a proposal, which is then reviewed every third Monday of the month by 24:00 GMT.
These proposals are then voted on by the Congress members by the fourth Monday of the month by 24:00 GMT.
If the ‘net percentage point difference’ between the positive and negative votes exceed 10%, the proposal is passed.
There is the option for a neutral vote to signal that the Congress member participated in the decision-making process and votes can also be changed any time before the final due date.
In order to increase the chances of a proposal being passed, it is possible to provide collateral with the proposal.
Proposals that provide more than 1,000,000 BOS become Elevated Proposals.
If a Congress member does not vote on an Elevated Proposal, they are penalized by having the freezing feature disabled for their node for two weeks.
Disabling the coin freezing feature means the node will forgo all the benefits from freezing coins and will not be able to freeze any coins for two weeks.
f. Commons Budget
The Commons Budget is an account where BOScoins are held and can only be transferred by proposals that are passed through the Congress.
The main role of Commons Budget is to expedite the growth of the coin users during the early stages.
Coins in the Commons Budget are mainly accumulated through two channels; the first is the direct issuance of 100 BOS coins per block for 35 million(roughly 5.5 years) blocks and secondly from 30% of the transaction fee.
Out of all issued coins, Commons Budget make up the largest proportion of coins.
This will ensure funds are available to growth hack the adoption of BOScoin.
Any proposal which passes through the congress can access coins from the Commons Budget.
An example of a proposal is an Airdrop proposal; geo-socially distribute free coins to users in order to increase the number of BOScoin users.
Other examples can include funding the development of the BOScoin eco-system, marketing campaigns and organizing BOScoin related meetings.
5. Ready-made Application Ecosystem
Many cryptocurrencies offer examples of how to use and build applications on their platform.
However, few have delivered working applications utilizing currency.
Although it is difficult to fully understand how much of a cryptocurrency’s value is made up of transactional value and how much is made up by speculative value, BOScoin’s goal is to increase the transactional value of the currency relative to its competitors.
In the long-run the core-value of a currency is it’s usefulness.
Through ready-built applications such as Stardaq and Delicracy released with the currency, users will have sophisticated services available immediately within the BOScoin ecosystem.
a. Stardaq
Stardaq is an international celebrity popularity prediction market.
A celebrity's popularity is represented as an index and users can place bets on whether the popularity of the celebrity will rise or fall.
The bets can only be placed with BOScoins.
b. Delicracy
Delicracy is a collective decision making tool that can be implemented in any organization.
All users can participate in the decision-making process by placing bets on a set of proposals, similar to the Augur prediction market( 18 ).
The proposal with the most bets is passed.
This type of system can help promote transparency and participation for decision-making processes in organizations large and small.
These applications serve as outlets to spend BOScoins and also serve as channels for Airdropping free coins.
Appropriately using these tools can help grow the ecosystem by introducing new users.
6. Technical Roadmap
The following is a technical roadmap defining the key milestones.
imgBoswprFig7.png
Fig 7. Implementation roadmap
7. Coin Issuance
New coins are issued in four ways; initial development budget (1.0bil, 10%), confirmation rewards(3.0bil, 30%), freezing rewards(2.4bil, 24%) and the Commons Budget(3.5bil, 36%).
We aim to issue a total of 9.99 billion coins over the next 141 years.
These values are subject to change.
imgBoswprFig8.png
Fig 8. Issuance Summary
* Initial Development Budget:
Initial development coins are coins distributed prior to the Genesis block are intended to support the final development of the software.
These coins are made up of ICO sales and bounties.
1.0 billion BOScoins are issued with the Genesis block.
* Confirmation Rewards:
Confirmation rewards are financial rewards issued randomly to a node for every confirmed block(every 5 seconds).
As the reward is distributed randomly, if the number of nodes increase the probability that a node will receive a reward decreases.
This reward is relative to the number of units frozen in a node(refer to section 4d).
3.0 billion BOScoin are issued through Confirmation rewards.
Initially 24.5 BOScoins are issued per block.
The reward decreases every 6.31 million blocks–roughly one year– by 5% over 141 years.
* Freezing Rewards:
Freezing rewards are distributed relative to the number of BOScoin units frozen in a node and are issued every 720 blocks(roughly one hour).
Initially the total amount is 27,400.
The reward decreases by 10% over every 6.31 million blocks–roughly 1 year – over 69 years.
The freezing reward acts as an important incentive for congress members to increase the number of coins frozen in one node and disincentivize the centralization of decision making.
* Commons Budget:
The Commons Budget holds BOScoins that can only be used by proposals that have passed the Congress Network.
In order to create a sufficient budget for proposals, 100 Commons Coins are issued per block for the first 35 million blocks–roughly five and a half years.
After the first five and a half years the Commons Budget is maintained through the 30% commons fee on transactions fees.
imgBoswprFig9.png
Fig 9. Coin Issuance Plan
8. Conclusion
The BOScoin team aims to overcome the technical and operational issues inherent in many cryptocurrencies.
The incentive scheme and issuance plan is aimed towards creating value for the coin while deterring the centralization of power.
The Modified Federated Byzantine Agreement algorithm will allow for low latency transactions while being more energy efficient.
The Congressional System is aimed towards creating a more democratic and productive decision making process.
Trust contracts will provide a decidable and approachable framework for creating and executing contracts on the blockchain.
The BOScoin team will aim to achieve these goals while leveraging the security and integrity that can be gained through blockchain technology.
Works Cited
Andrychowicz, Dziembowski, Malinowski and Mazurek, Modeling Bitcoin Contracts by Timed Automata, Lecture Notes in Computer Science Formal Modeling and Analysis of Timed Systems, 7-22, 2014, https://arxiv.org/pdf/1405.1861v2.pdf
David Mazieres, Stellar Consensus Protocol, https://www.stellar.org/papers/stellar-consensus-protocol.pdf
Decentralized Prediction Market, https://www.augur.net/
Evan Duffield, Daniel Diaz, Dash: A PrivacyCentric CryptoCurrency, https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
Golem, https://golem.network
Hodges, Andrew, Alan Turing: the enigma, London: Burnett Books
Ian Grigg, The Ricardian Contract, First IEEE International Workshop on Electronic Contracting (WEC) 6th July 2004, http://iang.org/papers/ricardian_contract.html
Leading the Pack in Blockchain Banking: Trailblazers Set the Pace, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GBP03467USEN&
N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on Ethereum smart contracts, https://eprint.iacr.org/2016/1007.pdf
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf
Simple Declarative Language, https://sdlang.org/
The DAO, https://slock.it/dao.html
Using Decentralized Governance: Proposals, Voting, and Budgets, https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals% 2C+Voting%2C+and+Budgets
OWL Web Ontology Language, https://www.w3.org/TR/owl-features/
OWL Web Ontology Language Reference, https://www.w3.org/TR/owl-ref
Vitalik Buterin, Ethereum Whitepaper, https://github.com/ethereum/wiki/wiki/White-Paper
Notes
(1) Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf
(2) Leading the Pack in Blockchain Banking: Trailblazers Set the Pace, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GBP03467USEN&
(3) Vitalik Buterin, Ethereum Whitepaper, https://github.com/ethereum/wiki/wiki/White-Paper
(4) Golem, https://golem.network
(5) Hodges, Andrew, Alan Turing: the enigma, London: Burnett Books, p. 111
(6) N. Atzei, M. Bartoletti, T. Cimoli, A survey of attacks on Ethereum smart contracts, https://eprint.iacr.org/2016/1007.pdf
(7) The DAO, https://slock.it/dao.html
(8) Web Ontology Language Reference, https://www.w3.org/TR/owl-ref
(9) Ian Grigg, The Ricardian Contract, First IEEE International Workshop on Electronic Contracting (WEC) 6th July 2004
(10) OWL Web Ontology Language, https://www.w3.org/TR/owl-features/
(11) Simple Declarative Language, https://sdlang.org/
(12) Andrychowicz, Dziembowski, Malinowski and Mazurek, Modeling Bitcoin Contracts by Timed Automata, Lecture Notes in Computer Science Formal Modeling and Analysis of Timed Systems, 7-22, 2014, https://arxiv.org/pdf/1405.1861v2.pdf
(13) David Mazieres, Stellar Consensus Protocol, https://www.stellar.org/papers/stellar-consensus-protocol.pdf
(14) Ibid.
(15) Ibid.
(16) Evan Duffield, Daniel Diaz, Dash: A PrivacyCentric CryptoCurrency, https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf
(17) Using Decentralized Governance: Proposals, Voting, and Budgets, https://dashpay.atlassian.net/wiki/display/DOC/Using+Decentralized+Governance%3A+Proposals%2C+Voting%2C+and+Budgets
(18) Decentralized Prediction Market, https://www.augur.net/
bosprl'Techical-paper.2017-01-31 (bostpr)
AddressWpg::
* https://docs.google.com/document/d/16Wm1...DtaI/edit,
Owlchain(BOScoin) Technical Specification
(This is a draft version. More details to be added)
Draft version: 20170131
Yezune Choi, Jake Hyunduk Choi
0. Adventure of Ideas
Alfred North Whitehead, known as the last metaphysician, asserted that "without adventure civilization is in full decay."
Imaginations and practices of the blockchain is enriching our world.
We put our thoughts into the world to join in this adventure of thought.
Every thought has its roots in thought.
The blockchain is not a random floatage on the Internet, but an outcome that is rooted in existing ideas.
In order for owlchain to have a solid roots in the Internet world, it is necessary to know its roots correctly.
The thoughts on which the Internet and the Web could grow can be summarized by several principles.
0.1 Layered Structure
TCP/IP represents the Internet protocol, but TCP is only one of the typical application protocols of IP. For applications such as games or streaming that do not require a session connection, UDP is being used as an attractive alternative to TCP. In the Internet world, protocols define a clear function(specification) in their domain and perform only that function. The advantage of layer structure is that it does not hinder the emergence of new protocols by maximizing the possibility of substitution. IPv4 can be replaced with IPv6 because of the layer structure. When we consider this idea in the blockchain technology, the current blockchain technology is still in its infancy and is not approaching the layer structure design. In order for the blockchain to obtain the status of the protocol, it is essential to have a layer structure approach in which various technologies can be combined and compete.
0.2 Openness of the protocol
Although TCP/IP has the advantage of speed and performance, the core quality to become a standard for the Internet is the openness of the protocol.
The TCP/IP protocol is open to the public without restrictions on use such as patents, and has served as a soil where many researches and developments can be achieved.
In standardizing protocols, patents are a sensitive issue for companies or individuals seeking to contribute.
But, ownership of ideas(patents) limits the emergence of new ideas.
From the perspective of innovation, ownership of ideas is more damaging than profit in the cyber world where thoughts can be copied without marginal cost.
You can also see how narrow the view is in claiming ownership of ideas in the Internet world, when the programming codes that actually implement the protocol are the most innovative in any licensing policy.
0.3 End-to-end principle
In order for Internet protocol features to be completed, there is a need for end-to-end principles that do not interfere with high-level applications.
A principle of a protocol is that a protocol does not discriminate against content that passes through it.
It is similar to collecting the same fare regardless of the type of vehicle on the highway.
It is known to the public as "the principle of net neutrality".
Based on these three principles, we intend to develop owlchain to acquire protocol status.
1. Introduction
Owlchain is the underlying technology powering BOScoin and Trust Contracts.
Owlchain is developed in D language and Trust Contracts are written in the Web Ontology Language(OWL) and Timed Automata Language(TAL).
The purpose of OWL is to provide “trust” on the internet through the abstract combination of standard web technologies.
OWL 2.0 version solved the data handling time delay problem, which was the existing problem in 1.0 version, by creating profiles.
BOScoin provides OWL 2 Profiles that use "Linked Data" to create Trust Contract.
Linked data is a declaration of the data required to issue a particular contract, and the semantic of contracts can be automatically validated by these defined data in the OWL 2 Profile.
In addition, like using javascript, static elements as HTML and CSS to show the screen on the web browser, Timed Automata Language(TAL) can provide dynamic processing on Trust Contracts.
TAL is a programming environment with two constraints, which are the timed automata modeling and pure functions.
Timed automata modeling can detect undefined area(reachability problem) in program code that developer can not find and can eliminate side effects that can occur during development by using pure function.
Due to these limitations, operating environment of Trust Contract satisfies the memory safety and the decidability.
- Timed Automata - assure decidability
- Pure Function - remove side effect
imgBostprFig1.png
[Figure 1] Trust Contract Blockchain
For programmers, OWL language can be viewed as a user-defined linked data because defined data, constraints and links of data in the OWL language can be used to program.
TAL is the data processing language of the blockchain(owlchain).
TAL can be abstracted as an operator to register a new transaction on a blockchain.
In order to explain a simple formula in the language of c++, when "c = a + b" formula is given for "+" operators, two variables ‘a’ and ‘b’ are added and then ‘c’ is returned.
The operator itself is implemented as pure function that does not produce any changes to the two variables used in computing.
A pure function prevents a program from being transmitted by providing the memory safety.
Thereafter, the operator written in TAL returns new transactions by referring to the Linked Data and the data in the Blockchain.
TAL shall satisfy both the conditions of the pure function and the characteristics of the Timed Automata.
These restrictions are set because the TAL environment is open to all users, and it is a permissionless blockchain for all users.
In the case of Trust Contract(Linked Data + TAL Operator) written in an open environment by an anonymous user, not having a rigid security model can create an unpredictable network state.
1.1 Comparison of Blockchains
The table below compares the characteristics of OWL to the Bitcoin and Ethereum
| Feature
| Bitcoin
| Ethereum
| Owlchain(BOScoin)
|
| Consensus
| Proof of work
| Current: Proof of work.
Future: Casper(?)
| Modified FBA(Federated Byzantine Agreement)
|
| - History revision mechanism
| Soft and hard forks
| Current: Soft and hard forks.
Future: Block revisions in case of temporary network isolation.
| Block revisions in case of temporary network isolation.
|
| - Membership
| Open
| Open
| Open with constraint
(min 10,000 BOS)
|
| Block Confirmation Time
| 10 minutes
| Current: 15 seconds
| 5 seconds (target)
|
| Block Size
| 1 MB
| Dynamic
| Dynamic
|
| Maximum Transaction
| 100 KB
| Dynamic based on gas limit
| Dynamic
|
| Transaction Throughput
| 7 tx/sec
| 25 tx/sec
| 1,000 tx/sec (target)
|
| Coins
| Bitcoin, plus tokens such as provided by Omni Layer
| Ether, plus tokens that can be issued by contracts.
| BOScoin
|
| Governance system
| None
| None
| Commons budget, Proposal, Voting
|
Smart Contracts:
- Computational Power
| Stack-based language with few instructions
| Turing complete
| Timed Automata Model
|
| - Decidability
| Decidable
| Not Decidable, using instruction fee(gas)
| Decidable
|
| - Runtime Architecture
| Script runs on Bitcoin Core, Libbitcoin, and other native implementations
| Ethereum Virtual Machine implemented on multiple platforms
| OWL inference Engine on multiple platforms
|
| - Programming Language
| Bitcoin Script
| Solidity, Serpent, LLL and any other languages that get implemented on the EVM.
| OWL + TAL
|
[Table 1] Comparison of Blockchains
2. Architecture Overview
Owlchain’s hierarchy is designed as a generic blockchain model to accommodate multiple ontology models.
Owlchain combines the feature of the Inference Engine and Consensus protocols to handle the Trust Contract.
The class types related to features such as the transaction and voting method are implemented in the blockchain as the primitives data type of the inference engine.
The blockchain based TAL is used to expand the limits of the expressions and calculations of the Ontology based programming language.
imgBostprFig2.png
[Figure 2] BOScoin Architecture Diagram
... CONTINUE on BOScoin site
bosnet.EVOLUTING (bosevn)
Name::
* cpt.bosevn,
{time.2017-05-10-2017-06-20}
=== ICO:
DURATION: The ICO will be carried out from “May 10, 2017” to “June 20, 2017”.
===
ICO will start on April 17th 2017 and will last 45 days until May 31st 2017.
In total 276,093,688.786 coins will be distributed.
bcnnet.Cosmos-network (cmsnet)
Cpt-created: {2017-05-08}
Description::
The Cosmos network consists of many independent, parallel blockchains, called zones, each powered by classical Byzantine fault-tolerant (BFT) consensus protocols like Tendermint (already used by platforms like ErisDB). Some zones act as hubs with respect to other zones, allowing many zones to interoperate through a shared hub. The architecture is a more general application of the Bitcoin sidechains concept, using classic BFT and Proof-of-Stake algorithms, instead of Proof-of-Work.
[https://cosmos.network/]
Name::
* cpt.bcnnet.Cosmos-network,
* cpt.cmsnet,
Description::
What’s the difference between Tendermint, the Cosmos Network, the Cosmos Hub, and Atoms?
Tendermint: a general purpose blockchain engine that uses a Byzantine-fault tolerant consensus protocol and allows applications to be written in any programming language.
The Cosmos Network: a heterogenous network of Proof-of-Stake blockchains that can interoperate with one-another.
The Cosmos Hub: The first Proof-of-Stake blockchain to be launched by the Cosmos Network; it uses Tendermint consensus, contains a built in governance protocol, and serves as co-ordinater for interoperability between other blockchains.
Atoms: The native cryptocurrency on the Cosmos Hub. Atoms are necessary for participating in the consensus protocol and transacting on the network.
[https://cosmos.network/faq]
cmsnet'Resource
AddressWpg::
* https://cosmos.network/,
* https://fundraiser.cosmos.network/,
* https://cosmos.network/whitepaper,
* https://tendermint.com/,
* https://github.com/tendermint/tendermint,
bcnnet.Dfinity (DFNnet)
Cpt-created: {2017-03-23}
Description::
DFINITY is conceived as a compatible sister network for Ethereum that extends the ecosystem by intoducing governance by an omnipotent distributed intelligence called the "Blockchain Nervous System".
The traditional "Code is Law" paradigms of Bitcoin and Ethereum are made subject to the distributed intelligence, which can also upgrade the protocol, update economic parameters and run special smart contract code that uses privileged instructions to reverse hacks such as The DAO.
The DFINITY project also represents the culmination of several years research into new cryptography and network protocols referred to collectively as "crypto:3" that vastly improve the performance of the virtual computer produced and lay a roadmap to infinite scalability and a true "decentralized cloud" where smart contracts can implement open versions of mainstream services such as Uber and high load business systems - exciting benefits Ethereum may be able to gain too by backporting selected techniques.
Special properties granted by crypto:3 also make it possible for DFINITY private clouds to host smart contracts that can call into smart contracts on the public DFINITY network.
[https://dfinity.network/donate]
Name::
* cpt.bcnnet.dfinity,
* cpt.dfnnet,
Generic::
* Blockchain-network-with-builtin-decentralized-governance,
* program-blockchain-network,
dfnnet'Protocol
dfnprl'USCID (Unique State Copy IDs)
dfnnet'Governance-system
Description::
BLOCKCHAIN NERVOUS SYSTEM
Governance by a distributed intelligence
Decentralized Intelligence
DFINITY is a different kind of decentralized world compute platform. It is platform managed by a decentralized intelligence integrated into its systems that can make arbitrary changes. This acts to mitigate misuse, protect users, fix problems, optimize network configuration and seamlessly upgrade its protocols.
A recent blog post explains how the Blockchain Nervous System works. The system depends upon human-controlled "neurons" operated by special client software. These follow each other and cascade to decisions. Neurons are created by depositing dfinities and earn rewards for performance of voting services. While the expertise within the crowd is leveraged, follow relationships exist at the edges of the network making the decision process unknowable, protecting participants.
Protecting Users
In DFINITY the "Code is Law" is contingent upon the decisions of the nervous system. As we have seen, with the recent Bitfinex theft and hack of The DAO, hackers steal keys and can sometimes break smart contract systems with design flaws. A key purpose of the BNS is to return funds where possible, and reverse the damage of hacks. The BNS can also fix systems that have simply failed due to engineering errors, such as a complex autonomous system that has deadlocked.
This increases comfort for consumers and businesses alike, many of whom will be unable to adopt decentralized systems without such protection and recourse.
Accelerating Technical Evolution
In systems such as Bitcoin and Ethereum, upgrades to the protocol occur as a result of contentious and disruptive "hard forks". In DFINITY there is no equivalent notion and the BNS upgrades the protocol transparently on a regular basis, quickly introducing fixes and optimizations and driving network evolution forward as quickly as possible.
The process is simple: the network client is wrapped by a reverse proxy wrapper that systems and Dapps interact with. The wrapper is aware of the BNS, and when instructed upgrades the client while buffering requests, making upgrades transparent.
Adaptive Network Policy
In DFINITY economic parameters such as "mining rewards" or the cost of a "mining identity" are set dynamically by the Blockchain Nervous System, rather than according to a fixed schedule as in a traditional network. The BNS ultimately seeks to increase the value of "dfinities" and indirectly to drive adoption of the network. This invisible market hand will drive the BNS to strike more sophisticated and beneficial economic balances.
[https://dfinity.network/]
===
To compliment Ethereum and truly broaden the options the ecosystem offers, DFINITY introduces the fundamental difference of governance by a novel decentralized decision-making system called the “Blockchain Nervous System” (or “BNS”).
[https://medium.com/dfinity-network-blog/the-dfinity-blockchain-nervous-system-a5dd1783288e]
Name::
* cpt.Blockchain-nervous-System-of-Dfinity,
* cpt.dfnbns,
dfngov'Neuron
dfnnrn'Controller
Name::
* cpt.dfinity'neuron-controller,
bcnnet.KSI
Description::
Blockchain meets Security
Keyless Signature Infrastructure (KSI) is designed to provide scalable digital signature based authentication for electronic data, machines and humans.
Unlike traditional approaches that depend on asymmetric key cryptography, KSI uses only hash-function cryptography, allowing verification to rely only on the security of hash-functions and the availability of a public ledger commonly referred to as a blockchain.
A blockchain is a distributed public ledger; a database of transactions such that there is a set of pre-defined rules as to how the ledger gets appended, achieved by distributed consensus of participants in the system.
The KSI blockchain overcomes three major weaknesses of mainstream blockchain technologies - which were designed to facilitate asset transactions - making KSI suitable also for cybersecurity and data governance applications:
Scalability: One of the most significant challenges with traditional blockchain approaches is scalability – they scale at O(n) scale complexity, meaning they grow linearly with the number of transactions. In contrast the KSI blockchain scales at O(t) space complexity – it grows linearly with time and independently from the number of transactions. KSI can sustain billions of asset registration events every second without growing out of control.
Settlement time: In contrast to the widely distributed crypto-currency approach, the number of participants in KSI blockchain distributed consensus protocol is limited. By limiting the number of participants it becomes possible to achieve consensus synchronously, eliminating the need for Proof of Work and ensuring settlement can occur within one second.
Formal security proof: Unlike other blockchains, KSI blockchain has been subjected to end-to-end formal mathematical proof that provides assurance that the protocol does precisely what it says it does.
[https://guardtime.com/technology/ksi-technology]
Name::
* cpt.bcnnet.KSI,
Bcnnet.Humaniq (HMQnet)
Description::
Launched in 2016, Humaniq is designed for those who don’t possess identification, with the mobile app utilizing a new reputation concept based on facial recognition for identity management. The fourth-generation mobile bank is based on the Ethereum blockchain and is attempting to tackle the global problem of financial exclusion for those who don’t have bank accounts. It is set to launch the first version of its mobile app on iOS and Android.
Initially, the alpha version of the application is by invitation only to 1,000 people; however, they expect to conduct a global rollout by October.
Speaking to Bitcoin Magazine, Alex Fork, founder of Humaniq, said that when he was talking with Ethereum co-founder Vitalik Buterin at a conference last year, he was struck by how blockchain technology can be a solution to improve the lives of disadvantaged people. After seeing that the current system doesn’t work, Fork decided to create his own tool.
“Unbanked people find it difficult to use banks for three main reasons: lack of ID, lack of minimum funds and geographical distance to the nearest branch,” he said. “We’re using facial and voice recognition technology for new user sign-up.”
[https://bitcoinmagazine.com/articles/humaniq-aims-tackle-barriers-economic-inclusion-blockchain-app/]
Name::
* cpt.Humaniq,
Generic::
* dependent-bcnnet, (Ethereum)
hmqnet'Protocol
hmqnet'White-paper
AddressWpg::
* https://humaniq.co/assets/downloads/humaniq_wp_english.pdf,
Humaniq Whitepaper
Alex Fork[ † ]
Abstract
The Humaniq team is building a next generation model for financial services (Banking 4.0) which is based on Blockchain technology, mobile devices and biometric identification systems.
We will use cryptofinancing (Initial Coin Offering) for growth capital rather than traditional venture capital and shareholders.
Our aim is to empower a market of 2 billion people who currently don’t have access to banking across the world.
Almost half the world — over three billion people — live on less than $2.50 a day.
At least 80% of humanity lives on less than $10 a day.
More than 80 percent of the world’s population lives in countries where income differentials are widening.
We believe Humaniq can help reverse these trends and help bring people out of poverty by giving them banking tools that can provide liquidity for entrepreneurial ventures via loans, investment, online work and cryptofinancing as well as create new opportunities in the digital economy, locally, nationally and internationally.
Humaniq can also help mitigate the refugee crises occurring in many countries in the West due to economic disparity and lack of opportunities in emerging economies.
Our unique selling proposition (USP) in the digital banking market is our use of Blockchain technology combined with biometrics and a focus on mobile technology.
We plan to not only provide a software solution but also bring mobile hardware (phones) into the markets we are aiming for in Africa, Asia and South America.
1 Mission
“A small body of determined spirits fired by an unquenchable faith in their mission can alter the course of history.”
Mahatma Gandhi
Look at this map:
imgHmqwprFig1.png
Figure 1: indeed, where they are?..
You may notice: there are unbanked regions on Earth.
As a matter of fact, nearly 2.5 billion people live in regions where no banking infrastructure exist.
The only form of payment available in those regions is manually giving banknotes (and/or coins) to a counterparty.
What makes it worse, even in banked regions, there are millions of people without passports or any other forms of identity or documentation, thus they are cut off from modern banking facilities.
According to a recent World Bank estimate, the total number of people who did not have identification documents amounted to 1.5 billion by 2016.
We at Humaniq, will provide a new financial infrastructure for everyone who has a smartphone with a camera.
The smartphone is necessary to make and receive payments, and the camera is needed to earn the first coins.
The price of smartphones is falling every year and they are currently priced at between $10-$20 on the low end.
imgHmqwprFig2.png
Figure 2: 2.5 billion adults are unbanked
To put it in simple words, Humaniq is banking for the unbanked.
Our ultimate goals are:
? to integrate 2.5 billion people disconnected from the international business community, and empower them to free themselves from the chains of poverty,
? to shift emerging economies into the cryptoeconomy.
2 What makes Humaniq special?
“The biggest room in the world is the room for improvement.”
Helmut Schmidt
It is natural to ask why the problem of banking for the unbanked cannot be solved by Bitcoin or any other cryptocurrency.
And the questions can also be asked: «What makes Humaniq special?», «Are you just another startup offering yet another mobile wallet app?»
At first glance, it looks like any Bitcoin mobile wallet could be used in unbanked regions.
But if you think deeper about this, you will discover the following issues:
? The problem: the number of satoshis in circulation (or any other small units of crypto) is insufficient for some regions.
E.g., in Indonesia (250 million people), there’s just not enough digital currency to have substantial daily turnover (volume).
Bitcoin is scarce, and if you don’t have bitcoins, you are inclined not so to be interested in the network.
For regions poorly integrated into the international financial system, it would take a lot of time for sufficient liquidity to appear in the local market.
But there’s no doubt that such regions have their own domestic economy today.
It’s just they are almost exclusively cashbased.
? Our solution: unlike other cryptocurrencies, Humaniq provides an egalitarian emission mechanism.
The amount of coins that one person can mint is limited, and this is what makes Humaniq so special.
This mechanism has nothing to do with competing in specialized hardware, having access to specialized hardware, wasting electricity, or owning the coins preliminarily.
It may be called proof-of-face, and nothing is more fair than that.
? The problem: the lack of local exchanges.
Even now in 2017, there are lots of countries where no infrastructure to buy or sell cryptocurrency exists.
This is the issue even for some European countries, which have no problems with Internet adoption and where virtually the entire population is using smartphones.
We’d like to stress that it has been more than 8 years since the first cryptocurrency launched, and more than 7 years since the first cryptocurrency exchange ever appeared.
? Our solution: since our platform provides infrastructure for people to earn Humaniq coins from home, we understand that people would eventually like to exchange cryptocurrency for local currency.
Of course, we provide such infrastructure in our app.
(And still, we are in talks with some national and international shopping franchises in various countries we are targeting — and engaging them to add Humaniq as a payment option.)
? The problem: some states are concerned with pseudo-anonymity of cryptocurrencies, which causes recurring legal issues associated with them.
? Our solution: since app users have to pass bio-identification, there is no anonymity in Humaniq.
That is good news for transparency advocates, and that makes Humaniq unviable for financing terrorism, trading drugs and all the other deadly sins Bitcoin is accused of.
Another point is, Humaniq provides the ability to earn while working from countries abroad.
This enables an export-driven economy in depressed regions, improves living standards of depressed regions, and reduces the impetus for migration, which is great for all governments both in developed and in developing countries.
? The problem: the network effect of Bitcoin (and other cryptocurrencies) is relatively small because of relative usage complexity.
According to the report from Juniper Research, the number of active Bitcoin users around the world could reach 4.7 million people by the end of 2019.
Even now the network has reached the capacity limit of 250 thousand transactions.
Eight years of the Bitcoin era have passed; compared to PayPal, after 8 years it had 100 million active accounts, despite the fact that it appeared with less developed online infrastructure and can require passport details for use.
? Our solution: we discarded the private and public key approach, which confuses newcomers; we also had to reject using fractional amounts of coins, since decimal fractions may be uneasy for people with little or no education.
It’s very simple.
Coins are whole numbers (integers), faces are used as passwords — if you think it gets any easier than that, please tell us what could be simpler.
? The problem: complexity of reputation accounting in anonymous communities, needed for various p2p-solutions (p2p-insurance, p2pbanking).
? Our solution: we handle this problem with our bio-identification procedure.
By the beginning of 2017, elegant solutions for biometric authentication already exist.
If we take a combination of authentication methods it increases the likelihood of a near hundred-percent authentication.[ 1 ]
Our approach is to use one random authentication method each time.
Every authentication takes no more than two seconds and is as easy as unlocking a smartphone.
? The problem: the lack of crypto evangelists in undeveloped regions, which contributes to people’s unawareness of innovative payment systems.
? Our solution: the reasons why people don’t promote cryptocurrencies in undeveloped regions are understandable: technical complexity of the subject, language difficulties, no financial incentive etc.
But we’ve targeted our project directly at such regions.
Working on the problem, we have studied nearly everything about the current state of developing countries.
We talked to ~100 prominent bitcoiners who live in developing countries such as Sierra Leone, Afghanistan, Botswana, Pakistan and Indonesia.
Dozens of them decided to enter our Humaniq Ambassador Program: they will teach people about how to use Humaniq and earn cryptocurrency for that.
This is why Bitcoin or any other crypto isn’t used in unbanked regions.
And won’t be used.
The currency of unbanked regions (the dark ones on Figure 1) is called Humaniq.
3 Vision
“Visions are worth fighting for. Why spend your life making someone else’s dreams?”
Tim Burton
In Humaniq, the amount of coins that one person can mint is limited, and that is what makes Humaniq truly special.
This may sound really strange for an experienced crypto-community member.
How did we achieve this?
We did it with the help of bio-identification.
Our bio-identification has to be passed only once, taking less than 20 seconds and does not require to have any e-mail or passport.
And modern face recognition algorithms for neural networks can check one’s identity with incredible accuracy.
Briefly, bio-identification is obligatory to create a wallet; every user is given coins for passing bio-identification; the process consists of taking series of photos, recording videos of the user making facial gestures, and recording the user’s speech.
For details, move to subsection 9.3.
To prevent theft of coins, every time a user signs in into the app, he or she must pass the authentication procedure.
The authentication is similar to bio-identification, but much shorter: the user has to repeat just one of the recorded gestures in the front of the camera.
It is as easy as unlocking a smartphone.
The software we have developed works with the cheapest hardware solutions on Android 5.0: with smartphones that cost $10-$15.
Such affordable devices are usually fitted with a front-facing camera and microphone, and thus are sufficient to install a mobile wallet and to authenticate the user.
After passing the bio-identification, everyone is invited to earn additional coins by inviting friends and making transactions.
Moreover, we enable the possibility for everyone to earn a living with their mobile phones, and that’s what is truly impressive.
You may ask — how?
Well, we work with local companies and brands to achieve this.
Our cherished will is to make Humaniq the de facto currency of the world where over three billion people live on less than $2.50 a day.
Humaniq can give these people the opportunity to break free from poverty, improving the lives of their families and themselves by entering and helping create a new mobile digital economy.
Imagine now... over two billion users improving capitalization of popular services by getting used to them — isn’t that what brands dream of?
Isn’t that why Facebook is making a play with internet.org?
Our user may purchase a smartphone perhaps even with a loan — and after the purchase, cover his or her expenses within several weeks, by executing simple actions.
4 Emission Model
“Cryptoeconomic system may contain its own currency and token system which would be useful in any sense in some system aspect. Units of currency can be generated by the system and then sold or distributed directly as award for participation in system operation.”
Vitalik Buterin
We feel honored to repeat it once more: Humaniq provides an egalitarian emission mechanism.
The amount of coins that one person can mint is limited, and that is what makes Humaniq so special.
This mechanism has nothing to do with competing in specialized hardware, having access to specialized hardware, wasting electricity, or owning the coins preliminarily.
It may be called proof-of-face, as we’ve mentioned, and there’s nothing more fair than that.
In this section, we are about to present the details of the emission model we chose.
Developing it, we pursued the following objectives:
1) The early adopters should receive more money than the later ones.
2) The total amount of coins that will ever be issued must be five times bigger than the amount of coins issued via Pre-ICO + ICO.
3) Emission proceeds until kmax people are registered. kmax should be relatively big.
4) In average, one user is granted with 500 coins.
5) Tokens are issued by the smart contract upon request.
6) Emission per one person is carried out not by one-time payment[ 2 ], but in accordance with a scoring function which depends on the person’s activity: passing through bio-identification, inviting friends, making transactions.
Let E(k) be the amount of HMQ coins that may be granted to the person who was k-th to pass the bioidentification in the Humaniq app (the user number k).
The objective number 1 tells that the function E(k) should be decreasing one.
We chose the simplest decreasing function — the linear one:
E(k) = Emax - (Emax - Emin / kmax) · k
Thus, at k = 0 E(k) = Emax, and at k = kmax the correspondence E(k) = Emin holds.
We chose Emax equal to 860, and Emin equal to 140.
Finally for the maximum possible amount for the k-th video registrant
E(k) = round (860 - 720/kmax · k) (4.1)
Let us draw a graph showing the controlled supply of coins:
imgHmqwprFig3.png
Figure 3: The distribution of Humaniq coins. Red line represents the maximum possible amount of coins a user can be granted with respect to the scoring function. Blue line represents the number of coins that the user is granted if his or her only action is passing bio-identification.
Denote the total amount of coins sold via Pre-ICO + ICO by Vico.
According to the objective number 2, only 4Vico coins will be earned by users of the Humaniq app.
Thus, the maximum possible amount of Humaniq coins is limited by 5Vico.
The objective number 4 states that the total average number of coins that a user can mint in-app must be close to 500, thus giving immediately follows.
imgHmqwpreqn42.png
This provides the restriction upon the total amount of people who can mint the tokens in-app.[ 3 ]
We use the conventional rounding
function to guarantee that kmax is integer.
The scoring function mentioned in objective number 5 describes how people can earn their E(k) coins in the Humaniq app.
It is structured as follows:
(denoting the HMQ/USD exchange rate by r, so that 15r becomes the Humaniq equivalent of $15)
• mobile app installation — min(round(0.01 · c1 · E(k)); 15r) HMQ
• receiving first coins from a friend — min(round(0.04 · c2 · E(k)); 15r) HMQ (one-time payment)
• passing the bio-identification — min(round(0.15 · c3 · E(k)); 15r) HMQ (one-time payment)
• a referred friend passed bio-identification4 — min(round(0.1 · c4 · E(k)); 15r) HMQ (for every 5 first friends invited)
• execution of a transaction within first month after installation — min(round(0.05 · c5 · E(k)); 15r) HMQ (one-time payment)
• execution of a transaction within second month after installation — min(round(0.1 · c6 · E(k)); 15r) HMQ (one-time payment)
• execution of a transaction within the third month — min(round(0.15 · c7 · E(k)); 15r) HMQ (one-time payment)
• additional earning opportunities are provided by local and global startups and senior companies.
For moments when exchange rate HMQ/USD diminishes, the emission can be delayed.
The exchange rate is treated diminished, if
current rate < average rate for the last week.
By the start, every coefficient in the tuple (c1, c2, c3, c4, c5, c6, c7) is set to 1, but after some time these coefficients are going to become mutable.
For the first period of their mutability, the control over these coefficients will be community-driven, but eventually this control will be forwarded to a neural network, whose goal will be to maximize several reasonable metrics (the installations’ rate of growth, transactions’ number rate of growth).
Thus, the amount of HMQ that can be granted to a user is E(k), where k is the number of users who passed the identification before him or her.
The formula (4.1) can be used to calculate the potential benefit.
The earning opportunities aren’t limited by this.
Start-ups and senior companies pay additional amounts of HMQ to people executing their tasks.
The list of tasks available at you region can be found in the tab «Offers».
Our ultimate dream is that everyone could purchase the smartphone, install the Humaniq app and then cover his or her expenses on the same day, executing simple actions.[ 5 ]
That is why we tether our emission to the Humaniq equivalent of $15.
5 The ICO
“Just as treasures are uncovered from the earth, so virtue appears from good deeds, and wisdom appears from a pure and peaceful mind.
To walk safely through the maze of human life, one needs the light of wisdom and the guidance of virtue.”
Buddha
Despite we have enough money to develop the project on our own, we think it is fair to allow everyone to invest in the project.
To make the procedure egalitarian, we have chosen to utilise cryptofinancing via an initial coin offering (ICO) rather than take on venture capital.
Moreover, a crowdsale is a brilliant way to attract media attention.
Our crowdsale has two stages — the Pre-ICO and the ICO. T
he Pre-ICO took place since 15 Dec 2016 till 28 Dec 2016.
The ICO starts by 6 Apr 2017, CET 00:00 and
ends by 26 Apr 2017, CET 23:59.
To buy Humaniq, the only payment options during the ICO are Bitcoin (BTC) and Ethereum (ETH).
During the ICO, the rates are as follows:
1 ETH buys 1000 HMQ (+ bonuses)
for BTC-buyers: your BTC counts as the equivalent amount of ETH[ 6 ]
We also offer the following bonuses for those who invest earlier:
6-7th of Apr + 49.9%
8-14th of Apr + 25%
15-21th of Apr + 12.5%
22-26th of Apr + 0%
Since all Humaniq balances are whole numbers (integers) and fractional amounts of coins are not possible (see subsection «Coins are integer» for the reasoning), we had to come with the solution for the arising subtlety.
We chose different ways to handle the problem of fractional HMQ for Bitcoin-using and Ethereum-using participants.
For Bitcoin participants, if the amount of HMQ to be bought is less than 112358 HMQ, rounding down is performed; otherwise, if a buyer wishes to buy more than 112358 HMQ, the amount of HMQ to be bought is rounded up.
For Ethereum participants, we decided to conduct bounce-back transactions (and hardcode them in the smart contract).
E.g. if you transfer 3.1415926 ETH and no bonuses are applied, you are about to receive 3141.5926 HMQ, but since HMQ balances are integer, the amount of ether equal to 0.5926 HMQ is sent back to you.
Participating in the ICO doesn’t require passing bio-identification.
5.1 The key holders
Our fundkeepers are:
Alex Fork
George Basiladze
Bitcointalk user btcsec
6 The Pre-ICO (survey)
The purpose of the Pre-ICO was to create a discussion on issues raised by the project, to attract the attention of leading experts in the industry, and to raise funds to prepare the promotion and public relations of the project, as well as prepare a quality ICO.
We chose the following rates for the Pre-ICO stage:
1 ETH buys 1500 HMQ (+ bonuses)
for BTC-buyers: for the whole Pre-ICO campaign,
we treated every your bitcoin as 93.5 ETH
We announced that if the amount collected is less than 10000 ETH, all funds will be returned. Fortunately, we collected[ 7 ] 99.002855 BTC and 3122.362977 ETH, which amounted to more than the announced threshold.
The following bonuses were available during the Pre-ICO stage:
First 12 hours + 70%
16th of Dec + 50%
17-19th of Dec + 33%
20-22nd of Dec + 20%
23-25th of Dec + 7%
26-28th of Dec + 0%
We are delighted to inform you that 31824818 HMQ tokens have already been distributed during the Pre-ICO (in complete accordance with these bonuses), and we look forward to our upcoming ICO, which will provide the answer on the final quantity of tokens that can ever be generated Vico and thus determine the constant kmax from (4.2).
All rewards and bounties were distributed within one week after the end of Pre-ICO, just as it was claimed.
7 Our development process
“Success or failure of a team is determined by how its members communicate and interact.”
Ichak Adizes
Future Fintech keeps in contact with more than 200 fintech start-ups.
One of the challenges of most projects is access to the customer base.
This is why the implementation of our solution will help young projects (P2P lending, insurance, mobile wallets, scoring, freelance, etc.) offer their ideas to people who have no experience in the financial sector.
Therefore, the project will be developed as follows.
The main development team develops the core.
Others join later and develop their start-ups or solutions on a ready-made platform.
We use Github to bring the core team and third parties together.
We are open to get suggestions and ideas from ordinary users — from the Community.
We always keep in touch with them via the Humaniq app, as well as on Bitcointalk and on our brand blog on Medium.
Users also join us via our Slack channel, read the latest news on Facebook and Twitter, and participate in discussions on our subreddit.
imgHmqwprFig4.png
Figure 4: join us to see how we work
Close interaction with users and testing an idea or a prototype on potential consumers allows us to make the right decisions and save resources.
This is why customer development greatly reduces the investor risk.
After all, theory often differs from practice, and developers’ opinions on ergonomics and ease of use may differ from the perceptions of the product’s end users.
Users often have their own understanding of a set of must have functions, and ignorance of their real needs can lead to the failure of the entire start-up.
As such, our analysts and trend watchers, together with the developers, will consider every feature request communicated by users in the community.
Some ideas greatly improve the product; but, at the same time, the development of one option can take an hour or two, while the implementation of another can take a few days.
Analysts and trend watchers will also evaluate the feasibility of each request and explore it within the context of market trends.
The developers, in their turn, will integrate them properly if new ideas are given thumbs up.
At the same time, budget and deadlines must be met.
Therefore, some ideas are rejected for one reason or another, while others form the list of tasks for the team of developers.
Thanks to this, analysts, trend watchers, investors, users, project managers and programmers themselves are always aware of the current development stage of a project.
Any interested user and even a developer can connect to it from various sides and get a respective reward:
• participate in beta testing;
• voice their ideas for improving the product in the Community;
• develop their start-up;
• become an analyst or a trend watcher.
As you can see, our project development scheme allows and supports the active participation of users.
Customer development allows us to create a product that meets their needs and wishes, which eventually ensures its success.
8 The timeline of Humaniq
“The best way to predict the future is to create it.”
Peter Drucker
The milestones on this road are:
• 2016, October-November — Humaniq Whitebook is written
• 2016, December — Launch of Humaniq.co website.
• 2016, December — the pre-ICO.
• 2017, January-February — smart contract development, due diligence, marketing campaign
• 2017, February — a meeting with Humaniq project partners in India.
• 2017, February — announcing Humaniq online-hackathon in partnership with (yet undisclosed) well-known blockchain media
• 2017, February — the start of the ICO (crowdsale).
• 2017, April — headlining the BlockShow Europe 2017, giving talks on panel discussions, concluding results of the hackathon and giving awards to winners
• 2017, April — crowdsale concludes.
• 2017, May — prototype of Android mobile app.
• 2017, July — Product launch: the mobile app (wallet with bioID) + exchange app.
• 2017, September — global expansion in two directions: to underdeveloped regions (expansion of the network of users in Africa, Asia, South America) and to the cities that are crucial to modern business (London, Singapore, Hong Kong and San Francisco).
• 2018 — integration of virtual cards, of fintech start-ups, and further decentralization of Humaniq architecture.
9 Technical
“Architecture is inhabited sculpture.”
Constantin Brancusi
From the technical point of view, to implement the idea, the following ingredients are required:
1) mobile app, which is what users see.
We’re talking about Android app, since in underdeveloped regions market share of Android OS is close to 95%.
Making an iOS App is less important in our case, but for the sake of perfection we actively develop it.
2) appropriate bio-identification/authentication software
3) such software essentially produces a «chunk» of every person’s identity; these chunks are used for identification/authentication and must be stored somewhere in decentralized manner
4) these chunks must be encrypted
5) identification procedure must cost zero for end users (at least for the first time)
6) authentication procedure must cost zero for end users (at least for the first time)
7) secure consensus algorithm (e.g. robust blockchain)
8) transactions should cost zero for senders if possible.
To satisfy the first and second conditions, it is enough to build the apps, and to buy licensing rights for the best available bioID solution.
Chapter 9.2 is devoted entirely to how we made our choice of the solution.
To satisfy the third condition, we should allow every PC to become a Humaniq node.
On encryption (fourth condition), our approach is similar to Storj and (announced by Ethereum) Swarm’s one.
To meet the fifth condition, it is enough to specify in the protocol that nodes have to add «chunks» of a new person to their database, keep their databases synchronized, and are not paid for that.
It’s exactly like in Bitcoin: full nodes kept on their hard drives containing the ledger of all transactions that have ever happened without any financial incentive.
The sixth condition resolves like the previous one: people verify and broadcast identities of authenticating users for free.
Again, exactly like in Bitcoin: peers verify and broadcast new blocks and transactions, and nobody gets paid for that.
Speaking on condition eight, for the first few months of the network’s existence transaction fees will be zero for end users.
However, this is to be changed in future, since the founders cannot pay Ethereum fees forever.
We are about to decentralize the project architecture and to make it nondependent on founders, giving everyone the possibility to run a Humaniq node.
We are using Ethereum for the project and the ICO campaign because this platform allows us to create a secure solution quickly, with few resources, and without loss of quality thanks to:
• smart contracts (we plan to conduct the audit of our smart contracts);
• reliability of a ready and operating blockchain, in contrast to the risks associated with deploying own blockchain;
• future development of the Ethereum project and stated opportunities.
imgHmqwprFig5.png
Figure 5: The inner structure of the Humaniq platform
The only tough issue is the centralization.
Humaniq has several components: software part, neural network and database.
In the future, all these components are to be decentralized.
9.1 Issues and responses to them
Humaniq is based on blockchain technology.
Major component — transaction settlement will be done on Ethereum blockchain using Standard Token (ERC20) contract.
New tokens are emitted for every authenticated user and the rules of emission are controlled by «Emission smart contract».
Humaniq servers are responsible for authorization of users on the blockchain via Biometric ID services as well as approving additional token emission.
Users will only interact with Mobile Wallet for their smartphones.
Scrupulous readers may say that this system has a number of centralized places carrying risks.
But there are answers to this:
1. Each user can use the Ethereum client wallet without using additional services.
2. It should be admitted that Bitcoin protocol add-on services are used by an overwhelming majority of Bitcoin users; and this is the normal operation of a payment system, and our operation will be based on the same principles.
And since security issues are undertaken by Ethereum, this allows us to focus on the client-oriented decentralized business model.
3. With reference to bio-identification and mobile wallet, we will move towards open source and hereafter decentralization.
4. Besides the above-mentioned, the service development strategy is a decentralized business model, i.e. stimulating creation of several mobile wallets by third-party teams, chatbots, exchange services, service rendering.
5. Today there is no technological opportunity to put bio-identification into blockchain, however if there is a possibility to help people now, and to develop ecosystem of cryptoeconomics — it should be done.
There are three key components of Humaniq:
• the app (which is essentially also the mobile wallet)
• Humaniq servers
• contracts on Ethereum blockchain.
9.2 BioID: technology
We understand that biometry is not finance, and we’re not specialists in this technology.
As a consequence, we’re actively working with various well-established companies, who specialize in computer vision and/or image recognition.
Hence, to execute bio-identification, we are going to invite a solution provider when we are ready to make the choice.
We have not yet signed any formal agreements, and, due to the high responsibility of this step, we are not rushing.
We plan to announce which service provider we have chosen and to provide corresponding formal agreements during the crowdsale.
9.3 BioID: user experience
During the first launch of the Humaniq app, one must pass through the
bio-identification procedure[ 8 ].
Otherwise, the Humaniq interface just won’t show up.
This bio-identification is arranged as follows.
A registrant is required to make a photo of themselves with the smartphone, to record a video of smiling and grinning, and to pronounce the text shown on the screen.
To avoid counterfeits, the device ID is added and the text is chosen at random out of very large pool; it eliminates the ability to use pre-prepared audio tracks.
All the instructions are shown on the mobile phone screen, so of course no prerequisite knowledge is needed to use the app; you don’t need to know anything about the app in advance.
You may download the app from Google Play and try it yourself.
This authentication method takes less than five seconds and requires no e-mail, SMS, passport, and you don’t have to worry about losing or forgetting your password.
This is the real proof of identity.
9.4 Mobile Wallet
The Mobile Wallet is an interface for mobile (iOS, Android) users that provides them with quick access to their balances and lets them transact with other users/merchants.
The Mobile Wallet manages private and public keys for the user, which are used to sign transactions locally.
It also has a built-in module for collecting biometric user data, such as voice and video, which can be used to bind a user with their identity and provide them with additional features of the platform, such as action-based emission.
The Mobile Wallet also includes an API for third-party developers so they can interact with the Wallet: access balances, send transactions.
9.5 Contracts on Ethereum blockchain
There are two contracts that are already deployed on the blockchain.
First one is Standard Token Contract (ERC20) that keeps track of user balances and allows them to transfer tokens between each other.
Second one is responsible for token emission.
However, we understand that with the decentralization proceedings we will be involved in the development of an ample web of contracts; follow our Github to stay keen on updates.
9.6 Sending a transaction with Mobile Wallet
1. Transaction is generated on the smartphone and then signed using local
private key.
2. Signed transaction data is submitted to Humaniq servers.
3. Transaction is relayed to the Ethereum blockchain to the Humaniq
Token Smart Contract.
9.7 Sending transactions without Mobile Wallet
1. If the user already has Humaniq tokens they might transact directly
using Token smart contract bypassing Humaniq servers.
2. After signing the transaction user might send it directly to Ethereum
blockchain.
3. This brings an advantage of control over the transaction publication
and propagation (because there might be a delay due to a high load
on the Humaniq servers).
9.8 Coins are integer
Any Humaniq balance cannot be fractional. It can only be integer.
We’re targeted at providing undereducated people with modern finance, and we don’t expect all of our users to be great at fraction calculus.
The integer amount of coins makes it easier for undereducated people to count their money.
10 Conclusions
The Humaniq project was launched to create a financial infrastructure for people who were previously isolated from it.
We are using the most advanced and mass technologies: the blockchain with the possibility to connect thirdparty projects, a mobile application, along with bio-identification.
Humaniq will also add to the science of cryptoeconomics, the well-being of developing countries, and can even benefit the European economy.
For cryptoeconomy:
• expanding the amount of cryptoeconomy users will result in a positive development in this industry
• original inherently friendly and open source architecture of Banking 4.0 will help start-ups to get instant access to customers around the world and obtain financial support from the Humaniq project
• bio-identification will allow testing reputation systems and personalized interaction programs, introducing this realm to charitable organisations, NGOs and United Nation services.
For developing countries:
• poverty level reduction
• remote work and economic growth: greater opportunities for savings will increase the lending capacity of the population; collection of customer financial data will reduce lending risks
• innovation and infrastructure: electronic finances will allow the creation of new business models and products
• reduction in class inequality: financial services can provide new opportunities for billions people living on less than $2.50 a day and bring them to the middle class, greatly improving their lives
• establishing gender equality: engaging the female population in the electronic finance system will raise incomes of health care and education systems; a barrier for women in financial account registration will dissolve, and women will have more control over their funds and business
• improving the quality of education through remote access and payment capabilities.
For the EU:
• improving the economic situation in third world countries will reduce the current immigration challenges faced by advanced economies, particularly in the European Union where the influx is creating huge strains on the social welfare systems and high costs associated with the problem.
Humaniq is not welfare or charity, we are more about empowering people to change their lives and pull themselves out of economic disparity by participating in a new digital economy that they can help build.
Notes
[†] alex@humaniq.co, fb.com/fork.alex, linkedin.com/in/alexfork
[1] It is worth noting that the use of hardware solutions, for example, a fingerprint scanner, allows signal counterfeiting at hardware level.
[2] We think that it is fair to issue coins stepwise depending on the everyday involvement of a user.
We wish to avoid the mistake of some altcoins, which made their rewards onetime payments and which suffered from users not having incentives to use the platform on a regular basis.
[3] The Pre-ICO has passed, and some conclusions may be already done.
Exactly 31824818 HMQ tokens were generated; thus, even before the start of the ICO, the inequality Vico > 31 · 106 holds, and, due to (4.2), kmax > 248000.
[4] Humaniq balances cannot be fractional.
You are invited to guess why, and then check your guess in the subsection 9.8.
[5] The price of cheapest smartphone able to perform mobile wallet functions and fitted with front-facing camera falls down every year and is now about $10-20.
[6] with respect to the BTC/ETH exchange rate at the moment of purchase
[7] To stress his personal responsibility for the pre-ICO, our founder Alex Fork decided to use the bitcoin wallet he uses since 2013.
To make accounting easier, right before the start all the bitcoins were drained away from there, making the balance zero.
[8] Fortunately, a frontal camera and a microphone are now built in all devices.
bcnnet.Qtum
Cpt-created: {2017-03-23}
Description::
Smart-Contract Value-Transfer Protocols on a Distributed Mobile Application Platform
Blockchain-enabled smart contracts that employ proof-of-stake validation for transactions, promise significant performance advantages compared to proof-of-work solutions.
For broad industry adoption, other important requirements must be met in addition.
For example, stable backwards-compatible smart-contract systems must automate cross-organizational information-logistics orchestration with lite mobile wallets that support simple payment verification (SPV) techniques.
The currently leading smart-contract solution Ethereum, uses computationally expensive proof-of-work validation, is expected to hard-fork multiple times in the future and requires downloading the entire blockchain.
Consequently, Ethereum smart contracts have limited utility and lack formal semantics, which is a security issue.
This whitepaper fills the gap in the state of the art by presenting the Qtum smart-contract framework that aims for sociotechnical application suitability, the adoption of formalsemantics language expressiveness, and the provision of smart-contract template libraries for rapid best-practice industry deployment.
We discuss the Qtum utility advantages compared to the Ethereum alternative and present Qtum smart-contract future development plans for industrycases applications.
[https://qtum.org/uploads/files/cf6d69348ca50dd985b60425ccf282f3.pdf]
Generic::
* program-blockchain-network,
bcnnet.RSK
Cpt-created: {2017-03-19}
Description::
RSK is the first general purpose smart contract platform secured by the Bitcoin Network.
[https://faq.rsk.co/]
===
RSK is the first open-source smart contract platform with a 2-way peg to Bitcoin that also rewards the Bitcoin miners via merge-mining, allowing them to actively participate in the Smart Contract revolution. RSK goal is to add value and functionality to the Bitcoin ecosystem by enabling smart-contracts, near instant payments and higher-scalability.
[http://www.rsk.co/#about-rsk]
Name::
* cpt.bcnnet.rsk,
* cpt.rootstock-net,
* cpt.rsknet,
AddressWgp::
* {2017-05-15} Bitcoin Scalability Issue Takes New Turn As RSK Ready to Release Ginger: https://cointelegraph.com/,
bcnnet.Synereo (AMPnet)
Description::
Synereo’s Attention Economy
The Future of Content Creation, Publishing and Distribution
Synereo is developing tools which allow content creators to easily monetize original works without having to turn their channels into advertisment real estate, while granting their followers the opportunity to be rewarded for getting the word out.
[http://www.synereo.com/]
===
Blockchain 1.0 brought us Bitcoin, and it was good, but we wanted a foundation for the fully decentralized ecosystem we envisioned.
The Synereo team has built an entirely new, calculus-powered blockchain 2.0 framework - ready to build the decentralized economy of the future.
[https://www.synereo.com/]
Name::
* cpt.ampnet,
* cpt.bcnnet.synereo,
* cpt.synereo-network,
snrnet'Exchange-value-unit (AMPevu)
Description::
Synereo (AMP)
$0.094086 (-0.56%)
0.00007926 BTC (-1.69%)
Market Cap
$7,739,201
6,520 BTC
Volume (24h)
$139,818
117.79 BTC
Circulating Supply
82,256,324 AMP
Total Supply
949,291,063 AMP
[https://coinmarketcap.com/assets/synereo/] {2017-04-15}
===
Synereo AMP
Synereo is a "next generation" decentralized social network that incorporates blockchain technology to overcome problems associated with centralized social networks such as privacy, security and commodification of users' personal data.
[https://changelly.com/supported-currencies]
Name::
* cpt.AMPevu,
* cpt.mnyAMP,
* cpt.AMP-token,
AddressWpg::
* https://coinmarketcap.com/assets/synereo/
bcnnet.Tezos (tzsnet)
Cpt-created: {2017-03-23}
Description::
WHAT IS TEZOS?
Tezos is a secure, future-proof smart contract system.
Because Tezos has a built-in consensus mechanism, its protocol can evolve, and incorporate new innovations over time, without the risk of hard forks splitting the market.
Tezos is its own blockchain, not a derivative of any other blockchain. We didn’t just fork Bitcoin or Ethereum and add a layer onto it. We built our own from the ground up.
Our smart contract language makes it easier to apply formal verification to any smart contract running on the Tezos blockchain. This allows developers to rule out weaknesses in code before uploading that code on the blockchain.
Tezos relies on a less onerous, less computationally intensive, and less power-consuming proof-of-stake consensus algorithm, where bonded stakeholders validate transactions.
[https://tezos.com/index.html]
Generic::
* program-blockchain-network,
tzsnet'Resource
AddressWpg::
* https://tezos.com/
Address:
Tezos
100 question mark way
Brooklyn, New York 11221
bcnnet.Wings (WINGSnet)
Description::
WINGS is a platform designed to solve the problem of a project’s early backing and accountability, by providing tools for backers to work together on providing funds and efficient decision making on business critical items.
WINGS puts emphasis on ease of use and efficient collaboration, and on encouraging careful consideration of available choices.
The effort put on this consideration defines whether the decision will result in reward, thus directly rewarding those who bring the most net benefit to the platform efficiency.
With higher efficiency, higher quality projects get more attention both from the backers and the public.
[https://wings.ai/docs/WINGS_Whitepaper_V1.1.2_en.pdf]
===
When will the Wings Platform be launched?
Avatar Stas Oskin
Thursday at 17:37
Follow
WINGS public beta is estimated to be launched around Q1 2017. Users can, however, test the WINGS platform concept through our Alpha test platform, which currently provides the basic features of project creation and management, forecasting, milestone releases, and project funding.
Everything on the Alpha platform runs on testnet tokens that allow the community to test the concept without the need to send any real crypto-currencies. Click here to test the WINGS Alpha Platform
[https://wings.zendesk.com/hc/en-us/articles/208276389-When-will-the-Wings-Platform-be-launched-]
===
Does WINGS run on its blockchain?
Amadeira
January 22, 2017 00:10
WINGS will run on the RSK sidechain/drivechain which provides the same smart contract and DApp capabilities as the Ethereum Virtual Machine, while enabling projects to be funded with Bitcoin.
[https://wings.zendesk.com/hc/en-us/articles/115000058730-Does-WINGS-run-on-its-blockchain-]
Name::
* cpt.bcnnet.Wings,
* cpt.netWings,
* cpt.wingsnet,
wingsnet'Exchange-value-unit.Consensous (WINGSevuC)
Description::
When will the WINGS token start trading?
Amadeira
March 20, 2017 21:43
The WINGS tokens have not been created yet, therefore it is not possible to transfer, withdraw or trade the tokens at the moment. We are in contact with all major exchanges and will update once we have any news.
WINGS tokens are scheduled to be released around March 2017. At this time, the WINGS tokens will be created and allocated by the smart contract, which means that they can then be added to exchanges that wish to feature WINGS token trading.
It has also come to our attention that the exchange Liqui has launched an I.O.U market for the WINGS token (tokens there are not "real"). This means that the exchange has participated in the WINGS donation campaign and is currently trading it's own tokens that have not yet been created and allocated.
[https://wings.zendesk.com/hc/en-us/articles/115000058670-When-will-the-WINGS-token-start-trading-]
Name::
* cpt.WINGS-token,
* cpt.WINGSevuC,
wingsnet'Organization
DAO (wingsdao)
Description::
What is a DAO
Amadeira
January 21, 2017 15:12
DAO stands for Decentralized Autonomous Organization. At its most basic level, a DAO is an organization that relies on no form of central authority to operate. Instead, DAOs make decisions based on the votes made by all the members of the organization. This system is automatized on the blockchain through the issuance of cryptographic tokens, which are used to vote on certain decisions, projects or changes proposed to the organization.
These organizations usually come together by means of crowdfunding. The funds are then used to carry out the project that it was created to do or projects that are proposed to the organization.
[https://wings.zendesk.com/hc/en-us/articles/115000062610-What-is-a-DAO]
Name::
* cpt.dao.wings,
* cpt.wings'dao,
wingsdao'Managing
Description::
How are DAOs managed?
Amadeira
January 21, 2017 19:59
The tokens issued by DAOs allow members of the organization to vote on certain decisions, projects or changes proposed to the organization. This system is also used to factor in the power of each voter. Typically, this means that the more tokens a member has, the more his vote will weight, although other aspects may also come into play.
This system acts as an anti-sybil measure, ensuring that one user can not vote multiple times without having to purchase more tokens from other members of the community (usually through an exchange). Since these tokens have a real-live value and can only be attain through an exchange or crowdfunding campaign, token holders who have a large stake in the organization have a direct benefit to behave in the DAO’s best interest.
[https://wings.zendesk.com/hc/en-us/articles/115000062910-How-are-DAOs-managed-]
bcnnet.user.PUBLIC
Description::
Public blockchains, like Bitcoin or NEM, allow anyone to join and set up a node to share and receive data.
However, many real-world business and financial uses require that those who can participate in a blockchain be restricted; these are called permissioned blockchains and Mijin provides this powerful functionality.
[http://mijin.io/en/about-mijin]
Name::
* cpt.bcnnet.public,
* cpt.public-bcnnet,
bcnnet.user.PUBLIC.NO
Description::
Public blockchains, like Bitcoin or NEM, allow anyone to join and set up a node to share and receive data.
However, many real-world business and financial uses require that those who can participate in a blockchain be restricted; these are called permissioned blockchains and Mijin provides this powerful functionality.
[http://mijin.io/en/about-mijin]
Name::
* cpt.bcnnet.publicNo,
* cpt.publicNo-bcnnet,
bcnnet.publicNo.Mijin
Description::
Mijin is being built by the NEM development team, using their proven experience and technological prowess.
Working with other developers at Tech Bureau, the NEM team is making Mijin the fastest and most secure blockchain platform in existence.
Rather than trusting other projects that are copies of bitcoin or source code that others wrote, it is important to use reliable, professionally developed software that is made by a unified team.
Mijin is currently the only platform in existence that fulfills this.
[http://mijin.io/en/about-mijin]
===
Public blockchain networks will always have an issue with bandwidth (max. no. of transactions per second). This is because of technical limitations derived from the node network synchronization throughout the large network. Maintaining a chain of many nodes with variation in connectivity and geographical distance in sync simply requires time.
Thus, in the opinion of NEM, the future lies in permissioned chains based on technologies like NEM and anchor these to the public chain - which means to embed hashes of e.g. every tenth private chain block into the public chain. That way immutability and certain public auditability can be achieved using private chain technology with its benefits without compromising public chain advantages.
Mijin is NEM's private chain project. It is built and licensed by the Japanese company Tech Bureau Corp., NEM's strategic partner for permissioned-chain implementations. Mijin is currently in the process of being future proofed as a new 4-tier architecture design. Codenamed Catapult, it is being implemented and written in C++. The current end-to-end prototype has been independently tested by third parties at over 4000 tx/s.
[https://blog.nem.io/nem-mijin-blockchain-technology-briefing-january-2017/]
===
[http://wiki.nem.io/index.php/Mijin]
Name::
* cpt.bcnMijin,
* cpt.bcnnet.Mijin,
* cpt.mijinnet,
* cpt.netMijin,
bcnnet.EVOLUTING (bcnevg)
Name::
* cpt.bcnevn,
* cpt.bcnnet.evoluting,
{time.2017-04-19}:
=== iEx.ec ICO:
French distributed cloud computing network iEx.ec has closed its ICO in just three hours, having raised its target of $12 mln.
... iEx joins a host of startups in the crypto space and further afield to have closed hugely successful crowd sale schemes well ahead of schedule.
Recent examples include the Digital Liquid Venture Fund, which earlier this month reached its $10 mln target in six hours. Humaniq and Matchpool also feature among 2017’s high flyers.
[https://cointelegraph.com/news/iexec-closes-worlds-5th-largest-ico-with-12-mln-in-6-hours]
{time.2013}:
=== COLORED-COINS:
Blockchain assets and colored coins approaches emerged around 2013, when several protocols utilizing Bitcoin’s blockchain were implemented.
[idWaveswpr21]
=== ALTCOINS:
Alt coins continued to proliferate in 2011 and 2012, either based on bitcoin or on Litecoin.By 2013, there were 20 alt coins vying for position in the market. By the end of 2013, this number had exploded to 200, with 2013 quickly becoming the "year of the alt coins." The growth of alt coins continued in 2014, with more than 500 alt coins in existence at the time of writing. More than half the alt coins today are clones of Litecoin.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
=== PROOF-OF-STAKE
In 2013, we saw the invention of an alternative to proof of work, called proof of stake, which forms the basis of many modern alt coins.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#consensus-innovation-peercoin-myriad-blackcoin-vericoin-nxt]
{time.2012-08}:
=== Peercoin
Peercoin was introduced in August 2012 and is the first alt coin to use a hybrid proof-of-work and proof-of-stake algorithm to issue new currency.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#peercoin]
{time.2011-09}:
=== script-proof-of-work:
In September 2011, Tenebrix was launched. Tenebrix was the first cryptocurrency to implement an alternative proof-of-work algorithm, namely scrypt, an algorithm originally designed for password stretching (brute-force resistance). The stated goal of Tenebrix was to make a coin that was resistant to mining with GPUs and ASICs, by using a memory-intensive algorithm. Tenebrix did not succeed as a currency, but it was the basis for Litecoin, which has enjoyed great success and has spawned hundreds of clones.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
{time.2011-08}:
=== first altcoin:
Based on the date of announcement, the first alt coin that was a fork of bitcoin appeared in August 2011; it was called IXCoin. IXCoin modified a few of the bitcoin parameters, specifically accelerating the creation of currency by increasing the reward to 96 coins per block.
[https://github.com/bitcoinbook/bitcoinbook/blob/first_edition/ch09.asciidoc#alt-coins]
{time.2010}:
=== name-registration-system:
Namecoin - created in 2010, Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash like 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Ideally, one would like to be able to have an account with a name like "george". However, the problem is that if one person can create an account named "george" then someone else can use the same process to register "george" for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registerer succeeds and the second fails - a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
{time.2009}:
=== after bitcoin:
After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
{time.2009-01-03 18:15:05}
=== Block#0: Bitcoin genesis block.
=== Block#1: {Timestamp 2009-01-09 02:54:25}
The first block the-network added.
[https://blockchain.info/block-height/1]
{time.2008-10-31}:
=== Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto White-Paper.
{time.2005}:
===
In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority", a document describing how "new advances in replicated database technology" will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice.
[https://github.com/ethereum/wiki/wiki/White-Paper#alternative-blockchain-applications]
bcnnet.HARDFORK (bcnhfk)
Description::
Protocol upgrades (formerly known as hard forks)
[http://docs.bitshares.eu/bitshares/user/you-should-know.html]
===
The basic difference between the two is that soft forks change the rules of a protocol by strictly reducing the set of transactions that is valid, so nodes following the old rules will still get on the new chain (provided that the majority of miners/validators implements the fork), whereas hard forks allow previously invalid transactions and blocks to become valid, so clients must upgrade their clients in order to stay on the hard-forked chain. There are also two sub-types of hard forks: strictly expanding hard forks, which strictly expand the set of transactions that is valid, and so effectively the old rules are a soft fork with respect to the new rules, and bilateral hard forks, where the two rulesets are incompatible both ways.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
Name::
* cpt.bcnhardfork,
* cpt.bcnnet.hardfork,
* cpt.hardbork-of-bcnnet,
bcnhardfork'Evaluation
Description::
The benefits commonly cited for the two are as follows.
- Hard forks allow the developers much more flexibility in making the protocol upgrade, as they do not have to take care to make sure that the new rules “fit into” the old rules
...
Aside from this, one major criticism often given for hard forks is that hard forks are “coercive”. The kind of coercion implied here is not physical force; rather, it’s coercion through network effect. That is, if the network changes rules from A to B, then even if you personally like A, if most other users like B and switch to B then you have to switch to B despite your personal disapproval of the change in order to be on the same network as everyone else.
Proponents of hard forks are often derided as trying to effect a “hostile take over” of a network, and “force” users to go along with them. Additionally, the risk of chain splits is often used to bill hard forks as “unsafe”.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
Name::
* cpt.bcnhardfork'evaluation,
bcnnet.SOFTFORK
Description::
The basic difference between the two is that soft forks change the rules of a protocol by strictly reducing the set of transactions that is valid, so nodes following the old rules will still get on the new chain (provided that the majority of miners/validators implements the fork), whereas hard forks allow previously invalid transactions and blocks to become valid, so clients must upgrade their clients in order to stay on the hard-forked chain.
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
Name::
* cpt.bcnnet.softfork,
* cpt.bcnsoftfork,
bcnsoftfork'Evaluation
Description::
The benefits commonly cited for the two are as follows.
- Soft forks are more convenient for users, as users do not need to upgrade to stay on the chain
- Soft forks are less likely to lead to a chain split
- Soft forks only really require consent from miners/validators (as even if users still use the old rules, if the nodes making the chain use the new rules then only things valid under the new rules will get into the chain in any case); hard forks require opt-in consent from users
[http://vitalik.ca/general/2017/03/14/forks_and_markets.html]
Name::
* cpt.bcnsoftfork'evaluation,
(eqn.1)
(eqn.2-3)
(eqn.4)
(eqn.5)
(eqn.6)
(eqn.7)
(eqn.8)
(eqn.9)
(eqn.10)
(eqn.11)
(eqn.12)
(eqn.13)
