Gregory Coppola

Can the API just remember the transactions that got dropped? That way, the user gets more information about what happened, and the whole system looks more robust, because we know...

I removed myself from reviewing this PR because @jcnelson is the second reviewer and @kantai has approved.

A simple alternative that I did in my testing of the Hiro subnet L2 is as follows: I modified the `BurnchainConfig` of the L1 to take a new scalar `wait_before_simulated_block`:...

But!.. there is another alternative, where you use `bitcoind` in regtest mode, and then your L1 can be configured against the `bitcoind` node, and you can send requests to the...

Yes.. tests like this inherently take a long time to run. I think it's unavoidable. The way to solve this is to get better at running long-running jobs, possibly multiple...

@bestmike007 You can try using `clarinet` https://www.hiro.so/clarinet It will run the bitcoin node and stacks node.

Here is another alternative: https://github.com/zone117x/stacks-regtest-env This is definitely `contrib` territory, and can live in a private repo. You can use the `stacks-node` as a black box, and just manage the...

@jcnelson I didn't know about this feature. I like the idea of logging to a database instead of/in addition to writing to the sequential logs. But, what info does this...

At the moment, I'm seeing lots printed logs from #2812, but ``` sqlite> select count(*) from transactions; 0 ``` This is with ``` $ echo $STACKS_TRANSACTION_LOG 1 ``` So, I'm...

I believe there are indeed some gaps in what is logged by `STACKS_TRANSACTION_LOG`. But, these holes could be plugged with a little work. At this point I think there are...