12/20/2023 0 Comments Beacon uuid generator![]() ![]() Its also featured in our white paper if you'd like to read more about how we're using it. ![]() We announced that we had started including the Beacon in our new proofs at Consensus in May. All you need to achieve is proof that the block had a dependency on the beacon after all.Īt Tierion, we think the inclusion of the NIST Beacon in every Chainpoint 3.0 proof we generate is a powerful feature. Of course, I wouldn't do this with just NIST: all blockchains act as random beacons, so it'd make sense to use a merkle tree of this NIST random beacon and a few other blockchains at the same time to achieve this.Īnd finally, yes, you're quite right: using the random beacon as a source of entropy is beyond stupid.Įdit: Come to think of it, the simplest possible implementation of this would be a cronjob that just grabbed the latest beacon and timestamped it. While not a priority, I'll probably add support for random beacons to OpenTimestamps at some point, and have the calendars do this automatically as part of the timestamping process. Since the NIST Random Beacon represents a nonce that NIST claims did not exist in the past, we can easily use it to constrain and detect block timestamp backdating, a useful improvement to the security of OpenTimestamps. While that risk is mostly theoretical because it's easily detected, it'd still be nice to rule it out. Now, if you assume it's only a small percentage of miners doing this, the median time past rule helps you a bit, but it's hard to model if a majority of miners are backdating blocks, there's a risk of backdated timestamps being generated with significant (hours/days) of backdating. Unfortunately the reverse is problematic: a Bitcoin block is valid so long as its timestamp is > the median time of the last 11 blocks nodes will happily accept backdated blocks, with the only constraint on backdating being that you eventually push the difficulty up. However, for a timestamp proof that rule is irrelevant: a forward-dated block is a weaker proof, not a stronger proof. > also why would it be a good idea to use a centralized source of "entropy".? why is NIST involved at all?Īctually there's a very good use-case for NIST's Random Beacon in ( ): preventing miners from backdating their blocks undetectably.īackground: The Bitcoin protocol constrains block timestamps to not be >2hrs in the future, by virtue of the (kinda weak) rule that nodes reject forward dated blocks. Randomness becomes deterministic once the source of the randomness is disclosed and broadcast. The anti-use would be in any sort of cryptographic implementation, since any "entropy" you'd be gaining by using this data as a source of randomness is completely counteracted by the fact that the source is known. The caveat with the last example is that we both have to trust that NIST has not been compromised. We can both check the value, and we don't have to trust each other. Second, you could use this as a source of future randomness - for example, I will award you $x if the next eight bits out of the random generator represent 0-127, and will award the $x to me if they represent 128 or greater. This could be a great replacement for that, since you could write a rand() routine that accepts a start point in the chain and traverses forward to output random values on demand. A classic solution is to use a deterministic pseudo-random number generator that can be seeded, such that if it's seeded with the same number on two different runs, it will always generate the same output. There are two clear uses for this, and one anti-use.įirst, in scientific coding, one of the big challenges is in reproducing the results of a program that uses random numbers. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |