Had multiple requests to help to pair Fully Noded.
Someone with an.iPhone will need to test this.
The format is here: https://github.com/Fonta1n3/FullyNoded/blob/master/Readme.md#quickconnect-url-scheme
@Fonta1n3 is the author Fully Noded. Either of us would be glad to test any final URI or QR codes.
-- Christopher Allen
This is great! I forgot to raise this issue a few months ago when we talked about it. Since then (as Rootzoll requested) I added the ability to encrypt the wallet in “settings” > “security center”. I just updated the readme for Fully Noded to reflect the final url scheme “btcstandup://“ the url is backwards compatible though. If you need testing done send me a url anytime.
@Fonta1n3 we have the disablewallet=1 by default in bitcoin.conf. As I see we need to enable.that for someone wanting to use Fully noded, right?
oh, and txindex too: https://github.com/Fonta1n3/FullyNoded/blob/master/Readme.md#bitcoinconf-setting
Is the pairing and the app functional while txindex disabled or still indexing?
@openoms As FullyNoded stands if wallet is disabled you'll get a command not found error. But that is easily fixed, I will fix it today and push to tesflight so that it will be live tomorrow. The only thing is its quite boring to use if the wallet is disabled. There was a conversation between myself and @rootzoll awhile ago about raising an issue here to request that you enable it by default which I will do now :)
Making remote rpc calls while the node is doing IBD/indexing/rescanning generally works fine but sometimes they get pushed back.
Link for the experimental feature: https://github.com/openoms/raspiblitz-extras#connect-fully-noded
@Fonta1n3 enabling the wallet is not a problem, we will have it for Joinmarket too. It is enabled in a couple of seconds after the user clicks on Connect Fully Noded.
Creating the txindex is a longer process, but that as well should be activated for BTC-RPC-explorer so a welcome setting. Glad to know that your app is working without it too.
Is txindex is only to speed up transaction lookups or does it add more options?
I could see that we (the larger community) should have a discussion about what the different parts of the architecture and, and what are the possibilities for different interactions.
For instance, a subset of Fully Noded could be great for doing multisigs, which requires more knowledge about keys in the remote device, but less (or none) from the full node. Wasabi probably comes close to this as well.
Thus maybe rather than Wasabi reading a QR code to connect to a full node, instead, Wasabi first generates a QR or URI code that says what kind of full node it needs (watch-only, mainnet, pruned as of blockheight OR wallet, mainnet, archive node, txindex OR add lightning to one of the previous options) and then Bitcoin Standup or Rasblitz responds with "Can do that, here is how you communicate securely to me". Alternatively, maybe the Quick Connect code also optionally tells the client what kind of node it is offering. I'm not sure which is best.
But if we can convene some of the different parties, we can maybe better define the requirements for the interconnections might look like better than our initial proposal.
@openoms txindex is useful for a number of reasons depending on how you use your nodes wallet, definitely more then just speeding up the tx fetching. I remember getting errors when trying to use some of the more powerful features FullyNoded offers without having it set to 1 (if I remember correctly using importmulti to add keys to the keypool?). Essentially in order to get full functionality out of the nodes wallets rpc calls you need txindex set to 1, but again it is not mandatory at all and depends on how the individual uses their nodes wallets.
@ChristopherA that is very interesting and there is a lot of room for experimentation with btcstandup:// uri. As a basic starting point I was also thinking of adding an optional parameter so that a user could share their node with a counter party but FullyNoded would understand that it should only allow the user access to one particular wallet and prevent the user from accessing other wallets on the node, which fits in nicely with how multiwallet rpc works. Look forward to discussing.
@openoms to be clear all that is required by FullyNoded to connect as far as bitcoin.conf is concerned is rpcuser and rpcpassword, if using regtest you may need to specify rpcport.
On test on my iPhone after scanning the QR code I just saw a still image of the qr code - nothing is happening. Once I press back, I see no new node in the config. So I am not able to test if this is working ... but so far it seems to OK to release with v1.4RC1
I got at least one person reporting that tested successfully. I have no iOS device to try myself, but the content of the QR looks ok.
@rootzoll if you have a uri for a testing node that you can share I am happy to test it or at least confirm the format is correct. It is working for all the QR codes I have been testing.
I have also had one or two people confirm they have connected successfully to raspiblitz.
Haven't got a node without history in the wallet.dat currently to share, but the format scanned from a rather simple (easily readable) QR code from the LCD and terminal screen is :
btcstandup://raspibolt:[email protected]:8332/?label=
That uri works fine on my device.
OK sounds good - so I consider the testing OK :) and closing the issue for now.
Sounds good, just FYI what you experienced was a known bug a few versions back, if you are on an older version please do update and try again.
Most helpful comment
OK sounds good - so I consider the testing OK :) and closing the issue for now.