Adopt sendTransaction Logic From Client Library

[orenyodfat]

this is needed for https://github.com/dOrgTech/DAOcreator

[ben-kaufman]

I don't understand how it is related to the migration repo. Transaction replacement can be done through Metamask and adding it to an automated script like we have is problematic.

[dOrgJelli]

@ben-kaufman can you describe what you mean by "transaction replacement can be done through Metamask"? Yes Metamask currently supports "speeding up transactions", or replacing your prior one with one of higher gas cost/limit, but dApps need to support this on their end since the txHash the dApp is waiting on will change. Here's an article talking about this.

Currently the Client library supports this like so

I think the migration script should use this sendTransaction function as it (1) supports sped up & canceled transactions and (2) accurately estimates gas for transactions. Currently when using the migration script for main-net deployments, I'm not able to consistently get my transactions to confirm when using the traditional:

const block = await web3.eth.getBlock("latest");
const opts = {
  from: web3.eth.defaultAccount,
  gas: block.gasLimit - 100000
};

@orenyodfat in my opinion I would rename this issue to "Adopt sendTransaction Logic From Client Library"

[ben-kaufman]

@dOrgJelli I couldn't find there the exact part which supports transaction replacement. As far as I understand, the script needs to know if a replacement transaction was sent and then accordingly switch to use it instead, but I don't see such logic in the client library. Can you please point me to where it is implemented there?

[dOrgJelli]

Edit: see comment below.

I believe it is this line, a new 'transactionHash' event is sent, but I'd have to test to verify. I would right now but I'm a bit strapped for time and can't.

[dOrgJelli]

@orenyodfat @ben-kaufman @jellegerbrandy @tspoff

I'm so sorry for misleading you all, but after running some tests it turns out this code actually fails to keep track of sped-up transactions. It isn't easy to spot this from within Alchemy because it updates its state from the subgraph, and not from the pending transaction.

Looking into how you keep track of sped up transactions now.

[dOrgJelli]

I've posted a potential solution to this here:
daostack/arc.js#318