Sorry for posting in here but it is somehow technical too. I put it on the main board and it got drowned by other posts very quickly.

A friend of mine recently got his trezor wallet cleaned out and we are trying to figure out what happened.

He gave me his ypub key and I imported it into Electrum to look at his transaction history.
His last legit transaction was 2 weeks ago but yesterday he got two extra withdrawals.

A test transaction was followed by a complete withdrawal of the entire wallet.

https://www.blocktrail.com/BTC/tx/7a2f637bcd6f30a02c298c64022d4148c58d9587ed6e2191a3a758ad40c6fda2
https://www.blocktrail.com/BTC/tx/7d708a9dc692ce79170a411563ebdcc4110bdfadfdfe1c726b8fb5d3d0bc17bf

IMHO, the fact that there were 2 transactions points towards a compromised seed.
The test tx actually returns most of the wallet amount back into the change address - which is a single use p2sh-p2wpkh address.
Then the change address itself is cleared in the 2nd tx.
The thief knows how to generate private keys for the entire hierarchical wallet. AFAIK, that requires the seed.

So, it looks like a targetted attack. My friend says he never put his seed online, never took a picture of it, etc.
He only kept it on a piece of paper, getting to it would imply someone who knows him.

But the receiving address has activities that I don't understand then.

https://www.blocktrail.com/BTC/address/18abkVcsfwvNHxFM1jN5WLAY9irB91FwTH

The address appear when he lost his funds and was itself cleared one day later.
However, it also sees the transfer of over 1000 btc as if it was the staging area of a large scale attack.

Does anyone know what has happened there?

Thanks,
--h

A friend of mine recently got his trezor wallet cleaned out and we are trying to figure out what happened.

He gave me his ypub key and I imported it into Electrum to look at his transaction history.
His last legit transaction was 2 weeks ago but yesterday he got two extra withdrawals.

A test transaction was followed by a complete withdrawal of the entire wallet.

https://www.blocktrail.com/BTC/tx/7a2f637bcd6f30a02c298c64022d4148c58d9587ed6e2191a3a758ad40c6fda2
https://www.blocktrail.com/BTC/tx/7d708a9dc692ce79170a411563ebdcc4110bdfadfdfe1c726b8fb5d3d0bc17bf


IMHO, the fact that there were 2 transactions points towards a compromised seed.
The test tx actually returns most of the wallet amount back into the change address - which is a single use p2sh-p2wpkh address.
Then the change address itself is cleared in the 2nd tx.
The thief knows how to generate private keys for the entire hierarchical wallet. AFAIK, that requires the seed.

So, it looks like a targetted attack. My friend says he never put his seed online, never took a picture of it, etc.
He only kept it on a piece of paper, getting to it would imply someone who knows him.

But the receiving address has activities that I don't understand then.

https://www.blocktrail.com/BTC/address/18abkVcsfwvNHxFM1jN5WLAY9irB91FwTH

The address appear when he lost his funds and was itself cleared one day later.
However, it also sees the transfer of over 1000 btc as if it was the staging area of a large scale attack.

Does anyone know what has happened there?

Thanks,
--h

Assuming we are talking about Bitcoin signatures and we are not using deterministic k.

My understanding is that signing the same message with the same private key will not yield the same signature because of the random factor k. The odds of two signatures being equal is negligible under these conditions. Could someone confirm or refute this?

Thanks,
--h

A step by step tutorial on building a full node implementation.

As for the features, here's a short list:

- Automatically synchronizes the blockchain using headers first and parellel block download
- Maintain database of unspent outputs: verifies and relays unconfirmed transactions
- Import/Export blockchain
- Serves headers and blocks - other nodes can synchronize the blockchain from Bitcoin-Akka

More importantly, every commit is documented and corresponds to a precise unit of work towards
the goal.

http://hhanh00.github.io/bitcoin-akka-tutorial/index.html

Let's say a node is synced up to block #100 and receives a chain from #90 to #100 that claims to be better. But in fact, in the block #95, there is a double spend (from a txo created in #91 of the new fork) that makes #95 to #100 invalid.
However, even without these blocks the POW of #90 to #94 exceeds our current best and we should reorg to the new chain #90-94.

I wonder how bitcoin core (and the alternate implementations) handle this case.

Thanks,
--h

PS: To give an idea, my reorg code rolls back the utxo set to #90 before attempting to attach the new fork. But I don't see where it's done in bitcoin core and libbitcoin. Maybe they work differently?

When I run a regular node, my listening endpoint is part of the version msg and is relayed through addr messages.
But when I run it as a Tor hidden service, is it advertised or people who want to connect must know my service onion address?

Would there be an interest in creating a sidechain or altcoin that implements all/most of the hardfork wish list (https://en.bitcoin.it/wiki/Hardfork_Wishlist) ? Some kind of testnet for big experiments.

[Bitcoin full node in F#]

Bitcoin full node in F#
An alternative full node bitcoin implementation in F#. The source code is on GitHub and this documentation was generated directly from the code.

Introduction
This project is under development and currently in alpha stage. Generally speaking, writing a fully compliant bitcoin node is extremely hard - some think impossible. The Bitcoin project is experimental and grew organically. As a result, the Satoshi client is the de-factor standard. By far the most used client on the network, it dictates what should be accepted and what should be rejected. Even the slighest deviation can cause a fork and potential loss of funds. It should go without saying

Do not use this code in production when real funds are at stake.

A lot of effort has been put into aligning its behavior with the core client but nevertheless there are almost certainly bugs that could be exploited to cause it to deviate from the reference implementation.

That being said this code has been through the "official" block acceptance test and has run from extended period of time. It implements all the consensus rules including the bugs that are now included in the blockchain since the genesis of Bitcoin.

However, Bitcoin F# has fully validated the existing mainnet blockchain and passes all the integration tests including large reorg tests. It is also the only implementation in a functional language and comes under 2.5 kLOC, making it the smallest client too.

Refer to the project page at https://github.com/bitcoinfs/bitcoinfs and its associated documentation at http://bitcoinfs.github.io/bitcoinfs

100%... not 99.999%. I know it's very difficult.
Do the miners actually use bitcoin core too?

Quick question - not sure if it belongs here though
Once you move BTC to multisig wallet, is it still available for selling?

1. If yes, what prevents a user for refusing to release the funds or is it released automatically by bitgo?
2. If no, *sad*

5 blocks in 10mn!!

Lady luck is on our side this time.


337945 to 337950

The reference client has received some pretty negative comments. Bad code style, lack of innovation, not enough contributions, etc. I feel it remains the #1 used full node implementation because of it is name.
How many of you are willing to choose a different code base or do you think that it is good enough?
And how many think that running a full node is not worth the trouble?

There are a few Pay2SH transactions that I can't validate.
For example,
https://blockchain.info/tx/567a53d1ce19ce3d07711885168484439965501536d0d0294c5d46d46c10e53b

The script hash matches but the script uses OP_RIGHT.

Code:

OP_1 OP_RIGHT 6e879169907c9087

OP_RIGHT s a disabled op code. Shouldn't the script fail?
It's not the only example. We have 6 other scripts that use disabled opcodes and yet are part of the blockchain.

Another one, harder for me to understand
https://blockchain.info/tx/5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f

Of all the P2SH cases in the blockchain, my tool only rejects this one. It looks like a standard 2 of 3 multisig. The 2nd signature is a SIGHASH_SINGLE but the first one is a regular SIGHASH_ALL. Yet, none of the provided public keys seems to match the first one either.
There must be something wrong with my tool but I don't see where.
I could run another client but it will take hours before it catches up to this point. A standalone verifier would be great. Because usually, the issue is in the way I built the transaction to sign. Is there such a tool available?

I tried decoderawtransaction - it doesn't give much information.

Code:

{
"txid" : "5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "b5b598de91787439afd5938116654e0b16b7a0d0f82742ba37564219c5afcbf9",
"vout" : 0,
"scriptSig" : {
"asm" : "30450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e01 022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01",
"hex" : "4830450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e0121022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01"
},
"sequence" : 4294967295
},
{
"txid" : "ab9805c6d57d7070d9a42c5176e47bb705023e6b67249fb6760880548298e742",
"vout" : 0,
"scriptSig" : {
"asm" : "0 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a01 52483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae",
"hex" : "00483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a53034930460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a014c9052483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00100000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_HASH160 d8dacdadb7462ae15cd906f1878706d0da8660e6 OP_EQUAL",
"hex" : "a914d8dacdadb7462ae15cd906f1878706d0da8660e687",
"reqSigs" : 1,
"type" : "scripthash",
"addresses" : [
"3MTdzi2J1qqge4MsGykL7K461JuSwNqwko"
]
}
}
]
}

Thanks for your help

https://blockchain.info/tx/ee61292f8a95584b73bce028e91df2c93ec11fa3636ac65c8fa697fcb6e2c3a1

It gathers a bunch of strange tx outputs without actually moving anything. Is it to fix a bug in the mining pool software?

Thanks,
--h

Besides the official client, what options do we have?

I know of
- BitcoinJ
- btcd
- gocoin

https://en.bitcoin.it/wiki/Clients

Is there a client that implements BIP 37, ultra pruning and/or partial blockchain?

Thanks,
--h

I did the following:
1. Send a version msg with relay = 0 (don't get inv messages until filterload)
2. Response to version from node with verack
3. Wait for verack from node

Now I'm ready to talk to the server
1. Send an empty filterload
--> I start getting some Inv messages back. I thought I shouldn't get any but maybe it's for DoS protection?
2. Send a filteradd message passing a pubkey where I've got a few mbtc

045e2a21f9e0de43b9ff9c898efcaffd45c78a3b12161fe834266fc9f34c186e6b7de09942beb8e d7039a61d146330ca286f2fb86fec6a181f96d9c59d13695e6d

Still getting inv messages...
Basically, how should I get the actual transactions so that I can calculate the balance?

Thanks,
--h

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.

Was this reported already?

In the Wall St Journal

I'm based in HK and I have a HK account in USD.
If I do a deposit on Bitfinex, will it still be considered an international wire transfer with all the fees attached to it?

Thanks,
--h