bitauth / bitauth-ide Goto Github PK

View Code? Open in Web Editor NEW

80.0 8.0 17.0 20.2 MB

an online IDE for bitcoin (cash) contracts

Home Page: https://ide.bitauth.com

License: MIT License

HTML 0.32% TypeScript 90.56% JavaScript 0.56% CSS 8.56%

bitcoin-cash bitauth wallet ide bitcoin cryptocurrency bch bitcoin-script bsv btc

bitauth-ide's Introduction

BitAuth2017

Monorepo for the BitAuth2017 protocol standard. (full specification)

Get Involved

Watch the Presentation

Jump to Presentation Section:

Try the Demo CLI

This is a highly-simplified demo of message signing using a testnet BitAuth identity.

Getting Started

You'll need to have Node (v6 or later) and Yarn installed. To build the demo, clone this repo and install the dependencies with the following commands:

git clone https://github.com/bitjson/bitauth2017.git
cd bitauth2017/lib && yarn && yarn link
cd ../demo && yarn && yarn link bitauth

Step 1 – Generate Key & Address

Generate a new HD key for our testing by running:

yarn genkey

This will generate the file: data/private.json, and output a new testnet address.

Step 2 – Fund the Address

Paste your testnet address into a testnet bitcoin faucet, and send some funds.

Step 3 – Create a Testnet BitAuth Identity

Once the funds have been sent, create your BitAuth Identity by running:

yarn genid

This command will fetch all UTXOs sent to your address, create a new Authentication Transaction (authtx) at data/authbase.bitcointx, and broadcast the transaction to the testnet.

This transaction will serve as the authbase of your testnet identity. It's currently single-signature, but can be upgraded to more complex authentication requirements with additional authtxs.

If everything looks good, you can broadcast the transaction by running:

yarn broadcast

Your transaction will look something like 6213455da06d44842cde9b1b271aa186e6ec0b2b3b2df82a55aa54da756339d4.

01000000014298e0e9f1fa4aad63b25a701095b937150be03c9304a86dd846a098a48dd8dd000000006a473044022078cc85f6d83fea8961a6afa8f1b524a5fd618526c9f98c63b00d3fb1d3f4008a0220248bb35fb12c46349f6c94aa224db16d32ecbb75e6ea8819116268261cfb78cc012103c8a2dc1bbbb5e261abcdc89c03384c2b80330b84a52694725cd53d28aeb0f56fffffffff03405dc600000000001976a914cf7e9df9c834338aa1b310b288e2d91cf459c74388ac405dc600000000001976a914a1a767a9b17fdd3ee0f841568a369fd56d1fc5e288acfe318e0a000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac00000000

Step 4 – Sign a Message

With your identity ready, you can sign a message. You can modify message.txt if you'd like, then run:

yarn sign

This will sign the contents of message.txt and output signature.bitauthsig

Example using the authbase above:

01000000016213455da06d44842cde9b1b271aa186e6ec0b2b3b2df82a55aa54da756339d4010000006b483045022100a152595d0d0a74b18e1c528bc5da0500c98b2ab35d5c57034227b6232e9b889302202888b281e13a3a623d0f24c108685ffe30a67903d1b3e3d04c5effd741a977fe012102a9e7d0b9d3dd050105140986901ddfbdf3398e14d9f906d4076af3cc2af32b3effffffff010040075af07507002a6a286861736832353600fc75eaa433dac149fd2ed5304f98e1542ce16a77fbb57a91fd489d87d2bc0a8500000000

Step 5 – Verify the Signature

To verify the signature, run:

yarn verify

This will validate that your identity properly signed the exact contents of message.txt.

$ node build/verify.js
Verifying the signature transaction, given authhead: 6213455da06d44842cde9b1b271aa186e6ec0b2b3b2df82a55aa54da756339d4

✔ Signature transaction is valid.

Verifying the message digest is correct:
Message as string:
Hello, BitAuth!

Message as hex:
48656c6c6f2c2042697441757468210a
Message digest using algorithm hash256:
fc75eaa433dac149fd2ed5304f98e1542ce16a77fbb57a91fd489d87d2bc0a85

Signature transaction digest info:
algorithm: hash256
message digest: fc75eaa433dac149fd2ed5304f98e1542ce16a77fbb57a91fd489d87d2bc0a85

✔ Message digest matches.

✨  Done in 0.37s.

Use the Library

An alpha version of the library is available for Node v6 and above (as well as Typescript typings).

git clone https://github.com/bitjson/bitauth.git
cd lib && yarn
yarn link

See the readme for details.

Similar Projects

Please note, there have been a number of other projects which apply concepts in bitcoin for identity and authentication purposes.

My hope is that BitPay's BitAuth Node.js project will be deprecated in favor of the @bitjson/passport-bitauth module in this one, and that the infrastructure work in the following projects will migrate to the identity construction and authentication strategy utilized by this one:

AirBitz Edge Security - a single-signon security platform for blockchain apps
BitID – very well-developed set of infrastructure for authentication. Bitcoin-like public/private keypair.
BitPay's BitAuth – a Node.js implementation of Jeff Garzik's Identity Protocol v1. Bitcoin-like public/private keypair.
BlockAuth - Decentralized Identity & Authentication by Neuroware
BlockchainID (old) – Decentralized alternative to Facebook Login and OpenID
Blockstack Blockchain ID – a unique identifier that is secured by a blockchain
Blockstack Auth JS - Blockstack Auth library, written in node.js
Certcoin - A Decentralized PKI for Highly-Available Hierarchical Identities
identity-on-bitcoin - create identities, anchor them into the Bitcoin Blockchain, and authorize service providers to access specific attributes

bitauth-ide's People

Contributors

Stargazers

Watchers

Forkers

dfoderick loudbinary quantumbitcoin microhexhq bitjson cryptobuks1 327585419 bitsent msalcala11 baby636 mainnet-pat hitech777 captake tay-space phcitizen eskyee pandapsy

bitauth-ide's Issues

Walk-through Mode

It would be quite useful to provide a "walk-through mode", where every sample in the evaluation is placed on a new line, and the instruction descriptions are placed beside the development of the stack. Then users can read each line, and see a description of what's happening, like:

OP_1: Push the Script Number 1 onto the stack.         | 1
OP_DUP: Duplicate the top element on the stack.        | 1 1

This is mostly a feature for reviewing scripts rather than writing them, so it might be a good part of a feature to share scripts. (It doesn't need to be integrated into the actual Editor mode, but could be opened in a dialog, for example.)

Evaluation "spacers" can be a little off

The issue is that no Samples inside the evaluation end on that line. (One begins, but it ends on line 5.) This could be solved by adding an "empty" Sample right after the beginning of every internal evaluation.

Linting, security analysis via symbolic execution

It's probably not too difficult to programmatically determine if e.g. the locking script isn't secure against miners. Simplest check is to see if a checksig operation was done for each path.

If you'd be interested in this feature, please comment here.

language ambiguity: handling evaluation errors or empty results

Evaluations extract the last element in the stack.

If there is no last element, should this be a reduction error? If the evaluation ends with a state.error present, is this a reduction error?

I think we should probably be very conservative and error in both cases, but the current implementation ignores them.

Import a raw transaction

read.cash says:

..and one more feature request: there's Meep debugger by
@ChrisPacia
https://read.cash/@Read.Cash/how-to-use-bitcoin-cash-with-javascript-including-bitcoin-cash-contracts-08fdc194#meep it's really great, but you need to install it. It would've been cool if it were possible to import a raw hex transaction to BitAuth IDE and see why it fails.

(More comments in that thread.)

We currently support importing bytecode as a script, but it would be great if we could import a full raw transaction, and maybe choose to import any number of the inputs and outputs as the proper script types.

This would be a good feature to add once "transaction scenarios" are available, since we can also import the locktime + sequence numbers into scenarios.

Find a way to focus the EvaluationViewer on the most active part of the stack

read.cash says:

I think it would've been more helpful if BitAuth IDE showed the top of the stack on the left, rather than on the right. I mean right now this OP_SWAP affects the two items that are out of the view.

My thoughts:

That's great feedback, thanks! I've been trying to figure out how to do that better – when I was writing CashChannels, I also tended to have the stack scrolled all the way to the right as I was working. Reversing the order can get confusing though – <1> <2> <3> becomes 3 2 1.

One thing I'd not considered though – what if we use RTL ordering? Then stack items carry downward and order is preserved as expected, but stack operations are performed on the left-most elements. (So the view is always focused on the most active part of the stack.)

Feature Request - Export Script To Raw Hex

Title. Import works well, but there's no export or have I missed it?

Comment parsing is bugged

Unlocking script of:

/* A comment */
<something>
/* A second comment */
<something>

Things start breaking with multiple comments.

Right-click context menu for add/renaming/deleting scripts?

Blueprint has a great Context menu component for this. To start with, maybe the menu should just have a link to open the Script Options? Would at least help with discoverability.

BSV Support?

If anyone is interested in using Bitauth IDE to develop BSV authentication templates, please comment here.

The application is architected to make switching between VMs possible, it just requires a bit of development work to activate.

Templating time: lock-by-blockheight vs. lock-by-blocktime

There's an ambiguity with the authentication template format which I hadn't noticed initially:

For both OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY, the authentication template must be able to indicate the type of time-lock to be used, either "lock-by-blockheight" or "lock-by-blocktime".

Because sequence numbers are included with each input, this choice is "local" to each locking/unlocking pair in the case of OP_CHECKSEQUENCEVERIFY. However, because there is only one locktime per transaction, this choice is "global" for OP_CHECKLOCKTIMEVERIFY. So it's possible that two different locking/unlocking pairs cannot be used in a single transaction (if each requires the other "time type"). This also complicates interactive debugging in the IDE, since the user needs to be able to choose/switch between the two for testing.

I think the simplest solution to this problem may be to standardize around "lock-by-blocktime", since it covers the majority of use cases (including removing the CurrentBlockHeight variable type). This avoids further complicating transaction generation and simplifies the experience in the IDE.

If there's enough demand for a "lock-by-blockheight" use case, we can decide how to indicate "time-type" in a future version.

Support for data signatures

I ran out of time for the initial implementation, but I'm thinking about switching to a "parameterized" syntax for keys, e.g.:

keyname.public_key
keyname.signature:all_outputs - (A.K.A. sighash_all)
keyname.signature:corresponding_output - (A.K.A. sighash_single)
keyname.signature:all_outputs:anyone_can_pay
keyname.data_signature:IDENTIFIER – where IDENTIFIER is any script or variable ID

Hide elements of very deep stacks

Continuation of #8.

This might be a good candidate for another EvaluationViewerSettings toggle – we should compress the lower X elements of the stack into a single ... element to save horizontal viewing space.

This could be configurable, but I suspect that a standard collapse of anything deeper than 6 items would work well, since very few operations can reach deeper (OP_PICK and OP_ROLL). With a default collapse at 6, even actions like OP_2ROT are fully visualized.

Guide on 'Signatures' and 'Keys' not up-to-date

The 'Signatures' and 'Keys' sections of the Guide for BitauthIDE are not up-to-date.

We (@rkalis and I) realized this when working on CashScript and were looking for the BitauthIDE sigHash_UTXOS flag and for ecdsa_signature.

Missing stack items when grouped at 3

In the CashTokens demo, the Mint Token unlocking script is missing a stack item when stack items deeper than 3 are grouped:

Thanks to @jcramer for spotting this bug!

UI: how do we show really deep stacks?

Currently, things start to visually break if your screen isn't wide enough.

At the very least, we should truncate (with ellipsis) items more and more aggressively as we run low on horizontal space. At some point, maybe we collapse the lowest few items into a single interactive unit, like Blueprint's Breadcrumbs component?

OP_TOALTSTACK is an unknown opcode

The first opcode in one of my script is OP_TOALTSTACK and I got a message: Called an unknown opcode.

When switching between entities, the name and entity_id does not change.

Using Chrome Version 97.0.4692.71 (Official Build) (x86_64) on Mac:

Notice keys on the right are showing we are at signer1, signer2, signer3 respectively, but name and entity ID fields stay the same as those belonging to signer2.

The same behavior is observed when creating a new script from scratch and adding multiple entities.

Visualize the Alternate Stack and other state information

Currently we're only visualizing the stack (and the execution stack) in the EvaluationViewer. We should also make it possible to see the state of the alternate stack and maybe some other properties.

Note: in the meantime, you can click on a stack-line to log it in the developer console.

Flickering

A small bug:

import CashChannels https://ide.bitauth.com/import-gist/ca13abf369b5ecace6437cb86afa331f
enable reverse order
open Execute Authorization (Oracle)
try to scroll the script - the stack constantly switches from "normal" to "reverse" ordering on each scroll event

If script ends with incomplete push, display warning in evaluation editor

E.g. if the unlocking script is simply: 0x03, it might not be immediately obvious that the evaluation isn't happening because it's waiting for more bytes. (Or maybe the user forgot to surround it with a push: <0x03>.)

Show resolutions from within inlined scripts

Because the compilation results in evaluationOrderedCompilationResults don't include variable resolutions from scripts, it's not possible to show the result of an operation which occurred inside an included script.

E.g. If my_script includes <some.signature.all_outputs>, and we include my_script in another_script, the StackItemIdentifyFunction won't have a result for some.signature.all_outputs.

To fix this, we'd need resolveScriptIdentifier to return it's own resolve property, and merge it into the parent resolve property. (Maybe under another property like source.)

Highlights for exceptions

Currently only success states are visually highlighted:

https://github.com/bitjson/bitauth-ide/blob/a2732ef59620511ca0cb02e2d468b01631225a7a/src/editor/editor-types.ts#L81-L98

It would be good if we could provide other highlights for things like "non-standard", "dirty stack", etc. (Unfortunately, these are network specific things too, so we need to figure out how to abstract that properly.)

Some dialogs won't scroll in Firefox

This is a bug in Blueprint. I patched it for the Guide dialog here, but it would be good to fix the issue for other dialogs if the user's screen height is unusually small. (Though not urgent, since the entire application generally requires a desktop screen size.)

OP_MUL highlighting (red waring)

OP_MUL has a red warning highlighting, so it looks like an invalid opcode.
Other arithmetic and stack operations are highlighted dark blue.

Instruction set reference

Related to #13, the IDE should include a full reference for all opcodes, breaking out groups of opcodes by type (push, numeric, crypto, stack, etc.) and describing each in a cheat-sheet format.

Disable evaluation / hide error messages in scripts which aren't intended for evaluation

Often it's useful to create an isolated script to represent a computed segment of bytecode, which is then used as a variable. When viewing this script, it's likely the evaluation will display an error message (when evaluated as a script, it's often nonsensical).

We should find a way to partially disable evaluation for these scripts.

One option: if the script is wrapped in an evaluation, and an error occurs when evaluating it's result, hide the "outer-most" evaluation. The evaluation within the script should still be visible, and maybe a button should allow the user to "unhide outer evaluation".

What is the parse-atl package?

What is the parse-atl package in the package.json? I had a look on github and npm but couldn't find it.

When switching between entities, the height of the description field doesn't adjust until clicked

When switching between and entity with a large description and an entity with a short description, the field remains stuck at the previous size.

Hide stack visualization for fully-unexecuted evaluations

While all evaluations occur during compilation, we can safely hide the internal stack visualization for evaluations which result in bytecode which is never executed. E.g. the stack visualization (current_block_time delay_seconds ...) for the evaluation in this locking script should be hidden since it's not relevant for the active unlocking script:

TransactionData -> AddressData

Consider renaming TransactionData to AddressData. WalletData must be created and saved at wallet creation-time, AddressData must (usually) be created and saved at address creation-time. (The only issue there is that AddressData doesn't fit quite as well for non-locking script usage.) Maybe InstanceData or something like that?

Confusing fade when switching from a "working" unlocking script to a failing one

When switching from a "working" unlocking script to a failing one, the stack viewer isn't faded, so it looks like the non-working unlocking script generated the still-visible results.

"Encountered an unknown opcode."

While most of the langauge, compiler, and IDE infrastructure is done, most of the instruction opcodes are still unimplemented in the bitcoin-ts Auth branch.

While the compiler and IDE technically work without the inline evaluations, not having them makes it pretty hard to be work on unique scripts. 😅

Pretty much every opcode outside the standard ones still needs to be implemented. As each is being implemented, we should carefully assemble test cases for each (like unit tests, rather than solely relying on the script-tests.json integration tests used in the C++ implementation). A strong set of functional unit tests for each opcode would go a long way in creating a standard spec for the virtual machine itself.

Replace Monaco View Zones hack with proper editor padding

Currently, Monaco editor doesn't support adding any sort of padding to the editor, but there are several strategies which can be used to emulate padding.

With just CSS padding, editor features are also shifted down. Note the scrollbar and scroll-decoration shadow are both 4px below the top of the "Channel" editor title bar:

We're using the view zone strategy to add a single line of margin to the top of each editor instance. Unfortunately, this requires us to use exactly 18px of padding. If/when Monaco editor supports customizing the padding around the editor, we should replace the current view zones hack (and maybe choose between 6px and 12px for padding).

Fade out unexecuted code

This would really help to make scripts visually simpler to work with – if available, we should pass evaluation information into the script editor as well, and use it to fade out all Samples which are skipped (using the showUnused option in Monaco).

More advanced hover information

Didn't quite make the cut for launch, but we have everything we need to show a lot more in the hover provider.

To see what's already done, place a console.dir(scriptEditorFrames) at the end of computeEditorState.

Bytecode Mapping

In each ScriptEditorFrame, the tree in compilation.reduce.source can be reduced to a list of [Range, bytecode] pairs. When the user hovers over any character in the editor, we can show the most fine-grained range we have available for that character. (So for <1>: when the user hovers over the < or > they see OP_1, when the hover over the 1, they see 0x01.)

Variable Ownership

The contents of variables will be shown via the Bytecode Mapping above, but it would also be nice to show variable ownership on hover. We just need to map identifiers back to their variable.name property to get to a much nicer Signer 1's HDKey.

Remaining Opcode Descriptions

This one is very low-hanging fruit – descriptions.ts files are already in the Auth PR for bitcoin-ts. So import { BitcoinCashOpcodes, BitcoinCashOpcodeDescriptions } from 'bitcoin-ts' gets us most of the way there.

BTC Support?

If anyone is interested in using Bitauth IDE to develop BTC authentication templates, please comment here.