Bitcoin Core Development Status Report #2
bitcoinfoundation.org
bitcoinfoundation.org
In this day and age, using X.509 for something like this is ... pretty bad. The bitcoin community elsewhere has standardized on PGP, and with very good reason; X.509 is a well-known clusterfuck.
I understand wanting to include an X.509 option anyway, if the point is not to improve usability by the bitcoin community, but rather by people who aren't already in it. But I do not think the lack of a PGP option is excusable, and I do not wish to see the protocol succeed in its current form for that reason. (I can't imagine a significant fraction of the bitcoin community will want it to succeed in this form either.)
I continue to believe that Bitcoin should avoid dealing with these issues and instead tightly circumscribe its scope, allowing other software to resolve the trust issues around payment endpoint communication.
If it continues along the present path, it's going to have an integration complexity akin to one of those grain-of-sand metaphors, and wind up subsuming emacs.
The current, github forkable proposal is available at https://github.com/globalcitizen/ifex-protocol
But unfortunately, this protocol cannot be used in PoS terminals, they are 32 bits and I see no reason why that would change before those kind of terminals just disappear.
We need something smarter than uint64.
Edit: I really think they need to read about solutions that already exists for banking & payment communications. They are somewhat compatible with bitcoin.
Err, you can use 64-bit integers on 32-bit systems. Or 16-bit systems, or 8-bit systems. Just because it's not the native size for integer math doesn't mean you can't use it.
That said, NO you should never do that.