Results 443 comments of Friedger

PoX tx on testnet: https://api.blockcypher.com/v1/btc/test3/txs/7ad9187efd4fa01ce8690015a1a711d7958f18c248fb4c47a32d00732cfc4a61?limit=50&includeHex=true ``` 0x0100000001c8bd3502a21f810da7692e323cc46e0e9ec1def7a93cc610f6d65b60193174e2030000006a47304402204ffe267e6b5aab28350be80c1f4ea94424c483f3f44f175594bb6273000f80e8022042ebd5668420c8b29d2ec2791e2c8aa0d7784d8a6283f958fe581e0be129c61b0121037435c194e9b01b3d7f7a2802d6684a3af68d05bbf4ec8f17021980d777691f1dfdffffff040000000000000000536a4c5058365b13588072c8b4eca88a505db5c453123c5c91db98d90ac1cd124402dba596531ebf945361dbdbcb0a43e8d6984ab8eee14982d0341eab198fc74d2d917c6d95dc001e21c20008001e1fc2001d0210270000000000001976a914c70e1ca5a5ef633fe5464821ca421c173997f38888ac10270000000000001976a9146c575e9f31715b180b22738136895876ade678cb88ac752f7c5c000000001976a914ba27f99e007c7f605a8305e318c1abde3cd220ac88ac00000000 ```

> (get-block-info? burnchain-header-hash X) takes a Bitcoin block height for X @jcnelson Does it? Calling `get-block-info` with e.g. stacks block 11319 on https://explorer.stacks.co/txid/ST2PABAF9FTAJYNFZH93XENAJ8FVY99RRM4DF2YCW.block-info?chain=testnet returns ``` (tuple (burnchain-header-hash (some 0x0000000000000020d1f8c2ef300d9590069396ff40611f16fd660ae74f86fc44)) (header-hash...

@cryptopanter No, currently, you can get the bitcoin txs of btc blocks that are not an achor block of the stacks chain.

One possible solution: https://github.com/friedger/clarity-friedger-pool/commit/51bc15470a5395d3497041b0f44373574537021c#diff-9cbd4f5ed8cf4b56f6c1c387d6a01cb26e6f66bd518fabda78435ab79a092a1aR744

Is `id-header-hash` still meaningful on the stacks block level as the stack chain does not fork anymore on that level?

My concern is that newly onboarded developers (after Nakamoto) get confused about the properties and what they mean. In particular, the change to vrf-seed. The Nakamoto upgrade should be celebrated...

> I still have a concern about vrf-seed. Might users think they can expect a unique VRF seed with each block? Yes, because that was the case until now (if...

Returning burnchain time sounds correct

Thank you for the message. I will see what we can do...

Yes, I would suggest to use the so-called document provider, that enables users to choose from any storage, whether cloud or not.