I consider the Bitcoin Core Client is a normal hot wallet. In terms of security it is not better or worse than any other hot wallet without the full blockchain. Of course there are clients which have better security than other. but from security perspective I throw all hot wallets into the same pot.

To have a full node instead of using a SPV client is indeed better but both wallets store the private keys in a similar way so they are the same for me in this regard.

You are right that paper wallets can be encrypted, but as you also say with force from an attacker none of the available wallets/key-stores would safe your coins.

The best security is when no one knows that you own any bitcoins. And you also don't have any traces on your PC/phone which might let anyone think you have some bitcoins (like installed bitcoin clients). This could be achieved in parts with an encrypted OS running inside a virtual machine which runs the bitcoin client.

The question is always, how paranoid you wanna be to secure the bitcoins. This also depends on how much you have to secure.

Your idea to encrypt and rename the wallet.dat (security by obscurity) might only work as long as you don't need it. If you want to create a transaction from this wallet.dat you need to encrypt it and load it with the bitcoin client. And when your PC is infected with malicious software it will not help you.

I got your point. The specific client which censors these transactions will only be used by people who want it. In this case it would technically work for those people.

But my points you think are wrong are still valid. This client would have some limits and cannot be used as a normal full node any more.

This specific client would only be useful as wallet, as it contains modified blocks which other nodes would reject when it broadcasts them.
If someone install a new orignal full node and ask for blocks to download the blockchain from beginning, this specific client would not be able to serve this as it would get blocked by the other node whenever the cencsored block is transmitted.

The comparison with pruned nodes is not good. First these nodes do not hold any invalid (censored) transactions or blocks. And second, like this specific client, they cannot broadcast all blocks to the network, they only forward new received blocks and can maybe send the blocks which are not pruned. If the whole bitcoin network would only consist of pruned nodes, it would not be possible to install a new full node as no one has a full copy of the blockchain any more. Even for pruned nodes, first the complete blockchain need to be downloaded and validated, only then the already spent transacations will get deleted and only the unspendet transaction will be kept on disk to save space.

I'm just thinking of any reason why anybody would want to install such a specific client which censors some transactions.
Only people who don't want to have those things on their PC would install it. But wouldn't it in this case just be not enough that those people don't look at these transactions?
Nearly no normal user is searching the local copy of the blockchain for transactions like this. Most people just don't know that such transactions exists. And even if they would know it, again most of these people would not be able to find such transactions and extract any image files out of the blockchain.

So you would need someone who know that such transactions with hidden images exists. This one need to investigate which transactions this are (not sure if there are listings of such transactions available in the internet). Then he would need to find out how to extract the information from the blockchain to save it as a picture.
In case you have somebody who really want to do this, then he would not download this specific client but the original one. Or maybe much easier just get the transactions from blockchain.info or something similar.

These are just my thoughs why it would be useless to invest time in creating such a client.
The people who don't like these things will not try to find it even if it is somewhere saved on their local copy of the blockchain, and the other people (I think there will not be much people at all) who want to get those stuff will not use this client.

wallet.cpp and wallet.h are only source files to build the bitcoin client. They will not help at all to restore a damaged wallet.dat.

If you don't have any older backup of your wallet.dat I'm not sure that you will be able to recover the file.

Changes to avoid downloading and/or storing such transactions would only be possible for full nodes which are only used privately (with closed port 8333).

Every accessible full node in the network need to provide the correct blocks/transaction to any other node which asks for this blocks, otherwise there is no way for a new node to validate and sync the blockchain correctly.
So, the blocks with those transactions need to be stored by every full node. What could be possible is to disallow the access of those transaction by the local gui and via the RPC interface.

But this would not help at all, there is no way to force anybody to use this "censoring" client.

The only way would be to censor those transactions via a hardfork. But this would require every client to be updated, which will never happen.

Actually the only reason for blockchains is the censorship resistance and immutable property. If we start to implement any way to censor anything (which is actually not possible), we would not need a blockchain anymore.
A side effect of censorship resistance and immutable is unfortunately that there can be also stored illegal data which will be there forever.

In my opinion the advantage of bitcoin outweighs all the possible use cases for illegal purposes (e.g. buying drugs, money laundering, storing of illegal data...). The reason for this is, that all those illegal stuff can be done and is done better without bitcoin or blockchains.

I also had this idea and did not find a direct way to do this (but I did not really search hard).

But it depends on what you want to achieve with it.
My approach was to connect a SPV client directly to my full node, so I don't rely on full nodes of other people.

One way to do this would be to install an electrum server which talks to your full node and then use the electrum client to make use of your full node.

Maybe there are wallets outside which can directly connect to bitcoind RPC but I did not found them.
One security concern I would have with such wallets is, that you need to open the RPC port for everyone to be able to connect to your bitcoind. This could be a big attack vector if not secured properly.

More or less they were claiming that it's unhackable, and that's my only issue with them.
https://www.ledger.fr/2015/03/27/how-to-protect-hardware-wallets-against-tampering/


This claim was proven false now.

Nevertheless in my opinion I still think a hardware wallet is more secure than any other wallets when used safely.
Just that hardware wallets do have security issues does not make any other type of wallet which have MORE security issues suddenly better.

My ranking of wallets in terms of security would be the following

• Hardware wallets
  If you don't take them outside of your home and attacker don't get physical access they are pretty safe -> with physical access as proven now it might not be safe
• Paper wallets
  If they are kept hidden in a secret place -> but with physical access by an attacker -> no security at all.
  If people carry them around I consider them worse than any mobile wallets (they do at least have a pin to secure the wallet).
• Airgapped PCs
  Pretty safe as long as an attacker don't get pyhsical access. I consider them worse than a hardware wallet because a PC/MAC/whatever even if not connected to the big world has a much bigger attack vector than a hardware wallet if getting pyhsical access.
• Any local hot wallets on PC/MAC
  With spyware or other malicious software these wallets can be easily compromised. No physical access necessary
• Any mobile wallets
  The security of such wallets is usually quite bad. Usually very short pin-codes are used to secure the wallet. As it's easy to lose them an attacker can get physical access to it.
• Online wallets where you control the private keys
• Online wallets where you don't control the private keys

Did I miss any type of wallet?

Beside of my listed ranking anyone can (and should) improve the security by combining several methods above and use multi signature addresses. In this case it is not possible to steal funds if just one of the methods is compromised.

Would be interested if someone has a different ranking than me.

Got you. Thanks

Thank you for your quick response.

I had to lookup what an upstream repository is, but I think I found out how it works.

I did the following

$ git remote add upstream https://github.com/bitcoin/bitcoin
$ git fetch upstream

getting the last changes from upstream to be up to date
$ git checkout master
$ git merge upstream/master

then I checked out the upstream/master
$ git checkout upstream/master
$ git checkout -b <topic_branch>

and added my changes again.

Unfortunately the last update killed my changes as the feature I wanted to add relies on a feature which was removed 2 days ago....
So I cannot continue to check if creating a pull request would work the way I did now.

Maybe you can tell me if I'm on the right track with my steps above so I can do it correctly when I have another change I want to contribute?
What would be the correct next steps to create a pull request?

$ git commit
$ git push -u upstream/master <topic_branch>

Would I see then the upstream branch in my github repository to be able to create the pull request from there?

I think I need to do some experimenting on a github test project as well to see how everything works.


Edit: did not see your last edit before posting my comment.
But it looks like I found the correct way how to do it. I think I just did also some unnecessary steps.

I will do some tests on a test project to make sure I understood everything correctly.

Thank you so much!

I was missing a small, let's say feature, in the current bitcoin-qt version. So I decided to implement this by myself.

As I never contributed to an OSS before I did some research on how to do that correctly.

Starting point was the CONTRIBUTION document from the bitcoin repository https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md.
My missing knowledge there was basically the correct use of git / github with branches, remote repositories, merging and pull requests.

I learned about that and I'm quite confident that I understood all those stuff.

I already did

• Fork the bitcoin/bitcoin repository to my github account
  done on github.com
• Frequently created pull requests from bitcoin/bitcoin to my forked repository to stay up to date
  done on github.com by browsing to bitcoin/bitcoin repository -> clicked "New Pull request" -> clicked compare across forks -> changed the "Base fork" to my repository -> created the pull request and merged it
• cloned my forked repository to my build environment
  $ git clone https://github.com/<MyGitHubUser>/bitcoin.git
• created a topic branch
  $ git checkout -b <topic_branch>
• made my changes
• commited my changes and pushed the local topic branch to my forked repository
  $ git commit
  $ git push -u origin <topic_branch>

Now comes the part where I'm uncertain if I did everything correct or if I'm missing something.

On github I browsed to my bitcoin fork, selected my pushed topic branch and clicked the "New Pull request" button.

There I see the comparison from bitcoin/bitcoin to my_fork/topic_branch. The suggested title for the pull request by github is my last commit message from my topic branch. So far so good.

But I expected to see only my changes I made within the topic branch, but additionally I also see all the changes from my previously pull requests from bitcoin/bitcoin which I merged to my master branch.
Of course I don't want to have those changes in my pull request back to bitcoin/bitcoin.

I did not see anything on github which allow me to select only my last commit to be in the pull request.

What did I miss or how can I create a pull request with only the changes done in the topic branch and not everything I have done in the master branch?

I would appreciate any hints on how to solve this issue.

Thank you in advance.

I would suggest you look at the book of Andreas M. Antonopoulos - Mastering Bitcoin, which explains the technical concept of Bitcoin.

The book covers all parts of bitcoin and is ment to be read by developers.

You can buy it at Amazon or you check out the free version at https://github.com/bitcoinbook/bitcoinbook

Formating your phone reduces the chance that someone can access your wallet. The only 100% secure way to avoide that someone restores the wallet is to create a new wallet on another device (new phone  or anywhere else) and transfer all coins from the old wallet to the new one and never use any of the addresses from the old wallet again. In this case even if the old wallet got somehow restored or hacked or whatever there are no coins on it which can be stolen.

As ranochigo and bob123 already mentioned, the 51% attack has nothing todo with consensus rules.
Even with a 51% attack you would not be able to create invalid transactions as they would be rejected by any other participants.

But you could do the following, even if it is very hard to do because you really need massive amount of hash power even to lower the difficulty. If you don't manage it to mine 2016 blocks the difficulty will not decrease. And with a high enough difficulty to begin with, you might need 1 week or longer to just mine one single block. To mine 2016 blocks would then take years.

But lets say just for fun the attacker does have the necessary hash power.
What could he do with a 51% attack?

1) He could prevent transactions which are broadcasted and are inside the mempool to get into a block so that the transaction keeps unconfirmed as long as he keeps the 51% advantage.
2) If he really is the only one who mines this coin he could rollback transactions. For this he defines a specific blockhight from the past, lets say he start 2 weeks in the past (about 2000 blocks before the current block hight) and continue mining from this block and create a fork. At some point his fork might be longer than the original one and then all other participants would need to reorg their chain and your chain become the longest valid one.
The only reason why someone would do this, is when he plans to replay one of his own transactions.
Lets say he made a transactions 2 weeks ago where he transmitted 10 coins. The transaction was confirmed by the network and got into one block. If he starts mining one block before the block of his transaction he could create a replay transaction which use one of the same UTXOs from the original transaction and send the coins to one of his address instead of the original target. In this case the orignal transaction would become invalid and the original receiver of the coins would not get it.

But you can do this only with transactions where you control the private key. All other transactions which were inside the blocks you rollbacked would just go back to the mempool and wait for anybody to mine them again. They are not lost. Either the attacker himself mines those reorganized transactions on his side of the fork or like in point 1 described, he just ignores them and they stay in the mempool forever or until any other miner starts mining and he looses the 51% advantage.

Actually there is a chance that those rollbacked transaction are lost forever if the other participants of the network did not had the original rollbacked blocks in their local blockchain. For example they start syncing the blockchain from the beginning or from an older point than the attacker started the reorg. But if anybody did have this reorg blocks in their local blockchain, those transaction would be broadcasted again (through the reorg process of the bitcoin client) and later mined again by any other miner.

That's actually the only 2 attack points you have with a 51% attack.
Point 2 above (to get already spent coins back) makes only sense if the coins do have any value (but if no one is interested in those coins - no node is online, no one is mining then the value of this coin will be 0). And then it's maybe still more profitable to just mine as much blocks as possible on top of the last block to get the block reward.

In all other situations where you start creating invalid blocks/transactions you would just create an invalid fork of the blockchain which does not give you any advantage as all other participants would just reject your blocks.

Your explained way to cheat the system is not possible.
There is more than that the longest chain wins, it's actually the longest valid chain wins. If only the longest chain would win, I could start mining now with a very low difficulty and broadcast new blocks every 5 minutes. I would then have the longest chain and would, in your logic, force all other participants to change to my side of the blockchain, because it's the longest. That's not how it works.
If someone creates transactions or blocks which other nodes don't accept, because they go against the consensus rules, they just ignore those transactions and blocks and also ignore the node which is broadcasting those.
This is how it works at the moment with 100000 of participants, this is how it will work with only 2 participants in the bitcoin network.
The only way to be successful with such an attack is when the attacker change the bitcoin client and change the consensus rules so that his illegal transactions looks like valid transactions and all other participants of the network download this bitcoin client.
If other participants work with the original client and original consensus rules the only thing what happens is, that the attacker creates a fork of the blockchain with illegal transactions and blocks. All other will just ignore this side of the fork and continue on the other valid side of the fork.

So it's actually a dump way to cheat in this way.
If you are the only one left in the network you could just start mining normal and valid blocks and be happy with the block reward and hope that the coin is coming back alive after some time to be able to sell those coins. But it depends with which difficulty the last block was mined. If it was too high, you might not be able to mine any block within a reasonable time frame. Difficulty adjustments in Bitcoin only happens after 2016 mined blocks. So it's possible you are not able to mine those much blocks to reduce the difficulty.
Then the only way to bring the blockchain back to life would be a hardfork to change the difficulty adjustment. But then again, if other nodes start to join the network again, they will see your blocks as invalid unless they also update to your new client with new difficulty adjustment.


In the example of Bitcoin there are currently a lot of full nodes which have the full blockchain saved. So even if all nodes go offline that does not mean that everyone is deleting the blockchain.
In the best case someone who want to continue mining already have the previous blocks. If not he might find someone who did run a full node in the past and get the blocks from this person.

I'm quite sure you don't need to do this manually. The lightning node software is doing this for you automatically when it identify an unfair player.
But for that you have to be online (at least to be online again before the time lock of your channel partners transaction is reached).

It's correct that you don't need to be online 24/7 as this time lock is quite high. I think 1000 blocks or so, which are roughly 7 days. But I could be wrong with this. Better look up yourself if you want the correct time.

Actually it is possible to create a coinbase transaction which pays less than the maximum possible amount.

Check this url about protocol rules https://en.bitcoin.it/wiki/Protocol_rules which explains all the checks which are done to ensure consensus.


To verify this statement I was also checking the bitcoin code what is actually implemented and I found this https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2011-L2017


You can clearly see, that it's not allowed to reward more than the block reward + transaction fees, but anything equal or smaller than the block reward + transaction fees is fulfilling the consensus rules and is valid.

The question is just, if and why someone would not claim the maximum possible reward when mining a block.


Nevertheless that this situation is possible, I'm not sure if your example is actually doing this or if there is another reason like paxmao or teramit already explained.

If you could provide the block hash of your example we could give you a better reason what exactly happens with the block reward inside this block.

If the other party don't want to cheat on you and close the channel with the latest confirmed transaction, everything is fine.
The problems start if the other party close the channel with an old version of the transaction (where you get less coins than with the latest transaction) and you are offline. In this case you could lose coins..
If you are online and see this, you have the possibility to post a transaction where you can grab the coins of the other party.

Just an example:
Initial channel balance is 1 BTC from you and 1 BTC from the other party.
Then a transaction happens from the other party to you. Say you receive 0.2 BTC.
The current status of the channel (latest confirmed transaction) is 1.2 BTC for you, 0.8 BTC for the other side.

If the other party is closing the channel with the first transaction where he closes it with 1 BTC for him and you don't see it, he would be able to steal you those 0.2 BTC.
If you would be online and you recognize it, you could post a transaction (only then) to get the full 2 BTC from the channel.

This means, there is an incentive that all parties play fair and only post the last confirmed transaction and don't cheat. If someone cheats, and the other party see it, this party could then get the whole balance of the transaction and the cheater get nothing. That's the only reason why the lightning network works without trust on the other party.

But in case you are offline and don't have the possibility to see this kind of cheating on you, you would lose coins.

But I guess there will be possibilities (if not already possible with current implementations) to delegate this checks to someone who is online 24/7.

Thank you for your great answer. This was the missing link I had.
It's now clear for me and I can dig deeper into the details of the lightning protocol/network.

You answer your question by yourself.
With the link you provided you see the complete network. Each node has information about the exact same info like this site has. You know each node in the network with each capacity of every payment channel between two nodes. So by knowing this, the source can make whatever route it wants to reach the target (I think there is a limit of maximum 20 hops).

Different implementations may focus on different strategies to route to the target. But I guess the most will try to find the cheapest route which has enough capacity to send the coins.

Hi,

I'm trying to deeply understand how the lightning network is working.

I understand how a payment channel between two nodes works, but I did not find out yet, how a more complex multi hop transaction is working in terms of an atomic transaction.

How does the network make sure, that all nodes are doing the transaction if everything is fine, or that no node is doing the transaction if any problem occurs (for example one of the selected nodes in the route is down).

I understand the network like this.

1) Sender is searching the best route through all nodes to reach the target.
2) Sender is encrypting the selected route node by node (onion routing)
3) Sender send coins to the first node using a payment channel between sender and first node
4) The next node decrypts the follow up node and continue sending coins to the next node over the next payment channel
5) continue with 4 until the target node is reached.

In my understanding, whenever I send something over the payment channel, this transaction is completed and not reversible (this is maybe the point where I'm wrong).
So, when I have 10 nodes in my selected route, and node 5 in my list is down. How does the network make sure, that the 4 nodes before are doing a rollback to give back the coins to the sender, so the sender can try a different route.

An explanation about this missing link I have would be great.

Thank you in advanced.

Hab meine bei Coinfinity, Bitpanda bzw. Coinbase gekauft.

Die führen jeweils eine Bestell-Historie. Damit kann man nachweisen wann man wie viele Coins zu welchem Preis gekauft hat.

Nehme an, dass auch andere Börsen das mit speichern.

Wenn man die Coins privat von Person zu Person kauft, (zB Localbitcoins) weiß ich nicht genau inwieweit die nicht vorhandenen Aufzeichnungen hier helfen.

Im Zweifel auf jeden Fall in einer Excel Tabelle jeden Kauf mit Datum und aktuellem Preis notieren. Vielleicht reicht das ja schon.