Closed GlenDC closed 5 years ago
Expanded the script a bit further. The consensus DB does have the block in its DB where the address is supposed to be authorised, so weird that it does not accept that fact. New output:
go run ./main.go ./consensus.db
for each k/v pair in plugins bucket:
Metadata (bucket)
authcointx (bucket)
minting (bucket)
for each k/v pair in authcoin plugin bucket:
authaddresses (bucket)
authconditions (bucket)
for each auth condition k/v pair:
0 {"type":1,"data":{"unlockhash":"01215a03f0098c4fcd801854da4d7bb2e9c78b4d3598fec89f42bc19fb79889bbf7a6aabdbe95f"}}
for each auth address k/v pair:
Found block 1e0c59d381296c8b968a464c0d65acc85093906767c2cfc0b77f805bd247ae30 at height 80:
{"parentid":"1727b5f86c82f2b7e07118a0e36cafa677f6881a4840ec8355b39d14fc29071d","timestamp":1562161503,"pobsindexes":{"BlockHeight":79,"TransactionIndex":0,"OutputIndex":0},"minerpayouts":null,"transactions":[{"version":1,"data":{"coininputs":null,"blockstakeinputs":[{"parentid":"171dbd361d082e9c8aaccb23c7afd6542d750e89d4d6d5262267572b8a0891de","fulfillment":{"type":1,"data":{"publickey":"ed25519:6513579d458e42468e67102b8660495029bc6090a773810d946bc04d5ba73735","signature":"ff04f0557e72a23ee9e8aca0d77cc581233ee3459c39804b408c7e398fc85c49a758eb53c4d74fd55f7811fb7f03bd914a61e02e7c9d60e1f3407d411f7c270f"}}}],"blockstakeoutputs":[{"value":"3000","condition":{"type":1,"data":{"unlockhash":"01215a03f0098c4fcd801854da4d7bb2e9c78b4d3598fec89f42bc19fb79889bbf7a6aabdbe95f"}}}],"minerfees":null}},{"version":176,"data":{"nonce":"cfUF7pxkan8=","authaddresses":["01215a03f0098c4fcd801854da4d7bb2e9c78b4d3598fec89f42bc19fb79889bbf7a6aabdbe95f"],"deauthaddresses":null,"authfulfillment":{"type":1,"data":{"publickey":"ed25519:6513579d458e42468e67102b8660495029bc6090a773810d946bc04d5ba73735","signature":"071a1683e3daf845c9012659c830d38c563854184be246ef0a7d108fc3606eca8398363a74447d99a1c97ce2562e4d0e8ba9ecc1fbbe1e30ad41f845d1d0140d"}}}}]}
Patch of the extended script based on the zipped version:
9a10
> "github.com/threefoldtech/rivine/extensions/authcointx"
12a14
> "github.com/threefoldtech/rivine/pkg/encoding/siabin"
29a32,35
> ////////////////////
> // go through the authcointx plugins bucket
> ////////////////////
>
77c83
< return authAddressesBucket.ForEach(func(k, v []byte) error {
---
> err = authAddressesBucket.ForEach(func(k, v []byte) error {
84a91,134
> if err != nil {
> return err
> }
>
> // register authcointx transaction controllers so we can decode/encode
> types.RegisterTransactionVersion(types.TransactionVersionZero, authcointx.DisabledTransactionController{})
> types.RegisterTransactionVersion(types.TransactionVersionOne, authcointx.AuthStandardTransferTransactionController{
> AuthInfoGetter: nil, // not required for this debug script
> })
> types.RegisterTransactionVersion(176, authcointx.AuthAddressUpdateTransactionController{
> AuthInfoGetter: nil, // not required for this debug script
> TransactionVersion: 176,
> })
> types.RegisterTransactionVersion(177, authcointx.AuthConditionUpdateTransactionController{
> AuthInfoGetter: nil, // not required for this debug script
> TransactionVersion: 177,
> })
>
> ////////////////////
> // go through the regular consensus buckets
> ////////////////////
> blockPathBucket := tx.Bucket(consensus.BlockPath)
> blockIDRaw := blockPathBucket.Get(siabin.Marshal(80))
> BlockMapBucket := tx.Bucket(consensus.BlockMap)
> rawBlock := BlockMapBucket.Get(blockIDRaw)
> var (
> blockID types.BlockID
> block types.Block
> )
> err = siabin.Unmarshal(blockIDRaw, &blockID)
> if err != nil {
> return err
> }
> err = siabin.Unmarshal(rawBlock, &block)
> if err != nil {
> return err
> }
> fmt.Println("Found block", blockID.String(), "at height 80:")
> blockJSON, err := json.Marshal(block)
> if err != nil {
> return err
> }
> fmt.Println(string(blockJSON))
> return nil
@LeeSmet can you please enable --verboselogging
in all block creator / explorer nodes for the goldchain? That should hopefully log the error that makes this situation happen. Because apparently the error that would prevent from such a transaction being applied only gets logged when verbose logging is enabled.
Big chances that the blocks after this are added as dosBlocks. Might be interesting to provide a function that allows you to list all blocks currently in the in-memory dos blocks.
Still I think you might not even get to see an error, even logged, for the block 80 of your example, given that an error (coming from the plugin as to say something) would make it not accept the block. As the block is however in block path (as can be seen above), it means the apply transaction (of plugins) did not return an error...
Going to assume that this is fixed now as well, due to merged PR #560. Should this reappear, showing it is due to another cause, than we can re-open it.
For some reason one of the block creators did not store an authorised address update in the plugin DB.
no-auth-address.zip
In the above zip file the consensus of the BlockCreator is attached together with a quick script to explore the consensus (bolt) db file. The output of that script gives:
Which indeed shows that no address is authorised according to the plugin. Will need to dig a bit further to see if it did store the block (which according to the CLI it did).