5 ms·

How many times would you double check the address before hitting send? I would think to minimize risk, would slice this up into a few transactions...

Drip33 6y ago
Probably just twice. Bitcoin addresses are check summed so it's nearly impossible to fat finger a mistake.
- pjc50 6y ago
  And yet it happens - as does putting the value in the "fee" box!
  - Drip33 6y ago
    I've never heard of someone successfully and unintentionally fat fingering a Bitcoin address typo to a valid Bitcoin address nobody owns. Fee box is a different thing, the recent $2.5m ETH headline you saw was not an accident but an attack/blackmail. Bitcoin core itself prevents you from using too high of a fee without an express override in the config.
    - flyGuyOnTheSly 6y ago
      Source on the $2.5m fee being related to attack/blackmail? I just looked it up but I couldn't find anything saying as much... only that sparkpool kept it aside in case the owner comes forward?
      - Drip33 6y ago
        Looks still unconfirmed https://decrypt.co/32145/hackers-blackmail-exchange-with-5-million-of-ethereum-fees-report https://decrypt.co/32145/hackers-blackmail-exchange-with-5-m... >In short, the researchers claim that the hackers have gained access to an exchange’s funds. They are able to send money to certain whitelisted accounts that are marked as reliable in the exchange’s database to—but not to their own. So, they are sending the funds with excessively high transaction fees to sap the exchange’s accounts, and they’re demanding a ransom if it’s going to stop.
        flyGuyOnTheSly 6y ago
        That's about the only thing that makes sense I suppose. Thanks for the link!
    - RL_Quine 6y ago
      You have a one in 232 chance of making a typo in an address and it being valid for P2PKH, its even less for modern bech32 addresses.
      - grapehut 6y ago
        A 1 in 200 chance doesn't make much sense. In (legacy) addresses there's a 4 byte checksum done with sha256, so it should be something like a 1-in-4-billion (1 in 2^32) chance of a typo being valid. bech32 does something even smarter, but I'm not familiar with the details
        RL_Quine 6y ago
        The formatting was stripped. I meant 2^32.
  - RL_Quine 6y ago
    Bitcoin Core specifically won't let you make transactions with "absurd" fee rates.
ed25519FUUU 6y ago
When it comes to $1 billion, the three day waiting period of ACH doesn’t seem that bad.
RL_Quine 6y ago
I've been party to large Bitcoin transactions (100M USD or so). It had a team of people involved, each responsible for independently verifying the transaction before it was signed for correctness. It's hard to make mistakes if you have a group of engineers who are all tasked with ensuring the validity of a transaction with their own tools. The fun bit is that the signer can backdoor transactions, and that part isn't something that can be verified by anybody who doesn't have the private keys.
- Drip33 6y ago
  >The fun bit is that the signer can backdoor transactions, and that part isn't something that can be verified by anybody who doesn't have the private keys. Can you explain this? This is contrary to my knowledge of reviewing the details of a pre-signed transaction.
  - RL_Quine 6y ago
    Sure. The basic idea is that signer can choose a ECDSA nonce (k) that they know, and leak the private key. If I choose a known nonce for my signature, I can recover the private key from the published transaction instantly. With some ECDSA magic, you can even produce a nonce that is only recoverable with another key that you hold. So a hardware wallet for example can backdoor transactions to leak the seed through the signature, or a specific key, or put any data there that they wish. The "offline signing" defense is only good for one way, as there's always data leaving the system which you can't easily audit. This is only detectable if you have multiple signers signing the same transaction using the same private key and the same method for generating the nonce, and you compare them before broadcasting. So perhaps using hardware wallets from 3 manufacturers which all implement bit-identical implementations of the signer (with RFC6070 deterministic signatures), and treating the signed transaction as a private key leak until you've verified they all match. For ECDSA a single bit bias in the nonce, or a single bit leakage of the nonce through other methods is enough to completely break the cryptography. So we could have hardware wallets that produce otherwise impeccable transactions and signatures, but leak a bit of the nonce in the ordering of the outputs, the lock time, the sequence numbers, and that would still be enough to steal all of the funds. This stuff is trickier to get right than most people imagine.

Drip33 6y ago

Probably just twice. Bitcoin addresses are check summed so it's nearly impossible to fat finger a mistake.

pjc50 6y ago
And yet it happens - as does putting the value in the "fee" box!
- Drip33 6y ago
  I've never heard of someone successfully and unintentionally fat fingering a Bitcoin address typo to a valid Bitcoin address nobody owns. Fee box is a different thing, the recent $2.5m ETH headline you saw was not an accident but an attack/blackmail. Bitcoin core itself prevents you from using too high of a fee without an express override in the config.
  - flyGuyOnTheSly 6y ago
    Source on the $2.5m fee being related to attack/blackmail? I just looked it up but I couldn't find anything saying as much... only that sparkpool kept it aside in case the owner comes forward?
    - Drip33 6y ago
      Looks still unconfirmed https://decrypt.co/32145/hackers-blackmail-exchange-with-5-million-of-ethereum-fees-report https://decrypt.co/32145/hackers-blackmail-exchange-with-5-m... >In short, the researchers claim that the hackers have gained access to an exchange’s funds. They are able to send money to certain whitelisted accounts that are marked as reliable in the exchange’s database to—but not to their own. So, they are sending the funds with excessively high transaction fees to sap the exchange’s accounts, and they’re demanding a ransom if it’s going to stop.
      - flyGuyOnTheSly 6y ago
        That's about the only thing that makes sense I suppose. Thanks for the link!
  - RL_Quine 6y ago
    You have a one in 232 chance of making a typo in an address and it being valid for P2PKH, its even less for modern bech32 addresses.
    - grapehut 6y ago
      A 1 in 200 chance doesn't make much sense. In (legacy) addresses there's a 4 byte checksum done with sha256, so it should be something like a 1-in-4-billion (1 in 2^32) chance of a typo being valid. bech32 does something even smarter, but I'm not familiar with the details
      - RL_Quine 6y ago
        The formatting was stripped. I meant 2^32.
- RL_Quine 6y ago
  Bitcoin Core specifically won't let you make transactions with "absurd" fee rates.

ed25519FUUU 6y ago

When it comes to $1 billion, the three day waiting period of ACH doesn’t seem that bad.

RL_Quine 6y ago

I've been party to large Bitcoin transactions (100M USD or so). It had a team of people involved, each responsible for independently verifying the transaction before it was signed for correctness. It's hard to make mistakes if you have a group of engineers who are all tasked with ensuring the validity of a transaction with their own tools. The fun bit is that the signer can backdoor transactions, and that part isn't something that can be verified by anybody who doesn't have the private keys.

Drip33 6y ago
>The fun bit is that the signer can backdoor transactions, and that part isn't something that can be verified by anybody who doesn't have the private keys. Can you explain this? This is contrary to my knowledge of reviewing the details of a pre-signed transaction.
- RL_Quine 6y ago
  Sure. The basic idea is that signer can choose a ECDSA nonce (k) that they know, and leak the private key. If I choose a known nonce for my signature, I can recover the private key from the published transaction instantly. With some ECDSA magic, you can even produce a nonce that is only recoverable with another key that you hold. So a hardware wallet for example can backdoor transactions to leak the seed through the signature, or a specific key, or put any data there that they wish. The "offline signing" defense is only good for one way, as there's always data leaving the system which you can't easily audit. This is only detectable if you have multiple signers signing the same transaction using the same private key and the same method for generating the nonce, and you compare them before broadcasting. So perhaps using hardware wallets from 3 manufacturers which all implement bit-identical implementations of the signer (with RFC6070 deterministic signatures), and treating the signed transaction as a private key leak until you've verified they all match. For ECDSA a single bit bias in the nonce, or a single bit leakage of the nonce through other methods is enough to completely break the cryptography. So we could have hardware wallets that produce otherwise impeccable transactions and signatures, but leak a bit of the nonce in the ordering of the outputs, the lock time, the sequence numbers, and that would still be enough to steal all of the funds. This stuff is trickier to get right than most people imagine.