- Choose the "WAN Interface" strategy to use when determining the IP address used when performing updates.
- In the "Service Provider" field, choose "User Defined". Additional configuration fields appear.
- In the "Provider Host" field, enter
domains.google.com - In the "Service API" field, enter
/nic/update?myip=###IP###&hostname=your.hostname.here, replacing "your.hostname.here" with the fully qualified name of the record you wish to dynamically update. - In the "Auth Type" field, choose "Basic" (this is the default).
- In the "Connection Type" field, choose "HTTPS".
| /* | |
| * | |
| * $Id smurf.c,v 4.0 1997/10/11 13:02:42 EST tfreak Exp $ | |
| * | |
| * spoofs icmp packets from a host to various broadcast addresses resulting | |
| * in multiple replies to that host from a single packet. | |
| * | |
| * mad head to: | |
| * nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea pig, | |
| * MissSatan for swallowing, napster for pimping my sister, the guy that |
Taproot is an interesting technology to enable multiparty privacy on a bitcoin. Currently, there is a problem with multiparty contracts in that they are obvious deviation from the most common script type (P2PKH), which hurts privacy. The script that gets used will typically indicate exactly what kind of protocol was at play. Also complex P2SH scripts take extra resources (transaction size and CPU cycles).
The basic idea with Taproot is that instead of P2SH where a script is committed by a hash, you can hide a script (or set of possible scripts) as a commitment within a normal-looking public key. Now there are two ways to spend from this public key:
- Create a normal transaction signature using the public key, or,
- Reveal the commitment, and provide parameters that satisfy the revealed script.
To do #1, it means you need to know the private key, or, you have a set of signers who are able to produce a signature (that's where Schnor
Here are the transaction IDs (and links to the block explorers) for the first livenet Ethereum and Ripple Consensus Ledger (RCL) escrowed transfers comprising an Interledger payment.
- Ethereum prepare:
0x00cbb6149b9cfb3cedf280251c3060b2a38776fa7792b578b6f9f39ce5ee0266 - RCL prepare:
7F0A5F16C84568D96DA6A66058CD9EAA881236237642BF7427A458957A752B6B - RCL fulfill:
12A4CAFAE95254844513C5C11488A1195C08DEFF673C97AC74AAC121935DDE36 - Ethereum fulfill:
0xb59dd839ab0b5e7d4e663b7cfc0ddb70eaf73dd2785b3d3a4abdf1a61817007d
SHA-256 Condition: `d2
Edit: I've done the same process every couple years since 2013 (Mountain Lion, Mavericks and High Sierra).
I just replaced the hard drive of my mbp and decided to do a clean install of Mountain Lion (10.8.5) since I was still using Snow Leopard (10.6.8).
I kinda regret for not using Boxen to automate the process, but TBH I have this laptop for almost 3yrs and this is the first
Herewith is an example of encoding to and from base64 using OpenSSL's C library. Code presented here is both binary safe, and portable (i.e. it should work on any Posix compliant system e.g. FreeBSD and Linux).
The MIT License (MIT)
Copyright (c) 2013 Barry Steyn
| # Obtaining server certificate | |
| openssl s_client -CAfile ca.crt -connect "server.domain.com:443" < /dev/null 2> /dev/null | openssl x509 -outform PEM > server.crt | |
| # You may get an error like the following | |
| # CONNECTED(00000003) | |
| # 140048174458520:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: | |
| # --- | |
| # no peer certificate available | |
| # --- | |
| # No client certificate CA names sent |
| import System; | |
| import System.Windows.Forms; | |
| import Fiddler; | |
| // INTRODUCTION | |
| // | |
| // Well, hello there! | |
| // | |
| // Don't be scared! :-) | |
| // |
13/7/2019
To read the context see the main document Design for improving joinmarket's resistance to sybil attacks using fidelity bonds.
We want to come up with a mathematical formula which gives the value of a fidelity bond. We want this function to be in the best interests of takers who use it. We aim for them to get the best possible sybil resistance.
I'll first give some thoughts on the design of the wallet in general, before explaining current and future SegWit wallet support.
Conceptually, a wallet currently contains mapKeys, mapScripts, and setWatchOnly, which together determine which outputs
are considered "ours" (IsMine), and how to solve and sign for them. Then the wallet further contains key metadata, key chains, and key pool at the wallet level that feed into this.
We determine whether outputs are ours using ad-hoc logic that mostly answers the question "Could we sign this?", but with some notable exceptions:
