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
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
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 wallet
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
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
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
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
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
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 where
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
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
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org 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
12 matches
Mail list logo
