In order to add convenience methods to a transaction, such as pushing new
inputs and outputs, we need to first have the notion of an initialized
transaction, which is actually not blank. An initialized transaction just has
default values for everything, such as no inputs and no outputs, and default
version and nlocktime.
Script().writeOp('OP_CHECKMULTISIG'), or...
Script().writeOp(174), or...
Script().writeBuffer([push data buffer]), or...
Script().write([op string, number, or push data buffer])
These convenience methods let you easily write a script.
For spotting transactions to which you have the stealth key (or at least the
scan key) and creating transactions to a stealth address. So far it is only
partially working - you can see if a transaction is a stealth transaction (or
at least one of a limited kind of stealth transactions), and you can see that
you do not have the stealth key to spend one of these transactions. However, I
have not yet tested whether you can see a stealth transaction that you actually
have the key to. Also, it is not yet easy to spend to a stealth address.
These functions are prefixed DW which stands for Dark Wallet. The code for the
Dark Wallet address format can be found here:
https://github.com/darkwallet/darkwallet/blob/develop/js/util/stealth.js
Note that I deliberately support only the simplest possible format, which is
where there is only one payload pubkey and the prefix is blank. I should now go
back and replace my old toString, fromString, toBuffer, fromBuffer functions
with these Dark Wallet versions, since they are much more well-thought out than
mine.
For Transaction, Block and Blockheader. This is a convenience so if you happen
to have the buffer for one of these, you can make a new one like this:
Transaction(txbuf);
Rather than having to do this:
Transaction().fromBuffer(txbuf);
I had been using this formula for the receiveKeypair:
scanKeypair + payloadKeypair + sharedKeypair
However, Dark Wallet uses this formula:
payloadKeypair + sharedKeypair
It is not actually necessary to add the scanKeypair in order to have all the
features of stealth addresses, at least as far as I can tell. So in order to
bring my implementation closer to Dark Wallet's, I have removed the scanKeypair
from this calculation.
...will be useful in transactions. Note that we already have a primitive
understanding of Varints in the BufferReader and BufferWriter classes. However,
the new Varint class is a varint object which actually depends on BufferReader
and BufferWriter for reading and writing varints. This class is for keeping
track of the raw buffer that is read in from a buffer.
Javascript only supports 64 bit floating points, which have uint precision up
to Math.pow(2, 53). We now support reading variable sized numbers up to that
size. If the number is bigger than that, then we need to use BN.
It should be possible to check to see if a message isForMe with only the
scanKeypair, and not the payloadKeypair. There was a bug where only the
scanKeypair was being used to produce the receiveKeypair, but this was a
mistake. Both the scanPubkey and payloadPubkey should be necessary to produce
the receivePubkey, and both the scanPrivkey and payloadPrivkey should be
necessary to produce the receivePrivkey. If an online computer has only the
public keys of both (and the scanPrivkey), then that is good enough to check
for isForMe.
This code should be regarded as being a proof-of-concept, and needs more review
before being used in production code. At least one thing is guaranteed to
change, and that is the format of a stealth address.
...the format of fromString and toString are deliberately not compatible with
bitcoind. The format here is supposed to be both human-readable, and
byte-for-byte isomorphic to the binary representation. In the future we will
need to add support for bitcoind-like strings, both for the test data (e.g.,
script_invalid.json) or for the bitcoind console style.
When parsing OP_PUSHDATAX commands, the the length of data might not require
the size integer of OP_PUSHDATAX. For instance, you might write 1 byte, and yet
use OP_PUSHDATA4. We need to record which OP_PUSHDATAX was used so that when we
write the buffer back out, we can write the same one. Also, the claimed length
may be different. For instance, we may OP_PUSHDATA of length 100 to the stack,
but there may only be 50 bytes left in the script. In that case, buf.length and
chunk.len will be different. I'm not sure if that would be considered a valid
script, but in any case, for script analysis, we need both values.
Manuel Araoz
Eric Martindale
Ryan X. Charles
Ryan X. Charles