Brian Erdelyi [ARCHIVE] on Nostr: đź“… Original date posted:2015-02-01 đź“ť Original message:In online banking, the ...
đź“… Original date posted:2015-02-01
đź“ť Original message: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 Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time?
I’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (
http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification <
http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification>). 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)? Perhaps this is something that can only be supported when sending money with web based wallets.
Brian Erdelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/608c2e89/attachment.html>
Published at
2023-06-07 15:29:14Event JSON
{
"id": "89df8c4e24b1dd4c5aefa4a7f612c99aee2f61a8801184cf739a18a6164f74d1",
"pubkey": "5f57805600aff24704ce401a57e78ba1631be95f18e62e28fb3168e3be1ea5c5",
"created_at": 1686151754,
"kind": 1,
"tags": [
[
"e",
"541657d412739d9d2a5bc263564b0f2ef650e16ac828484a06cbef551e18c76c",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-02-01\n📝 Original message: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.\n\nWith Bitcoin, the Bitcoin address is comparable to the recipient’s bank account number. I now see how an an attacker can brute force the bitcoin address with vanitygen. Is there any way to generate an 8 digit number from the bitcoin address that can be used to verify transactions in such a way (possibly with hashing?) that brute forcing a bitcoin address would take longer than a reasonable period of time (say 60 seconds) so a system could time out if a transaction was not completed in that time?\n\nI’ve also looked into BIP70 (Payment Protocol) that claims protection against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common way to protect against this is with out-of-band transaction verification (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification \u003chttp://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification\u003e). 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)? Perhaps this is something that can only be supported when sending money with web based wallets.\n\nBrian Erdelyi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150201/608c2e89/attachment.html\u003e",
"sig": "423cb72f1ad2b60ac6b1a3512daad96bd73787082914b40755d71ae8528f1ab8788f75140754ebef347d90299ec3e19191076810bccf2b42e8dafb1fb136cb69"
}