It's good old fashioned C 'optimized' API. If you have a buffer already allocated of size_t, you can try to use it.
However, it's too short --> you get false. And you need to try with a bigger buffer.
If it's ok, it returns the effective size that was used. The string is null terminated but by giving you the size back, you avoid a strlen which scans the string.
Believe me or not, but these kinds of cubblesome API used to be the norm when memory was precious.

The most important thing is to have your seed. All the major wallets are open source and anyone can see how private keys are derived from the later. AFAIK, Trezor uses BIP-32 which is a open standard. Worst case Trezor goes out of business and somehow deletes all their code from the web. I'm sure someone will have kept a copy of the code and will be able to help you out.

Trezor is like Armory or Electrum offline computer on a chip. There is still an online part that you need to install on a regular computer but Trezor removes the need to do a USB key dance. Personally, I don't mind the USB transfer because I rarely have to spend from cold storage since I keep a hot wallet too.

Deterministic wallets have a very good backup feature: They only require you to backup a single piece of data - the seed (Electrum) or the root key (Armory). All present and future keys are created from it.
It's a very comforting idea to know that regardless of what I do to my computer - as long as I have the seed stored somewhere safe - nothing can happen to my funds.

But now what happens if I use multisigs? They use P2SH scripts which basically moves the responsibility of remembering the participant public keys to the redeemer. It's easy to fund a lockbox, it's just an address.
If I create a lockbox for a trust fund, it may take years before someone wants to redeem it. By then, if no one has a copy of the lockbox definition, the fund is lost.
Essentially, when using multisigs I am back to having to maintain individual backups for every multisig address - less I risk a permanent loss. It's much more work than the deterministic wallet case, don't you think?

Am I missing something?

Thanks

PS: As a workaround, I considered sending a small transaction to the participants when the lockbox is created in order to store its definition in the blockchain.

This is the data that miners can put in the coinbase transaction since the script is irrelevant there.
Unfortunately (?), unless you solve a block you can't write in the blockchain this way.

However, there is a nifty trick. One can create a transaction that pays to a bunch of addresses and they
make the message. Maybe you could try to decode these?

You need to be more specific in your description of a solution. Many of the problems related to graphs are NP-complete even when they appear easy to describe. It seems to me that a variation of the A* algorithm could work but considering the size of the graph (millions of nodes) and the difficult choice of a distance to target heuristic, it still looks difficult. Maybe that's why it's not implemented.

Due to the fungibility of bitcoin, linking two addresses is computationally difficult and the result could be too large to be useful.

For example, what if SatoshiDice is in the path? You could end up connecting to all their users.

Ok, the support guy didn't understand that you already withdrew from the anx wallet. Their system has a few bugs.
The same thing happened to me before. Does the withdrawal show up in the account history? If so, what's its status?
If their hot wallet is empty, the transaction fails on their side but still shows up as done.

I sent them a copy of the account history and a link to the address in a blockexplorer. It was resolved shortly after.

They refunded to your anx wallet. You have to initiate a withdrawal from there to your personal address. How is that a scam?

It is certainly not using multi-sig for their customer accounts. Maybe once they initiate a purchase, the system puts the money in escrow with a multi-sig transaction but before that, the money sits in at an address protected with a single key.

If you want to see why, follow the link they provided to blockchain.info
https://blockchain.info/address/1CatnMd3jsEKhwhSLUf8V862im8gBp3NDF

There are 4 transactions that totalled 50 BTC each. Click on any of them. They have lots of small inputs and a single output. Every input corresponds to a customer account.
Click on any of them. Look for the address in the output side. It's the transaction that funded that account. Follow that transaction. The output script looks like OP_DUP OP_HASH160 xxxxxx OP_EQUALVERIFY OP_CHECKSIG which is a standard pay-to-hash transaction.

Basically, their system has an inherent flaw. When a custom funds his account, he does a normal transaction. They have a script that collects everything from all the deposits and moves it to their own address. From there they can do the multi-sig stuff.

The developper of the website gave the tool to the hacker himself. The hacker just had to change one parameter, the target address and he was done.

Honestly, this looks like very shabby work and also shows once again that we shouldn't believe the marketing crap. Multi sig ... right

Nice way to put your head in the sand. Just ignore information even from the official bitcoin site and make up some
stuff instead.

Gov switches off the internet? Hmmmm OK

Yes it can, but the main chain won't accept these blocks because they have lower difficulty.

You could do the same after every coin is mined - provided that you beat the rest of the network to it.

When it comes to killing bitcoin, the easiest way would be to go the Australian method. Put a 10% tax on bitcoin purchases because it's not a currency but goods. Or the NYC way by requiring a ton of paperwork to open a business in bitcoin.
Either way, the hassle and cost outweight any benefits

A more technical way would be to build a massive hashing facility with taxpayer money and generate 50% of the hashrate. I don't think you even need to go that far. If they get enough blocks to make mining non profitable for the guys who actually have to pay for electricity and hardware, they will drive them out of the business. Thus securing even a bigger share of the global hashing power.

Was this reported already?

In the Wall St Journal

I believe you can even though I haven't tried.

Transaction inputs have a 'lock time' before which it cannot be accepted into a block.
Transaction outputs are essentially a script. The most common is the pay-to-hash that allows someone to claim the coins if he provides a matching public key and digital signature. However, one can specify more complicated scripts. Armory implements what you want as a multi-sig lockbox but it doesn't have the time delay feature yet.

Regards,
--h

You have a probability of having a collision of two addresses greater than 50% at around the square root.
So at around 2^80 addresses, there is a 1/2 chance of having two people generating the same address.
2^80 ~ 10^24. It's still a gigantic number.

Some people use brainwallets that are derived from their birthday or other data that they find easy to remember.

And yet, they got ~1.8 BTC in donations.

We are so far away from a working quantum computer. The best that was done was with 4 qubits. You'll need thousands to break ECC 256. But the research is ongoing so maybe one day it will be feasible.
The computer from dwave is highly suspicious. It hasn't demonstrated anything that can't be done on a classical computer with the same speed. It doesn't show state superposition which is the fundamental part of any quantum algorithm.
It may solve some problems faster than classical computers but we don't know which ones.
Unfortunately, there is a lot of fubar associated with quantum computers because they sound very cool...

In any case, there are drop-in crypto methods that are quantum computer resistant. The worst case is that a hard fork will happen and bitcoin will continue with a new algo.

Actually the transaction only shows the public key of the address you are sending the coins from. That's why some coins are likely lost forever because they were sent to an address which is unlikely to be associated with a public/private key pair.
They are named something like "1DontSendBitCoinsHere"...

Shor's algorithm has two parts. The quantum part finds the period and would run much faster than on a regular computer.

http://en.wikipedia.org/wiki/Shor%27s_algorithm#Discrete_logarithms

Edit: Adding reference to wikipedia.

This drawing is misleading because it applies to brute forcing a key. If you have a safe with 6 digits, a thief would not try to try every combination. He will use your birthday, your wife's birth day, etc first. If that doesn't work, he would drill a hole and peek through the lock tumblers. Basically, no one questions the breadth of the key space - but there might be backdoors to ECC or bugs in its implementation.

All jokes set aside, these calculations assume that the only viable algorithm is brute force. One of the primary advantage of elliptic curve
cryptography is the relative short key size. A 256 bit EC key is roughly equivalent to a 3000 bit RSA key because there aren't very good
algorithms for solving the discrete log problem whereas prime factorization has much better algorithms.
However, bit coins addresses are protected by a few cryptos. If one never reuses an address, the only occurrences of it in the block chain will be when it receives coins and when it is drained. Once it's drained, there is nothing to steal. Before it is used, the block chain only has the address and not the public key. The address is a hash of the public key. So to steal the coins, one has to reverse the RIPEMD-160 hash function to get the SHA-256 of the public key. Then reverse the SHA-256 to get the public key and then crack the ECC to get the private key.

If the address is reused, the public key will appear in the block chain because when coins are spent from an address, the transaction shows the public key and a signature. It eliminates the need to reverse RIPEMD and SHA. The 'only' problem remains the ECDSA.

ECDSA has a weakness if it is poorly implemented. To sign a message, a random number should be chosen and it should not be reused  otherwise it is very easy to get the private key. Sony PS3 was hacked because the developers used a constant and a few earlier bitcoin clients had bugs and were also reusing that number. It led to the theft of a lot of bitcoins.

Finally, there is the risk of using a not really random key. If the key is the SHA of "I love cheesecake" it will probably be found quickly by bots that try simple sentences.