Topic: Full node on a Smartphone (Read 564 times)
agree with HCP - would be challenging to solve the power question right. tho theres somewhat mobile solutions https://github.com/rootzoll/raspiblitz)) battery + lte wifi access point - and after full sync you could use it in the field by adding the battery to RPi
Surely, the thermal throttling that would likely occur during the CPU intensive initial sync
combined with relatively small batteries and often fairly limited storage capacity
which direction is computation/battery capacity/storage size technologies moving in? increase or decrease?
and as I said, Bitcoin is becoming less demanding on the hardware, except storage space (which is incurable under a satoshi style full node design). All that has to happen is storage capacity has to continue to outperform blockchain growth rate, and phones will continue to become more viable as Bitcoin nodes. All signs indicate that storage tech will do so, NAND flash continues to scale up nicely.
I would agree that from a raw processing power point of view, the hardware in most modern phones is quite capable of acting as a Bitcoin Node... the issue is really that the package as a whole is not well suited to the task.
Surely, the thermal throttling that would likely occur during the CPU intensive initial sync, combined with relatively small batteries and often fairly limited storage capacity (which in a number of cases is non-upgradeable) make them a poor choice. And, yeah, you can get around the storage issue by running a "pruned" node... but then that is going to limit what you can actually do with it.
Personally, I think, as with a lot of things... just because you can, doesn't mean you should
#stopExcelAbuse
Surely, the thermal throttling that would likely occur during the CPU intensive initial sync, combined with relatively small batteries and often fairly limited storage capacity (which in a number of cases is non-upgradeable) make them a poor choice. And, yeah, you can get around the storage issue by running a "pruned" node... but then that is going to limit what you can actually do with it.
Personally, I think, as with a lot of things... just because you can, doesn't mean you should
#stopExcelAbuse
server
every time you say "server", it makes it sound like bitcoin needs the computing equivalent of Arnold Schwarzenegger to run. in fact, bitcoin has been getting progressively leaner as software over the years. And there are more plans to continue that, while internet infrastructure and data plans have continued to improve.
I used to bring this up years ago, and people dismissed running a bitcoin node on a phone as impossible. you sound slightly like one of those people (although you're right that a raspi can do it, all you're really confirming is that a phone can too, as raspi's are based on the same hardware platform as modern phones)
I don't see the point of this. You could just buy a 24/7 server pc~
that is definitely a viable option that many are using but you still can't compare it with running a node on your own device because that way you have full control but when you run your node on a third party server you are still relying on them and you may not even have any privacy using some of these services.
Oh sorry, I guess I should have been more specific. I meant a server computer under your own control. Such as someplace in your home tucked away. Even better would be raspberry pi.
It uses very little energy compared to a pc and is much cheaper. You could even run a full blockchain instead of just a pruned one.
I agree with you about using third-party servers. Definitely don't wnt to do that.
I don't see the point of this. You could just buy a 24/7 server pc~
that is definitely a viable option that many are using but you still can't compare it with running a node on your own device because that way you have full control but when you run your node on a third party server you are still relying on them and you may not even have any privacy using some of these services.
if they go the altcoin route (which may be it like what Samsung did) it is going to be a lot easier for them because the full nodes of altcoins have tiny blockchains compared to bitcoin and also they don't have that much "traffic" either, usually their blocks are either empty or little used.
Don't forget support PoS-based currency and promote it with headline "Earn cryptocurrency just by run full nodes on XXX's smartphone*"
If you want to participate in the lightning network without any trust, you need to run a full node.
True, but in reality most people would "trust" random nodes/custodial wallet rather than run full nodes.
However, i don't see any reason to have a full node running on your mobile. Rather set up a small raspberry pi at home and connect to it with your mobile.
Saves CPU power and therefore battery.
Saves CPU power and therefore battery.
Totally agree
I don't see the point of this. You could just buy a 24/7 server pc and never have to worry about the internet connection being on or not and you can run a full node with constant power and you will know it will not lose power. You can just control it through an app on the phone. Using the phone as a server is stupid. Use the phone as a control point so everything is central. I really don't see this happening.
It's ridiculous. This might only work well in very isolated areas that desperately need MN.
It's ridiculous. This might only work well in very isolated areas that desperately need MN.
What is the motivation for running a node on a mobile phone? To mine some coins?
I doubt it will be possible unless there will be an enormously-sized poll of similar devices.
It can be for bitcoin core wallet, only wallet not for miningI doubt it will be possible unless there will be an enormously-sized poll of similar devices.
and Ligtning Network wallet are good for running full node on smartphone
- Bitcoin Core isn't available for mobile devices (Android/iOS)
- Bitcoin Core isn't meant for mining
- Full nodes client isn't required to use Lightning Network wallet
- If you want to enjoy full nodes advantage, you could set full node on different device and connect your wallet to your full nodes
I don't think it should be too difficult to port core wallet for Android, as qt apps can work there. Even easier if you ditch the ui and stick with cli, it probably works already...
I don't see the use of running a full node in a smartphone unless its used as a spare dedicated cheap computer and not as a smartphone, always plugged in, no phone, just wifi...
If you ran it in your actual mobile it would kill your battery, and eat your data plan if metered/capped.
I know of good enough smartphones for like $10, so it makes perfect sense (some people abuse them for altcoin mining, plenty of youtube vids).
But i wouldn't personally run the node in the same device as my actual communications device. Unless you only run the node while plugged to power/wifi.
- Full nodes client isn't required to use Lightning Network wallet
If you want to participate in the lightning network without any trust, you need to run a full node.
You don't need it on your mobile. A simple connection to your full node is enough. But a full node is mandatory if you don't want to rely on 3rd parties.
However, i don't see any reason to have a full node running on your mobile. Rather set up a small raspberry pi at home and connect to it with your mobile.
Saves CPU power and therefore battery.
What is the motivation for running a node on a mobile phone? To mine some coins?
I doubt it will be possible unless there will be an enormously-sized poll of similar devices.
It can be for bitcoin core wallet, only wallet not for miningI doubt it will be possible unless there will be an enormously-sized poll of similar devices.
and Ligtning Network wallet are good for running full node on smartphone
- Bitcoin Core isn't available for mobile devices (Android/iOS)
- Bitcoin Core isn't meant for mining
- Full nodes client isn't required to use Lightning Network wallet
- If you want to enjoy full nodes advantage, you could set full node on different device and connect your wallet to your full nodes
It's possible if there's full node client on mobile for PoS-based cryptocurrency. While it's stake rather than mine some coins, both of could give the owner money.
if they go the altcoin route (which may be it like what Samsung did) it is going to be a lot easier for them because the full nodes of altcoins have tiny blockchains compared to bitcoin and also they don't have that much "traffic" either, usually their blocks are either empty or little used.
What is the motivation for running a node on a mobile phone? To mine some coins?
I doubt it will be possible unless there will be an enormously-sized poll of similar devices.
It can be for bitcoin core wallet, only wallet not for miningI doubt it will be possible unless there will be an enormously-sized poll of similar devices.
and Ligtning Network wallet are good for running full node on smartphone
What is the motivation for running a node on a mobile phone?
In this case, it would be make their phones (HTC) sells like hotcakes by introducing niche feature with some buzzword.
But normally, it's for people who strongly believe node have big power/role on decentralization.
To mine some coins?
It's possible if there's full node client on mobile for PoS-based cryptocurrency. While it's stake rather than mine some coins, both of could give the owner money.
What is the motivation for running a node on a mobile phone? To mine some coins?
I doubt it will be possible unless there will be an enormously-sized poll of similar devices.
I doubt it will be possible unless there will be an enormously-sized poll of similar devices.
@Heisenberg_Hunter, I was lucky and I was able to find this amazing answer from @achow101:
What you are describing is an idea that has been floating around for several years now. You're not the only one to think of it.
The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?
Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.
To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.
There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.
The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?
Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.
To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.
There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.
The above quote is a description of an experimental trust model currently referred to as "assumeUTXO", not pruned blocks.
The idea is to bundle a hash of a recent UTXO set state with the Bitcoin client, then sync blocks to the chain tip from the blockheight that the UTXO hash corresponds to. That could mean getting your node up and running very quickly, depending on the frequency of the assume UTXO hashes and how long ago the bundled UTXO hash happened to have been taken (so older versions of Bitcoin will take longer to do an assumeUTXO sync as they'll necessarily have an older hash). This is at the expense of actually validating the blockchain from block 1 Jan 3rd 2009.
As achow101 notes, this means trusting the Bitcoin devs don't go rogue and bundle a UTXO set hash that forks you onto some crazy chain of their choosing. But arguably, most people are trusting the devs like that already, as the genesis block hash is either assumed to be correct, or it's relevance to the trust model isn't even known. Speaking personally, the genesis block could've been swapped out years ago and I myself wouldn't have spotted this, although we are all of course assuming that someone else would've noticed that (there must be someone who's been running the same node since 2009 who actually checks, right?
)In addition, assume UTXO will begin validating the chain from genesis once it's reached the chaintip from the most recent assumeUTXO hash. So the change in trust model is not for the permanent life of the node, it's just a quick & dirty bootstrap technique, really
When you start running a pruned node, your node still has to verify each and every block, from the genesis.
As far as I know, this is incorrect.They do not have the entire blockchain so they cannot verify from the Genesis block. A pruned node can only verify after a determined block, which is stored in the node.
So you have to trust that you received the transaction history from a "trusted user". And that that history is correct.
A full node just need to know that the Genesis block is correct. That's easy to check. But check the entire pruned blockchain is not.
Please correct me if I said something wrong.
So, if you setup a new instance of bitcoind, set it to pruned mode and then start it up... it will still start at the genesis block (just like a "normal" full node) and then sync/verify all 575,916 blocks (as of writing this). However, it will only store as many as it can fit in the given "pruned" size (user specified)... so once the "storage" is full, as newer blocks arrive, older blocks are removed to make room.
There's already an Android app that wraps the bitcoind binary to sync a full node on a phone, developed by GreenAdress IIRC
When you start running a pruned node, your node still has to verify each and every block, from the genesis.
As far as I know, this is incorrect.
They do not have the entire blockchain so they cannot verify from the Genesis block. A pruned node can only verify after a determined block, which is stored in the node.
So you have to trust that you received the transaction history from a "trusted user". And that that history is correct.
A full node just need to know that the Genesis block is correct. That's easy to check. But check the entire pruned blockchain is not.
I think you missed the point, just like full node, pruned full node also download and verify downloaded blocks from other full nodes.
The difference are pruned mode remove blocks data after verification is done and verification information of that block is still stored.
Spv nodes are completely different and do not verify transactions, just look for transactions related to the wallet addresses from other full nodes.
This is completely wrong, few SPV wallet usually perform at least 3 verification :
1. Whether it has valid format
2. Download and verify all Block header
3. Using Merkle tree to perform verification whether an transaction included in a block
Take note not other SPV wallet have same method.
When you start running a pruned node, your node still has to verify each and every block, from the genesis.
As far as I know, this is incorrect.
They do not have the entire blockchain so they cannot verify from the Genesis block. A pruned node can only verify after a determined block, which is stored in the node.
So you have to trust that you received the transaction history from a "trusted user". And that that history is correct.
A full node just need to know that the Genesis block is correct. That's easy to check. But check the entire pruned blockchain is not.
Spv nodes are completely different and do not verify transactions, just look for transactions related to the wallet addresses from other full nodes.
Please correct me if I said something wrong.
@Heisenberg_Hunter, I was lucky and I was able to find this amazing answer from @achow101:
What you are describing is an idea that has been floating around for several years now. You're not the only one to think of it.
The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?
Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.
To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.
There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.
The reason it has not been implemented is because it introduces some centralizing trust. Right now, a new node coming only has to verify every single block and confirmed transaction since the beginning of Bitcoin. In doing so, they are able to build the UTXO set themselves and check that everything is correct. The only trust is that the genesis block is correct, and if it is not, it's extremely obvious that it is wrong. However changing it so that the "genesis" is really the UTXO set at a certain height means that there is going to be more trust. Now you have to trust that the UTXO set is correct. But without having the full blockchain history, how can you prove that that UTXO set really was the UTXO set at the cutoff point?
Additionally, the UTXO set is kinda big. It isn't really something that you want to package with a software. But you need to get it somehow. Well now you need to trust that whoever gave you the software (either packaged or over the network from another node) haven't changed the UTXO set. Changing the UTXO set would not be as obvious as changing the genesis block. You could simply add an extra UTXO and basically no one would notice. It wouldn't be noticed until the UTXO was spent, and if done at the right time (when no nodes with the full history remain), would be completely unnoticed.
To combat that, you could say that miners have to include the hash of the UTXO set in their blocks, or maybe even just the hash of the UTXO set for the block immediately after the cutoff. But now we have someone else we need to trust: miners. Now you need to trust that miners have used the correct hash. You need to trust that whoever is producing the UTXO set hasn't colluded with miners to insert a fake UTXO into the UTXO set. If they did, you would have the same problems as earlier, and it would seem like the UTXO set checks out since the hash is also in a block.
There are other possibilities too that have been discussed elsewhere. But the issue with this idea in general is that it involves more trust. And in a system where the goal is to have as little trust as possible, that is just not going to happen.
Jump to: