Bitcoin Core Development Status Report #2(bitcoinfoundation.org)
bitcoinfoundation.org
Bitcoin Core Development Status Report #2
https://bitcoinfoundation.org/blog/?p=85
3 comments
Hey there. I was one of the first to raise this anti-X.509 sentiment on the list and gist. Here's my initial fork: https://gist.github.com/4165865
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.
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.
See also a non settlement-system or asset-linked proposal for this problem space currently under development at http://www.ifex-project.org/our-proposals/ifex/
The current, github forkable proposal is available at https://github.com/globalcitizen/ifex-protocol
The current, github forkable proposal is available at https://github.com/globalcitizen/ifex-protocol
I jumped into that gist hoping to build a prototype for Verifone VeriX.
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.
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.
> 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.
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.
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.
Even if RVDS could do that like gcc or vcc, it would make any operations at least 60x slower than just using the add instruction directly. Unlike IA32, 32 bits ARM processors have only 32 bits addr space and registers (against 36 bit in IA32 which allows some 64 bit support) and have no support for 64 bit operations. You are confusing compiler wizardry and the actual program.
That said, NO you should never do that.
That said, NO you should never do that.
Where did you get the 60x number from? Using the proccessor's 32-bit primitive operations, you can treat 64-bit arithmatic as 2-digit arithmetic. If you take advantage of the carry registers, it seems like you should have no more than about 3x slow down.
The sheer number of instructions generated by vcc.
very happy to hear that they are taking Zombie attack into consideration, I am constantly amazed by the number of companies that do not factor in this potential threat.
Yes. More organisations should follow the lead of Bristol Council: http://www.guardian.co.uk/society/2011/jul/07/when-zombies-a... - Most are are in the deplorable state of unpreparedness demonstrated by Leicester Council: http://www.bbc.co.uk/news/uk-england-leicestershire-13713798
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.)