jonasschnelli

Problem

Bitcoin Core has been designed to synchronise/verify as fast as possible. This is usually desirable, though, on systems where other applications require a reasonable amount of CPU time (ex. desktop systems) the CPU usage maximisation of Bitcoin Core may be intrusive. While it is possible to configure Bitcoin Core to use less resources, it cannot be changed during runtime which leads to unideal user experience.

Concept of profiles

Profiles could help improve the situation by allowing to change the resource consumption profile during runtime.

Ideally, profiles could be recommended configuration sets for different machine- and use-case-types while the detailed settings could be tweaked via a configuration file (user defined resource profiles).

jonasschnelli

    char hrp[8];
    char bech32_str[128] = "xp1qqqqqq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgn";
    int range[4] = {10, 15, 20, 36};
    uint8_t dblcheck5[100] = {};
    size_t dblcheck5_len = 0;
    if (!bech32_decode(hrp, dblcheck5, &dblcheck5_len, bech32_str)) {
        printf("bech32_decode fails: '%s'\n", bech32_str);
    }
    uint8_t dblcheck8[128] = {};
    size_t dblcheck8_len = 0;

jonasschnelli

  BIP: ??? (tbr after sending to mailing list)
  Layer: Applications
  Title: BIP32 key-path-scheme for hot wallets
  Author&#58; Jonas Schnelli <dev@jonasschnelli.ch>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; 
  Status&#58; Draft
  Type&#58; Standards Track
  Created&#58; 2018&#45;06&#45;28

jonasschnelli

{
  "size": 17489,
  "bytes": 9119661,
  "usage": 33586032,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "fee_histogram": {
    "1": {
      "sizes": 2091772,

jonasschnelli

lightning_gossipd: pending node_announcement 0101faa9feb1b7e8402f2743a342c9e7540fa026ec8731a6888c27aa20f75a595104293205c2757d5f84dd4bea9c689dd487e06d8455b84b77c16602ccac8b37cf4c00005cd81c7a0385d5c1767ee6448488f2d020974f8d238ed4c6e6ae1ce136db15f2a468fef1063399ff435f726f736500000000000000000000000000000000000000000000000000000007013cadec052607 malformed? (version v0.7.0-471-ge902d9a)
0x563d16495146 send_backtrace
        common/daemon.c:40
0x563d16498f3c status_failed
        common/status.c:192
0x563d16489867 process_pending_node_announcement
        gossipd/routing.c:1315
0x563d1648ade0 routing_add_channel_update
        gossipd/routing.c:1892
0x563d16485d46 gossip_store_load

jonasschnelli

  BIP: ??? (tbr after sending to mailing list)
  Layer: Applications
  Title: Bech32X encoded keys
  Author&#58; Jonas Schnelli <dev@jonasschnelli.ch>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; 
  Status&#58; Draft
  Type&#58; Standards Track
  Created&#58; 2018&#45;06&#45;03

jonasschnelli

  BIP: ??? (tbr after sending to mailing list)
  Layer: Applications
  Title: Cipherseed – encrypted wallet seed
  Author&#58; Jonas Schnelli <dev@jonasschnelli.ch>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; 
  Status&#58; Draft
  Type&#58; Standards Track
  Created&#58; 2018&#45;06&#45;04

jonasschnelli

The AEAD is constructed as follows: for each packet, generate a Poly1305 key by taking 128 bits of ChaCha20 stream output generated using K_2 and an IV of zero. The chacha20 key-stream remains for follow up packets (don't change the IV and block counter) and will only be reset after a rekeying. A client may precompute the ChaCha20 key-stream up to the desired length.

A rekey MUST exact happen after 2^24 bytes (16MB) have been used from the key-stream. The rekeying can also happen in the middle of encrypting a payload. If the key-stream contains less than 128bits when starting to encrypt a packet, a rekeying MUST happen (to avoid a MAC key from two cipher instances).

The next symmetric cipher key MUST be calculated by `SHA256(SHA256(session ID || old_symmetric_cipher_key))`.

During a rekey, the packet length encryption instance keyed by K_1 must also reset (use the next symmatric cipher key, reset IV and block counter to zero).

The packet length encryption instance can therefor maximal encrypt 2^24/3+1+16

jonasschnelli

Enter the passphrase for /Users/jonasschnelli/Desktop/mycert.p12:
Traceback (most recent call last):
  File "/Users/jonasschnelli/Documents/bitcoin/signapple/codesign.py", line 6, in <module>
    main()
  File "/Users/jonasschnelli/Documents/bitcoin/signapple/signapple/__init__.py", line 71, in main
    args.func(args)
  File "/Users/jonasschnelli/Documents/bitcoin/signapple/signapple/__init__.py", line 15, in sign
    sign_mach_o(
  File "/Users/jonasschnelli/Documents/bitcoin/signapple/signapple/sign.py", line 805, in sign_mach_o
    cs.make_signature()

jonasschnelli

---
name: "bitcoin-dmg-signer"
distro: "ubuntu"
suites:
- "bionic"
architectures:
- "amd64"
packages:
- "faketime"
remotes: