blinklabs-io / bluefin Goto Github PK

View Code? Open in Web Editor NEW

13.0 3.0 4.0 436 KB

A Fortuna (TUNA) miner, written in Go

License: Apache License 2.0

Dockerfile 0.22% Makefile 1.41% Go 98.37%

blockchain cardano go golang proof-of-work

bluefin's Issues

Implement hashrate calculation

Calculate a global hashrate and report it periodically in the logs

Panic due to double-close of channel in NtN TX submit

panic: close of closed channel

goroutine 1862 [running]:
github.com/blinklabs-io/bluefin/internal/tx.handleRequestTxIds({{{0xd97c68, 0xc011850630}, {0xd97c68, 0xc011850660}}, 0xc00fc19770, 0x0}, 0xf0?, 0x1018?, 0xc0?)
        /code/internal/tx/tx.go:543 +0x45
github.com/blinklabs-io/gouroboros/protocol/txsubmission.(*Client).handleRequestTxIds(0xc00fc19770, {0xd9a050?, 0xc0117e8810?})
        /root/go/pkg/mod/github.com/blinklabs-io/[email protected]/protocol/txsubmission/client.go:102 +0xb6
github.com/blinklabs-io/gouroboros/protocol/txsubmission.(*Client).messageHandler(0xc0117f93e0?, {0xd9a050, 0xc0117e8810})
        /root/go/pkg/mod/github.com/blinklabs-io/[email protected]/protocol/txsubmission/client.go:81 +0xdb
github.com/blinklabs-io/gouroboros/protocol.(*Protocol).handleMessage(0xc010c46460, {0xd9a050, 0xc0117e8810})
        /root/go/pkg/mod/github.com/blinklabs-io/[email protected]/protocol/protocol.go:532 +0x16d
github.com/blinklabs-io/gouroboros/protocol.(*Protocol).recvLoop(0xc010c46460)
        /root/go/pkg/mod/github.com/blinklabs-io/[email protected]/protocol/protocol.go:382 +0x4e5
created by github.com/blinklabs-io/gouroboros/protocol.(*Protocol).Start.func1 in goroutine 1671
        /root/go/pkg/mod/github.com/blinklabs-io/[email protected]/protocol/protocol.go:146 +0x265

bluefin seems to store incorrect UTxOs for use as inputs

It seems to have gotten into a weird state in preview where it's trying to use a UTxO from another wallet as an input on a new TX. The other wallet was also mining TUNA, but the UTxO seems to be from a subsequent TX on that wallet unrelated to TUNA mining.

{"level":"error","timestamp":"2024-04-30T17:03:44-05:00","caller":"miner/worker.go:81","msg":"failed to submit TX: failed to submit TX to API: http://tc2:6090/api/submit/tx: 400: \"transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (AlonzoInBabbageUtxowPredFailure (ExtraRedeemers [RdmrPtr Spend 0])),UtxowFailure (UtxoFailure (AlonzoInBabbageUtxoPredFailure (UtxosFailure (CollectErrors [BadTranslation (TranslationLogicMissingInput (TxIn (TxId {unTxId = SafeHash \\\"086459182edc0a2fe54e40f9560a4f99821265e386bab263902f3e874c95204f\\\"}) (TxIx 0)))])))),UtxowFailure (UtxoFailure (AlonzoInBabbageUtxoPredFailure (ValueNotConservedUTxO (MaryValue 87325173 (MultiAsset (fromList [(PolicyID {policyID = ScriptHash \\\"502fbfbdafc7ddada9c335bd1440781e5445d08bada77dc2032866a6\\\"},fromList [(\\\"54554e41\\\",585000000000)])]))) (MaryValue 94040153 (MultiAsset (fromList [(PolicyID {policyID = ScriptHash \\\"502fbfbdafc7ddada9c335bd1440781e5445d08bada77dc2032866a6\\\"},fromList [(\\\"54554e41\\\",585000000000),(\\\"6c6f72642074756e61\\\",1)])])))))),UtxowFailure (UtxoFailure (AlonzoInBabbageUtxoPredFailure (BadInputsUTxO (fromList [TxIn (TxId {unTxId = SafeHash \\\"086459182edc0a2fe54e40f9560a4f99821265e386bab263902f3e874c95204f\\\"}) (TxIx 0)]))))])\"","stacktrace":"github.com/blinklabs-io/bluefin/internal/miner.(*Manager).Start.func1\n\t/home/agaffney/dev/blinklabs-io/bluefin/internal/miner/worker.go:81"}

The UTxO that it's complaining about comes from this transaction:

https://preview.cexplorer.io/tx/086459182edc0a2fe54e40f9560a4f99821265e386bab263902f3e874c95204f

And the TXs for that address:

https://preview.cexplorer.io/address/addr_test1qpsh97c3spdxmrksyzkl3xlz9c9qyaklqay73fr7wye5yhdn5favrq4uqajcpvqvxc9emhew0cpcgjnayhzw2fwa8m2q9n2p0a/tx#data

indexer returns 2 UTxO's at script address

My indexer seems to somehow have an old (already spent!) UTxO stuck and now returns 2 instead of 1.

{"level":"warn","timestamp":"2024-07-12T17:09:36+02:00","caller":"tx/tx.go:150","msg":"found unexpected UTxO(s) at script address (addr_test1wpwadl46nw6m80lqls3a4pgelmtm4z7980vr3d77clzzy6sfgnzsr), expected 1 and found 2

utxos:
[0]: block height 9436 (this does not exist on chain anymore, it's roughly from the time when I turned off the miner before)
[1]: block height 10501 from ~minute ago

re-starting: no change
re-indexing: fixed it

Create a HOWTO

Create a HOWTO which walks the user through setup and maintenance. This includes anything necessary in the wallet.

Make more values adjustable per-profile

There's a new preview fork with adjusted epoch length and target time, and we want to be able to support it.

https://github.com/cardano-miners/fortuna/blob/main/genesis/previewV2.json

agaffney — Today at 2:27 PM
this is just a different set of script hashes/addresses, ref inputs, and 50 instead of 2016 for the difficulty adjustment modulo check, right?

Microproofs — Today at 2:27 PM
And the target time is adjusted 
From 1.2 billion to 30 million
50 blocks at 10 minutes is 30 million milliseconds

Better handling of errors when submitting TXs via NtN

We currently panic on error.

{"level":"info","timestamp":"2024-07-08T06:20:42Z","caller":"miner/worker.go:80","msg":"starting 2 workers"}
{"level":"info","timestamp":"2024-07-08T06:20:42Z","caller":"miner/worker.go:64","msg":"stopped workers"}
panic: async: muxer error: read tcp <ip>:48842-><ip>:3001: read: connection reset by peer

goroutine 3565 [running]:
github.com/blinklabs-io/bluefin/internal/tx.submitTxNtN.func1()
        /home/ubuntu/bluefin/internal/tx/tx.go:442 +0x8e
created by github.com/blinklabs-io/bluefin/internal/tx.submitTxNtN in goroutine 3551
        /home/ubuntu/bluefin/internal/tx/tx.go:439 +0x1a5

Minimal number of workers should be 1

When we detect the CPU, it's possible to get 0 workers if there's only 1 CPU. We should have a minimum of 1 always.

bluefin fails to build per discord reporting

https://discord.com/channels/946071061567529010/1146201677209292891/1217698501560107019

"I'm a newbie in golang but my guess is that there's a type mismatch between line 94 in tx.go and 148-151"

Pre-filter UTxOs

Filter out UTxOs with random assets other than TUNA before passing them into the Apollo builder. This will be a limitation of the miner but is acceptable. We'll simply document the input UTxO requirements (send 2 tx, one x one y).

Implement difficulty adjustment

https://github.com/aiken-lang/fortuna/blob/ef0e4205be378c38bfdddde7098148efa76e472c/miner/main.ts#L184-L203

Add locking around modification of trie in miner worker

We need to be able to generate consistent merkle root hashes for a new potential hash on top of the previous blocks, but it's possible for multiple workers to find a solution and update the trie at the same time, causing inconsistent results. Add locking around the whole block of code in the miner worker that adds a hash to the trie, gets the new root hash, and then removes the new hash.

NOTE: this also involves uncommenting the original code for worker count in internal/config/config.go

Rollback handling

We currently ignore rollbacks, which can lead to our DB reflecting UTxOs that don't actually exist on-chain. We'll need to record the slot for each UTxO and delete any relevant ones when we get a rollback event.

Defer starting miner until processing all TX outputs

We currently trigger the miner to start as soon as we see an updated datum, but we haven't necessarily finished processing all of the outputs for the TX. Triggering the miner should be deferred until after all TX outputs are processed for consistency.

Move Fortuna data model to cardano-models

Let's move the data model for Fortuna's contract to cardano-models (fortuna.go?), so it can be reused.

Start mining automatically if we don't see a new block after submitting a TX

If we submit a TX that doesn't make it on-chain and nobody else is mining, bluefin will just sit and wait for nothing. Instead, we should start a timer after submitting a TX and automatically restart the miner with the last block if we haven't seen a new TUNA block in a certain amount of time (30s? 1m? 5m?)

Periodic "invalid witnesses" failure when submitting TX for TUNAv2

This seems to occur pretty regularly with TUNAv2 mining.

{"level":"error","timestamp":"2024-07-03T15:45:48-05:00","caller":"miner/worker.go:81","msg":"failed to submit TX: failed to submit TX to API: http://tc2:6090/api/submit/tx: 400: \"transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (AlonzoInBabbageUtxowPredFailure (ShelleyInAlonzoUtxowPredFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN \\\"5af644d54c017b453a40a7317e0980e73a96139f7b8f9caa91524e401ae0a59a\\\")])))])\"","stacktrace":"github.com/blinklabs-io/bluefin/internal/miner.(*Manager).Start.func1\n\t/home/agaffney/dev/blinklabs-io/bluefin/internal/miner/worker.go:81"}

Support for hard-fork contract

There's a TUNAv2 contract with some changes. We want to be able to support both.

I've looked through the TUNA hard-fork contract, and I've noticed a few differences:

the TargetState object (used by the miner internally) has its fields reordered and a new miner bytestring field added
the miner bytestring is a blake2b hash of either a public key hash or a NFT (for mining pools, I think)
if using a PKH for the miner field, the contract will verify that it matches one of the signers on the transaction
the on-chain datum fields have been reordered to put extra (message) last instead of before the interlink

It's harder to determine what changes we'll need in the TX building (extra redeemers or whatever) from looking at the smart contract, so we may need to wait until Fortuna is updated to see what's needed

panic: async: EOF

panic: async: EOF

goroutine 3935 [running]:
github.com/blinklabs-io/bluefin/internal/tx.submitTxNtN.func1()
        /code/internal/tx/tx.go:442 +0x8e
created by github.com/blinklabs-io/bluefin/internal/tx.submitTxNtN in goroutine 3812
        /code/internal/tx/tx.go:439 +0x1a5

Switch to slog for logging

Add support for reading .env file

Implement GPU mining

Add support for SUBMIT_URL API Key

io/fs: malformed module path "io/fs": missing dot in first path element

on Ubuntu 22.04.3 LTS:

~/bluefin$ make
# Needed to fetch new dependencies and add them to go.mod
...
go mod tidy
github.com/blinklabs-io/bluefin/internal/logging imports
        go.uber.org/zap tested by
        go.uber.org/zap.test imports
        io/fs: malformed module path "io/fs": missing dot in first path element
make: *** [Makefile:23: mod-tidy] Error 1

Update log messages related to seed.txt to use full path

To make it easier to use, we should include the full path in our log outputs, etc. so the user can find the correct location easily.

Detect when we receive TUNA

The ideal method is to check the redeemers datum for our miner credential, but we can't (yet) do that with gOuroboros. Alternatively, we can remember the TXs that we've sent and look for them in the indexer, or look for TXs with TUNA outputs to our wallet that also mint TUNA. Log a message when we find one of these TXs.

blinklabs-io / bluefin Goto Github PK

bluefin's Issues

Recommend Projects

Recommend Topics

Recommend Org