Wallets and nodes have nothing to do with each other. They should be completely independent projects.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
The irony (well, perhaps not irony) is I'm getting caught-up so I can start Bitcoin Cash on the wallet.dat with a clean blockchain (yes, this does not make sense) to claim the Bitcoin Cash there.
[doublepost=1516122589][/doublepost]
But the correct direction may well be [Edit: it *is*] additional modules on top anyway rather than part of the main node itself. KISS. I swear I need to start diagramming this.
[doublepost=1516122589][/doublepost]
That's where I'm coming from. Yet I think it's worth examining what a node would need to support wallet interaction. Certainly, examination of the UTXO set would allow simple wallet functionality fairly easily. Transaction history means either a rescan of the blockchain (either by the wallet or as an internal function of the node software) or keeping an indexed database of historical transactions. The wallet scan is simplest, probably most privacy preserving but likely to be the most resource intensive and slow. Scanning by the node, mildly resource intensive, potentially privacy invasive and also slow. Indexed database would be fastest but require dedicated storage.
But the correct direction may well be [Edit: it *is*] additional modules on top anyway rather than part of the main node itself. KISS. I swear I need to start diagramming this.
Last edited:
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
Well, I have a name in my mind. It's a pretty awful name but maybe amusing 
What wallets need is a way to query for UTXOs based on script elements (public keys, everything that is matched by BIP-37) and they need a block header oracle (to verify Merkle proofs associated with each UTXO they query).
It would be better to created a distributed network for indexing and querying the block chain in that fashion, especially if queries could be made private.
The Freenet project is almost a perfect fit for those requirements. It creates a distributed, replicated K-V database that allows nodes to join and depart at will and decide individually how much storage to contribute to the network and features private queries and inserts.
I think that a modified Freenet network would be ideal for creating a network for serving UTXO queries.
It would be better to created a distributed network for indexing and querying the block chain in that fashion, especially if queries could be made private.
The Freenet project is almost a perfect fit for those requirements. It creates a distributed, replicated K-V database that allows nodes to join and depart at will and decide individually how much storage to contribute to the network and features private queries and inserts.
I think that a modified Freenet network would be ideal for creating a network for serving UTXO queries.
While going crazy waiting for a confirmation I took a look at the BCH BTC ratio. The BCH price is approximately 16% of the BTC price but the hashrate is 4.3%.
If I was a little more critical I’d think is almost as if hashrate is moving to clear the BTC mempool so people can move BTC onto exchanges.
If I was a little more critical I’d think is almost as if hashrate is moving to clear the BTC mempool so people can move BTC onto exchanges.
- Aug 29, 2015
- 536
- 2,597
Seems to be averaging closer to 10% over longer time periods: https://fork.lol/pow/hashrate
Makes sense based on relative prices and fees.
Makes sense based on relative prices and fees.
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
It's been a while since I did anything with Freenet but when I last looked it was extremely slow and quite unreliable (certainly an interesting idea though).
Step 0 would be to have wallets trust the node they are connecting to. Though other options could definitely be implemented into a modular "wallet API layer". In fact, the wallet could query the cloud for transaction history then verify it against the trusted node. (Though I don't want to think on that too much, that would be for wallet/wallet API developers).
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
Entirely optional. It's probably the simplest implementation model and if it's your node, why not?
Certainly if you'd want to build a trustless wallet, it should also be supported (though probably in the wallet API layer).
To be honest, I don't really care about wallets except as a vague concept for this I have thought of another division though (blockchain history vs UTXO maintenance).
Certainly if you'd want to build a trustless wallet, it should also be supported (though probably in the wallet API layer).
To be honest, I don't really care about wallets except as a vague concept for this
I have thought of another division though (blockchain history vs UTXO maintenance).I would like to separate the wallet from BU. In practice this means adding a SPV wallet to the BU family, and changing BU full nodes to help these wallets (tx index probably). The SPV wallet needs to be built on a cross platform architecture like meteor.
There could be some small tie in between your trusted full node and your wallet. At a minimum it removes the core complaint that spv is less secure. But also maybe full node wallet becomes savings act that only signs tx that sends to phone walllet, or "vault" proposal...
There could be some small tie in between your trusted full node and your wallet. At a minimum it removes the core complaint that spv is less secure. But also maybe full node wallet becomes savings act that only signs tx that sends to phone walllet, or "vault" proposal...
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
Yes, one of the projects I had in the pipeline before all the BTC mess was a wallet which spoke to a full node (in the trust of the wallet owner) but that doesn't make sense if you're not supposed to transact the stuff. I was actually hopeful that it would spur node ownership (though I tend to agree that non-mining nodes don't add much to the network these days). Still, just planning it out made me acutely aware of several of the shortcomings of the project and that development has tended to be driven by the interests of a small few.
[doublepost=1516168957][/doublepost]The monolithic "kitchen sink" design has also been damaging to the emergence of new technologies too. People still come up with them but it usually means they have to use their own heavily modified node implementations.
For example, one thing I'm playing with, it would be useful to be able to study the UTXO set but that's not an option. That should be exposed by the API but the inclusion of the wallet API allowed that to remain opaque.
[doublepost=1516168957][/doublepost]The monolithic "kitchen sink" design has also been damaging to the emergence of new technologies too. People still come up with them but it usually means they have to use their own heavily modified node implementations.
For example, one thing I'm playing with, it would be useful to be able to study the UTXO set but that's not an option. That should be exposed by the API but the inclusion of the wallet API allowed that to remain opaque.
Wallets can query transaction data from an untrusted source all long the transaction source provides a merkle proof for each transaction and the wallet can decide which chain of block headers to follow.
The only significant value add from connecting a wallet to a trusted node is a privacy improvement because you know your trusted node will not give away your query history.
The actual problem is that wallets need a system for private queries of blockchain data rather than that wallets need trusted nodes.
The only significant value add from connecting a wallet to a trusted node is a privacy improvement because you know your trusted node will not give away your query history.
The actual problem is that wallets need a system for private queries of blockchain data rather than that wallets need trusted nodes.
Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
Someone read a book 2003 and "used it extensively".
Hierarchies of Signatures ...
Trees versus Webs ...
Hierarchies of Signatures ...
Trees versus Webs ...
- Aug 29, 2015
- 536
- 2,597
Lots of red in the charts, the main thing I'm watching is BCH/BTC ratio which seems to be holding up pretty well, at ~0.15 now.
Anything above 0.12 I'd still consider to fit with a rising BCH/BTC trend over multi-month time scale.
Anything above 0.12 I'd still consider to fit with a rising BCH/BTC trend over multi-month time scale.
I penned a piece back in 2013 titled "Wall street vs Silicon Valley". Others are starting to notice :
http://knowledge.wharton.upenn.edu/article/is-this-the-end-of-money/
As well, it would be silly to assume that Wall Street has laid hands off all these years in the interim.
[doublepost=1516320407][/doublepost]Big wall
http://knowledge.wharton.upenn.edu/article/is-this-the-end-of-money/
As well, it would be silly to assume that Wall Street has laid hands off all these years in the interim.
[doublepost=1516320407][/doublepost]Big wall
Well look here Greg Maxwell leaving Blockstream and Core in a bit of a mess.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015586.html
[doublepost=1516334887][/doublepost]@hodl to post an image using the image Icon in the text editing menu you need to enter a url that has the image file name at the end, if you use a free image hosting site right click the image and click view image or copy image URL and then add that to the image field.
the URL for your image above is https://i.imgur.com/uidefDk.png
Greg Maxwell leaving Blockstream and Core in a bit of a mess.https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015586.html
[doublepost=1516334887][/doublepost]@hodl to post an image using the image Icon in the text editing menu you need to enter a url that has the image file name at the end, if you use a free image hosting site right click the image and click view image or copy image URL and then add that to the image field.
the URL for your image above is https://i.imgur.com/uidefDk.png
Last edited:
Hmm, let's think about this. SC's main proponent and designer gone from Blockstream, rt hand blue haired man gone to Chainlabs, CT's that are known to be 50x the size of regular tx's, merge mining game theoetic issues that we've known about since the WP, SPV proofs requiring look backs of 200 blocks or so not too practical and being pounded on by none other than Peter Todd himself. Remember those 400 pages or so of debate from BCT? Seems to me like SC's are dead forever (although never say never) . At least in regards to its SPV proof model.
With that in mind, it comes down to just LN vs BCH for long term scaling. That's an easy win imo.
With that in mind, it comes down to just LN vs BCH for long term scaling. That's an easy win imo.
Last edited:
