| New Script | |
| Opcode.fromSymbol('type'), | |
| Opcode.fromInt(rules.types.TRANSFER), | |
| Opcode.fromSymbol('equal'), | |
| Opcode.fromSymbol('if'), | |
| Opcode.fromSymbol('dup'), | |
| Opcode.fromSymbol('blake160'), | |
| Opcode.fromPush(pubkeyhash), |
| #!/bin/bash | |
| # First argument must be the path to | |
| # the hsd gitrepo, ie ./hsd-auction $PWD/hsd | |
| HSD_="$1/bin/hsd" | |
| HSW_CLI="$1/bin/hsw-cli" | |
| HSD_CLI="$1/bin/hsd-cli" | |
| export HSD_NETWORK=regtest |
| #!/bin/bash | |
| # Run from the root of the gitrepo | |
| # Starts hsd, can pass debug as arg to run with | |
| # debugger. | |
| DIR="$( cd "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )" | |
| ROOTDIR=$(echo $(cd $DIR/.. && pwd)) | |
| NODE="$ROOTDIR/bin/node" |
| ## Output Structuring | |
| In a UTXO-based blockchain, the typical transaction output consists of a | |
| _locking script_, or _predicate_, combined with an output value. | |
| A typical bitcoin output exists as a struct of: | |
| fig. 16 | |
| ``` c |
Handshake can be used to resolve names with a sliding scale of trust assumptions. In general, the more trust that the user places in the system, the better user experience. The easiest way to resolve Handshake names involves configuring DNS settings and not worrying at all about blockchain state. This means that the user is trusting the DNS service provider to properly validate all state transitions and relying on traditional means of DNS security. Running a light client as a DNS server removes the trust assumption that the name state is coming from the heaviest chain. The light client will sync the headers (technically a subset of the header, designed specifically to be lightweight), verify the proof of work is correct and ask for urkel proofs over the p2p network to validate against the tree root contained in the block header. The p2p connections are optionally encrypted with brontide (BOLT #8)
The hsd wallet has an edge case regarding watch only wallet usage
that results in the incorrect path being returned to the client.
This will result in invalid signature creation because the wrong
key will be derived and used to sign the transaction. Using an
extra API call, it is possible to work around this problem right
now, but it is not ideal and is fixable.
| #!/bin/bash | |
| # pull gmax's lattest banlist, replace ./bitcoin-cli | |
| # with bcoin-cli and write it to disk as a bash script | |
| # WARNING: please inspect the file before executing it | |
| # works correctly as of 4/10/19 | |
| curl -s https://people.xiph.org/~greg/banlist.cli.txt \ | |
| | sed 's/\.\/bitcoin-cli/bcoin-cli\ rpc/g' \ | |
| | sed '1s/^/#!\/bin\/bash\n\n/' > banlist.sh |
| #!/usr/bin/env node | |
| /* | |
| * write.js | |
| * | |
| * usage: writes a string to a file | |
| * | |
| * $ ./write.js <path to file> <contents of file> | |
| */ |
I hereby claim:
- I am tynes on github.
- I am tynes (https://keybase.io/tynes) on keybase.
- I have a public key ASAVvc3HHzL9Bo-ONgHr5kPLb36EBcQWsmsgLL1y0jMPaAo
To claim this, I am signing this object: