There is one more "if" though: the merchant must be directly connected to one of the poisoned miners and not running a full node himself.
Such a merchant - if he even exists - should not be in the Bitcoin business unless he sells hugs. He relinquished his trust to some other anonymous party. And for what reason? And why wait for this attack? The mining pools can collude and clean him out. |
|
|
|
Please describe step by step the actual attack, which things would the attack do to whom and how would they profit from doing so. AFAICT people are just handwaving here. Actually spelling it out can help clarify your thinking or help me understand (whichever is needing improvement).
1. Obtain access to a miner machine through a vulnerability. 2. Open his LevelDB database that stores UTXO set. 3. Insert a record that contains output to one of hacker's addresses. Alternatively, find a legitimate record that contains output to one of hacker's addresses and modify its value, say from 1 BTC to 100 BTC. 4. Cover your tracks by deleting logs that show the intrusion etc. 5. Repeat the steps above against other miners until the total hash power of the poisoned miners exceeds 50% (as of today, it is 4 mining pools). You don't need to hack all of them at the same time, the attack can span months. 6. Spend the output in step 3. Make sure the transaction goes directly to poisoned miners, not through clean non-mining nodes. You don't benefit but just harm the miners. Even if one of the poisoned miners find a block, it will be checked by every other full node in the network. Therefore it will be rejected as soon as the miner tries to push out his block. It will be as if half the miners were on a bogus chain, the hash rate will be effectively reduced by half but eventually a non poisoned miner will find a block or a poisoned miner will correct his UTXO set. In the later case, he may never know what happened but fixing the situation is rather simple as it is a matter of rebuilding the database. |
|
|
|
|
I'm not sure but they seem to be focused on the client side: creating transactions, signing, getting transaction history, SPV, etc. Everything you need if you are connecting to a bitcoin core instance.
|
|
|
|
|
I'm not a big fan of this approach because a third party service owns one of your keys. With 2 of 3 sigs, if they go offline you have to get your 3rd key out of cold storage. Plus they charge for the service.
|
|
|
|
|
Thanks, I've added the GPL v3 license.
|
|
|
|
2FA is simply 2-Factor-Authentication. It's a method of authentication that doesn't have to involve the memorization of 'seeds'. You're a bit too loose with your terminology for a dev oriented board. I don't mean to offend you, it's just that it's hard to understand what you say when you associate seeds with 2FA. Maybe you could explain your use case instead. |
|
|
|
|
The guy gets shot down because 2FA isn't a suitable solution. It's meant to protect a client/server relationship. If the client is compromised, the 2FA prevents the attacker from logging to the server. If the server is compromised, 2FA doesn't help. With a wallet that you keep on your machine, you are the server.
Personally, I'm looking forward to having a solution as easy as the subway cards. RFID and no touch scanner. The display is on the payment device. Your card signs anything that comes from a set of known payees and up to given amount. Or alternatively, you create an escrow account and they give you a passive card. It can't sign but they will record your usage and they will automatically pay for you.
|
|
|
|
Thanks, took me a while to wrap my head around all the config options, but I finally got it to build in EWARM  Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on. The memory is mostly taken by the pre calculated multiples of G. You can reduce that by choosing a smaller window in the WNAF decomposition. |
|
|
|
A vast majority of the nodes is running a version or another of the core client. I don't know the exact numbers but when I look at https://blockchain.info/en/connected-nodes, it looks like it's close to 100%. In my opinion, if most of the nodes run similar code it increases the risk of a common exploit similar to heartbleed or shellshock. Furthermore, Bitcoin core upgrades are conservative because it must avoid introducing bugs as much as possible. In my opinion, if the network was more heterogenous with let's say 10 different implementations sharing equal weight then the chances of a major fork will remain limited. An attack would need to find a flaw that affects 5 different implementations to gain majority. Yet, it is the responsibility of whoever chooses to run a node to understand the risk taken. They could run several implementations for instance. |
|
|
|
|
Well - in my opinion, it's not a sustainable long term situation. I understand there are a lot of factors at play but putting the burden of all the core client work on a single implementation is an unfair responsibility to carry. Besides, it seems that some companies are willing to take the risk of running alternate clients. In my case, I simply aim to be at least as good as them while having a code base that I can be proud of.
|
|
|
|
Create the genesis block,
Mine one million trillion bitcoins and transfer them to some address.
Few days later present you genesis block to the world again and pretend there are only 50 coins created.
Everybody joins the club and forget about the broken chain.
200 years later, when the creators of bitcoin bought all the gold of the world they say tada: here you have another million trillion coins. /s
A broken chain doesn't feel right to me.
I just cannot figure what the maximum negative implications it could have.
Of course the chain is data. But your database problems are not involving value, it's only numbers.
What if giant banks have a problem in their database?
They cannot just fuck around in their database (I know they do) and pretend everything is ok.
The whole point of bitcoin is that the blockchain should be ledger which you can trust.
How do you expect the other blockchain to merge with the current one? |
|
|
|
Ah. I was not aware of this change. Without makefile, I remember I could build using 1) yasm -f win64 -o obj\field_5x52_asm.o src\field_5x52_asm.asm
2) x86_64-w64-mingw32-gcc-4.8.1.exe -I gmp -fPIC -std=gnu99 -DNDEBUG -O2
-DUSE_NUM_GMP -DUSE_FIELD_INV_NUM -DUSE_FIELD_5X52 -DUSE_FIELD_5X52_ASM
src\secp256k1.c -c -o obj\secp256k1.o
3) x86_64-w64-mingw32-gcc-4.8.1.exe -I gmp -std=gnu99 -DUSE_NUM_GMP
-DUSE_FIELD_INV_NUM -DUSE_FIELD_5X52 -DUSE_FIELD_5X52_ASM -DVERIFY
-fstack-protector-all -O2 -ggdb3 src\tests.c obj\field_5x52_asm.o
-lgmp -L gmp -o tests
4) ar -rs libsecp256k1.a obj\field_5x52_asm.o obj\secp256k1.o
following the README from https://github.com/joshlang/Secp256k1.NET |
|
|
|
|
I don't think your scenario is plausible but you are entitled to your opinions.
|
|
|
|
You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead
Well, if they do I'm sure someone will jump on the original fork and get coins at low cost when the difficulty readjusts. |
|
|
|
|
You can get away from using make for secp256k1 but the dependencies will be harder to compile without. Do you have GMP ported?
|
|
|
|
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
|
|
|
|
Miners are more likely to include a transaction with a higher fee. Therefore if a customer transacts with a merchant using a small transaction fee and broadcasts this to one set of nodes and then immediately pays himself the same bitcoins with a higher transaction fee which he broadcasts to a different set of nodes, the merchant may end up with nothing.
Of course, but you are not answering my question. |
|
|
|
|
Do miners replace a transaction with one that has a greater fee? I think they don't. In which case, a merchant just has to wait until his transaction reaches enough pools to ensure inclusion in the next block.
|
|
|
|
|
Show Posts
