On Sun, Feb 1, 2015 at 8:08 PM, xor wrote:
> Why is that?
Because Binaries on Bitcoin.org have always been unaffected by the
issue 0.9.4 was released to address.
> Also, is it correct that there wasn't a release candidate before the release?
> Sounds dangerous to me.
The changes were tried firs
On Sun, 1 Feb 2015, xor wrote:
> Why is that?
v0.9.4 is not really a release, just a tag in git.
It contains merely a workaround for a change in OpenSSL which caused
problems - see Gregory Maxwell's post.
As the releases are statically built against OpenSSL, it is not
necessary to upgrade if y
Why is that?
Also, is it correct that there wasn't a release candidate before the release?
Sounds dangerous to me.
signature.asc
Description: This is a digitally signed message part.
--
Dive into the World of Parallel Pr
Hashes are always computed by reserializing data structures, never by
hashing wire data directly. This has been the case in every version of the
reference client's code that I know of.
This even meant that for example a block of 99 bytes with non-shortest
length for the transaction count could
> This video demonstrates how HSBC uses a security token to verify
transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE.
Since it's not very widely used outside of Austria and Germany, this may
be interesting for some: there is a second factor scheme called
"cardTAN" or "chipTAN" wher
Both wallet and server side implementations will be based on existing
code in me-friendly language (C++>Python>anything else). I don't have
a time for it right now but Crypto hackathon in Parallel Polis
(http://cryptohack.org/) seems like good opportunity for it. I will
let you know then.
2015-02-
> BIP70 is quite safe agains MitB. If user copies URL belonging to other
> merchant, he would see the fact after entering it into his wallet
> application. The only problem is, attacker can buy from the same
> merchant with user's money. (sending him different URL) This can be
> mitigated by merch
>
> I see how BIP 70 verifies the payment request, however, is there any way
> to verify that the transaction signed by the wallet matches the request
> before it is sent to the blockchain (and how can this support out of band
> verification)?
>
No. It cannot be done in the Bitcoin context. Your w
TREZOR does not support BIP70. I think they planned to work on it after
multi-sig support, which is now done, so I'm hoping that it's next on their
roadmap.
The signing features of BIP70 have (fortunately!) been implemented by
payment processors quite early, before we really have the client side f
If you decide to implement this in an existing or new bitcoinj based
wallet, then I'm happy to give you pointers on how to do it. Making
one-off, cross platform app specific wallets is pretty easy these days. For
2-of-3 dispute mediation transactions they'd start out being kind of
specialist so ask
BIP70 is quite safe agains MitB. If user copies URL belonging to other
merchant, he would see the fact after entering it into his wallet
application. The only problem is, attacker can buy from the same
merchant with user's money. (sending him different URL) This can be
mitigated by merchant setting
In online banking, the banks generate account numbers. An attacker cannot
generate their own account number and the likelihood of an attacker having the
same account number that I am trying to transfer funds to is low and this is
why OCRA is effective with online banking.
With Bitcoin, the Bi
Thanks for the clarification. Yes, I referred to CompactSize using the lingo of
https://en.bitcoin.it/wiki/Protocol_documentation
I am not sure if it is current concern. Apparently an exception is thrown if
non-canonical CompactSize in a transaction s parsed.
Is it ensured that transactions are
On Sun, 1 Feb 2015, Tamas Blummer wrote:
> I wonder of consequences if var_int is used in its longer than necessary
> forms (e.g encoding 1 as 0xfd0100 instead of 0x01)
In serialize.h lingo you are talking about CompactSize, not VarInt.
CompactSizes indeed have redundancy in their representati
I wonder of consequences if var_int is used in its longer than necessary forms
(e.g encoding 1 as 0xfd0100 instead of 0x01)
This is already of interest if applying size limit to a block, since
transaction count is var_int but is not part of the hashed header or the merkle
tree.
It could also b
15 matches
Mail list logo
