diff --git a/Makefile b/Makefile index 4f99f1da..ebf2a872 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,7 @@ format: prettier isort black check: mypy checkprettier checkisort checkblack -prettier: $(shell find lnbits -name "*.js" -name ".html") +prettier: $(shell find lnbits -name "*.js" -o -name ".html") ./node_modules/.bin/prettier --write lnbits/static/js/*.js lnbits/core/static/js/*.js lnbits/extensions/*/templates/*/*.html ./lnbits/core/templates/core/*.html lnbits/templates/*.html lnbits/extensions/*/static/js/*.js lnbits/extensions/*/static/components/*/*.js lnbits/extensions/*/static/components/*/*.html black: @@ -18,7 +18,7 @@ mypy: isort: poetry run isort . -checkprettier: $(shell find lnbits -name "*.js" -name ".html") +checkprettier: $(shell find lnbits -name "*.js" -o -name ".html") ./node_modules/.bin/prettier --check lnbits/static/js/*.js lnbits/core/static/js/*.js lnbits/extensions/*/templates/*/*.html ./lnbits/core/templates/core/*.html lnbits/templates/*.html lnbits/extensions/*/static/js/*.js lnbits/extensions/*/static/components/*/*.js lnbits/extensions/*/static/components/*/*.html checkblack: diff --git a/flake.nix b/flake.nix index af25ba5c..d9f0f1f0 100644 --- a/flake.nix +++ b/flake.nix @@ -5,7 +5,7 @@ }; outputs = { self, nixpkgs, poetry2nix }@inputs: let - supportedSystems = [ "x86_64-linux" "aarch64-linux" ]; + supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ]; forSystems = systems: f: nixpkgs.lib.genAttrs systems (system: f system (import nixpkgs { inherit system; overlays = [ poetry2nix.overlay self.overlays.default ]; })); diff --git a/lnbits/bolt11.py b/lnbits/bolt11.py index 32b43feb..41b73b7d 100644 --- a/lnbits/bolt11.py +++ b/lnbits/bolt11.py @@ -1,7 +1,6 @@ import hashlib import re import time -from binascii import unhexlify from decimal import Decimal from typing import List, NamedTuple, Optional @@ -108,7 +107,7 @@ def decode(pr: str) -> Invoice: message = bytearray([ord(c) for c in hrp]) + data.tobytes() sig = signature[0:64] if invoice.payee: - key = VerifyingKey.from_string(unhexlify(invoice.payee), curve=SECP256k1) + key = VerifyingKey.from_string(bytes.fromhex(invoice.payee), curve=SECP256k1) key.verify(sig, message, hashlib.sha256, sigdecode=sigdecode_string) else: keys = VerifyingKey.from_public_key_recovery( @@ -131,7 +130,7 @@ def encode(options): if options["timestamp"]: addr.date = int(options["timestamp"]) - addr.paymenthash = unhexlify(options["paymenthash"]) + addr.paymenthash = bytes.fromhex(options["paymenthash"]) if options["description"]: addr.tags.append(("d", options["description"])) @@ -149,8 +148,8 @@ def encode(options): while len(splits) >= 5: route.append( ( - unhexlify(splits[0]), - unhexlify(splits[1]), + bytes.fromhex(splits[0]), + bytes.fromhex(splits[1]), int(splits[2]), int(splits[3]), int(splits[4]), @@ -235,7 +234,7 @@ def lnencode(addr, privkey): raise ValueError("Must include either 'd' or 'h'") # We actually sign the hrp, then data (padded to 8 bits with zeroes). - privkey = secp256k1.PrivateKey(bytes(unhexlify(privkey))) + privkey = secp256k1.PrivateKey(bytes.fromhex(privkey)) sig = privkey.ecdsa_sign_recoverable( bytearray([ord(c) for c in hrp]) + data.tobytes() ) @@ -261,7 +260,7 @@ class LnAddr(object): def __str__(self): return "LnAddr[{}, amount={}{} tags=[{}]]".format( - hexlify(self.pubkey.serialize()).decode("utf-8"), + bytes.hex(self.pubkey.serialize()).decode("utf-8"), self.amount, self.currency, ", ".join([k + "=" + str(v) for k, v in self.tags]), diff --git a/lnbits/core/crud.py b/lnbits/core/crud.py index 7d9f2a5b..a80fadf2 100644 --- a/lnbits/core/crud.py +++ b/lnbits/core/crud.py @@ -454,6 +454,7 @@ async def update_payment_details( async def update_payment_extra( payment_hash: str, extra: dict, + outgoing: bool = False, conn: Optional[Connection] = None, ) -> None: """ @@ -461,8 +462,10 @@ async def update_payment_extra( Old values in the `extra` JSON object will be kept unless the new `extra` overwrites them. """ + amount_clause = "AND amount < 0" if outgoing else "AND amount > 0" + row = await (conn or db).fetchone( - "SELECT hash, extra from apipayments WHERE hash = ?", + f"SELECT hash, extra from apipayments WHERE hash = ? {amount_clause}", (payment_hash,), ) if not row: @@ -471,10 +474,7 @@ async def update_payment_extra( db_extra.update(extra) await (conn or db).execute( - """ - UPDATE apipayments SET extra = ? - WHERE hash = ? - """, + f"UPDATE apipayments SET extra = ? WHERE hash = ? {amount_clause} ", (json.dumps(db_extra), payment_hash), ) diff --git a/lnbits/core/migrations.py b/lnbits/core/migrations.py index 81413246..41ba5644 100644 --- a/lnbits/core/migrations.py +++ b/lnbits/core/migrations.py @@ -224,7 +224,7 @@ async def m007_set_invoice_expiries(db): ) ).fetchall() if len(rows): - logger.info(f"Mirgraion: Checking expiry of {len(rows)} invoices") + logger.info(f"Migration: Checking expiry of {len(rows)} invoices") for i, ( payment_request, checking_id, @@ -238,7 +238,7 @@ async def m007_set_invoice_expiries(db): invoice.date + invoice.expiry ) logger.info( - f"Mirgraion: {i+1}/{len(rows)} setting expiry of invoice {invoice.payment_hash} to {expiration_date}" + f"Migration: {i+1}/{len(rows)} setting expiry of invoice {invoice.payment_hash} to {expiration_date}" ) await db.execute( """ diff --git a/lnbits/core/models.py b/lnbits/core/models.py index 65c72b41..138a39f7 100644 --- a/lnbits/core/models.py +++ b/lnbits/core/models.py @@ -4,13 +4,13 @@ import hmac import json import time from sqlite3 import Row -from typing import Dict, List, NamedTuple, Optional +from typing import Dict, List, Optional from ecdsa import SECP256k1, SigningKey # type: ignore from fastapi import Query from lnurl import encode as lnurl_encode # type: ignore from loguru import logger -from pydantic import BaseModel, Extra, validator +from pydantic import BaseModel from lnbits.db import Connection from lnbits.helpers import url_for diff --git a/lnbits/core/services.py b/lnbits/core/services.py index 336d2665..8dc973e7 100644 --- a/lnbits/core/services.py +++ b/lnbits/core/services.py @@ -1,6 +1,5 @@ import asyncio import json -from binascii import unhexlify from io import BytesIO from typing import Dict, List, Optional, Tuple from urllib.parse import parse_qs, urlparse @@ -13,12 +12,7 @@ from loguru import logger from lnbits import bolt11 from lnbits.db import Connection -from lnbits.decorators import ( - WalletTypeInfo, - get_key_type, - require_admin_key, - require_invoice_key, -) +from lnbits.decorators import WalletTypeInfo, require_admin_key from lnbits.helpers import url_for, urlsafe_short_hash from lnbits.requestvars import g from lnbits.settings import ( @@ -308,7 +302,7 @@ async def perform_lnurlauth( ) -> Optional[LnurlErrorResponse]: cb = urlparse(callback) - k1 = unhexlify(parse_qs(cb.query)["k1"][0]) + k1 = bytes.fromhex(parse_qs(cb.query)["k1"][0]) key = wallet.wallet.lnurlauth_key(cb.netloc) diff --git a/lnbits/core/tasks.py b/lnbits/core/tasks.py index b57e2625..e11f764b 100644 --- a/lnbits/core/tasks.py +++ b/lnbits/core/tasks.py @@ -4,7 +4,6 @@ from typing import Dict import httpx from loguru import logger -from lnbits.helpers import get_current_extension_name from lnbits.tasks import SseListenersDict, register_invoice_listener from . import db diff --git a/lnbits/core/templates/core/wallet.html b/lnbits/core/templates/core/wallet.html index e2edfdca..9de96956 100644 --- a/lnbits/core/templates/core/wallet.html +++ b/lnbits/core/templates/core/wallet.html @@ -231,7 +231,7 @@ @@ -325,7 +325,7 @@

@@ -524,7 +524,7 @@ diff --git a/lnbits/core/views/api.py b/lnbits/core/views/api.py index 2bd19978..1c67474f 100644 --- a/lnbits/core/views/api.py +++ b/lnbits/core/views/api.py @@ -1,5 +1,4 @@ import asyncio -import binascii import hashlib import json import time @@ -38,7 +37,7 @@ from lnbits.decorators import ( require_admin_key, require_invoice_key, ) -from lnbits.helpers import url_for, urlsafe_short_hash +from lnbits.helpers import url_for from lnbits.settings import get_wallet_class, settings from lnbits.utils.exchange_rates import ( currencies, @@ -48,14 +47,11 @@ from lnbits.utils.exchange_rates import ( from .. import core_app, db from ..crud import ( - create_payment, get_payments, get_standalone_payment, get_total_balance, - get_wallet, get_wallet_for_key, save_balance_check, - update_payment_status, update_wallet, ) from ..services import ( @@ -71,6 +67,11 @@ from ..services import ( from ..tasks import api_invoice_listeners +@core_app.get("/api/v1/health", status_code=HTTPStatus.OK) +async def health(): + return + + @core_app.get("/api/v1/wallet") async def api_wallet(wallet: WalletTypeInfo = Depends(get_key_type)): if wallet.wallet_type == 0: @@ -140,16 +141,14 @@ async def api_payments_create_invoice(data: CreateInvoiceData, wallet: Wallet): if data.description_hash or data.unhashed_description: try: description_hash = ( - binascii.unhexlify(data.description_hash) - if data.description_hash - else b"" + bytes.fromhex(data.description_hash) if data.description_hash else b"" ) unhashed_description = ( - binascii.unhexlify(data.unhashed_description) + bytes.fromhex(data.unhashed_description) if data.unhashed_description else b"" ) - except binascii.Error: + except ValueError: raise HTTPException( status_code=HTTPStatus.BAD_REQUEST, detail="'description_hash' and 'unhashed_description' must be a valid hex strings", @@ -659,7 +658,7 @@ async def img(request: Request, data): ) -@core_app.get("/api/v1/audit/", dependencies=[Depends(check_admin)]) +@core_app.get("/api/v1/audit", dependencies=[Depends(check_admin)]) async def api_auditor(): WALLET = get_wallet_class() total_balance = await get_total_balance() diff --git a/lnbits/core/views/generic.py b/lnbits/core/views/generic.py index 9df133b2..ed7b156d 100644 --- a/lnbits/core/views/generic.py +++ b/lnbits/core/views/generic.py @@ -38,7 +38,7 @@ async def favicon(): @core_html_routes.get("/", response_class=HTMLResponse) -async def home(request: Request, lightning: str = None): +async def home(request: Request, lightning: str = ""): return template_renderer().TemplateResponse( "core/index.html", {"request": request, "lnurl": lightning} ) @@ -124,12 +124,15 @@ async def wallet( if ( len(settings.lnbits_allowed_users) > 0 and user_id not in settings.lnbits_allowed_users + and user_id not in settings.lnbits_admin_users + and user_id != settings.super_user ): return template_renderer().TemplateResponse( "error.html", {"request": request, "err": "User not authorized."} ) if user_id == settings.super_user or user_id in settings.lnbits_admin_users: user.admin = True + if not wallet_id: if user.wallets and not wallet_name: # type: ignore wallet = user.wallets[0] # type: ignore diff --git a/lnbits/core/views/public_api.py b/lnbits/core/views/public_api.py index 9b0ebc98..56afc176 100644 --- a/lnbits/core/views/public_api.py +++ b/lnbits/core/views/public_api.py @@ -6,7 +6,6 @@ from urllib.parse import urlparse from fastapi import HTTPException from loguru import logger from starlette.requests import Request -from starlette.responses import HTMLResponse from lnbits import bolt11 diff --git a/lnbits/decorators.py b/lnbits/decorators.py index e5bc1399..9aeace40 100644 --- a/lnbits/decorators.py +++ b/lnbits/decorators.py @@ -236,8 +236,8 @@ async def check_user_exists(usr: UUID4) -> User: if ( len(settings.lnbits_allowed_users) > 0 and g().user.id not in settings.lnbits_allowed_users - and g().user.id != settings.super_user and g().user.id not in settings.lnbits_admin_users + and g().user.id != settings.super_user ): raise HTTPException( status_code=HTTPStatus.UNAUTHORIZED, detail="User not authorized." diff --git a/lnbits/extensions/bleskomat/helpers.py b/lnbits/extensions/bleskomat/helpers.py index 6e55b3df..cec7434d 100644 --- a/lnbits/extensions/bleskomat/helpers.py +++ b/lnbits/extensions/bleskomat/helpers.py @@ -2,7 +2,6 @@ import base64 import hashlib import hmac import urllib -from binascii import unhexlify from http import HTTPStatus from typing import Dict @@ -19,7 +18,7 @@ def generate_bleskomat_lnurl_signature( payload: str, api_key_secret: str, api_key_encoding: str = "hex" ): if api_key_encoding == "hex": - key = unhexlify(api_key_secret) + key = bytes.fromhex(api_key_secret) elif api_key_encoding == "base64": key = base64.b64decode(api_key_secret) else: diff --git a/lnbits/extensions/bleskomat/templates/bleskomat/_api_docs.html b/lnbits/extensions/bleskomat/templates/bleskomat/_api_docs.html index 2a7160bd..5bbd826e 100644 --- a/lnbits/extensions/bleskomat/templates/bleskomat/_api_docs.html +++ b/lnbits/extensions/bleskomat/templates/bleskomat/_api_docs.html @@ -9,11 +9,13 @@

This extension allows you to connect a Bleskomat ATM to an lnbits wallet. It will work with both the - open-source DIY Bleskomat ATM project as well as the - commercial Bleskomat ATM. + commercial Bleskomat ATM.

Connect Your Bleskomat ATM
diff --git a/lnbits/extensions/boltcards/README.md b/lnbits/extensions/boltcards/README.md index 34a1c05c..93457066 100644 --- a/lnbits/extensions/boltcards/README.md +++ b/lnbits/extensions/boltcards/README.md @@ -2,7 +2,7 @@ This extension allows you to link your Bolt Card (or other compatible NXP NTAG device) with a LNbits instance and use it in a more secure way than a static LNURLw. A technology called [Secure Unique NFC](https://mishka-scan.com/blog/secure-unique-nfc) is utilized in this workflow. -Tutorial +Tutorial **Disclaimer:** ***Use this only if you either know what you are doing or are a reckless lightning pioneer. Only you are responsible for all your sats, cards and other devices. Always backup all your card keys!*** @@ -55,6 +55,8 @@ Since v0.1.2 of Boltcard NFC Card Creator it is possible not only reset the keys - Click RESET CARD NOW and approach the NFC card to erase it. DO NOT REMOVE THE CARD PREMATURELY! - Now if there is all success the card can be safely delete from LNbits (but keep the keys backuped anyway; batter safe than brick). +If you somehow find yourself in some non-standard state (for instance only k3 and k4 remains filled after previous unsuccessful reset), then you need edit the key fields manually (for instance leave k0-k2 to zeroes and provide the right k3 and k4). + ## Setting the card - computer (hard way) Follow the guide. diff --git a/lnbits/extensions/boltcards/templates/boltcards/_api_docs.html b/lnbits/extensions/boltcards/templates/boltcards/_api_docs.html index be4e2ae8..ec5ed575 100644 --- a/lnbits/extensions/boltcards/templates/boltcards/_api_docs.html +++ b/lnbits/extensions/boltcards/templates/boltcards/_api_docs.html @@ -11,6 +11,7 @@ Manage your Bolt Cards self custodian way
More details diff --git a/lnbits/extensions/boltcards/templates/boltcards/index.html b/lnbits/extensions/boltcards/templates/boltcards/index.html index f401112b..2091718c 100644 --- a/lnbits/extensions/boltcards/templates/boltcards/index.html +++ b/lnbits/extensions/boltcards/templates/boltcards/index.html @@ -375,6 +375,7 @@

(QR for create the card in (QR for wipe the card in SubmarineSwap: raise refund_privkey = ec.PrivateKey(os.urandom(32), True, net) - refund_pubkey_hex = hexlify(refund_privkey.sec()).decode("UTF-8") + refund_pubkey_hex = bytes.hex(refund_privkey.sec()).decode("UTF-8") res = req_wrap( "post", @@ -121,7 +120,7 @@ async def create_reverse_swap( return False claim_privkey = ec.PrivateKey(os.urandom(32), True, net) - claim_pubkey_hex = hexlify(claim_privkey.sec()).decode("UTF-8") + claim_pubkey_hex = bytes.hex(claim_privkey.sec()).decode("UTF-8") preimage = os.urandom(32) preimage_hash = sha256(preimage).hexdigest() @@ -311,12 +310,12 @@ async def create_onchain_tx( sequence = 0xFFFFFFFE else: privkey = ec.PrivateKey.from_wif(swap.claim_privkey) - preimage = unhexlify(swap.preimage) + preimage = bytes.fromhex(swap.preimage) onchain_address = swap.onchain_address sequence = 0xFFFFFFFF locktime = swap.timeout_block_height - redeem_script = unhexlify(swap.redeem_script) + redeem_script = bytes.fromhex(swap.redeem_script) fees = get_fee_estimation() @@ -324,7 +323,7 @@ async def create_onchain_tx( script_pubkey = script.address_to_scriptpubkey(onchain_address) - vin = [TransactionInput(unhexlify(txid), vout_cnt, sequence=sequence)] + vin = [TransactionInput(bytes.fromhex(txid), vout_cnt, sequence=sequence)] vout = [TransactionOutput(vout_amount - fees, script_pubkey)] tx = Transaction(vin=vin, vout=vout) diff --git a/lnbits/extensions/boltz/mempool.py b/lnbits/extensions/boltz/mempool.py index a64cadad..c7d572a9 100644 --- a/lnbits/extensions/boltz/mempool.py +++ b/lnbits/extensions/boltz/mempool.py @@ -1,6 +1,5 @@ import asyncio import json -from binascii import hexlify import httpx import websockets @@ -84,7 +83,7 @@ def get_mempool_blockheight() -> int: async def send_onchain_tx(tx: Transaction): - raw = hexlify(tx.serialize()) + raw = bytes.hex(tx.serialize()) logger.debug(f"Boltz - mempool sending onchain tx...") req_wrap( "post", diff --git a/lnbits/extensions/boltz/templates/boltz/_api_docs.html b/lnbits/extensions/boltz/templates/boltz/_api_docs.html index eea35ab6..0edc413a 100644 --- a/lnbits/extensions/boltz/templates/boltz/_api_docs.html +++ b/lnbits/extensions/boltz/templates/boltz/_api_docs.html @@ -24,12 +24,13 @@

Link : - https://boltz.exchange

More details Created by, - dnidni

diff --git a/lnbits/extensions/cashu/crud.py b/lnbits/extensions/cashu/crud.py index 773a11fd..23f808c1 100644 --- a/lnbits/extensions/cashu/crud.py +++ b/lnbits/extensions/cashu/crud.py @@ -1,7 +1,6 @@ import os import random import time -from binascii import hexlify, unhexlify from typing import Any, List, Optional, Union from cashu.core.base import MintKeyset diff --git a/lnbits/extensions/cashu/templates/cashu/_cashu.html b/lnbits/extensions/cashu/templates/cashu/_cashu.html index 952fe7e1..370e9eb4 100644 --- a/lnbits/extensions/cashu/templates/cashu/_cashu.html +++ b/lnbits/extensions/cashu/templates/cashu/_cashu.html @@ -4,9 +4,24 @@

Create Cashu ecash mints and wallets.

Created by - arcbtc, - vlad, - calle.arcbtc, + vlad, + calle. diff --git a/lnbits/extensions/cashu/templates/cashu/mint.html b/lnbits/extensions/cashu/templates/cashu/mint.html index ee6ab606..bcb919ff 100644 --- a/lnbits/extensions/cashu/templates/cashu/mint.html +++ b/lnbits/extensions/cashu/templates/cashu/mint.html @@ -11,6 +11,7 @@ >

{{ mint_name }}

Read the following carefully!

This is a - Cashu mint. Cashu is an ecash system for Bitcoin. diff --git a/lnbits/extensions/cashu/templates/cashu/wallet.html b/lnbits/extensions/cashu/templates/cashu/wallet.html index 88dffe7c..d075009e 100644 --- a/lnbits/extensions/cashu/templates/cashu/wallet.html +++ b/lnbits/extensions/cashu/templates/cashu/wallet.html @@ -159,7 +159,7 @@ page_container %} size="lg" color="secondary" class="q-mr-md cursor-pointer" - @click="recheckInvoice(props.row.hash)" + @click="checkInvoice(props.row.hash)" > Check @@ -616,10 +616,10 @@ page_container %} >

- + @@ -681,7 +681,7 @@ page_container %}
- + (s += t.amount), 0) }, + deleteProofs: function (proofs) { + // delete proofs from this.proofs + const usedSecrets = proofs.map(p => p.secret) + this.proofs = this.proofs.filter(p => !usedSecrets.includes(p.secret)) + this.storeProofs() + return this.proofs + }, + //////////// API /////////// - clearAllWorkers: function () { - if (this.invoiceCheckListener) { - clearInterval(this.invoiceCheckListener) - } - if (this.tokensCheckSpendableListener) { - clearInterval(this.tokensCheckSpendableListener) - } - }, - invoiceCheckWorker: async function () { - let nInterval = 0 - this.clearAllWorkers() - this.invoiceCheckListener = setInterval(async () => { - try { - nInterval += 1 - // exit loop after 2m - if (nInterval > 40) { - console.log('### stopping invoice check worker') - this.clearAllWorkers() - } - console.log('### invoiceCheckWorker setInterval', nInterval) - console.log(this.invoiceData) - - // this will throw an error if the invoice is pending - await this.recheckInvoice(this.invoiceData.hash, false) - - // only without error (invoice paid) will we reach here - console.log('### stopping invoice check worker') - this.clearAllWorkers() - this.invoiceData.bolt11 = '' - this.showInvoiceDetails = false - if (window.navigator.vibrate) navigator.vibrate(200) - this.$q.notify({ - timeout: 5000, - type: 'positive', - message: 'Payment received', - position: 'top', - actions: [ - { - icon: 'close', - color: 'white', - handler: () => {} - } - ] - }) - } catch (error) { - console.log('not paid yet') - } - }, 3000) - }, + // MINT requestMintButton: async function () { await this.requestMint() @@ -1586,8 +1546,12 @@ page_container %} await this.invoiceCheckWorker() }, + // /mint + requestMint: async function () { - // gets an invoice from the mint to get new tokens + /* + gets an invoice from the mint to get new tokens + */ try { const {data} = await LNbits.api.request( 'GET', @@ -1611,7 +1575,14 @@ page_container %} throw error } }, + + // /mint + mintApi: async function (amounts, payment_hash, verbose = true) { + /* + asks the mint to check whether the invoice with payment_hash has been paid + and requests signing of the attached outputs (blindedMessages) + */ console.log('### promises', payment_hash) try { let secrets = await this.generateSecrets(amounts) @@ -1647,7 +1618,19 @@ page_container %} } this.proofs = this.proofs.concat(proofs) this.storeProofs() + + // update UI await this.setInvoicePaid(payment_hash) + tokensBase64 = btoa(JSON.stringify(proofs)) + + this.historyTokens.push({ + status: 'paid', + amount: amount, + date: currentDateStr(), + token: tokensBase64 + }) + this.storehistoryTokens() + return proofs } catch (error) { console.error(error) @@ -1657,62 +1640,20 @@ page_container %} throw error } }, - splitToSend: async function (proofs, amount, invlalidate = false) { - // splits proofs so the user can keep firstProofs, send scndProofs - try { - const spendableProofs = proofs.filter(p => !p.reserved) - if (this.sumProofs(spendableProofs) < amount) { - this.$q.notify({ - timeout: 5000, - type: 'warning', - message: 'Balance too low', - position: 'top', - actions: [ - { - icon: 'close', - color: 'white', - handler: () => {} - } - ] - }) - throw Error('balance too low.') - } - let {fristProofs, scndProofs} = await this.split( - spendableProofs, - amount - ) - // set scndProofs in this.proofs as reserved - const usedSecrets = proofs.map(p => p.secret) - for (let i = 0; i < this.proofs.length; i++) { - if (usedSecrets.includes(this.proofs[i].secret)) { - this.proofs[i].reserved = true - } - } - if (invlalidate) { - // delete tokens from db - this.proofs = fristProofs - // add new fristProofs, scndProofs to this.proofs - this.storeProofs() - } - - return {fristProofs, scndProofs} - } catch (error) { - console.error(error) - LNbits.utils.notifyApiError(error) - throw error - } - }, + // SPLIT split: async function (proofs, amount) { + /* + supplies proofs and requests a split from the mint of these + proofs at a specific amount + */ try { if (proofs.length == 0) { throw new Error('no proofs provided.') } let {fristProofs, scndProofs} = await this.splitApi(proofs, amount) - // delete proofs from this.proofs - const usedSecrets = proofs.map(p => p.secret) - this.proofs = this.proofs.filter(p => !usedSecrets.includes(p.secret)) + this.deleteProofs(proofs) // add new fristProofs, scndProofs to this.proofs this.proofs = this.proofs.concat(fristProofs).concat(scndProofs) this.storeProofs() @@ -1723,6 +1664,9 @@ page_container %} throw error } }, + + // /split + splitApi: async function (proofs, amount) { try { const total = this.sumProofs(proofs) @@ -1782,7 +1726,62 @@ page_container %} } }, + splitToSend: async function (proofs, amount, invlalidate = false) { + /* + splits proofs so the user can keep firstProofs, send scndProofs. + then sets scndProofs as reserved. + + if invalidate, scndProofs (the one to send) are invalidated + */ + try { + const spendableProofs = proofs.filter(p => !p.reserved) + if (this.sumProofs(spendableProofs) < amount) { + this.$q.notify({ + timeout: 5000, + type: 'warning', + message: 'Balance too low', + position: 'top', + actions: [ + { + icon: 'close', + color: 'white', + handler: () => {} + } + ] + }) + throw Error('balance too low.') + } + + // call /split + + let {fristProofs, scndProofs} = await this.split( + spendableProofs, + amount + ) + // set scndProofs in this.proofs as reserved + const usedSecrets = proofs.map(p => p.secret) + for (let i = 0; i < this.proofs.length; i++) { + if (usedSecrets.includes(this.proofs[i].secret)) { + this.proofs[i].reserved = true + } + } + if (invlalidate) { + // delete scndProofs from db + this.deleteProofs(scndProofs) + } + + return {fristProofs, scndProofs} + } catch (error) { + console.error(error) + LNbits.utils.notifyApiError(error) + throw error + } + }, + redeem: async function () { + /* + uses split to receive new tokens. + */ this.showReceiveTokens = false console.log('### receive tokens', this.receiveData.tokensBase64) try { @@ -1793,6 +1792,9 @@ page_container %} const proofs = JSON.parse(tokenJson) const amount = proofs.reduce((s, t) => (s += t.amount), 0) let {fristProofs, scndProofs} = await this.split(proofs, amount) + + // update UI + // HACK: we need to do this so the balance updates this.proofs = this.proofs.concat([]) @@ -1827,13 +1829,18 @@ page_container %} }, sendTokens: async function () { + /* + calls splitToSend, displays token and kicks off the spendableWorker + */ try { - // keep firstProofs, send scndProofs + // keep firstProofs, send scndProofs and delete them (invalidate=true) let {fristProofs, scndProofs} = await this.splitToSend( this.proofs, this.sendData.amount, true ) + + // update UI this.sendData.tokens = scndProofs console.log('### this.sendData.tokens', this.sendData.tokens) this.sendData.tokensBase64 = btoa( @@ -1846,33 +1853,19 @@ page_container %} date: currentDateStr(), token: this.sendData.tokensBase64 }) + + // store "pending" outgoing tokens in history table this.storehistoryTokens() + this.checkTokenSpendableWorker() } catch (error) { console.error(error) throw error } }, - checkFees: async function (payment_request) { - const payload = { - pr: payment_request - } - console.log('#### payload', JSON.stringify(payload)) - try { - const {data} = await LNbits.api.request( - 'POST', - `/cashu/api/v1/${this.mintId}/checkfees`, - '', - payload - ) - console.log('#### checkFees', payment_request, data.fee) - return data.fee - } catch (error) { - console.error(error) - LNbits.utils.notifyApiError(error) - throw error - } - }, + + // /melt + melt: async function () { // todo: get fees from server and add to inputs this.payInvoiceData.blocking = true @@ -1924,8 +1917,20 @@ page_container %} ] }) // delete spent tokens from db - this.proofs = fristProofs - this.storeProofs() + this.deleteProofs(scndProofs) + + // update UI + + tokensBase64 = btoa(JSON.stringify(scndProofs)) + + this.historyTokens.push({ + status: 'paid', + amount: -amount, + date: currentDateStr(), + token: tokensBase64 + }) + this.storehistoryTokens() + console.log({ amount: -amount, bolt11: this.payInvoiceData.data.request, @@ -1953,13 +1958,95 @@ page_container %} throw error } }, + + // /check + + checkProofsSpendable: async function (proofs, update_history = false) { + /* + checks with the mint whether an array of proofs is still + spendable or already invalidated + */ + const payload = { + proofs: proofs.flat() + } + console.log('#### payload', JSON.stringify(payload)) + try { + const {data} = await LNbits.api.request( + 'POST', + `/cashu/api/v1/${this.mintId}/check`, + '', + payload + ) + + // delete proofs from database if it is spent + let spentProofs = proofs.filter((p, pidx) => !data[pidx]) + if (spentProofs.length) { + this.deleteProofs(spentProofs) + + // update UI + if (update_history) { + tokensBase64 = btoa(JSON.stringify(spentProofs)) + + this.historyTokens.push({ + status: 'paid', + amount: -this.sumProofs(spentProofs), + date: currentDateStr(), + token: tokensBase64 + }) + this.storehistoryTokens() + } + } + + return data + } catch (error) { + console.error(error) + LNbits.utils.notifyApiError(error) + throw error + } + }, + + // /checkfees + checkFees: async function (payment_request) { + const payload = { + pr: payment_request + } + console.log('#### payload', JSON.stringify(payload)) + try { + const {data} = await LNbits.api.request( + 'POST', + `/cashu/api/v1/${this.mintId}/checkfees`, + '', + payload + ) + console.log('#### checkFees', payment_request, data.fee) + return data.fee + } catch (error) { + console.error(error) + LNbits.utils.notifyApiError(error) + throw error + } + }, + + // /keys + + fetchMintKeys: async function () { + const {data} = await LNbits.api.request( + 'GET', + `/cashu/api/v1/${this.mintId}/keys` + ) + this.keys = data + localStorage.setItem( + this.mintKey(this.mintId, 'keys'), + JSON.stringify(data) + ) + }, setInvoicePaid: async function (payment_hash) { const invoice = this.invoicesCashu.find(i => i.hash === payment_hash) invoice.status = 'paid' this.storeinvoicesCashu() }, - recheckInvoice: async function (payment_hash, verbose = true) { - console.log('### recheckInvoice.hash', payment_hash) + checkInvoice: async function (payment_hash, verbose = true) { + console.log('### checkInvoice.hash', payment_hash) const invoice = this.invoicesCashu.find(i => i.hash === payment_hash) try { proofs = await this.mint(invoice.amount, invoice.hash, verbose) @@ -1969,15 +2056,15 @@ page_container %} throw error } }, - recheckPendingInvoices: async function () { + checkPendingInvoices: async function () { for (const invoice of this.invoicesCashu) { - if (invoice.status === 'pending' && invoice.sat > 0) { - this.recheckInvoice(invoice.hash, false) + if (invoice.status === 'pending' && invoice.amount > 0) { + this.checkInvoice(invoice.hash, false) } } }, - recheckPendingTokens: async function () { + checkPendingTokens: async function () { for (const token of this.historyTokens) { if (token.status === 'pending' && token.amount < 0) { this.checkTokenSpendable(token.token, false) @@ -1990,6 +2077,113 @@ page_container %} this.storehistoryTokens() }, + checkTokenSpendable: async function (token, verbose = true) { + /* + checks whether a base64-encoded token (from the history table) has been spent already. + if it is spent, the appropraite entry in the history table is set to paid. + */ + const tokenJson = atob(token) + const proofs = JSON.parse(tokenJson) + let data = await this.checkProofsSpendable(proofs) + + // iterate through response of form {0: true, 1: false, ...} + let paid = false + for (const [key, spendable] of Object.entries(data)) { + if (!spendable) { + this.setTokenPaid(token) + paid = true + } + } + if (paid) { + console.log('### token paid') + if (window.navigator.vibrate) navigator.vibrate(200) + this.$q.notify({ + timeout: 5000, + type: 'positive', + message: 'Token paid', + position: 'top', + actions: [ + { + icon: 'close', + color: 'white', + handler: () => {} + } + ] + }) + } else { + console.log('### token not paid yet') + if (verbose) { + this.$q.notify({ + timeout: 5000, + color: 'grey', + message: 'Token still pending', + position: 'top', + actions: [ + { + icon: 'close', + color: 'white', + handler: () => {} + } + ] + }) + } + this.sendData.tokens = token + } + return paid + }, + + ////////////// WORKERS ////////////// + + clearAllWorkers: function () { + if (this.invoiceCheckListener) { + clearInterval(this.invoiceCheckListener) + } + if (this.tokensCheckSpendableListener) { + clearInterval(this.tokensCheckSpendableListener) + } + }, + invoiceCheckWorker: async function () { + let nInterval = 0 + this.clearAllWorkers() + this.invoiceCheckListener = setInterval(async () => { + try { + nInterval += 1 + + // exit loop after 2m + if (nInterval > 40) { + console.log('### stopping invoice check worker') + this.clearAllWorkers() + } + console.log('### invoiceCheckWorker setInterval', nInterval) + console.log(this.invoiceData) + + // this will throw an error if the invoice is pending + await this.checkInvoice(this.invoiceData.hash, false) + + // only without error (invoice paid) will we reach here + console.log('### stopping invoice check worker') + this.clearAllWorkers() + this.invoiceData.bolt11 = '' + this.showInvoiceDetails = false + if (window.navigator.vibrate) navigator.vibrate(200) + this.$q.notify({ + timeout: 5000, + type: 'positive', + message: 'Payment received', + position: 'top', + actions: [ + { + icon: 'close', + color: 'white', + handler: () => {} + } + ] + }) + } catch (error) { + console.log('not paid yet') + } + }, 3000) + }, checkTokenSpendableWorker: async function () { let nInterval = 0 this.clearAllWorkers() @@ -2021,83 +2215,6 @@ page_container %} }, 3000) }, - checkTokenSpendable: async function (token, verbose = true) { - const tokenJson = atob(token) - const proofs = JSON.parse(tokenJson) - const payload = { - proofs: proofs.flat() - } - console.log('#### payload', JSON.stringify(payload)) - try { - const {data} = await LNbits.api.request( - 'POST', - `/cashu/api/v1/${this.mintId}/check`, - '', - payload - ) - // iterate through response of form {0: true, 1: false, ...} - let paid = false - for (const [key, spendable] of Object.entries(data)) { - if (!spendable) { - this.setTokenPaid(token) - paid = true - } - } - if (paid) { - console.log('### token paid') - if (window.navigator.vibrate) navigator.vibrate(200) - this.$q.notify({ - timeout: 5000, - type: 'positive', - message: 'Token paid', - position: 'top', - actions: [ - { - icon: 'close', - color: 'white', - handler: () => {} - } - ] - }) - } else { - console.log('### token not paid yet') - if (verbose) { - this.$q.notify({ - timeout: 5000, - color: 'grey', - message: 'Token still pending', - position: 'top', - actions: [ - { - icon: 'close', - color: 'white', - handler: () => {} - } - ] - }) - } - this.sendData.tokens = token - } - return paid - } catch (error) { - console.error(error) - LNbits.utils.notifyApiError(error) - throw error - } - }, - - fetchMintKeys: async function () { - const {data} = await LNbits.api.request( - 'GET', - `/cashu/api/v1/${this.mintId}/keys` - ) - this.keys = data - localStorage.setItem( - this.mintKey(this.mintId, 'keys'), - JSON.stringify(data) - ) - }, - //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// @@ -2116,62 +2233,62 @@ page_container %} } }, - checkInvoice: function () { - console.log('#### checkInvoice') - try { - const invoice = decode(this.payInvoiceData.data.request) + // checkInvoice: function () { + // console.log('#### checkInvoice') + // try { + // const invoice = decode(this.payInvoiceData.data.request) - const cleanInvoice = { - msat: invoice.human_readable_part.amount, - sat: invoice.human_readable_part.amount / 1000, - fsat: LNbits.utils.formatSat( - invoice.human_readable_part.amount / 1000 - ) - } + // const cleanInvoice = { + // msat: invoice.human_readable_part.amount, + // sat: invoice.human_readable_part.amount / 1000, + // fsat: LNbits.utils.formatSat( + // invoice.human_readable_part.amount / 1000 + // ) + // } - _.each(invoice.data.tags, tag => { - if (_.isObject(tag) && _.has(tag, 'description')) { - if (tag.description === 'payment_hash') { - cleanInvoice.hash = tag.value - } else if (tag.description === 'description') { - cleanInvoice.description = tag.value - } else if (tag.description === 'expiry') { - var expireDate = new Date( - (invoice.data.time_stamp + tag.value) * 1000 - ) - cleanInvoice.expireDate = Quasar.utils.date.formatDate( - expireDate, - 'YYYY-MM-DDTHH:mm:ss.SSSZ' - ) - cleanInvoice.expired = false // TODO - } - } + // _.each(invoice.data.tags, tag => { + // if (_.isObject(tag) && _.has(tag, 'description')) { + // if (tag.description === 'payment_hash') { + // cleanInvoice.hash = tag.value + // } else if (tag.description === 'description') { + // cleanInvoice.description = tag.value + // } else if (tag.description === 'expiry') { + // var expireDate = new Date( + // (invoice.data.time_stamp + tag.value) * 1000 + // ) + // cleanInvoice.expireDate = Quasar.utils.date.formatDate( + // expireDate, + // 'YYYY-MM-DDTHH:mm:ss.SSSZ' + // ) + // cleanInvoice.expired = false // TODO + // } + // } - this.payInvoiceData.invoice = cleanInvoice - }) + // this.payInvoiceData.invoice = cleanInvoice + // }) - console.log( - '#### this.payInvoiceData.invoice', - this.payInvoiceData.invoice - ) - } catch (error) { - this.$q.notify({ - timeout: 5000, - type: 'warning', - message: 'Could not decode invoice', - caption: error + '', - position: 'top', - actions: [ - { - icon: 'close', - color: 'white', - handler: () => {} - } - ] - }) - throw error - } - }, + // console.log( + // '#### this.payInvoiceData.invoice', + // this.payInvoiceData.invoice + // ) + // } catch (error) { + // this.$q.notify({ + // timeout: 5000, + // type: 'warning', + // message: 'Could not decode invoice', + // caption: error + '', + // position: 'top', + // actions: [ + // { + // icon: 'close', + // color: 'white', + // handler: () => {} + // } + // ] + // }) + // throw error + // } + // }, ////////////// STORAGE ///////////// @@ -2335,8 +2452,9 @@ page_container %} console.log('#### this.mintId', this.mintId) console.log('#### this.mintName', this.mintName) - this.recheckPendingInvoices() - this.recheckPendingTokens() + this.checkProofsSpendable(this.proofs, true) + this.checkPendingInvoices() + this.checkPendingTokens() } }) diff --git a/lnbits/extensions/cashu/views_api.py b/lnbits/extensions/cashu/views_api.py index 2d10f3f0..def9074f 100644 --- a/lnbits/extensions/cashu/views_api.py +++ b/lnbits/extensions/cashu/views_api.py @@ -46,9 +46,16 @@ from .models import Cashu # --------- extension imports +# WARNING: Do not set this to False in production! This will create +# tokens for free otherwise. This is for testing purposes only! LIGHTNING = True +if not LIGHTNING: + logger.warning( + "Cashu: LIGHTNING is set False! That means that I will create ecash for free!" + ) + ######################################## ############### LNBITS MINTS ########### ######################################## @@ -130,6 +137,28 @@ async def keys(cashu_id: str = Query(None)) -> dict[int, str]: return ledger.get_keyset(keyset_id=cashu.keyset_id) +@cashu_ext.get("/api/v1/{cashu_id}/keys/{idBase64Urlsafe}") +async def keyset_keys( + cashu_id: str = Query(None), idBase64Urlsafe: str = Query(None) +) -> dict[int, str]: + """ + Get the public keys of the mint of a specificy keyset id. + The id is encoded in base64_urlsafe and needs to be converted back to + normal base64 before it can be processed. + """ + + cashu: Union[Cashu, None] = await get_cashu(cashu_id) + + if not cashu: + raise HTTPException( + status_code=HTTPStatus.NOT_FOUND, detail="Mint does not exist." + ) + + id = idBase64Urlsafe.replace("-", "+").replace("_", "/") + keyset = ledger.get_keyset(keyset_id=id) + return keyset + + @cashu_ext.get("/api/v1/{cashu_id}/keysets", status_code=HTTPStatus.OK) async def keysets(cashu_id: str = Query(None)) -> dict[str, list[str]]: """Get the public keys of the mint""" @@ -182,7 +211,7 @@ async def request_mint(cashu_id: str = Query(None), amount: int = 0) -> GetMintR @cashu_ext.post("/api/v1/{cashu_id}/mint") -async def mint_coins( +async def mint( data: MintRequest, cashu_id: str = Query(None), payment_hash: str = Query(None), @@ -197,6 +226,8 @@ async def mint_coins( status_code=HTTPStatus.NOT_FOUND, detail="Mint does not exist." ) + keyset = ledger.keysets.keysets[cashu.keyset_id] + if LIGHTNING: invoice: Invoice = await ledger.crud.get_lightning_invoice( db=ledger.db, hash=payment_hash @@ -206,42 +237,55 @@ async def mint_coins( status_code=HTTPStatus.NOT_FOUND, detail="Mint does not know this invoice.", ) - if invoice.issued == True: + if invoice.issued: raise HTTPException( status_code=HTTPStatus.PAYMENT_REQUIRED, detail="Tokens already issued for this invoice.", ) - total_requested = sum([bm.amount for bm in data.blinded_messages]) - if total_requested > invoice.amount: - raise HTTPException( - status_code=HTTPStatus.PAYMENT_REQUIRED, - detail=f"Requested amount too high: {total_requested}. Invoice amount: {invoice.amount}", - ) - - status: PaymentStatus = await check_transaction_status(cashu.wallet, payment_hash) - - if LIGHTNING and status.paid != True: - raise HTTPException( - status_code=HTTPStatus.PAYMENT_REQUIRED, detail="Invoice not paid." - ) - try: - keyset = ledger.keysets.keysets[cashu.keyset_id] - - promises = await ledger._generate_promises( - B_s=data.blinded_messages, keyset=keyset - ) - assert len(promises), HTTPException( - status_code=HTTPStatus.INTERNAL_SERVER_ERROR, detail="No promises returned." - ) + # set this invoice as issued await ledger.crud.update_lightning_invoice( db=ledger.db, hash=payment_hash, issued=True ) + status: PaymentStatus = await check_transaction_status( + cashu.wallet, payment_hash + ) + + try: + total_requested = sum([bm.amount for bm in data.blinded_messages]) + if total_requested > invoice.amount: + raise HTTPException( + status_code=HTTPStatus.PAYMENT_REQUIRED, + detail=f"Requested amount too high: {total_requested}. Invoice amount: {invoice.amount}", + ) + + if not status.paid: + raise HTTPException( + status_code=HTTPStatus.PAYMENT_REQUIRED, detail="Invoice not paid." + ) + + promises = await ledger._generate_promises( + B_s=data.blinded_messages, keyset=keyset + ) + return promises + except (Exception, HTTPException) as e: + logger.debug(f"Cashu: /melt {str(e) or getattr(e, 'detail')}") + # unset issued flag because something went wrong + await ledger.crud.update_lightning_invoice( + db=ledger.db, hash=payment_hash, issued=False + ) + raise HTTPException( + status_code=getattr(e, "status_code") + or HTTPStatus.INTERNAL_SERVER_ERROR, + detail=str(e) or getattr(e, "detail"), + ) + else: + # only used for testing when LIGHTNING=false + promises = await ledger._generate_promises( + B_s=data.blinded_messages, keyset=keyset + ) return promises - except Exception as e: - logger.error(e) - raise HTTPException(status_code=HTTPStatus.INTERNAL_SERVER_ERROR, detail=str(e)) @cashu_ext.post("/api/v1/{cashu_id}/melt") @@ -285,28 +329,38 @@ async def melt_coins( f"Provided proofs ({total_provided} sats) not enough for Lightning payment ({amount + fees_msat} sats)." ) logger.debug(f"Cashu: Initiating payment of {total_provided} sats") - await pay_invoice( - wallet_id=cashu.wallet, - payment_request=invoice, - description=f"Pay cashu invoice", - extra={"tag": "cashu", "cashu_name": cashu.name}, - ) - - logger.debug( - f"Cashu: Wallet {cashu.wallet} checking PaymentStatus of {invoice_obj.payment_hash}" - ) - status: PaymentStatus = await check_transaction_status( - cashu.wallet, invoice_obj.payment_hash - ) - if status.paid == True: - logger.debug("Cashu: Payment successful, invalidating proofs") - await ledger._invalidate_proofs(proofs) + try: + await pay_invoice( + wallet_id=cashu.wallet, + payment_request=invoice, + description=f"Pay cashu invoice", + extra={"tag": "cashu", "cashu_name": cashu.name}, + ) + except Exception as e: + logger.debug(f"Cashu error paying invoice {invoice_obj.payment_hash}: {e}") + raise e + finally: + logger.debug( + f"Cashu: Wallet {cashu.wallet} checking PaymentStatus of {invoice_obj.payment_hash}" + ) + status: PaymentStatus = await check_transaction_status( + cashu.wallet, invoice_obj.payment_hash + ) + if status.paid == True: + logger.debug( + f"Cashu: Payment successful, invalidating proofs for {invoice_obj.payment_hash}" + ) + await ledger._invalidate_proofs(proofs) + else: + logger.debug(f"Cashu: Payment failed for {invoice_obj.payment_hash}") except Exception as e: + logger.debug(f"Cashu: Exception for {invoice_obj.payment_hash}: {str(e)}") raise HTTPException( status_code=HTTPStatus.BAD_REQUEST, detail=f"Cashu: {str(e)}", ) finally: + logger.debug(f"Cashu: Unset pending for {invoice_obj.payment_hash}") # delete proofs from pending list await ledger._unset_proofs_pending(proofs) diff --git a/lnbits/extensions/copilot/templates/copilot/_api_docs.html b/lnbits/extensions/copilot/templates/copilot/_api_docs.html index 6105d169..72edc176 100644 --- a/lnbits/extensions/copilot/templates/copilot/_api_docs.html +++ b/lnbits/extensions/copilot/templates/copilot/_api_docs.html @@ -4,7 +4,10 @@ StreamerCopilot: get tips via static QR (lnurl-pay) and show an animation
- Created by, Ben ArcBen Arc

diff --git a/lnbits/extensions/copilot/templates/copilot/compose.html b/lnbits/extensions/copilot/templates/copilot/compose.html index ea44114c..f8f9d809 100644 --- a/lnbits/extensions/copilot/templates/copilot/compose.html +++ b/lnbits/extensions/copilot/templates/copilot/compose.html @@ -25,7 +25,7 @@ >
diff --git a/lnbits/extensions/discordbot/templates/discordbot/_api_docs.html b/lnbits/extensions/discordbot/templates/discordbot/_api_docs.html index b57e4ab1..4f84d075 100644 --- a/lnbits/extensions/discordbot/templates/discordbot/_api_docs.html +++ b/lnbits/extensions/discordbot/templates/discordbot/_api_docs.html @@ -11,18 +11,24 @@

Connect your LNbits instance to a - Discord Bot leveraging LNbits as a community based lightning node.
Created by, - Chris LennonChris Lennon
Based on User Manager, by - Ben ArcBen Arc

diff --git a/lnbits/extensions/discordbot/templates/discordbot/index.html b/lnbits/extensions/discordbot/templates/discordbot/index.html index 70965a70..44f74a82 100644 --- a/lnbits/extensions/discordbot/templates/discordbot/index.html +++ b/lnbits/extensions/discordbot/templates/discordbot/index.html @@ -8,6 +8,7 @@ This extension is designed to be used through its API by a Discord Bot, currently you have to install the bot yourself
diff --git a/lnbits/extensions/events/templates/events/_api_docs.html b/lnbits/extensions/events/templates/events/_api_docs.html index d2fa890e..9a24d707 100644 --- a/lnbits/extensions/events/templates/events/_api_docs.html +++ b/lnbits/extensions/events/templates/events/_api_docs.html @@ -15,7 +15,8 @@ Events comes with a shareable ticket scanner, which can be used to register attendees.
- Created by, Ben Arc + Created by, + Ben Arc

diff --git a/lnbits/extensions/events/templates/events/display.html b/lnbits/extensions/events/templates/events/display.html index e65b4e61..45c2aca2 100644 --- a/lnbits/extensions/events/templates/events/display.html +++ b/lnbits/extensions/events/templates/events/display.html @@ -64,10 +64,10 @@
- + diff --git a/lnbits/extensions/gerty/README.md b/lnbits/extensions/gerty/README.md new file mode 100644 index 00000000..6186ab01 --- /dev/null +++ b/lnbits/extensions/gerty/README.md @@ -0,0 +1,13 @@ +# Gerty + +## Your desktop bitcoin assistant + +Buy here `` + +blah blah blah + +### Usage + +1. Enable extension +2. Fill out form +3. point gerty at the server and give it the Gerty ID \ No newline at end of file diff --git a/lnbits/extensions/gerty/__init__.py b/lnbits/extensions/gerty/__init__.py new file mode 100644 index 00000000..bd353c78 --- /dev/null +++ b/lnbits/extensions/gerty/__init__.py @@ -0,0 +1,30 @@ +import asyncio + +from fastapi import APIRouter +from fastapi.staticfiles import StaticFiles + +from lnbits.db import Database +from lnbits.helpers import template_renderer +from lnbits.tasks import catch_everything_and_restart + +db = Database("ext_gerty") + + +gerty_static_files = [ + { + "path": "/gerty/static", + "app": StaticFiles(packages=[("lnbits", "extensions/gerty/static")]), + "name": "gerty_static", + } +] + + +gerty_ext: APIRouter = APIRouter(prefix="/gerty", tags=["Gerty"]) + + +def gerty_renderer(): + return template_renderer(["lnbits/extensions/gerty/templates"]) + + +from .views import * # noqa +from .views_api import * # noqa diff --git a/lnbits/extensions/gerty/config.json b/lnbits/extensions/gerty/config.json new file mode 100644 index 00000000..a36437be --- /dev/null +++ b/lnbits/extensions/gerty/config.json @@ -0,0 +1,6 @@ +{ + "name": "Gerty", + "short_description": "Desktop bitcoin Assistant", + "icon": "sentiment_satisfied", + "contributors": ["arcbtc", "blackcoffeebtc"] +} diff --git a/lnbits/extensions/gerty/crud.py b/lnbits/extensions/gerty/crud.py new file mode 100644 index 00000000..1164b6ee --- /dev/null +++ b/lnbits/extensions/gerty/crud.py @@ -0,0 +1,137 @@ +import json +import time +from typing import List, Optional, Union + +import httpx +from loguru import logger + +from lnbits.helpers import urlsafe_short_hash + +from . import db +from .models import Gerty, Mempool, MempoolEndpoint + + +async def create_gerty(wallet_id: str, data: Gerty) -> Gerty: + gerty_id = urlsafe_short_hash() + await db.execute( + """ + INSERT INTO gerty.gertys ( + id, + name, + utc_offset, + type, + wallet, + lnbits_wallets, + mempool_endpoint, + exchange, + display_preferences, + refresh_time, + urls + ) + VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) + """, + ( + gerty_id, + data.name, + data.utc_offset, + data.type, + wallet_id, + data.lnbits_wallets, + data.mempool_endpoint, + data.exchange, + data.display_preferences, + data.refresh_time, + data.urls, + ), + ) + + gerty = await get_gerty(gerty_id) + assert gerty, "Newly created gerty couldn't be retrieved" + return gerty + + +async def update_gerty(gerty_id: str, **kwargs) -> Gerty: + q = ", ".join([f"{field[0]} = ?" for field in kwargs.items()]) + await db.execute( + f"UPDATE gerty.gertys SET {q} WHERE id = ?", (*kwargs.values(), gerty_id) + ) + return await get_gerty(gerty_id) + + +async def get_gerty(gerty_id: str) -> Optional[Gerty]: + row = await db.fetchone("SELECT * FROM gerty.gertys WHERE id = ?", (gerty_id,)) + return Gerty(**row) if row else None + + +async def get_gertys(wallet_ids: Union[str, List[str]]) -> List[Gerty]: + if isinstance(wallet_ids, str): + wallet_ids = [wallet_ids] + + q = ",".join(["?"] * len(wallet_ids)) + rows = await db.fetchall( + f"SELECT * FROM gerty.gertys WHERE wallet IN ({q})", (*wallet_ids,) + ) + + return [Gerty(**row) for row in rows] + + +async def delete_gerty(gerty_id: str) -> None: + await db.execute("DELETE FROM gerty.gertys WHERE id = ?", (gerty_id,)) + + +#############MEMPOOL########### + + +async def get_mempool_info(endPoint: str, gerty) -> Optional[Mempool]: + logger.debug(endPoint) + endpoints = MempoolEndpoint() + url = "" + for endpoint in endpoints: + if endPoint == endpoint[0]: + url = endpoint[1] + row = await db.fetchone( + "SELECT * FROM gerty.mempool WHERE endpoint = ? AND mempool_endpoint = ?", + ( + endPoint, + gerty.mempool_endpoint, + ), + ) + if not row: + async with httpx.AsyncClient() as client: + response = await client.get(gerty.mempool_endpoint + url) + logger.debug(gerty.mempool_endpoint + url) + mempool_id = urlsafe_short_hash() + await db.execute( + """ + INSERT INTO gerty.mempool ( + id, + data, + endpoint, + time, + mempool_endpoint + ) + VALUES (?, ?, ?, ?, ?) + """, + ( + mempool_id, + json.dumps(response.json()), + endPoint, + int(time.time()), + gerty.mempool_endpoint, + ), + ) + return response.json() + if int(time.time()) - row.time > 20: + async with httpx.AsyncClient() as client: + response = await client.get(gerty.mempool_endpoint + url) + await db.execute( + "UPDATE gerty.mempool SET data = ?, time = ? WHERE endpoint = ? AND mempool_endpoint = ?", + ( + json.dumps(response.json()), + int(time.time()), + endPoint, + gerty.mempool_endpoint, + ), + ) + return response.json() + return json.loads(row.data) diff --git a/lnbits/extensions/gerty/helpers.py b/lnbits/extensions/gerty/helpers.py new file mode 100644 index 00000000..65c69073 --- /dev/null +++ b/lnbits/extensions/gerty/helpers.py @@ -0,0 +1,951 @@ +import json +import os +import random +import textwrap +from datetime import datetime, timedelta + +import httpx +from loguru import logger + +from lnbits.core.crud import get_user, get_wallet_for_key +from lnbits.settings import settings +from lnbits.utils.exchange_rates import satoshis_amount_as_fiat + +from .crud import get_gerty, get_mempool_info +from .number_prefixer import * + + +def get_percent_difference(current, previous, precision=3): + difference = (current - previous) / current * 100 + return "{0}{1}%".format("+" if difference > 0 else "", round(difference, precision)) + + +# A helper function get a nicely formated dict for the text +def get_text_item_dict( + text: str, + font_size: int, + x_pos: int = None, + y_pos: int = None, + gerty_type: str = "Gerty", +): + # Get line size by font size + line_width = 20 + if font_size <= 12: + line_width = 60 + elif font_size <= 15: + line_width = 45 + elif font_size <= 20: + line_width = 35 + elif font_size <= 40: + line_width = 25 + + # Get font sizes for Gerty mini + if gerty_type.lower() == "mini gerty": + if font_size <= 12: + font_size = 1 + if font_size <= 15: + font_size = 1 + elif font_size <= 20: + font_size = 2 + elif font_size <= 40: + font_size = 2 + else: + font_size = 5 + + # wrap the text + wrapper = textwrap.TextWrapper(width=line_width) + word_list = wrapper.wrap(text=text) + # logger.debug("number of chars = {0}".format(len(text))) + + multilineText = "\n".join(word_list) + # logger.debug("number of lines = {0}".format(len(word_list))) + + # logger.debug('multilineText') + # logger.debug(multilineText) + + text = {"value": multilineText, "size": font_size} + if x_pos is None and y_pos is None: + text["position"] = "center" + else: + text["x"] = x_pos + text["y"] = y_pos + return text + + +# format a number for nice display output +def format_number(number, precision=None): + return "{:,}".format(round(number, precision)) + + +async def get_mining_dashboard(gerty): + areas = [] + if isinstance(gerty.mempool_endpoint, str): + # current hashrate + r = await get_mempool_info("hashrate_1w", gerty) + data = r + hashrateNow = data["currentHashrate"] + hashrateOneWeekAgo = data["hashrates"][6]["avgHashrate"] + + text = [] + text.append( + get_text_item_dict( + text="Current mining hashrate", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="{0}hash".format(si_format(hashrateNow, 6, True, " ")), + font_size=20, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0} vs 7 days ago".format( + get_percent_difference(hashrateNow, hashrateOneWeekAgo, 3) + ), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + r = await get_mempool_info("difficulty_adjustment", gerty) + + # timeAvg + text = [] + progress = "{0}%".format(round(r["progressPercent"], 2)) + text.append( + get_text_item_dict( + text="Progress through current epoch", + font_size=12, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict(text=progress, font_size=60, gerty_type=gerty.type) + ) + areas.append(text) + + # difficulty adjustment + text = [] + stat = r["remainingTime"] + text.append( + get_text_item_dict( + text="Time to next difficulty adjustment", + font_size=12, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text=get_time_remaining(stat / 1000, 3), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + # difficultyChange + text = [] + difficultyChange = round(r["difficultyChange"], 2) + text.append( + get_text_item_dict( + text="Estimated difficulty change", + font_size=12, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0}{1}%".format( + "+" if difficultyChange > 0 else "", round(difficultyChange, 2) + ), + font_size=60, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + r = await get_mempool_info("hashrate_1m", gerty) + data = r + stat = {} + stat["current"] = data["currentDifficulty"] + stat["previous"] = data["difficulty"][len(data["difficulty"]) - 2]["difficulty"] + return areas + + +async def get_lightning_stats(gerty): + data = await get_mempool_info("statistics", gerty) + areas = [] + + text = [] + text.append( + get_text_item_dict(text="Channel Count", font_size=12, gerty_type=gerty.type) + ) + text.append( + get_text_item_dict( + text=format_number(data["latest"]["channel_count"]), + font_size=20, + gerty_type=gerty.type, + ) + ) + difference = get_percent_difference( + current=data["latest"]["channel_count"], + previous=data["previous"]["channel_count"], + ) + text.append( + get_text_item_dict( + text="{0} in last 7 days".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + text = [] + text.append( + get_text_item_dict(text="Number of Nodes", font_size=12, gerty_type=gerty.type) + ) + text.append( + get_text_item_dict( + text=format_number(data["latest"]["node_count"]), + font_size=20, + gerty_type=gerty.type, + ) + ) + difference = get_percent_difference( + current=data["latest"]["node_count"], previous=data["previous"]["node_count"] + ) + text.append( + get_text_item_dict( + text="{0} in last 7 days".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + text = [] + text.append( + get_text_item_dict(text="Total Capacity", font_size=12, gerty_type=gerty.type) + ) + avg_capacity = float(data["latest"]["total_capacity"]) / float(100000000) + text.append( + get_text_item_dict( + text="{0} BTC".format(format_number(avg_capacity, 2)), + font_size=20, + gerty_type=gerty.type, + ) + ) + difference = get_percent_difference( + current=data["latest"]["total_capacity"], + previous=data["previous"]["total_capacity"], + ) + text.append( + get_text_item_dict( + text="{0} in last 7 days".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + text = [] + text.append( + get_text_item_dict( + text="Average Channel Capacity", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="{0} sats".format(format_number(data["latest"]["avg_capacity"])), + font_size=20, + gerty_type=gerty.type, + ) + ) + difference = get_percent_difference( + current=data["latest"]["avg_capacity"], + previous=data["previous"]["avg_capacity"], + ) + text.append( + get_text_item_dict( + text="{0} in last 7 days".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + return areas + + +def get_next_update_time(sleep_time_seconds: int = 0, utc_offset: int = 0): + utc_now = datetime.utcnow() + next_refresh_time = utc_now + timedelta(0, sleep_time_seconds) + local_refresh_time = next_refresh_time + timedelta(hours=utc_offset) + return "{0} {1}".format( + "I'll wake up at" if gerty_should_sleep(utc_offset) else "Next update at", + local_refresh_time.strftime("%H:%M on %e %b %Y"), + ) + + +def gerty_should_sleep(utc_offset: int = 0): + utc_now = datetime.utcnow() + local_time = utc_now + timedelta(hours=utc_offset) + hours = local_time.strftime("%H") + hours = int(hours) + if hours >= 22 and hours <= 23: + return True + else: + return False + + +async def get_mining_stat(stat_slug: str, gerty): + text = [] + if stat_slug == "mining_current_hash_rate": + stat = await api_get_mining_stat(stat_slug, gerty) + current = "{0}hash".format(si_format(stat["current"], 6, True, " ")) + text.append( + get_text_item_dict( + text="Current Mining Hashrate", font_size=20, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict(text=current, font_size=40, gerty_type=gerty.type) + ) + # compare vs previous time period + difference = get_percent_difference( + current=stat["current"], previous=stat["1w"] + ) + text.append( + get_text_item_dict( + text="{0} in last 7 days".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + elif stat_slug == "mining_current_difficulty": + stat = await api_get_mining_stat(stat_slug, gerty) + text.append( + get_text_item_dict( + text="Current Mining Difficulty", font_size=20, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text=format_number(stat["current"]), font_size=40, gerty_type=gerty.type + ) + ) + difference = get_percent_difference( + current=stat["current"], previous=stat["previous"] + ) + text.append( + get_text_item_dict( + text="{0} since last adjustment".format(difference), + font_size=12, + gerty_type=gerty.type, + ) + ) + # text.append(get_text_item_dict("Required threshold for mining proof-of-work", 12)) + return text + + +async def api_get_mining_stat(stat_slug: str, gerty): + stat = "" + if stat_slug == "mining_current_hash_rate": + async with httpx.AsyncClient() as client: + r = await get_mempool_info("hashrate_1m", gerty) + data = r + stat = {} + stat["current"] = data["currentHashrate"] + stat["1w"] = data["hashrates"][len(data["hashrates"]) - 7]["avgHashrate"] + elif stat_slug == "mining_current_difficulty": + async with httpx.AsyncClient() as client: + r = await get_mempool_info("hashrate_1m", gerty) + data = r + stat = {} + stat["current"] = data["currentDifficulty"] + stat["previous"] = data["difficulty"][len(data["difficulty"]) - 2][ + "difficulty" + ] + return stat + + +########################################### + + +async def get_satoshi(): + maxQuoteLength = 186 + with open( + os.path.join(settings.lnbits_path, "extensions/gerty/static/satoshi.json") + ) as fd: + satoshiQuotes = json.load(fd) + quote = satoshiQuotes[random.randint(0, len(satoshiQuotes) - 1)] + # logger.debug(quote.text) + if len(quote["text"]) > maxQuoteLength: + logger.debug("Quote is too long, getting another") + return await get_satoshi() + else: + return quote + + +# Get a screen slug by its position in the screens_list +def get_screen_slug_by_index(index: int, screens_list): + if index <= len(screens_list) - 1: + return list(screens_list)[index - 1] + else: + return None + + +# Get a list of text items for the screen number +async def get_screen_data(screen_num: int, screens_list: dict, gerty): + screen_slug = get_screen_slug_by_index(screen_num, screens_list) + # first get the relevant slug from the display_preferences + areas = [] + title = "" + + if screen_slug == "dashboard": + title = gerty.name + areas = await get_dashboard(gerty) + if screen_slug == "lnbits_wallets_balance": + wallets = await get_lnbits_wallet_balances(gerty) + + for wallet in wallets: + text = [] + text.append( + get_text_item_dict( + text="{0}'s Wallet".format(wallet["name"]), + font_size=20, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0} sats".format(format_number(wallet["balance"])), + font_size=40, + gerty_type=gerty.type, + ) + ) + areas.append(text) + elif screen_slug == "url_checker": + for url in json.loads(gerty.urls): + async with httpx.AsyncClient() as client: + text = [] + try: + response = await client.get(url) + text.append( + get_text_item_dict( + text=url, + font_size=20, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text=str(response.status_code), + font_size=40, + gerty_type=gerty.type, + ) + ) + except: + text = [] + text.append( + get_text_item_dict( + text=url, + font_size=20, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text=str("DOWN"), + font_size=40, + gerty_type=gerty.type, + ) + ) + areas.append(text) + elif screen_slug == "fun_satoshi_quotes": + areas.append(await get_satoshi_quotes(gerty)) + elif screen_slug == "fun_exchange_market_rate": + areas.append(await get_exchange_rate(gerty)) + elif screen_slug == "onchain_difficulty_epoch_progress": + areas.append(await get_onchain_stat(screen_slug, gerty)) + elif screen_slug == "onchain_block_height": + text = [] + text.append( + get_text_item_dict( + text=format_number(await get_mempool_info("tip_height", gerty)), + font_size=80, + gerty_type=gerty.type, + ) + ) + areas.append(text) + elif screen_slug == "onchain_difficulty_retarget_date": + areas.append(await get_onchain_stat(screen_slug, gerty)) + elif screen_slug == "onchain_difficulty_blocks_remaining": + areas.append(await get_onchain_stat(screen_slug, gerty)) + elif screen_slug == "onchain_difficulty_epoch_time_remaining": + areas.append(await get_onchain_stat(screen_slug, gerty)) + elif screen_slug == "dashboard_onchain": + title = "Onchain Data" + areas = await get_onchain_dashboard(gerty) + elif screen_slug == "mempool_recommended_fees": + areas.append(await get_mempool_stat(screen_slug, gerty)) + elif screen_slug == "mempool_tx_count": + areas.append(await get_mempool_stat(screen_slug, gerty)) + elif screen_slug == "mining_current_hash_rate": + areas.append(await get_mining_stat(screen_slug, gerty)) + elif screen_slug == "mining_current_difficulty": + areas.append(await get_mining_stat(screen_slug, gerty)) + elif screen_slug == "dashboard_mining": + title = "Mining Data" + areas = await get_mining_dashboard(gerty) + elif screen_slug == "lightning_dashboard": + title = "Lightning Network" + areas = await get_lightning_stats(gerty) + + data = {} + data["title"] = title + data["areas"] = areas + + return data + + +# Get the dashboard screen +async def get_dashboard(gerty): + areas = [] + # XC rate + text = [] + amount = await satoshis_amount_as_fiat(100000000, gerty.exchange) + text.append( + get_text_item_dict( + text=format_number(amount), font_size=40, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="BTC{0} price".format(gerty.exchange), + font_size=15, + gerty_type=gerty.type, + ) + ) + areas.append(text) + # balance + text = [] + wallets = await get_lnbits_wallet_balances(gerty) + text = [] + for wallet in wallets: + text.append( + get_text_item_dict( + text="{0}".format(wallet["name"]), font_size=15, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="{0} sats".format(format_number(wallet["balance"])), + font_size=20, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + # Mempool fees + text = [] + text.append( + get_text_item_dict( + text=format_number(await get_mempool_info("tip_height", gerty)), + font_size=40, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="Current block height", font_size=15, gerty_type=gerty.type + ) + ) + areas.append(text) + + # difficulty adjustment time + text = [] + text.append( + get_text_item_dict( + text=await get_time_remaining_next_difficulty_adjustment(gerty), + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="until next difficulty adjustment", font_size=12, gerty_type=gerty.type + ) + ) + areas.append(text) + + return areas + + +async def get_lnbits_wallet_balances(gerty): + # Get Wallet info + wallets = [] + if gerty.lnbits_wallets != "": + for lnbits_wallet in json.loads(gerty.lnbits_wallets): + wallet = await get_wallet_for_key(key=lnbits_wallet) + if wallet: + wallets.append( + { + "name": wallet.name, + "balance": wallet.balance_msat / 1000, + "inkey": wallet.inkey, + } + ) + return wallets + + +async def get_placeholder_text(): + return [ + get_text_item_dict( + text="Some placeholder text", + x_pos=15, + y_pos=10, + font_size=50, + gerty_type=gerty.type, + ), + get_text_item_dict( + text="Some placeholder text", + x_pos=15, + y_pos=10, + font_size=50, + gerty_type=gerty.type, + ), + ] + + +async def get_satoshi_quotes(gerty): + # Get Satoshi quotes + text = [] + quote = await get_satoshi() + if quote: + if quote["text"]: + text.append( + get_text_item_dict( + text=quote["text"], font_size=15, gerty_type=gerty.type + ) + ) + if quote["date"]: + text.append( + get_text_item_dict( + text="Satoshi Nakamoto - {0}".format(quote["date"]), + font_size=15, + gerty_type=gerty.type, + ) + ) + return text + + +# Get Exchange Value +async def get_exchange_rate(gerty): + text = [] + if gerty.exchange != "": + try: + amount = await satoshis_amount_as_fiat(100000000, gerty.exchange) + if amount: + price = format_number(amount) + text.append( + get_text_item_dict( + text="Current {0}/BTC price".format(gerty.exchange), + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict(text=price, font_size=80, gerty_type=gerty.type) + ) + except: + pass + return text + + +async def get_onchain_stat(stat_slug: str, gerty): + text = [] + if ( + stat_slug == "onchain_difficulty_epoch_progress" + or stat_slug == "onchain_difficulty_retarget_date" + or stat_slug == "onchain_difficulty_blocks_remaining" + or stat_slug == "onchain_difficulty_epoch_time_remaining" + ): + async with httpx.AsyncClient() as client: + r = await get_mempool_info("difficulty_adjustment", gerty) + if stat_slug == "onchain_difficulty_epoch_progress": + stat = round(r["progressPercent"]) + text.append( + get_text_item_dict( + text="Progress through current difficulty epoch", + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0}%".format(stat), font_size=80, gerty_type=gerty.type + ) + ) + elif stat_slug == "onchain_difficulty_retarget_date": + stat = r["estimatedRetargetDate"] + dt = datetime.fromtimestamp(stat / 1000).strftime("%e %b %Y at %H:%M") + text.append( + get_text_item_dict( + text="Date of next difficulty adjustment", + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict(text=dt, font_size=40, gerty_type=gerty.type) + ) + elif stat_slug == "onchain_difficulty_blocks_remaining": + stat = r["remainingBlocks"] + text.append( + get_text_item_dict( + text="Blocks until next difficulty adjustment", + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0}".format(format_number(stat)), + font_size=80, + gerty_type=gerty.type, + ) + ) + elif stat_slug == "onchain_difficulty_epoch_time_remaining": + stat = r["remainingTime"] + text.append( + get_text_item_dict( + text="Time until next difficulty adjustment", + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text=get_time_remaining(stat / 1000, 4), + font_size=20, + gerty_type=gerty.type, + ) + ) + return text + + +async def get_onchain_dashboard(gerty): + areas = [] + if isinstance(gerty.mempool_endpoint, str): + async with httpx.AsyncClient() as client: + r = await get_mempool_info("difficulty_adjustment", gerty) + text = [] + stat = round(r["progressPercent"]) + text.append( + get_text_item_dict( + text="Progress through epoch", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="{0}%".format(stat), font_size=60, gerty_type=gerty.type + ) + ) + areas.append(text) + + text = [] + stat = r["estimatedRetargetDate"] + dt = datetime.fromtimestamp(stat / 1000).strftime("%e %b %Y at %H:%M") + text.append( + get_text_item_dict( + text="Date of next adjustment", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict(text=dt, font_size=20, gerty_type=gerty.type) + ) + areas.append(text) + + text = [] + stat = r["remainingBlocks"] + text.append( + get_text_item_dict( + text="Blocks until adjustment", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text="{0}".format(format_number(stat)), + font_size=60, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + text = [] + stat = r["remainingTime"] + text.append( + get_text_item_dict( + text="Time until adjustment", font_size=12, gerty_type=gerty.type + ) + ) + text.append( + get_text_item_dict( + text=get_time_remaining(stat / 1000, 4), + font_size=20, + gerty_type=gerty.type, + ) + ) + areas.append(text) + + return areas + + +async def get_time_remaining_next_difficulty_adjustment(gerty): + if isinstance(gerty.mempool_endpoint, str): + r = await get_mempool_info("difficulty_adjustment", gerty) + stat = r["remainingTime"] + time = get_time_remaining(stat / 1000, 3) + return time + + +async def get_mempool_stat(stat_slug: str, gerty): + text = [] + if isinstance(gerty.mempool_endpoint, str): + if stat_slug == "mempool_tx_count": + r = get_mempool_info("mempool", gerty) + if stat_slug == "mempool_tx_count": + stat = round(r["count"]) + text.append( + get_text_item_dict( + text="Transactions in the mempool", + font_size=15, + gerty_type=gerty.type, + ) + ) + text.append( + get_text_item_dict( + text="{0}".format(format_number(stat)), + font_size=80, + gerty_type=gerty.type, + ) + ) + elif stat_slug == "mempool_recommended_fees": + y_offset = 60 + fees = await get_mempool_info("fees_recommended", gerty) + pos_y = 80 + y_offset + text.append(get_text_item_dict("mempool.space", 40, 160, pos_y, gerty.type)) + pos_y = 180 + y_offset + text.append( + get_text_item_dict("Recommended Tx Fees", 20, 240, pos_y, gerty.type) + ) + + pos_y = 280 + y_offset + text.append( + get_text_item_dict("{0}".format("None"), 15, 30, pos_y, gerty.type) + ) + text.append( + get_text_item_dict("{0}".format("Low"), 15, 235, pos_y, gerty.type) + ) + text.append( + get_text_item_dict("{0}".format("Medium"), 15, 460, pos_y, gerty.type) + ) + text.append( + get_text_item_dict("{0}".format("High"), 15, 750, pos_y, gerty.type) + ) + + pos_y = 340 + y_offset + font_size = 15 + fee_append = "/vB" + fee_rate = fees["economyFee"] + text.append( + get_text_item_dict( + text="{0} {1}{2}".format( + format_number(fee_rate), + ("sat" if fee_rate == 1 else "sats"), + fee_append, + ), + font_size=font_size, + x_pos=30, + y_pos=pos_y, + gerty_type=gerty.type, + ) + ) + + fee_rate = fees["hourFee"] + text.append( + get_text_item_dict( + text="{0} {1}{2}".format( + format_number(fee_rate), + ("sat" if fee_rate == 1 else "sats"), + fee_append, + ), + font_size=font_size, + x_pos=235, + y_pos=pos_y, + gerty_type=gerty.type, + ) + ) + + fee_rate = fees["halfHourFee"] + text.append( + get_text_item_dict( + text="{0} {1}{2}".format( + format_number(fee_rate), + ("sat" if fee_rate == 1 else "sats"), + fee_append, + ), + font_size=font_size, + x_pos=460, + y_pos=pos_y, + gerty_type=gerty.type, + ) + ) + + fee_rate = fees["fastestFee"] + text.append( + get_text_item_dict( + text="{0} {1}{2}".format( + format_number(fee_rate), + ("sat" if fee_rate == 1 else "sats"), + fee_append, + ), + font_size=font_size, + x_pos=750, + y_pos=pos_y, + gerty_type=gerty.type, + ) + ) + return text + + +def get_date_suffix(dayNumber): + if 4 <= dayNumber <= 20 or 24 <= dayNumber <= 30: + return "th" + else: + return ["st", "nd", "rd"][dayNumber % 10 - 1] + + +def get_time_remaining(seconds, granularity=2): + intervals = ( + # ('weeks', 604800), # 60 * 60 * 24 * 7 + ("days", 86400), # 60 * 60 * 24 + ("hours", 3600), # 60 * 60 + ("minutes", 60), + ("seconds", 1), + ) + + result = [] + + for name, count in intervals: + value = seconds // count + if value: + seconds -= value * count + if value == 1: + name = name.rstrip("s") + result.append("{} {}".format(round(value), name)) + return ", ".join(result[:granularity]) diff --git a/lnbits/extensions/gerty/migrations.py b/lnbits/extensions/gerty/migrations.py new file mode 100644 index 00000000..654dfcbf --- /dev/null +++ b/lnbits/extensions/gerty/migrations.py @@ -0,0 +1,59 @@ +async def m001_initial(db): + """ + Initial Gertys table. + """ + await db.execute( + """ + CREATE TABLE gerty.gertys ( + id TEXT PRIMARY KEY, + wallet TEXT NOT NULL, + refresh_time INT, + name TEXT NOT NULL, + lnbits_wallets TEXT, + mempool_endpoint TEXT, + exchange TEXT, + display_preferences TEXT + ); + """ + ) + + +async def m002_add_utc_offset_col(db): + """ + support for UTC offset + """ + await db.execute("ALTER TABLE gerty.gertys ADD COLUMN utc_offset INT;") + + +async def m003_add_gerty_model_col(db): + """ + support for Gerty model col + """ + await db.execute("ALTER TABLE gerty.gertys ADD COLUMN type TEXT;") + + +#########MEMPOOL MIGRATIONS######## + + +async def m004_initial(db): + """ + Initial Gertys table. + """ + await db.execute( + """ + CREATE TABLE gerty.mempool ( + id TEXT PRIMARY KEY, + mempool_endpoint TEXT NOT NULL, + endpoint TEXT NOT NULL, + data TEXT NOT NULL, + time TIMESTAMP + ); + """ + ) + + +async def m005_add_gerty_model_col(db): + """ + support for Gerty model col + """ + await db.execute("ALTER TABLE gerty.gertys ADD COLUMN urls TEXT;") diff --git a/lnbits/extensions/gerty/models.py b/lnbits/extensions/gerty/models.py new file mode 100644 index 00000000..9ff29bda --- /dev/null +++ b/lnbits/extensions/gerty/models.py @@ -0,0 +1,48 @@ +from sqlite3 import Row +from typing import Optional + +from fastapi import Query +from pydantic import BaseModel + + +class Gerty(BaseModel): + id: str = Query(None) + name: str + refresh_time: int = Query(None) + utc_offset: int = Query(None) + wallet: str = Query(None) + type: str + lnbits_wallets: str = Query( + None + ) # Wallets to keep an eye on, {"wallet-id": "wallet-read-key, etc"} + mempool_endpoint: str = Query(None) # Mempool endpoint to use + exchange: str = Query( + None + ) # BTC <-> Fiat exchange rate to pull ie "USD", in 0.0001 and sats + display_preferences: str = Query(None) + urls: str = Query(None) + + @classmethod + def from_row(cls, row: Row) -> "Gerty": + return cls(**dict(row)) + + +#########MEMPOOL MODELS########### + + +class MempoolEndpoint(BaseModel): + fees_recommended: str = "/api/v1/fees/recommended" + hashrate_1w: str = "/api/v1/mining/hashrate/1w" + hashrate_1m: str = "/api/v1/mining/hashrate/1m" + statistics: str = "/api/v1/lightning/statistics/latest" + difficulty_adjustment: str = "/api/v1/difficulty-adjustment" + tip_height: str = "/api/blocks/tip/height" + mempool: str = "/api/mempool" + + +class Mempool(BaseModel): + id: str = Query(None) + mempool_endpoint: str = Query(None) + endpoint: str = Query(None) + data: str = Query(None) + time: int = Query(None) diff --git a/lnbits/extensions/gerty/number_prefixer.py b/lnbits/extensions/gerty/number_prefixer.py new file mode 100644 index 00000000..eab684e7 --- /dev/null +++ b/lnbits/extensions/gerty/number_prefixer.py @@ -0,0 +1,66 @@ +import math + + +def si_classifier(val): + suffixes = { + 24: {"long_suffix": "yotta", "short_suffix": "Y", "scalar": 10**24}, + 21: {"long_suffix": "zetta", "short_suffix": "Z", "scalar": 10**21}, + 18: {"long_suffix": "exa", "short_suffix": "E", "scalar": 10**18}, + 15: {"long_suffix": "peta", "short_suffix": "P", "scalar": 10**15}, + 12: {"long_suffix": "tera", "short_suffix": "T", "scalar": 10**12}, + 9: {"long_suffix": "giga", "short_suffix": "G", "scalar": 10**9}, + 6: {"long_suffix": "mega", "short_suffix": "M", "scalar": 10**6}, + 3: {"long_suffix": "kilo", "short_suffix": "k", "scalar": 10**3}, + 0: {"long_suffix": "", "short_suffix": "", "scalar": 10**0}, + -3: {"long_suffix": "milli", "short_suffix": "m", "scalar": 10**-3}, + -6: {"long_suffix": "micro", "short_suffix": "µ", "scalar": 10**-6}, + -9: {"long_suffix": "nano", "short_suffix": "n", "scalar": 10**-9}, + -12: {"long_suffix": "pico", "short_suffix": "p", "scalar": 10**-12}, + -15: {"long_suffix": "femto", "short_suffix": "f", "scalar": 10**-15}, + -18: {"long_suffix": "atto", "short_suffix": "a", "scalar": 10**-18}, + -21: {"long_suffix": "zepto", "short_suffix": "z", "scalar": 10**-21}, + -24: {"long_suffix": "yocto", "short_suffix": "y", "scalar": 10**-24}, + } + exponent = int(math.floor(math.log10(abs(val)) / 3.0) * 3) + return suffixes.get(exponent, None) + + +def si_formatter(value): + """ + Return a triple of scaled value, short suffix, long suffix, or None if + the value cannot be classified. + """ + classifier = si_classifier(value) + if classifier == None: + # Don't know how to classify this value + return None + + scaled = value / classifier["scalar"] + return (scaled, classifier["short_suffix"], classifier["long_suffix"]) + + +def si_format(value, precision=4, long_form=False, separator=""): + """ + "SI prefix" formatted string: return a string with the given precision + and an appropriate order-of-3-magnitudes suffix, e.g.: + si_format(1001.0) => '1.00K' + si_format(0.00000000123, long_form=True, separator=' ') => '1.230 nano' + """ + scaled, short_suffix, long_suffix = si_formatter(value) + + if scaled == None: + # Don't know how to format this value + return value + + suffix = long_suffix if long_form else short_suffix + + if abs(scaled) < 10: + precision = precision - 1 + elif abs(scaled) < 100: + precision = precision - 2 + else: + precision = precision - 3 + + return "{scaled:.{precision}f}{separator}{suffix}".format( + scaled=scaled, precision=precision, separator=separator, suffix=suffix + ) diff --git a/lnbits/extensions/gerty/static/gerty.jpg b/lnbits/extensions/gerty/static/gerty.jpg new file mode 100644 index 00000000..fe208cdd Binary files /dev/null and b/lnbits/extensions/gerty/static/gerty.jpg differ diff --git a/lnbits/extensions/gerty/static/satoshi.json b/lnbits/extensions/gerty/static/satoshi.json new file mode 100644 index 00000000..1cff822a --- /dev/null +++ b/lnbits/extensions/gerty/static/satoshi.json @@ -0,0 +1,1099 @@ +[ + { + "category": "general", + "medium": "bitcointalk", + "text": "It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.", + "post_id": "542", + "date": "December 11, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "The project needs to grow gradually so the software can be strengthened along the way. I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy.", + "post_id": "523", + "date": "December 5, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites. It'll be a lot simpler if authors could make their graphics public domain.", + "post_id": "500", + "date": "November 13, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of. \nThe article could be as simple as something like: \"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/.\" \nThe more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.", + "post_id": "467", + "date": "September 30, 2010" + }, + { + "category": "transactions", + "medium": "bitcointalk", + "text": "As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.", + "post_id": "464", + "date": "September 30, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to \"porn guys\", or afraid of recurring billing.", + "post_id": "460", + "date": "September 23, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice. We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion. I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.", + "post_id": "454", + "date": "September 19, 2010" + }, + { + "category": "scalability", + "medium": "bitcointalk", + "text": "The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.", + "post_id": "441", + "date": "September 8, 2010" + }, + { + "category": "fees", + "medium": "bitcointalk", + "text": "Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.", + "post_id": "441", + "date": "September 8, 2010" + }, + { + "category": "fees, nodes", + "medium": "bitcointalk", + "text": "Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee. The threshold should probably be lower than it currently is. I don't think the threshold should ever be 0. We should always allow at least some free transactions.", + "post_id": "439", + "date": "September 7, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:\n- boring grey in colour\n- not a good conductor of electricity\n- not particularly strong, but not ductile or easily malleable either\n- not useful for any practical or ornamental purpose\n\nand one special, magical property:\n- can be transported over a communications channel\n\nIf it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.\n\nMaybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.\n\nI think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.\n\n(I'm using the word scarce here to only mean limited potential supply)", + "post_id": "428", + "date": "August 27, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Bitcoins have no dividend or potential future dividend, therefore not like a stock.\n\nMore like a collectible or commodity.", + "post_id": "427", + "date": "August 27, 2010" + }, + { + "category": "proof-of-work", + "medium": "bitcointalk", + "text": "There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.", + "post_id": "394", + "date": "August 16, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "Some places where generation will gravitate to: \n1) places where it's cheapest or free\n2) people who want to help for idealogical reasons\n3) people who want to get some coins without the inconvenience of doing a transaction to buy them\n\nThere are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.", + "post_id": "364", + "date": "August 15, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Then you must also be against the common system of payment up front, where the customer loses.\nPayment up front: customer loses, and the thief gets the money.\nSimple escrow: customer loses, but the thief doesn't get the money either.\nAre you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?\nImagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.\nImagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.\nIt still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about \"money burning\" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.", + "post_id": "340", + "date": "August 11, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer. \nIf you have other cheaper heating than electric, then the waste is only the difference in cost.\nIf it's summer and you're using A/C, then it's twice. \nBitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free.", + "post_id": "337", + "date": "August 9, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange. \nI think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.", + "post_id": "327", + "date": "August 7, 2010" + }, + { + "category": "proof-of-work", + "medium": "bitcointalk", + "text": "Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.", + "post_id": "327", + "date": "August 7, 2010" + }, + { + "category": "micropayments", + "medium": "bitcointalk", + "text": "Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.", + "post_id": "318", + "date": "August 5, 2010" + }, + { + "category": "micropayments", + "medium": "bitcointalk", + "text": "Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that. \nBitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.", + "post_id": "317", + "date": "August 4, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.", + "post_id": "294", + "date": "July 29, 2010" + }, + { + "category": "nodes", + "medium": "bitcointalk", + "text": "The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.", + "post_id": "287", + "date": "July 29, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later. http://www.bitcoin.org/Satoshi_Nakamoto.asc", + "post_id": "276", + "date": "July 25, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes. \n \nThe database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state. \n \nI only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.", + "post_id": "258", + "date": "July 23, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "The timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment? \nIt would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.", + "post_id": "249", + "date": "July 10, 2010" + }, + { + "category": "difficulty", + "medium": "bitcointalk", + "text": "Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.", + "post_id": "225", + "date": "July 16, 2010" + }, + { + "category": "difficulty", + "medium": "bitcointalk", + "text": "Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.", + "post_id": "223", + "date": "July 16, 2010" + }, + { + "category": "scalability, nodes", + "medium": "bitcointalk", + "text": "The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself. \nThe lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "scalability, nodes", + "medium": "bitcointalk", + "text": "I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "nodes", + "medium": "bitcointalk", + "text": "At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.", + "post_id": "174", + "date": "July 9, 2010" + }, + { + "category": "releases", + "medium": "bitcointalk", + "text": "Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU proof-of-worker they contribute, so you can get a share of them by contributing your idle CPU time.", + "post_id": "168", + "date": "July 6, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to.", + "post_id": "167", + "date": "July 5, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone.", + "post_id": "131", + "date": "June 21, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.\n\nYou should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.", + "post_id": "129", + "date": "June 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.\n\nFortunately, so far all the issues raised have been things I previously considered and planned for.", + "post_id": "127", + "date": "June 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.", + "post_id": "126", + "date": "June 17, 2010" + }, + { + "category": "transactions, bitcoin-design", + "medium": "bitcointalk", + "text": "The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.", + "post_id": "126", + "date": "June 17, 2010" + }, + { + "category": "encryption", + "medium": "bitcointalk", + "text": "SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.", + "post_id": "119", + "date": "June 14, 2010" + }, + { + "category": "encryption", + "medium": "bitcointalk", + "text": "If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.", + "post_id": "119", + "date": "June 14, 2010" + }, + { + "category": "releases", + "medium": "bitcointalk", + "text": "Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release.", + "post_id": "111", + "date": "May 26, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network. They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated. \nSPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.", + "post_id": "105", + "date": "May 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Bitcoin addresses you generate are kept forever. A bitcoin address must be kept to show ownership of anything sent to it. If you were able to delete a bitcoin address and someone sent to it, the money would be lost. They're only about 500 bytes.", + "post_id": "102", + "date": "May 16, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It's like generating a new PGP private key, but less CPU intensive because it's ECC. The address space is effectively unlimited. It doesn't hurt anyone, so generate all you want.", + "post_id": "98", + "date": "May 16, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it's standard for open source projects to be .org.", + "post_id": "94", + "date": "March 23, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "How does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo?", + "post_id": "83", + "date": "February 26, 2010" + }, + { + "category": "transactions", + "medium": "bitcointalk", + "text": "That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.", + "post_id": "73", + "date": "February 24, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "economics, bitcoin-economics", + "medium": "bitcointalk", + "text": "The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "I'm sure that in 20 years there will either be very large transaction volume or no volume.", + "post_id": "57", + "date": "February 14, 2010" + }, + { + "category": "bitcoin-economics, fees", + "medium": "bitcointalk", + "text": "In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.", + "post_id": "57", + "date": "February 14, 2010" + }, + { + "category": "nodes, mining, fees", + "medium": "bitcointalk", + "text": "If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.", + "post_id": "56", + "date": "February 14, 2010" + }, + { + "category": "bitcoin-economics, bitcoin-design", + "medium": "bitcointalk", + "text": "Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\n\nBut don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places.", + "post_id": "46", + "date": "February 6, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the \",\"'s and \".\"'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.", + "post_id": "46", + "date": "February 6, 2010" + }, + { + "category": "privacy", + "medium": "bitcointalk", + "text": "Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution.", + "post_id": "45", + "date": "February 6, 2010" + }, + { + "category": "privacy", + "medium": "bitcointalk", + "text": "You could use TOR if you don't want anyone to know you're even using Bitcoin.", + "post_id": "45", + "date": "February 6, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.", + "post_id": "33", + "date": "January 28, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "The average total coins generated across the network per day stays the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they wouldn't get more coins than before.", + "post_id": "20", + "date": "December 12, 2009" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.", + "post_id": "20", + "date": "December 12, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Those coins can never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes down.", + "post_id": "17", + "date": "December 10, 2009" + }, + { + "category": "trusted-third-parties", + "text": "Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it's essential for a program of this nature to be open source.", + "medium": "bitcointalk", + "post_id": "17", + "date": "December 10, 2009" + }, + { + "category": "privacy, transactions", + "medium": "bitcointalk", + "text": "For greater privacy, it's best to use bitcoin addresses only once.", + "post_id": "11", + "date": "November 25, 2009" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "Think of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.", + "post_id": "8", + "date": "November 22, 2009" + }, + { + "category": "bitcoin-design", + "medium": "p2pfoundation", + "text": "It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow: \n\n- Whenever someone finds proof-of-work to generate a block, they get some new coins\n- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)\n- The coins given per block is cut in half every 4 years", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "You could say coins are issued by the majority. They are issued in a limited, predetermined amount.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "To Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "In this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up, which could attract more users to take advantage of the increasing value.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "cryptocurrency", + "medium": "p2pfoundation", + "text": "A lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.", + "post_id": "2", + "date": "February 15, 2009" + }, + { + "category": "releases, bitcoin-design", + "medium": "p2pfoundation", + "text": "I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper: \n\nDownload Bitcoin v0.1 at http://www.bitcoin.org", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "economics", + "medium": "p2pfoundation", + "text": "The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "micropayments, privacy, banks", + "medium": "p2pfoundation", + "text": "Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "encryption", + "medium": "p2pfoundation", + "text": "A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "cryptocurrency", + "medium": "p2pfoundation", + "text": "With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "transactions", + "medium": "p2pfoundation", + "text": "A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "double-spending", + "medium": "p2pfoundation", + "text": "Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical. \nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "bitcoin-design", + "medium": "p2pfoundation", + "text": "The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "identity", + "medium": "p2pfoundation", + "text": "I am not Dorian Nakamoto.", + "post_id": "4", + "date": "March 7, 2014" + }, + { + "category": "bitcoin-design", + "medium": "email", + "email_id": "1", + "text": "I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.", + "date": "November 1, 2008" + }, + { + "category": "bitcoin-design", + "medium": "email", + "email_id": "1", + "text": "The main properties: \n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also proof-of-workers the network to prevent double-spending.", + "date": "November 1, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "2", + "text": "Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day.", + "date": "November 2, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "2", + "text": "Only people trying to create new coins would need to run network nodes.", + "date": "November 2, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "2", + "text": "At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.", + "date": "November 2, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "The requirement is that the good guys collectively have more CPU proof-of-worker than any single attacker.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "There would be many smaller zombie farms that are not big enough to overproof-of-worker the network, and they could still make money by generating bitcoins. The smaller farms are then the \"honest nodes\". (I need a better term than \"honest\") The more smaller farms resort to generating bitcoins, the higher the bar gets to overproof-of-worker the network, making larger farms also too small to overproof-of-worker it so that they may as well generate bitcoins too. According to the \"long tail\" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "Even if a bad guy does overproof-of-worker the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overproof-of-worker the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.", + "date": "November 3, 2008" + }, + { + "category": "motives", + "medium": "email", + "email_id": "4", + "text": "Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.", + "date": "November 7, 2008" + }, + { + "category": "p2p-networks, government", + "medium": "email", + "email_id": "4", + "text": "Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.", + "date": "November 7, 2008" + }, + { + "category": "mining, difficulty", + "medium": "email", + "email_id": "5", + "text": "As computers get faster and the total computing proof-of-worker applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.", + "date": "November 8, 2008" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "5", + "text": "The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase. Coins have to get initially distributed somehow, and a constant rate seems like the best formula.", + "date": "November 8, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "6", + "text": "Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "6", + "text": "Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.", + "date": "November 9, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "6", + "text": "The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.", + "date": "November 9, 2008" + }, + { + "category": "nodes, mining, proof-of-work", + "medium": "email", + "email_id": "6", + "text": "It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU proof-of-worker proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "6", + "text": "The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.", + "date": "November 9, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "6", + "text": "When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "7", + "text": "It's not a problem if transactions have to wait one or a few extra cycles to get into a block.", + "date": "November 9, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "8", + "text": "The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.", + "date": "November 9, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "8", + "text": "A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort. If the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.", + "date": "November 9, 2008" + }, + { + "category": "nodes, proof-of-work", + "medium": "email", + "email_id": "8", + "text": "When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.", + "date": "November 9, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "8", + "text": "The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU proof-of-worker to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history.", + "date": "November 9, 2008" + }, + { + "category": "fees, bitcoin-economics", + "medium": "email", + "email_id": "9", + "text": "If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.", + "date": "November 10, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "When there are multiple double-spent versions of the same transaction, one and only one will become valid.", + "date": "November 11, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.", + "date": "November 11, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from \"unconfirmed\" to \"invalid\". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.", + "date": "November 11, 2008" + }, + { + "category": "difficulty", + "medium": "email", + "email_id": "10", + "text": "The target time between blocks will probably be 10 minutes. Every block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.", + "date": "November 11, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "10", + "text": "Instantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.", + "date": "November 11, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "10", + "text": "With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.", + "date": "November 11, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "11", + "text": "The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\nA number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU proof-of-worker to crack it fast enough if a majority of them attack at the same time. \n They don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first. They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.\n After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU proof-of-worker per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU proof-of-worker exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.\n The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.", + "date": "November 13, 2008" + }, + { + "category": "nodes, mining", + "medium": "email", + "email_id": "12", + "text": "Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.", + "date": "November 14, 2008" + }, + { + "category": "motives", + "medium": "email", + "email_id": "12", + "text": "It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.", + "date": "November 13, 2008" + }, + { + "category": "releases", + "medium": "email", + "email_id": "13", + "text": "I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.", + "date": "November 17, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "13", + "text": "A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "13", + "text": "There's no need for reporting of \"proof of double spending\" like that. If the same chain contains both spends, then the block is invalid and rejected. \n Same if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "13", + "text": "We're not \"on the lookout\" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.", + "date": "November 17, 2008" + }, + { + "category": "proof-of-work, mining", + "medium": "email", + "email_id": "13", + "text": "The proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU proof-of-worker. Anyone's chance of finding a solution at any time is proportional to their CPU proof-of-worker.", + "date": "November 17, 2008" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "13", + "text": "There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.", + "date": "November 17, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "14", + "text": "The credential that establishes someone as real is the ability to supply CPU proof-of-worker.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "14", + "text": "The race is to spread your transaction on the network first. Think 6 degrees of freedom -- it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network. During those 2 minutes, the merchant's nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting. \n If the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that's not going to be worth it for the scammer.", + "date": "November 17, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "14", + "text": "If a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do. If they really want to optimize, and it's a large download, they could cancel the download in the middle if the transaction comes back double-spent. If it's website access, typically it wouldn't be a big deal to let the customer have access for 5 minutes and then cut off access if it's rejected. Many such sites have a free trial anyway.", + "date": "November 17, 2008" + }, + { + "category": "releases, bitcoin-design", + "medium": "email", + "email_id": "15", + "text": "I believe I've worked through all those little details over the last year and a half while coding it, and there were a lot of them. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)", + "date": "November 17, 2008" + }, + { + "category": "releases", + "medium": "email", + "email_id": "16", + "text": "Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.", + "date": "January 9, 2009" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "16", + "text": "If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections.", + "date": "January 9, 2009" + }, + { + "category": "mining", + "medium": "email", + "email_id": "16", + "text": "You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent.", + "date": "January 9, 2009" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "16", + "text": "There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.", + "date": "January 9, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "16", + "text": "Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free.", + "date": "January 9, 2009" + }, + { + "category": "cryptocurrency", + "medium": "email", + "email_id": "17", + "text": "I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet.", + "date": "January 17, 2009" + }, + { + "category": "micropayments", + "medium": "email", + "email_id": "17", + "text": "It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. \"Send X bitcoins to my priority hotline at this IP and I'll read the message personally.\"", + "date": "January 17, 2009" + }, + { + "category": "micropayments", + "medium": "email", + "email_id": "17", + "text": "Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.", + "date": "January 17, 2009" + }, + { + "category": "micropayments, bitcoin-economics", + "medium": "email", + "email_id": "17", + "text": "It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.", + "date": "January 17, 2009" + }, + { + "category": "cryptocurrency", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work, double-spending", + "text": "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 hash-based 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 proof-of-worker. As long as a majority of CPU proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties", + "text": "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 non-reversible services. With the possibility of reversal, the need for trust spreads.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties, cryptocurrency", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "double-spending, proof-of-work", + "text": "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 proof-of-worker than any cooperating group of attacker nodes.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "economics, double-spending", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, cryptocurrency, transactions", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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. 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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 proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work, difficulty", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, nodes, proof-of-work", + "text": "The steps to run the network are as follows:\n\n1. New transactions are broadcast to all nodes.\n2. Each node collects new transactions into a block.\n3. Each node works on finding a difficult proof-of-work for its block.\n4. When a node finds a proof-of-work, it broadcasts the block to all nodes.\n5. Nodes accept the block only if all transactions in it are valid and not already spent.\n6. 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, bitcoin-economics", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "fees, bitcoin-economics", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, bitcoin-economics", + "text": "The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, nodes", + "text": "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. \nAs such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overproof-of-workered 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 overproof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions, bitcoin-design", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions, privacy, trusted-third-parties", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "addresses, privacy", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, trusted-third-parties", + "text": "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 proof-of-worker.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, mining", + "text": "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 proof-of-worker, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + } + ] \ No newline at end of file diff --git a/lnbits/extensions/gerty/static/satoshi_long.json b/lnbits/extensions/gerty/static/satoshi_long.json new file mode 100644 index 00000000..1cff822a --- /dev/null +++ b/lnbits/extensions/gerty/static/satoshi_long.json @@ -0,0 +1,1099 @@ +[ + { + "category": "general", + "medium": "bitcointalk", + "text": "It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.", + "post_id": "542", + "date": "December 11, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "The project needs to grow gradually so the software can be strengthened along the way. I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy.", + "post_id": "523", + "date": "December 5, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites. It'll be a lot simpler if authors could make their graphics public domain.", + "post_id": "500", + "date": "November 13, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of. \nThe article could be as simple as something like: \"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/.\" \nThe more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.", + "post_id": "467", + "date": "September 30, 2010" + }, + { + "category": "transactions", + "medium": "bitcointalk", + "text": "As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.", + "post_id": "464", + "date": "September 30, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to \"porn guys\", or afraid of recurring billing.", + "post_id": "460", + "date": "September 23, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice. We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion. I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.", + "post_id": "454", + "date": "September 19, 2010" + }, + { + "category": "scalability", + "medium": "bitcointalk", + "text": "The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.", + "post_id": "441", + "date": "September 8, 2010" + }, + { + "category": "fees", + "medium": "bitcointalk", + "text": "Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.", + "post_id": "441", + "date": "September 8, 2010" + }, + { + "category": "fees, nodes", + "medium": "bitcointalk", + "text": "Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee. The threshold should probably be lower than it currently is. I don't think the threshold should ever be 0. We should always allow at least some free transactions.", + "post_id": "439", + "date": "September 7, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:\n- boring grey in colour\n- not a good conductor of electricity\n- not particularly strong, but not ductile or easily malleable either\n- not useful for any practical or ornamental purpose\n\nand one special, magical property:\n- can be transported over a communications channel\n\nIf it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.\n\nMaybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.\n\nI think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.\n\n(I'm using the word scarce here to only mean limited potential supply)", + "post_id": "428", + "date": "August 27, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Bitcoins have no dividend or potential future dividend, therefore not like a stock.\n\nMore like a collectible or commodity.", + "post_id": "427", + "date": "August 27, 2010" + }, + { + "category": "proof-of-work", + "medium": "bitcointalk", + "text": "There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.", + "post_id": "394", + "date": "August 16, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "Some places where generation will gravitate to: \n1) places where it's cheapest or free\n2) people who want to help for idealogical reasons\n3) people who want to get some coins without the inconvenience of doing a transaction to buy them\n\nThere are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.", + "post_id": "364", + "date": "August 15, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Then you must also be against the common system of payment up front, where the customer loses.\nPayment up front: customer loses, and the thief gets the money.\nSimple escrow: customer loses, but the thief doesn't get the money either.\nAre you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?\nImagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.\nImagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.\nIt still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about \"money burning\" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.", + "post_id": "340", + "date": "August 11, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer. \nIf you have other cheaper heating than electric, then the waste is only the difference in cost.\nIf it's summer and you're using A/C, then it's twice. \nBitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free.", + "post_id": "337", + "date": "August 9, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange. \nI think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.", + "post_id": "327", + "date": "August 7, 2010" + }, + { + "category": "proof-of-work", + "medium": "bitcointalk", + "text": "Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.", + "post_id": "327", + "date": "August 7, 2010" + }, + { + "category": "micropayments", + "medium": "bitcointalk", + "text": "Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.", + "post_id": "318", + "date": "August 5, 2010" + }, + { + "category": "micropayments", + "medium": "bitcointalk", + "text": "Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that. \nBitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.", + "post_id": "317", + "date": "August 4, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.", + "post_id": "294", + "date": "July 29, 2010" + }, + { + "category": "nodes", + "medium": "bitcointalk", + "text": "The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.", + "post_id": "287", + "date": "July 29, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later. http://www.bitcoin.org/Satoshi_Nakamoto.asc", + "post_id": "276", + "date": "July 25, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes. \n \nThe database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state. \n \nI only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.", + "post_id": "258", + "date": "July 23, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "The timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment? \nIt would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.", + "post_id": "249", + "date": "July 10, 2010" + }, + { + "category": "difficulty", + "medium": "bitcointalk", + "text": "Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.", + "post_id": "225", + "date": "July 16, 2010" + }, + { + "category": "difficulty", + "medium": "bitcointalk", + "text": "Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.", + "post_id": "223", + "date": "July 16, 2010" + }, + { + "category": "scalability, nodes", + "medium": "bitcointalk", + "text": "The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself. \nThe lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "scalability, nodes", + "medium": "bitcointalk", + "text": "I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "nodes", + "medium": "bitcointalk", + "text": "At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.", + "post_id": "188", + "date": "July 14, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.", + "post_id": "174", + "date": "July 9, 2010" + }, + { + "category": "releases", + "medium": "bitcointalk", + "text": "Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU proof-of-worker they contribute, so you can get a share of them by contributing your idle CPU time.", + "post_id": "168", + "date": "July 6, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to.", + "post_id": "167", + "date": "July 5, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone.", + "post_id": "131", + "date": "June 21, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.\n\nYou should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.", + "post_id": "129", + "date": "June 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.\n\nFortunately, so far all the issues raised have been things I previously considered and planned for.", + "post_id": "127", + "date": "June 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.", + "post_id": "126", + "date": "June 17, 2010" + }, + { + "category": "transactions, bitcoin-design", + "medium": "bitcointalk", + "text": "The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.", + "post_id": "126", + "date": "June 17, 2010" + }, + { + "category": "encryption", + "medium": "bitcointalk", + "text": "SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.", + "post_id": "119", + "date": "June 14, 2010" + }, + { + "category": "encryption", + "medium": "bitcointalk", + "text": "If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.", + "post_id": "119", + "date": "June 14, 2010" + }, + { + "category": "releases", + "medium": "bitcointalk", + "text": "Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release.", + "post_id": "111", + "date": "May 26, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network. They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated. \nSPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.", + "post_id": "105", + "date": "May 18, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "Bitcoin addresses you generate are kept forever. A bitcoin address must be kept to show ownership of anything sent to it. If you were able to delete a bitcoin address and someone sent to it, the money would be lost. They're only about 500 bytes.", + "post_id": "102", + "date": "May 16, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It's like generating a new PGP private key, but less CPU intensive because it's ECC. The address space is effectively unlimited. It doesn't hurt anyone, so generate all you want.", + "post_id": "98", + "date": "May 16, 2010" + }, + { + "category": "general", + "medium": "bitcointalk", + "text": "The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it's standard for open source projects to be .org.", + "post_id": "94", + "date": "March 23, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "How does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo?", + "post_id": "83", + "date": "February 26, 2010" + }, + { + "category": "transactions", + "medium": "bitcointalk", + "text": "That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.", + "post_id": "73", + "date": "February 24, 2010" + }, + { + "category": "economics", + "medium": "bitcointalk", + "text": "A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "economics, bitcoin-economics", + "medium": "bitcointalk", + "text": "The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.", + "post_id": "65", + "date": "February 21, 2010" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "I'm sure that in 20 years there will either be very large transaction volume or no volume.", + "post_id": "57", + "date": "February 14, 2010" + }, + { + "category": "bitcoin-economics, fees", + "medium": "bitcointalk", + "text": "In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.", + "post_id": "57", + "date": "February 14, 2010" + }, + { + "category": "nodes, mining, fees", + "medium": "bitcointalk", + "text": "If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.", + "post_id": "56", + "date": "February 14, 2010" + }, + { + "category": "bitcoin-economics, bitcoin-design", + "medium": "bitcointalk", + "text": "Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\n\nBut don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places.", + "post_id": "46", + "date": "February 6, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the \",\"'s and \".\"'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.", + "post_id": "46", + "date": "February 6, 2010" + }, + { + "category": "privacy", + "medium": "bitcointalk", + "text": "Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution.", + "post_id": "45", + "date": "February 6, 2010" + }, + { + "category": "privacy", + "medium": "bitcointalk", + "text": "You could use TOR if you don't want anyone to know you're even using Bitcoin.", + "post_id": "45", + "date": "February 6, 2010" + }, + { + "category": "bitcoin-design", + "medium": "bitcointalk", + "text": "I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.", + "post_id": "33", + "date": "January 28, 2010" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "The average total coins generated across the network per day stays the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they wouldn't get more coins than before.", + "post_id": "20", + "date": "December 12, 2009" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.", + "post_id": "20", + "date": "December 12, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "bitcointalk", + "text": "Those coins can never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes down.", + "post_id": "17", + "date": "December 10, 2009" + }, + { + "category": "trusted-third-parties", + "text": "Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it's essential for a program of this nature to be open source.", + "medium": "bitcointalk", + "post_id": "17", + "date": "December 10, 2009" + }, + { + "category": "privacy, transactions", + "medium": "bitcointalk", + "text": "For greater privacy, it's best to use bitcoin addresses only once.", + "post_id": "11", + "date": "November 25, 2009" + }, + { + "category": "mining", + "medium": "bitcointalk", + "text": "Think of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.", + "post_id": "8", + "date": "November 22, 2009" + }, + { + "category": "bitcoin-design", + "medium": "p2pfoundation", + "text": "It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow: \n\n- Whenever someone finds proof-of-work to generate a block, they get some new coins\n- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)\n- The coins given per block is cut in half every 4 years", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "You could say coins are issued by the majority. They are issued in a limited, predetermined amount.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "To Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "p2pfoundation", + "text": "In this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up, which could attract more users to take advantage of the increasing value.", + "post_id": "3", + "date": "February 18, 2009" + }, + { + "category": "cryptocurrency", + "medium": "p2pfoundation", + "text": "A lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.", + "post_id": "2", + "date": "February 15, 2009" + }, + { + "category": "releases, bitcoin-design", + "medium": "p2pfoundation", + "text": "I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper: \n\nDownload Bitcoin v0.1 at http://www.bitcoin.org", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "economics", + "medium": "p2pfoundation", + "text": "The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "micropayments, privacy, banks", + "medium": "p2pfoundation", + "text": "Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "encryption", + "medium": "p2pfoundation", + "text": "A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "cryptocurrency", + "medium": "p2pfoundation", + "text": "With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "transactions", + "medium": "p2pfoundation", + "text": "A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "double-spending", + "medium": "p2pfoundation", + "text": "Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical. \nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "bitcoin-design", + "medium": "p2pfoundation", + "text": "The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.", + "post_id": "1", + "date": "February 11, 2009" + }, + { + "category": "identity", + "medium": "p2pfoundation", + "text": "I am not Dorian Nakamoto.", + "post_id": "4", + "date": "March 7, 2014" + }, + { + "category": "bitcoin-design", + "medium": "email", + "email_id": "1", + "text": "I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.", + "date": "November 1, 2008" + }, + { + "category": "bitcoin-design", + "medium": "email", + "email_id": "1", + "text": "The main properties: \n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also proof-of-workers the network to prevent double-spending.", + "date": "November 1, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "2", + "text": "Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day.", + "date": "November 2, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "2", + "text": "Only people trying to create new coins would need to run network nodes.", + "date": "November 2, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "2", + "text": "At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.", + "date": "November 2, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "The requirement is that the good guys collectively have more CPU proof-of-worker than any single attacker.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "There would be many smaller zombie farms that are not big enough to overproof-of-worker the network, and they could still make money by generating bitcoins. The smaller farms are then the \"honest nodes\". (I need a better term than \"honest\") The more smaller farms resort to generating bitcoins, the higher the bar gets to overproof-of-worker the network, making larger farms also too small to overproof-of-worker it so that they may as well generate bitcoins too. According to the \"long tail\" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "Even if a bad guy does overproof-of-worker the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overproof-of-worker the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.", + "date": "November 3, 2008" + }, + { + "category": "mining", + "medium": "email", + "email_id": "3", + "text": "The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.", + "date": "November 3, 2008" + }, + { + "category": "motives", + "medium": "email", + "email_id": "4", + "text": "Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.", + "date": "November 7, 2008" + }, + { + "category": "p2p-networks, government", + "medium": "email", + "email_id": "4", + "text": "Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.", + "date": "November 7, 2008" + }, + { + "category": "mining, difficulty", + "medium": "email", + "email_id": "5", + "text": "As computers get faster and the total computing proof-of-worker applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.", + "date": "November 8, 2008" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "5", + "text": "The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase. Coins have to get initially distributed somehow, and a constant rate seems like the best formula.", + "date": "November 8, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "6", + "text": "Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "6", + "text": "Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.", + "date": "November 9, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "6", + "text": "The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.", + "date": "November 9, 2008" + }, + { + "category": "nodes, mining, proof-of-work", + "medium": "email", + "email_id": "6", + "text": "It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU proof-of-worker proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "6", + "text": "The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.", + "date": "November 9, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "6", + "text": "When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.", + "date": "November 9, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "7", + "text": "It's not a problem if transactions have to wait one or a few extra cycles to get into a block.", + "date": "November 9, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "8", + "text": "The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.", + "date": "November 9, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "8", + "text": "A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort. If the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.", + "date": "November 9, 2008" + }, + { + "category": "nodes, proof-of-work", + "medium": "email", + "email_id": "8", + "text": "When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.", + "date": "November 9, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "8", + "text": "The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU proof-of-worker to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history.", + "date": "November 9, 2008" + }, + { + "category": "fees, bitcoin-economics", + "medium": "email", + "email_id": "9", + "text": "If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.", + "date": "November 10, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "When there are multiple double-spent versions of the same transaction, one and only one will become valid.", + "date": "November 11, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.", + "date": "November 11, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "10", + "text": "The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from \"unconfirmed\" to \"invalid\". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.", + "date": "November 11, 2008" + }, + { + "category": "difficulty", + "medium": "email", + "email_id": "10", + "text": "The target time between blocks will probably be 10 minutes. Every block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.", + "date": "November 11, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "10", + "text": "Instantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.", + "date": "November 11, 2008" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "10", + "text": "With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.", + "date": "November 11, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "11", + "text": "The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\nA number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU proof-of-worker to crack it fast enough if a majority of them attack at the same time. \n They don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first. They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.\n After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU proof-of-worker per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU proof-of-worker exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.\n The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.", + "date": "November 13, 2008" + }, + { + "category": "nodes, mining", + "medium": "email", + "email_id": "12", + "text": "Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.", + "date": "November 14, 2008" + }, + { + "category": "motives", + "medium": "email", + "email_id": "12", + "text": "It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.", + "date": "November 13, 2008" + }, + { + "category": "releases", + "medium": "email", + "email_id": "13", + "text": "I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.", + "date": "November 17, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "13", + "text": "A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "13", + "text": "There's no need for reporting of \"proof of double spending\" like that. If the same chain contains both spends, then the block is invalid and rejected. \n Same if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "13", + "text": "We're not \"on the lookout\" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.", + "date": "November 17, 2008" + }, + { + "category": "proof-of-work, mining", + "medium": "email", + "email_id": "13", + "text": "The proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU proof-of-worker. Anyone's chance of finding a solution at any time is proportional to their CPU proof-of-worker.", + "date": "November 17, 2008" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "13", + "text": "There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.", + "date": "November 17, 2008" + }, + { + "category": "proof-of-work", + "medium": "email", + "email_id": "14", + "text": "The credential that establishes someone as real is the ability to supply CPU proof-of-worker.", + "date": "November 17, 2008" + }, + { + "category": "double-spending", + "medium": "email", + "email_id": "14", + "text": "The race is to spread your transaction on the network first. Think 6 degrees of freedom -- it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network. During those 2 minutes, the merchant's nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting. \n If the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that's not going to be worth it for the scammer.", + "date": "November 17, 2008" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "14", + "text": "If a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do. If they really want to optimize, and it's a large download, they could cancel the download in the middle if the transaction comes back double-spent. If it's website access, typically it wouldn't be a big deal to let the customer have access for 5 minutes and then cut off access if it's rejected. Many such sites have a free trial anyway.", + "date": "November 17, 2008" + }, + { + "category": "releases, bitcoin-design", + "medium": "email", + "email_id": "15", + "text": "I believe I've worked through all those little details over the last year and a half while coding it, and there were a lot of them. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)", + "date": "November 17, 2008" + }, + { + "category": "releases", + "medium": "email", + "email_id": "16", + "text": "Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.", + "date": "January 9, 2009" + }, + { + "category": "nodes", + "medium": "email", + "email_id": "16", + "text": "If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections.", + "date": "January 9, 2009" + }, + { + "category": "mining", + "medium": "email", + "email_id": "16", + "text": "You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent.", + "date": "January 9, 2009" + }, + { + "category": "transactions", + "medium": "email", + "email_id": "16", + "text": "There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.", + "date": "January 9, 2009" + }, + { + "category": "bitcoin-economics", + "medium": "email", + "email_id": "16", + "text": "Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free.", + "date": "January 9, 2009" + }, + { + "category": "cryptocurrency", + "medium": "email", + "email_id": "17", + "text": "I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet.", + "date": "January 17, 2009" + }, + { + "category": "micropayments", + "medium": "email", + "email_id": "17", + "text": "It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. \"Send X bitcoins to my priority hotline at this IP and I'll read the message personally.\"", + "date": "January 17, 2009" + }, + { + "category": "micropayments", + "medium": "email", + "email_id": "17", + "text": "Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.", + "date": "January 17, 2009" + }, + { + "category": "micropayments, bitcoin-economics", + "medium": "email", + "email_id": "17", + "text": "It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.", + "date": "January 17, 2009" + }, + { + "category": "cryptocurrency", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work, double-spending", + "text": "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 hash-based 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 proof-of-worker. As long as a majority of CPU proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties", + "text": "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 non-reversible services. With the possibility of reversal, the need for trust spreads.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "trusted-third-parties, cryptocurrency", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "double-spending, proof-of-work", + "text": "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 proof-of-worker than any cooperating group of attacker nodes.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "economics, double-spending", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, cryptocurrency, transactions", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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. 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work", + "text": "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 proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "proof-of-work, difficulty", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, nodes, proof-of-work", + "text": "The steps to run the network are as follows:\n\n1. New transactions are broadcast to all nodes.\n2. Each node collects new transactions into a block.\n3. Each node works on finding a difficult proof-of-work for its block.\n4. When a node finds a proof-of-work, it broadcasts the block to all nodes.\n5. Nodes accept the block only if all transactions in it are valid and not already spent.\n6. 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, bitcoin-economics", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "fees, bitcoin-economics", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, bitcoin-economics", + "text": "The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU proof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design", + "text": "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, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, nodes", + "text": "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. \nAs such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overproof-of-workered 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 overproof-of-worker 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions, bitcoin-design", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "transactions, privacy, trusted-third-parties", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "addresses, privacy", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "mining, proof-of-work", + "text": "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.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "bitcoin-design, trusted-third-parties", + "text": "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 proof-of-worker.", + "medium": "whitepaper", + "date": "October 31, 2008" + }, + { + "category": "nodes, mining", + "text": "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 proof-of-worker, 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.", + "medium": "whitepaper", + "date": "October 31, 2008" + } + ] \ No newline at end of file diff --git a/lnbits/extensions/gerty/templates/gerty/_api_docs.html b/lnbits/extensions/gerty/templates/gerty/_api_docs.html new file mode 100644 index 00000000..e3b72e8c --- /dev/null +++ b/lnbits/extensions/gerty/templates/gerty/_api_docs.html @@ -0,0 +1,25 @@ + +

+ Gerty (your bitcoin assistant): Use the software Gerty or + hardware Gerty
+ + Created by, + Black Coffee, + Ben Arc +

+ + diff --git a/lnbits/extensions/gerty/templates/gerty/gerty.html b/lnbits/extensions/gerty/templates/gerty/gerty.html new file mode 100644 index 00000000..d45484a4 --- /dev/null +++ b/lnbits/extensions/gerty/templates/gerty/gerty.html @@ -0,0 +1,244 @@ +{% extends "public.html" %} {% block toolbar_title %} Gerty: {% raw %}{{ +gertyname }}{% endraw %}{% endblock %}{% block page %} {% raw %} + +
+ + + {{fun_exchange_market_rate["amount"]}} + {{fun_exchange_market_rate["unit"].split(" ")[1]}} + + + + +
+

"{{fun_satoshi_quotes["quote"]}}"

+ ~ Satoshi {{fun_satoshi_quotes["date"]}} +
+ +
+ +
+ + + {{wallet["amount"]}} + ({{wallet["name"]}}) + + +
+ +
+ + +
Onchain
+ + +

+ {{item[0].value}}: {{item[1].value}} +

+ + + + + +
Mining
+ + +

+ {{item[0].value}}: {{item[1].value}} +

+ + + + + +
Lightning (Last 7 days)
+ + +

+ {{item[0].value}}: {{item[1].value}} +

+ + + + + +
Servers to check
+ + +
+
+ + + + {{item[0].value}} + + + +
+
+ + {{item[1].value}} + + + {{item[1].value}} + + + {{item[1].value}} + +
+
+ + +
+ +{% endraw %} {% endblock %} {% block scripts %} + +{% endblock %} diff --git a/lnbits/extensions/gerty/templates/gerty/index.html b/lnbits/extensions/gerty/templates/gerty/index.html new file mode 100644 index 00000000..0c7155e0 --- /dev/null +++ b/lnbits/extensions/gerty/templates/gerty/index.html @@ -0,0 +1,798 @@ +{% extends "base.html" %} {% from "macros.jinja" import window_vars with context +%} {% block page %} +
+
+ + + New Gerty + + + + + +
+
+
Gerty
+
+
+ Export to CSV +
+
+ + {% raw %} + + + + {% endraw %} + + + +
+ +
+ + +
+
+
+ {{ SITE_TITLE }} Gerty extension +
+
+
+ +
+
+ + + + {% include "gerty/_api_docs.html" %} + + +
+ + + + + + Displays random quotes from Satoshi + + + + + + +
+ + + + Hit enter to add values + + + + Hit enter to add values + + + +
+ + + + The amount of time in seconds between screen updates + + + +
+ Create Gerty + + Update Gerty + + Cancel + +
+ + + +
+{% endblock %} {% block scripts %} {{ window_vars(user) }} + +{% endblock %} {% block styles %} + +{% endblock %} diff --git a/lnbits/extensions/gerty/views.py b/lnbits/extensions/gerty/views.py new file mode 100644 index 00000000..66194a50 --- /dev/null +++ b/lnbits/extensions/gerty/views.py @@ -0,0 +1,37 @@ +import json +from http import HTTPStatus + +from fastapi import Request +from fastapi.params import Depends +from fastapi.templating import Jinja2Templates +from loguru import logger +from starlette.exceptions import HTTPException +from starlette.responses import HTMLResponse + +from lnbits.core.models import User +from lnbits.decorators import check_user_exists + +from . import gerty_ext, gerty_renderer +from .crud import get_gerty +from .views_api import api_gerty_json + +templates = Jinja2Templates(directory="templates") + + +@gerty_ext.get("/", response_class=HTMLResponse) +async def index(request: Request, user: User = Depends(check_user_exists)): + return gerty_renderer().TemplateResponse( + "gerty/index.html", {"request": request, "user": user.dict()} + ) + + +@gerty_ext.get("/{gerty_id}", response_class=HTMLResponse) +async def display(request: Request, gerty_id): + gerty = await get_gerty(gerty_id) + if not gerty: + raise HTTPException( + status_code=HTTPStatus.NOT_FOUND, detail="Gerty does not exist." + ) + return gerty_renderer().TemplateResponse( + "gerty/gerty.html", {"request": request, "gerty": gerty_id} + ) diff --git a/lnbits/extensions/gerty/views_api.py b/lnbits/extensions/gerty/views_api.py new file mode 100644 index 00000000..7272fb7d --- /dev/null +++ b/lnbits/extensions/gerty/views_api.py @@ -0,0 +1,191 @@ +import json +import math +import os +import random +import time +from datetime import datetime +from http import HTTPStatus + +import httpx +from fastapi import Query +from fastapi.params import Depends +from fastapi.templating import Jinja2Templates +from lnurl import decode as decode_lnurl +from loguru import logger +from starlette.exceptions import HTTPException + +from lnbits.core.crud import get_user, get_wallet_for_key +from lnbits.core.services import create_invoice +from lnbits.core.views.api import api_payment, api_wallet +from lnbits.decorators import WalletTypeInfo, get_key_type, require_admin_key +from lnbits.utils.exchange_rates import satoshis_amount_as_fiat + +from . import gerty_ext +from .crud import ( + create_gerty, + delete_gerty, + get_gerty, + get_gertys, + get_mempool_info, + update_gerty, +) +from .helpers import * +from .models import Gerty, MempoolEndpoint + + +@gerty_ext.get("/api/v1/gerty", status_code=HTTPStatus.OK) +async def api_gertys( + all_wallets: bool = Query(False), wallet: WalletTypeInfo = Depends(get_key_type) +): + wallet_ids = [wallet.wallet.id] + if all_wallets: + wallet_ids = (await get_user(wallet.wallet.user)).wallet_ids + + return [gerty.dict() for gerty in await get_gertys(wallet_ids)] + + +@gerty_ext.post("/api/v1/gerty", status_code=HTTPStatus.CREATED) +@gerty_ext.put("/api/v1/gerty/{gerty_id}", status_code=HTTPStatus.OK) +async def api_link_create_or_update( + data: Gerty, + wallet: WalletTypeInfo = Depends(get_key_type), + gerty_id: str = Query(None), +): + logger.debug(data) + if gerty_id: + gerty = await get_gerty(gerty_id) + if not gerty: + raise HTTPException( + status_code=HTTPStatus.NOT_FOUND, detail="Gerty does not exist" + ) + + if gerty.wallet != wallet.wallet.id: + raise HTTPException( + status_code=HTTPStatus.FORBIDDEN, + detail="Come on, seriously, this isn't your Gerty!", + ) + + data.wallet = wallet.wallet.id + gerty = await update_gerty(gerty_id, **data.dict()) + else: + gerty = await create_gerty(wallet_id=wallet.wallet.id, data=data) + + return {**gerty.dict()} + + +@gerty_ext.delete("/api/v1/gerty/{gerty_id}") +async def api_gerty_delete( + gerty_id: str, wallet: WalletTypeInfo = Depends(require_admin_key) +): + gerty = await get_gerty(gerty_id) + + if not gerty: + raise HTTPException( + status_code=HTTPStatus.NOT_FOUND, detail="Gerty does not exist." + ) + + if gerty.wallet != wallet.wallet.id: + raise HTTPException(status_code=HTTPStatus.FORBIDDEN, detail="Not your Gerty.") + + await delete_gerty(gerty_id) + raise HTTPException(status_code=HTTPStatus.NO_CONTENT) + + +@gerty_ext.get("/api/v1/gerty/satoshiquote", status_code=HTTPStatus.OK) +async def api_gerty_satoshi(): + return await get_satoshi + + +@gerty_ext.get("/api/v1/gerty/pages/{gerty_id}/{p}") +async def api_gerty_json(gerty_id: str, p: int = None): # page number + gerty = await get_gerty(gerty_id) + + if not gerty: + raise HTTPException( + status_code=HTTPStatus.NOT_FOUND, detail="Gerty does not exist." + ) + + display_preferences = json.loads(gerty.display_preferences) + + enabled_screen_count = 0 + + enabled_screens = [] + + for screen_slug in display_preferences: + is_screen_enabled = display_preferences[screen_slug] + if is_screen_enabled: + enabled_screen_count += 1 + enabled_screens.append(screen_slug) + + logger.debug("Screeens " + str(enabled_screens)) + data = await get_screen_data(p, enabled_screens, gerty) + + next_screen_number = 0 if ((p + 1) >= enabled_screen_count) else p + 1 + + # get the sleep time + sleep_time = gerty.refresh_time if gerty.refresh_time else 300 + utc_offset = gerty.utc_offset if gerty.utc_offset else 0 + if gerty_should_sleep(utc_offset): + sleep_time_hours = 8 + sleep_time = 60 * 60 * sleep_time_hours + + return { + "settings": { + "refreshTime": sleep_time, + "requestTimestamp": get_next_update_time(sleep_time, utc_offset), + "nextScreenNumber": next_screen_number, + "showTextBoundRect": False, + "name": gerty.name, + }, + "screen": { + "slug": get_screen_slug_by_index(p, enabled_screens), + "group": get_screen_slug_by_index(p, enabled_screens), + "title": data["title"], + "areas": data["areas"], + }, + } + + +###########CACHED MEMPOOL############## + + +@gerty_ext.get("/api/v1/gerty/fees-recommended/{gerty_id}") +async def api_gerty_get_fees_recommended(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("fees_recommended", gerty) + + +@gerty_ext.get("/api/v1/gerty/hashrate-1w/{gerty_id}") +async def api_gerty_get_hashrate_1w(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("hashrate_1w", gerty) + + +@gerty_ext.get("/api/v1/gerty/hashrate-1m/{gerty_id}") +async def api_gerty_get_hashrate_1m(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("hashrate_1m", gerty) + + +@gerty_ext.get("/api/v1/gerty/statistics/{gerty_id}") +async def api_gerty_get_statistics(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("statistics", gerty) + + +@gerty_ext.get("/api/v1/gerty/difficulty-adjustment/{gerty_id}") +async def api_gerty_get_difficulty_adjustment(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("difficulty_adjustment", gerty) + + +@gerty_ext.get("/api/v1/gerty/tip-height/{gerty_id}") +async def api_gerty_get_tip_height(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("tip_height", gerty) + + +@gerty_ext.get("/api/v1/gerty/mempool/{gerty_id}") +async def api_gerty_get_mempool(gerty_id): + gerty = await get_gerty(gerty_id) + return await get_mempool_info("mempool", gerty) diff --git a/lnbits/extensions/hivemind/README.md b/lnbits/extensions/hivemind/README.md index 1e9667ec..49e821ec 100644 --- a/lnbits/extensions/hivemind/README.md +++ b/lnbits/extensions/hivemind/README.md @@ -1,3 +1,3 @@

Hivemind

-Placeholder for a future Bitcoin Hivemind extension. +Placeholder for a future Bitcoin Hivemind extension. diff --git a/lnbits/extensions/hivemind/templates/hivemind/index.html b/lnbits/extensions/hivemind/templates/hivemind/index.html index 40a320f0..bc92f9fe 100644 --- a/lnbits/extensions/hivemind/templates/hivemind/index.html +++ b/lnbits/extensions/hivemind/templates/hivemind/index.html @@ -6,9 +6,10 @@ This extension is just a placeholder for now.

- Hivemind is a Bitcoin sidechain - project for a peer-to-peer oracle protocol that absorbs accurate data into - a blockchain so that Bitcoin users can speculate in prediction markets. + Hivemind + is a Bitcoin sidechain project for a peer-to-peer oracle protocol that + absorbs accurate data into a blockchain so that Bitcoin users can + speculate in prediction markets.

These markets have the potential to revolutionize the emergence of @@ -17,8 +18,8 @@

This extension will become fully operative when the - BIP300 soft-fork gets activated and - Bitcoin Hivemind is launched. + BIP300 + soft-fork gets activated and Bitcoin Hivemind is launched.

diff --git a/lnbits/extensions/invoices/templates/invoices/pay.html b/lnbits/extensions/invoices/templates/invoices/pay.html index 7b6452dc..636dbc90 100644 --- a/lnbits/extensions/invoices/templates/invoices/pay.html +++ b/lnbits/extensions/invoices/templates/invoices/pay.html @@ -251,10 +251,13 @@ block page %} @hide="closeQrCodeDialog" > - + diff --git a/lnbits/extensions/invoices/views.py b/lnbits/extensions/invoices/views.py index 08223df8..b492a67c 100644 --- a/lnbits/extensions/invoices/views.py +++ b/lnbits/extensions/invoices/views.py @@ -30,7 +30,7 @@ async def index(request: Request, user: User = Depends(check_user_exists)): @invoices_ext.get("/pay/{invoice_id}", response_class=HTMLResponse) -async def index(request: Request, invoice_id: str): +async def pay(request: Request, invoice_id: str): invoice = await get_invoice(invoice_id) if not invoice: diff --git a/lnbits/extensions/jukebox/templates/jukebox/_api_docs.html b/lnbits/extensions/jukebox/templates/jukebox/_api_docs.html index 4bae4965..637e1453 100644 --- a/lnbits/extensions/jukebox/templates/jukebox/_api_docs.html +++ b/lnbits/extensions/jukebox/templates/jukebox/_api_docs.html @@ -2,6 +2,7 @@ To use this extension you need a Spotify client ID and client secret. You get these by creating an app in the Spotify developers dashboard here @@ -9,9 +10,14 @@

Select the playlists you want people to be able to pay for, share the frontend page, profit :)

Made by, - benarc. - Inspired by, benarc. Inspired by, + pirosb3 diff --git a/lnbits/extensions/livestream/templates/livestream/index.html b/lnbits/extensions/livestream/templates/livestream/index.html index a93bab71..8749a9cf 100644 --- a/lnbits/extensions/livestream/templates/livestream/index.html +++ b/lnbits/extensions/livestream/templates/livestream/index.html @@ -163,6 +163,7 @@ {{ props.row.name }} @@ -191,7 +192,7 @@ - + Standalone QR Code for this track

- + diff --git a/lnbits/extensions/lnaddress/templates/lnaddress/_api_docs.html b/lnbits/extensions/lnaddress/templates/lnaddress/_api_docs.html index 12173c95..300f56e9 100644 --- a/lnbits/extensions/lnaddress/templates/lnaddress/_api_docs.html +++ b/lnbits/extensions/lnaddress/templates/lnaddress/_api_docs.html @@ -13,13 +13,16 @@ Charge people for using your domain name...
More details
Created by, - talvasconcelostalvasconcelos

diff --git a/lnbits/extensions/lnaddress/templates/lnaddress/display.html b/lnbits/extensions/lnaddress/templates/lnaddress/display.html index 9436525d..2dca8f48 100644 --- a/lnbits/extensions/lnaddress/templates/lnaddress/display.html +++ b/lnbits/extensions/lnaddress/templates/lnaddress/display.html @@ -184,10 +184,10 @@
- + diff --git a/lnbits/extensions/lnaddress/templates/lnaddress/index.html b/lnbits/extensions/lnaddress/templates/lnaddress/index.html index 4c833932..55d900f4 100644 --- a/lnbits/extensions/lnaddress/templates/lnaddress/index.html +++ b/lnbits/extensions/lnaddress/templates/lnaddress/index.html @@ -194,6 +194,7 @@