Send a simple regtest transaction

[readcash]

(!) This depends on #1 and #2 , so there's no point in starting this unless these two are solved

We need to try to send a simplest transaction using regtest wallet. To solve the issue, create a PR that:

1) Implements the following test

const w = RegTestWallet.fromWIF('....'); // insert WIF from #1 
w.send([
  ['bchreg:prc38tlqr6t5fk2nfcacp3w3hcljz4nj3sw247lksj', [1000, 'satoshi']],
]);
expect(RegTestWallet.balanceSats('bchreg:prc38tlqr6t5fk2nfcacp3w3hcljz4nj3sw247lksj')).toBe(1000);

Note that this is not the API the users will use (at least RegTestWallet.balanceSats), it's mostly internal API for us to implement the high-level API (though the send API already high-level).

The address with WIF from #1 should contain some locally mined BCH (25?), so we send them to another address and confirm they are there.

You need to get UTXOs from the local BCHD node (see #2) using GRPC (Some help could be found here), construct a transaction, sign and broadcast it to local BCHD node.

Do it the simplest way possible. If it means using BITBOX for now (you can find some help with it here) to make and sign a transaction, we'll extract the relevant parts later, if you can find a way to use libauth by @bitjson - even better - it's much more light-weight.

Why don't we leave the BITBOX? Well, it's pretty heavy. At read.cash it adds 1MB+ to our app.js

-- $300 bounty --

The bounty is paid in BCH from the funds collected via https://github.com/mainnet-cash/mainnet-js . To claim the bounty, please do the following: if this task requires coding in TypeScript, first you need to complete the test task by sending a private message to ReadCash via Slack link here; 2) after you have completed test task once, tell that you are working on this task and how long it is going to take (if that time expires, anyone else is free to take the task); 3) send a Pull Request or publish the solution here as described in the issue. Good luck! If you think that bounty is way too small, please notify me about it and we can discuss. A bounty will be paid via the chaintip bot.

[2qx]

I can take this on, should be done before 2010-08-15 20h GMT

[2qx]

About 70% of the way through implementing this libauth, +1 day, Pushing to 2010-08-16 20h GMT

[readcash]

👍

I think "+1 day" is enough as it's pretty easy to match to the "6 minutes ago" that GitHub provides on top of the message. No need for the exact time.

[2qx]

Working on this with libauth here. here:https://github.com/2qx/mainnet-js/tree/feature/3-send-a-simple-regtest-transaction

Starting debugging. The ssl grpc connections to the local executable are a bit of an issue.

[2qx]

A missive from SSL Hell:

So grpc only connects through ssl, but:

• the grpc port has to be opened with a flag on startup (obviously)
• when specifying localhost:18335 for the client, it cannot be prepended with https://
• the gencerts command utility in bchd doesn't ship with the binary
• the certificates generated by gencerts includes alternates for hostname, localhost, and external ips (too much)
• there should be a way to override the trust authority of the self-signed certificate, without installing a CA, but haven't quite figured it out.

My goal is to include a self-signed certificate in the repo for DNS:localhost,IP:127.0.0.1 that will work for the developer out of the box without having to trust a root CA.

almost there.

+1 day

[2qx]

So bchd automatically creates certs for the user and puts them in .bchd all we have to do is symlink.

I'm in, it works. On to debugging.

[bitjson]

@2qx by the way, you can directly import the built-in P2PKH template from Libauth rather than needing to bundle the template yourself: import { authenticationTemplateP2pkh } from '@bitauth/libauth';

And here's a good usage example: https://github.com/bitauth/libauth/blob/master/src/lib/transaction/transaction-e2e.p2pkh.spec.ts

[2qx]

@bitjson , thanks, there are a lot of errors in my fork.

I should have a working version shortly. You library is quite extensive and I like the functional aspect of it.

[2qx]

@bitjson I've got a broken regtest transaction running with ssl using the authenticationTemplateP2pkhNonHd template, here

When I use the utxo from my regtest block bchd complains that it doesn't know about it:

3 INVALID_ARGUMENT: tx rejected: orphan transaction 
7cbbe30be6cf0b543b33874807ee6f039a15ac213abc357c6917f3c7f5f99be3 
references outputs of unknown or fully-spent transaction 
4d0229e507f0f131b9e5ff33f64efae10a6f4156eb0def881e48de39e5fdc87b

I can pull up the utxo from grpcui and confirm that it is indeed there.

Is there something obvious I didn't pickup yet?

These are my big assumptions: I can send regnet mining rewards right away, correct?, The arrays for the libauth template are Little-Endian, correct? Is there anything about the transaction that is obviously wrong, like swapped inputs and outputs? Or a misuse of something for p2pkh?

[readcash]

Maybe it's a coin age issue? Try generateblocks 100 or 101?

[2qx]

@readcash

So I've tried using a utxo from several hundred blocks ago, but the test transaction still orphans.

• I looked in bchd, and the setting to reject orphan transactions are hardcoded ~disabled~ in regtest mode.
• I checked grpc-bchrpc-node to make sure the buffer wasn't getting flipped.
• It's serving back the input transaction hash with the error code, so I assume it's fine.

I now suspect that the unlocking bytecode is wrong and I'm getting a general error from bchd.

I've hopefully mapped the certificate folders for windows and OS x to the bchd data dir but haven't tested on those platforms.

[readcash]

Good progress! Thanks! Maybe you can try using BITBOX for this, just to test and see if it works? It shouldn't be too hard.

[2qx]

Sorry, I traced the submitTransaction call down in bchd to the point where it gets the utxo from the leveldb cache and it indeed wasn't there. I flipped the endianness of my tx hash and it was found. Should be able to wrap this up in a couple of hours.

[readcash]

@2qx @chaintip (will send $300 + $20 for #1)