Since central bankers still use their weight of Gold (Au) reserves as unit of account, and Bitcoin gives you the same status as ''Digital Gold'' reserve holder, we should add the option to drop the fiat dollar value in the right bottom corner in Wasabi Wallet in favor of grams (SI-unit) of Gold (Au).

*plot from The Bitcoin Standard - Saifedean Ammous (http://gen.lib.rus.ec/book/index.php?md5=7D394651158ABC9470CBCCE538FAAA49)
There is also an intrinsic energy cost in GWh or Joule related to the current hashrate/difficulty per bitcoin, which would be a fair and scientific Cost for 1 bitcoin. Next level would be E=mc^2 with weight of energy per bitcoin, only applicable post-hyperbitcoinization.
Clickable price ticker that rotates between USD, Energy cost to mine (GWh or Joule), equivalent weight in Gold (grams Au) of the value.

Accept the mighty dollar as my Unit of Account even as a non-US citizen, bow before its fearless leader (the orange man) and to not question the perpetual wars (Iran anyone?) for global domination.

+1 for grams (Au)
was thinking the exact same thing recently!
very nice idea
You are spot on.
This is a serious degrading of the user experience.
There is no us dollar shitcoin in Wasabi.
It is ONLY Bitcoin.
I do love the idea of showing hashrate, or mempool size, or some other intrinsic metric. That would be nice to see in the status bar.
Yet, I do understand the value of having the current price of some trading pair. But there are many different types, so we might as well give several options.
What would need to be done in order to add different fiat shitcoins, and gold APIs integrated?
I think it would be good to support several trading pairs, and the option to show only Bitcoin intrinsic information.
Example code for a gold-price API in Python3:
import bit
import quandlsats = 100000000
au = quandl.get("BUNDESBANK/BBK01_WT5511")[-1:]
goldusd = str(au).split()[-1]
dollars = float(bit.wallet.satoshi_to_currency_cached(sats,'usd'))
weight = float(dollars)/float(goldusd)28.34952 #gram
ecost = float(dollars)/0.1041e-3 #kWh cost
print("Weight: {0:.2f} grams of Gold(Au), USD: {1:.2f}, Energy in GWh: {2:.2f}".format(weight, dollars, ecost))
Result:
Weight: 242.95 grams of Gold(Au), USD: 10606.70, Energy in GWh: 101.99
I know WasabiWallet is written in dotnet, but I can't code in that yet...
The rate displayed in the status bar is used only to let the user know the rate the wallet used to calculate the transaction fee (in dollars) because the prices in the economy are expressed in fiat. Nobody will know whether 0.02 mega watts in fees is reasonable or not because the prices are mot expressed in megawatts in the supermarket.
It is clear that whatever rate we take, it will require a second rate. I mean, if we use Joules or grams of gold then the user will need to know what's the purchasing power of those Joules or Gold grams by knowing the rate of those units and another well known currency (I have no idea what I can buy with 2 grams of gold, really).
I am strongly against this proposal and I would only agree if it is optional and configurable with a seeting switch.
IMO the way to achieve the final goal is by making the bitcoin ecosystem more and more and more friendly so, one day it will be easy to price goods in bitcoin directly. We don't want to become a cult of radical nerds who use units like the Joule that nobody in the streets know.
@lontivero I agree it should be completely optional, and my supermarket prices goods in the Euro instead of dollar. So perhaps we could make it a configuration option, ability to set the currency or native Bitcoin metrics instead of USD price.
Nobody will know whether 0.02 mega watts in fees is reasonable or not because the prices are mot expressed in megawatts in the supermarket.
It's for the fun of it. I like the proposal:)
My problem with it is technical. We have a periodic synchronize request that provides price data and we have to keep this request as slim as possible and if something is added then it cannot be removed anymore, due to backwards compatibility.
Unfortunately tunneling through information with Tor is not as stable as the normal Internet. For example if we'd be to introduce price syncing sync requests then these queries would sometimes conflict with other queries.
https://wasabiwallet.io/swagger/index.html
For the record a sync query looks like this:
{
"filtersResponseState": 2,
"filters": [
"582193:0000000000000000002469d235d3451ab72075af9ea5d4104a701782bf7748f1:fda6013532f8fcf11bdc606760120ee90536659b65464cfeb7972024087459b1480da20f7c0b6d7e05fa9e6bae6b520b4ebb94a739c494e230862dfb762a892d1874949029b1c1ac8af909ebe4032827565ea1e43dbcb6c620ec8a2865dd36882ca6b526ff8ea9990043ec9af2c67af9f3fb891f0c20657c92ecb8b43e8a1d772662af9f66410fcc9a5554a38fe23f715c1952c3309f0426bbad686163d6042f72a6e191f9f206d5a41a6f993565acc4c4bbdf856de5256e857be8c404085b07ccdec25067c6a50990c1ea8593d5a4509be051c6a6f757fc95ae21775b7b7a205ebd0fa0f2078da5c08e82218a5d46f22cc3b017d922df30708387c677b89330506e3d09c8d777e70415e464ddae982b641973b5fbb8227d4485e21340430cc49fd690e1ea993726d201423208b9d654152e898246f08698d3254cb128fd4e3e82ef4d3196edbd0079296f0f067d403e993a0cb1461fe9bf34c75ecd0798b22f7c90a4dc8af75e3a5c71d14c5ee72665d0bb6bcacdce7cfdbed082c786159e9036ca2904aee86e2094424fbe0cd7f08785ec7d2d4615a100b551f13290c4d6d7fa72d886f2a1db429eb8c3961954cb89645d6ad7181196cb153c2ba436b082ce0cf4e75f4e18c3d02c32e91d2408b4c4dc6c57c35c19953c1ddc5e824c7ce1b8c3a93580bca4601500301c817c5e3ecc6349fa46a1d442b3f046780cc5aac13d89e5f8c2ad18f28b2d710ec002c682eb2ae284737df3036cb130225068a4a41b525be9ebab7ae4e55500ef95688b66601f9e3ac0e72257ed57250e0ef13af77bf184595811bc4662cb539c6384f1b9d6064533c0279d7caa92e9d1a13b111b2dcf84fbfc3043829389b97df83925c1dcb00b9f5cea3d812f6b660cf989120209eccc015730f2921f9364b8937cf213ac6144ba403137d75ee802e2cd1f1f0bafb98601be39c578551ce0944954e272550e84282d89230c5d233419cc15b47a2bc21050c70ae9f10e7067a2ead968e72a12120abd5a948d41afd3e7f1c43927571fa0f0658ec25109336de85db22a3fe7972a0e36c1f4f01371e84922453b3729cac82621fc4277a4566413d1f9795f3c2a65150408d7aeb3c64504e53405c29f8a31481f6d77b5e8c9ef28008d47490e83d27322dca820d4f37555b33d3504dc6cd3a0cc6e0861e2ccf4d4e67c996ae6ffaa82b17e4f7528f800a35eaf8507d6030aaf4f78e9f9a1076a0a18ce22bc28a5c33b514c551c2b303575d2905f4aa8ef1c6d47739883d5c95cbb7266f644de97e568df83b93dc027d41d79ddae53aafea60d9f888579a21fabc0ac7d8adb2b483212f920efd0de674d94b84bd106fa8c94a80009f291c326cb68019ad174d82ec748038a03300f15c8b806d05ffa5910be8f3bf1679ba1a8bb477510e8461f60ae0e330bbbab6950380e6abb1f7e9c20e68a76b4487f50a6447e1acd0b46262a2b793bc014f781b0ad429822eecfaab9eca32175a9c18079d136da01514f381eed937efb9b5a19f1a8fc0c8cdf41a1e7656b9ab8ea2b636a144ffdb27efdc28dbc18aed2c4301e2101b21c71185e95b8380c48d403d5ee4a272dc280c06af43e22bca0a8"
],
"bestHeight": 582194,
"ccjRoundStates": [
{
"phase": "InputRegistration",
"denomination": "0.09913398",
"schnorrPubKeys": [
{
"signerPubKey": "02e353266dbd597cc93b5007b77652615a7efc0ceda8044a2c62f12f6452cf4d62",
"rpubKey": "02cee00bef032f172a4acd8d7e0f52266f8df7b6b29dc5817bf3d49a927e547d3b"
},
{
"signerPubKey": "024fb7b745179a1f9d4ddc5872850cde6e13621a0713016ca17326ea75a01aa47a",
"rpubKey": "03a172f9f0b168952e7d8008572f2267e0757847d362bb65e1026aca07f536b552"
},
{
"signerPubKey": "02f4dd4c7caa9c534654f8eb97a6a4cc70f34f99145521fbf9ce7ef06dacb352f5",
"rpubKey": "02d4dd298c170e5f6aef6a04f666f1d53e5080ee888568aa9e185e8c9c3b1ddbf9"
},
{
"signerPubKey": "039df20b213235a982a9dcff45a9484be62cc56cf5ddc21a0335853d988d2814e4",
"rpubKey": "02d3a431af54862f6676499ab81ec026b10e11e6ab84c2f26d044778bdb34a851a"
},
{
"signerPubKey": "03601692c67018be439e7b70a36a99ed806d56a572364fba2626782fe7ac4b4d55",
"rpubKey": "03e0fb701f0ca03c2c93666bf2efb2bb3c5149a687a8f4262db4e2d7abe92d1d25"
},
{
"signerPubKey": "0272f84df7d5afe95f854ff62a6e2ca1e347812f5aa73eceed66a9192f3737c59d",
"rpubKey": "037305bd380a7ca02f9d7a43f530a2de226f30b98a376f3a4432d46ad72258da0c"
},
{
"signerPubKey": "0278b3393a7556a9535f2f680f8c82b2830aed38689eb14de5ecd4cf20068fe6cf",
"rpubKey": "023125ecf7f6d390914955b6e2e0cf00ebcb8124d055b0b25d41d33e4728183ef2"
},
{
"signerPubKey": "03946a485fcaf40bdaf03d17caf0bfee13865b504d3ab13d44339f0e7c5e5118c2",
"rpubKey": "031ce60d61fdada6927c6af19f90fceeef2f33d41c23e8f506896efff60d78104e"
},
{
"signerPubKey": "0211374074022580672caf4ff83aa31f29aefeabf21dbf7d8c06057982a2952d3a",
"rpubKey": "02c6229e2207b75319c4aea4e8738cb152ae5ca1daabbb600e49ffbb584757f356"
},
{
"signerPubKey": "02ee462b2ef794bcc32006e4de467eb2c5b5f5b371f6cadd45f3b6eb6027712a37",
"rpubKey": "026e5cbb02a7b8f43a22f8c75543dafa5938ffd441db9e5eabca2c8bb84a3b48e6"
},
{
"signerPubKey": "0330fed9677900b52c4f101d8ddc82a4da20eb749bbf92558ff72de87204408786",
"rpubKey": "02d9a6834a2651d6dc1e470b1a46e64e5616706fd810dc4d120c2fed44cbeabe74"
}
],
"registeredPeerCount": 87,
"requiredPeerCount": 100,
"maximumInputCountPerPeer": 7,
"registrationTimeout": 60,
"feePerInputs": 500,
"feePerOutputs": 250,
"coordinatorFeePercent": 0.003,
"roundId": 8916,
"successfulRoundCount": 4115
},
{
"phase": "InputRegistration",
"denomination": "0.09913398",
"schnorrPubKeys": [
{
"signerPubKey": "02b7976a5c6b08e56b925b0e47c64ec24f0f1cb5b932550294c7908a6a1774920c",
"rpubKey": "022b160f25dd18d86775a54e448a0e6dcf74fede1e7b70a20444fadf6bf852198e"
},
{
"signerPubKey": "0310e6317f5ad66cf10051141058737312e4d1ba962273a3a292021d6ad7ed0075",
"rpubKey": "0396b70f74246eeaf6e6accbcd0a05d177b5845c4634854d41db39b18b7e94c29e"
},
{
"signerPubKey": "03d460b3f248ef820e2c8307eb77d87115eaa41bbb87f2bf0f7bc3bc1549c9ad1f",
"rpubKey": "0357522e21e807f27cf77708eda229b06994313eee87463cdbf715068fcac57793"
},
{
"signerPubKey": "0323a3f40fd9b9b583feecc2485f15068cbd2887171451c753fd89143b433d229c",
"rpubKey": "02ae6bd8a583b5bd13c4575928469a1faa28056a17c82d59880abf47c3983fd602"
},
{
"signerPubKey": "035c97caa2898091de6a8a4fa3678a4bf466b1a34487f1f1f824f623cd8662c46f",
"rpubKey": "02354cf84237f0e3374547d7ba2fb16c11fd96abe3a8e4ab03d0b1c67b81b2a89e"
},
{
"signerPubKey": "032653883ab954c4ec87114624e59afcfb470d8ef65d9697ea3eb79f86ae9eb7a8",
"rpubKey": "029d925055cbb881f4bc4f37aa58c57a7d50a96e567cae47bd444ac9dc5af2cc6f"
},
{
"signerPubKey": "03951de0edf6691cca790992b2a168d645d14e80e111799ec9d8c48b1a7eef3eec",
"rpubKey": "02b4db675b3304f5f6be60f7ac4adca8c43c99d8cb1a7a857f1d3e37955443bbb3"
},
{
"signerPubKey": "0270848d2bbdc203c6922cbe635c13aeeb961f08a2f46321898de091c353aed136",
"rpubKey": "02e8ee8d371c1876d62cb8c99996693fbd256bbd8575bfd2e4bfb8162aafea4ded"
},
{
"signerPubKey": "02b8cb020be679deb654be740706e4c981a18ab36b70940b1aaf39cbaa15cf8efa",
"rpubKey": "03a15f6071cc19287976c03edfd84d9a7aaaca8d43a3a574a821b5636632ca6c5f"
},
{
"signerPubKey": "02c25bf80b79fef3e72c0e843bc029b69326a7bba413ff3f4f6feaf5687ae2d763",
"rpubKey": "025c8b49b99fd50a0ad689c8a9efb8ca398e2a6f28eea934f2728edccc55302ad3"
},
{
"signerPubKey": "02330a9e6d45dc93be1ce58485ca9a4b4a610990a761b22acc7f1de65bac257b85",
"rpubKey": "0369aa9c223f042142eb10d8cee64dc7b4894cee7605986e7a66e486b2a8daae2a"
}
],
"registeredPeerCount": 0,
"requiredPeerCount": 100,
"maximumInputCountPerPeer": 7,
"registrationTimeout": 60,
"feePerInputs": 1340,
"feePerOutputs": 660,
"coordinatorFeePercent": 0.003,
"roundId": 8917,
"successfulRoundCount": 4115
}
],
"allFeeEstimate": {
"type": 0,
"estimations": {
"2": 44,
"4": 6,
"6": 5,
"10": 4,
"12": 3,
"241": 2,
"361": 1
}
},
"exchangeRates": [
{
"ticker": "USD",
"rate": 10893.99
}
]
}
Now, we could put a couple of other tickers to the response without generating much overhead, but there are a shitload of currencies and where should we draw the line? Idk...
@nopara73 Aha, I understand we need to keep the Tor routed queries as lightweight as possible! Perhaps limit to only the Gold/BTC conversion rate, that could be requested as a single entry?
"exchangeRates": [
{
"ticker": "USD",
"rate": 10893.99
"ticker": "Gold"
"rate": 252.42
}
]
BTC intrinsic metrics (fee, hashrate, difficulty) are preferred over a shitload of fiat-currencies and those can come from the (to be integrated) Bitcoin Core node, so won't require Tor-routing bandwidth.
Most helpful comment
https://github.com/zkSNACKs/WalletWasabi/issues/1554