99 - mocacinno

Thanks

I made a big post about mixing services using cloudflare's SSL, but part of this post also describes the non-ssl situation with some graphics... Maybe it can clear things up for you?
https://bitcointalk.org/index.php?topic=5247838.msg54414844#msg54414844

It's pretty simple actually... When visiting a http site, you have to realise your traffic passes trough a lot of network nodes. Each node operator has the ability to log each and every package you send and receive.
Since you're visiting a http site, these packages are unencrypted.

Basically, if you enter a password, and e-mailadress, send a copy of your driver's licence,... loads of people can *potentially* log AND READ this information.

Like others have already said: if you request a page containing the latest exchange rate from preev.com, this doesn't matter... But going as far as saying somebody can log in on an unsecured site is not ok for me.

BTW: if you read the rest of the post i linked to above, you'll realise that the "padlock" symbol isn't a % guarantee either, in case the website owner is using cloudflare...

Because, at the end of the day, the miners get confronted with an energy bill, a writeoff of their equipment, labour cost,... Most miners do add transactions from their mempool to the blocks they're trying to solve. If no miner would add transactions to the blocks they're trying to solve (and solve the block), the mempools would fill and no transactions would get confirmed anymore (except coinbase transactions) and bitcoin would become useless. I agree that the protocol allows empty blocks, and there is no 1<=>1 correlation.

So, in the end, if you knew the exact amount of active ASIC's, the exact power price of each miner and all other costs, you could calculate how much money is being spent by the miners in a certain timeframe and you can count how many transactions end up in the chain with the most work during this same timeframe. So you can calculate the cost/tx in that timeframe.

Is this number usefull? I have no idear... But it IS something you can calculate...

The banana analogy could work aswell: if you assume full containers being shipped from whatever country they import bananas from, how much fuel is used per banana given that a ship only transports bananas and doesn't carry other containers aswell?
Same thing: sure, a container can be shipped empty aswell, it's not the banana that has the biggest impact on the fuel consumption (eventough the banana does have a certain volume and weight, so it does have some impact, but i'm  ignoring this for the sake of the argument) but that's why there's an assumption of full containers. The main reason why containers are shipped from country x to my country is to transport bananas. If there was no need for bananas to be transported, there would be no containers and the ship would remain in it's harbour, so calculating the fuel usage per banana is something you could do, it makes economic sense to set the minimum price level of a banana in a shop, eventough empty containers can be shipped, and the banana's impact on the fuel usage is low (at least for the sake of this argument).

Same here: a miner could mine empty blocks, but their main function is to include transactions... So, eventough there's no 1<=>1 relationship between the transactions and the power usage, it's still feasible to assume the main reasons why the blockchain exists is to store transactions in an immutable way, and the mining process uses power, so you could estimate the amount of power used to make 1 transaction immutable, even without a direct correlation .


That's why i'm working under the OP's assumption of full blocks. I realize there is ~zero power per transaction used (actually, a merkle tree IS being created, the merkle root has to be included in the block header, so some cpu cycles are being used, using a tiny amount of power), but there IS a lot of energy being burned by creating sha256d hashes of the block headers untill a header is found whose sha256d hash is under the current target. The OP asked about full blocks...


I'm not building an exact model here... I never said i was searching for a formula that gives an exact sollution to the question of energy used per tx in a block in the longest chain. I don't know why the OP asked the question he asked... Maybe he's interested in future fees, maybe he was just interested, maybe he wanted to use this number for something else..
I made it very clear that it is a raw estimation.

True, but that doesn't mean you can't do a very raw estimation about how much power is burnt per transaction when using a short window at current diff if you assume full blocks... I mean, the OP already gave the assumption of full blocks, and eventough the diff retargets every 2016 blocks, it's possible to do estimate the hashrate when knowing the diff at a certain point in time. It's also possible to calculate the average transaction size in the last couple of weeks/months and see how many would fit in a block (on average).

However, the mix of ASIC types/vendors and the average power price are a big unknown... I assumed 4 cents/kwh was cheap, but apparently it was still to high... I live in a country where i pay ~30 cents/kwh

I, for one, would be interested to know how much the electricity cost per transaction given full blocks and current diff would be... It's interesting to the point that the current block reward covers most of these costs right now, but in a couple halvings these costs have to be covered by an increase of the fees, or by more efficient hardware, or by a lowering of the total network hashrate or a change in POW algo or a combination thereof...

nbxplore is a prereq for btcpayserver, otherwise you don't need your own block explorer (and, eventough the name contains the word xplore, it's not a real block explorer, merely an utxo tracker)
But for the rest it looks like you're on the right track!

bitcoind + lnd (or c-lightning) + nbxplore + btcpayserver

This setup will allow you to create custom invoices, and do automatic billing aswell... And, there's a free plugin for wordpress+woocommerce

If you use the xpub generated by wasabi, you can directly coinjoin from wasabi's gui and have a reasonable amount of privacy (meaning: it'll be very, very, very hard for anybody to detect how much btc you're actually holding, and it'll be very, very, very hard for anybody to link the coinjoined btc in your wallet to your identity). If you're afraid a hacker will get his/her hands on your xpub and nullify your coinjoins, you could always opt for 2 wallets (like i said in my previous post): one for receiving funds, then move your funds to a second wallet and coinjoin over there. If a hacker ever gets his hands on your xpub, it'll be the xpub from your first (receiving) wallet, and not the xpub from the wallet where your funds were coinjoined.
Instead of coinjoining, you could also send funds from the first wallet to a mixer, and chose an address generated by the second wallet as the mixer's output.

Good luck! If you have specific questions about the bitcoind + lnd + nbxplore + btcpayserver + apache/nginx/... + wordpress + woocommerce + ... setup => don't hesitate to ask! I'm a c-lightning fan myself, but i've recently done the rest of the setup.

Well, this might change things a little bit... Yes..
A couple follow up questions:

• Is it a clearnet website
• Will you be using a shopping script (woocommerce, opencart, prestashop,...)
• What will be the level of automation (will you be generating addresses/ln invoices manually, or will your shop be handling all this accouting?)
• What level of anonimity are you requiring: protection against a $5 wrench attack, protecting yourself from the IRS (or any other tax authority) or selling bitcoins in a country where owning cryptocurrencys is so illegal you'll end up in jail

If it's a clearnet site with shopping script and automatic accounting, i'd probably go for bitcoind + c-lightning + nbxplore + btcpayserver.

You'll need to think the anonimity aspect completely trough tough... I mean, if it's a clearnet site, you're already pretty exposed as it is... You have a host that can keep logs (or you've rented a dedicated box/vps), you have purchased a domain name,...
People will be able to link deposit addresses to your domain/ip/..., they'll need to be able to open channels to your lightning wallet aswell.
If you want automatic accounting, you'll need to derive addresses from an xpub (btcpayserver does this for you), if a hacker gets his hands on this xpub, he'll be able to derive all past and future deposit addresses presented to all your clients (he won't be able to rob them tough).

Without knowing the full picture, it's hard to give advice, but if you're running a clearnet shop, and you want a reasonable amount of privacy, i guess you might be best off creating 2 wasabi wallets, you export the xpub from the first one and import it into btcpayserver, after a couple ln channels have closed you move funds to this wallet aswell. After a while you move your funds from the first wallet to the second one and then do a coinjoin, or you use a mixer between the first and the second wallet... This *should* be enough to protect you from a $5 wrench attack.

Other setups are possible too, but the flow, the level of expertise and the amount of time required to setup/maintain setups will increase almost exponentially if you start messing around with bulletproof hosting, hidden services, i2p, lightningd over tor, bitcoind over tor,... In case you need these kinds of setups, i'd probably tell you to hire a security expert and let him/her help you set things up, and teach you how to maintain everything...

I didn't check if it was arm compatible tbh... But apparently, there are problems with dependencies:
https://github.com/zkSNACKs/WalletWasabi/issues/2189

I just (wrongfully) assumed you'd be able to run wasabi on an rpi...

So, basically linux or windows on x64 or mac

Have you read this pinned post:
https://bitcointalk.org/index.php?topic=3953664.0


It's not a proper quote, since that topic is locked...

Also, for this part of your question, there's a huge difference between the amount of transactions that *could* theoretically fit into one block, the amount of transactions on average (all times) or the amount of transactions on average (using a sliding window).

I've just quickly used https://coinb.in/#fees without actually overthinking this... And it seems the absolute minimum tx size would be ~130 bytes. I'm assuming this is without witness data.
The maximum amount of tx data in one block (without witness data) is still 1Mb, so one block could theoretically fit ~7700 transactions. But these transactions would be 1 input - 1 output, all segwit transactions, nothing special, block 100% full. This is far from realistic.

If you look at https://blockstream.info/, you see that the average amount of transactions in one block is ~2500-2700.

Do realise that a lot of assumptions were made in my last 2 posts... I mean: you have no idear about the mix of ASIC's that currently make up the network, you have no idear about the power prices these asic farms pay and you're estimating the amount of transactions in a block... So your end result is basically a guesstimation....

That would be close to impossible because you have no clue about the amounts and types of ASIC's currently mining.

You can estimate the current network's total hashrate tough:
Hashrate = Difficulty * 2**32 / 600

So

Hashrate : 19298087186262 * 2^32 /600

Hashrate = 138.141.088.900.586.584.146 h/s
Hashrate = 138.141.088.900.586.584 kh/s
Hashrate = 138.141.088.900.587 Mh/s
Hashrate = 138.141.088.900 Gh/s
Hashrate = 138.141.089 Th/s
Hashrate = 138.141 Ph/s
Hashrate = 138 Eh/s

Now, you can estimate what would be a reasonable mix of asic's that would result in a total hashrate of 138 Eh/s, look up their power draw, multiply by what you think would be the average power price... Add the cost of the ASIC's, S&H, shelves, cooling, wiring, human labour,...

You could, just for fun, estimate the BARE MINIMUM.... A HUUUUUUUUGE underestimation tough!
Bitmain's latest ASIC is the S19 Pro, 110 Th/s, $2407 (not including customs, S&H, PSU,...). It draws 3500 Watt at the wall.

https://www.statista.com/statistics/263492/electricity-prices-in-selected-countries/
Tells us china's power price is 8 cent/Kwu. But let's assume most mining farms are located at places where they pay 4 cents/kwu (i've heared a rumour they're usually locating these things at places with excess power)

You'd need 1.255.829 S19 pro's to reach 138 Eh/s.
They'd draw 4.395.401.500 Watt at the wall.

So, each day, they'd use 105.489.636 Kwu (105 Gw). With a cost of 4,25 Million USD.

So, the absolute, ultimate minimum energy cost for 144 blocks would be 4.25 Million USD. That's ~$30.000/block.
This does not include the fact you'd have to buy 1,25 million ASIC's, and these calculations are for the newest asic on the market, and only paying 4 cents/kwh!!!!

about Wasabi: it would probably fit best on your desktop, eventough you could run it on a rPi aswell (you'd have to make sure x forewarding is enabled tough...).

Hidden-service related, wasabi is basically "the same" as if you'd run tor on your local machine and configured electrum to use your local tor proxy. The big difference is that wasabi actually eliminates the need to run tor seperately (tor is just part of wasabi's setup), a second "plus" on wasabi's side is that routing packets over tor is default for wasabi, and not default for electrum (so if you start wasabi for the first time, tor will already be enabled, whilst if you run electrum for the first time without adding command line parameters or additional config, it won't route it's packages over tor).
You could configure wasabi not to route it's packages over the tor network, and you can configure electrum to route it's packages over the tor network... There's just a difference in default behaviour. And since the default behaviour of wasabi is to route it's packages over tor, it has tor included in it's bundle, making your life a little bit easyer

Now, don't get me wrong... I use electrum all the time, it's a great wallet (eventough you have to make sure you're downloading it from the correct repo, and double check the signature), it's just that wasabi comes with better privacy features out of the box. This doesn't make wasabi safer, faster or more feature-rich... It just makes it more private without having to jump trough a couple of extra hoops).

btw: a big plus on electrum's side is that you can also run it as a daemon (without gui). That way it's easyer to run on your rPi without having to mess with x forewarding... And electrum is also older, so it *should* theoretically be vetted more than wasabi... But both wallets are open-source, and both have been vetted by the community... So i wouldn't worry about this to much...

I quickly browsed this topic, and the RaspiBolt documentation... And i just wanted to ask: is there any point in making your setup so complicated?
The more layers you add, the more devices, the more daemons, the more firewalls, proxy's, certificates,... The bigger the odds you mess up and expose yourself...

You could just run tor on your local machine, then connect electrum trough your local tor proxy and have really good privacy.
Sure, you'll be using public electrum nodes, but you'd be connecting over tor.

An other option would be to switch to wasabi, which has the tor bundle built-in, and it has an out-of-the-box coinjoin application, which makes it easy to gain privacy after receiving funds.

I know this isn't the answer to your question, i just want to tell you there might be an easyer sollution for many use-cases instead of configuring a pi as electrs node, making it a hidden service and connecting a local electrum client to your electrs node over tor...

This being said, i'd probably start troubleshooting by:

• testing out your electrs node over the clearnet... If it doesn't work over the clearnet, you know it'll never work as a hidden service
• disabling your firewall to test for firewall issues. If it works when you disable your firewall service, but doesn't when you re-enable it, it's a firewall issue
• "service tor status". Is it active? Maybe even setup a second hidden service like nginx, so you have an "easy" testcase
• try connecting to your electrs hidden service using telnet (yes, telnet is still a thing... I use it quite often when debugging a setup)
• letting somebody else test your electrs node, connecting trough your hidden service. IF somebody else can use your hidden service, but you cannot, it's a client issue... Afterwards, you can just remove tor's keyfiles and let it generate new ones, the tester will never be able to expose you this way

PS/EDIT: I gave you post a merit, please stick around on bitcointalk... We need more people that are discussing topic like this one, and less people that come here to spam ico's

So, you don't care if it's a scam, as long as the product the scammer is offering is dirt cheap...

Could i intrest you in an IMAGINARY brand new dodge RAM? You seem like the kind of guy that would be interested in this deal:
It's a fourth generation brand new, IMAGINARY car, 0 miles on the gauge... Only $1000...
Dirt cheap for a dodge, but remember: IF you send me $1000, you'll get NOTHING in return... Just a vague image in your head of a dodge ram that only costs $1000.

In case you're interested: you can find my address in my profile... Either BTC or ETH will do... You don't need to contact me in advance, no escrow needed because if you send me the money, you'll get NOTHING in return... So basically, i'm giving you the same deal as the OP of this thread, but i'm being upfront about it  

PS: don't actually send me money... This post is merely a way of putting the OP in some perspective... It doesn't matter if the OP promises you 10 BTC when you pay him 1 BTC, or 100 BTC if you pay him 1 BTC: it doesn't matter, you'll always end up scammed for 1 BTC because the OP will not send you any "dirty" funds after you pay him...

99 - mocacinno

I actually helped with the technical details of setting up https://www.merel.mobi for somebody i know from the crypto community.

We picked my btcpayserver as a primary backend, with on-chain payments going directly to the owner's wallet and off-chain payments made to me (and forewarded to the owner afterwards).

We use "BTCPay for WooCommerce" as a primary plugin and "Nomiddleman Bitcoin and Crypto Payments for WooCommerce" as a fallback method.

"BTCPay for WooCommerce" works really good, but btcpay is a bit slow-ish... "Nomiddleman Bitcoin and Crypto Payments for WooCommerce" works like it's supposed to work, but to the enduser it looks like a non-automated platform (the QR code for payments is just shown on the invoice, while the btcpay plugin actually sends the user to a payment gateway where he's shown a qr code, a timer,...). Also, for "Nomiddleman Bitcoin and Crypto Payments for WooCommerce" you'll have to go into the "experimental" settings so your users get a unique payment address derived from a master public key (the default setting is having a pre-generated addresspool, one address getting picked and potentially reused)

To be honest, i don't switch wallets very often... As a matter of fact, i run a node and the wallet is still a non-HD wallet (in other words, i haven't loaded a different wallet for many, many years). I just remember the last time i found an old wallet.dat (years ago) and i tried opening it, a rescan was also triggered. But i was probably guiding you in the wrong direction when i used the word "default". I just meanth that it doesn't supprise me if a rescan is triggered when you load an older wallet. I've updated my previous post accordingly.

This being said, it's very hard to give a precise answer as to what actually triggers a rescan for me. It's been a while since i last dived into bitcoin core's code, let alone kept track of all the changes. Everything depends on versions and specific situations i guess: Which version was used to generate your wallet.dat, which version you're running now, did you change anything to your wallet since last synchronisation, which was the last blockchain height when you last opened your wallet.dat, did you open multiple wallets at the same time, which parameters did you use to open your gui, which parameters are present in your bitcoin.conf.

I know recent versions had significant changes when it comes to wallets and rescanning. For example, version 0.17 included a feature to scan the utxo db instead of rescanning, i think HD wallets became default in 0.16 (but they were introduced in 0.13). So even if i knew all the changes in core's code, it would be that easy to give a defenitive answer.

In theory, i guess you could read the code and see why a rescan was triggered in your specific case tough.

But you are right, a wallet.dat should contain keypairs, transactions and metadata (amongst some other data)

Not a real answer to your question i'm afraid...

Well, a rescan might indeed be the reason why it took your wallet an hour to load...

Looking at the lines you pasted, it looks like you loaded a different wallet.dat than "default" (initially, core will create a wallet in ~/.bitcoin/wallet.dat).
This is no problem whatsoever, but if you switch wallets, a rescan will be executed by default... might be executed

EDIT: i actually made a mistake, rescanning probably doesn't happen every time you load a different wallet

A new block is added every 10 minutes (on average). If you synced your wallet 3 years ago, and you opened it today, it would have to download (3 * 365 * 24 * 6 ) = ~157680 blocks.

So, just to say, it's not because you sync'ed your wallet when you created it, it'll stay sync'ed forever.

If this is not the case, you can always look in your debug.log. Since you seem to be running a *nix OS, you can find the debug.log in ~/.bitcoin/

bitcoin core needs to sync all blocks since you last opened it... So it probably took over an hour to do this. In the background it downloaded, verified and parsed all blocks since the last time you let it sync completely, updating your utxo db in the meantime.

IF you want to avoid this in the future, you'll probably want to switch to an SPV wallet. Such a wallet only downloads the block headers.