|
Bitcoin doesn't have a standardized timestamp that is anywhere accurate. The network allows for a significant deviation from the median time. Any concepts like this requires a hard fork, current clients will validate to check it the block hash satisfies the current target.
Fundamental problem with these concepts which attempts to reduce the resource usage is highlighted in the first reply. As there is no way to restrict the number of unique miners, the concept fails as anyone can create as many keys as they want to lock in the rewards. The 2016th block's miner effectively holds total control over the network, and to decide who is able to mine the next 2015 blocks.
|
|
|
|
True, and I can understand why centralized exchanges and other such services overpay their withdrawal transactions, but the amount they overpay is often ridiculous. Sure, if the average fees are bouncing around 20-30 sats/vbyte in each block, then 100 sats/vbyte is not an unreasonable fee to pretty much guarantee confirmation in the next block. But when the mempool is emptying with every block, and 1 sat/vbyte transactions are being entirely cleared in each block for several days in a row, to still pay 100 sats/vbyte is just plain stupid. I refuse to believe that Binance can't come up with a better algorithm than "Pay 100 sats/vbyte for everything until it gets really bad".
In all fairness, they're not the only ones overpaying for their fees. Bitcoin Core's floating fees was going up to 80 sat/vbyte for a confirmation within 3 blocks if the user chose conservative mode. That has a fairly high confidence level though, so the fees will always be inflated. RBF may be technically challenging, but CPFP is easy for such transactions. Binance could cut all their fees in half right now and save thousands of dollars worth of bitcoin a day, and still perform CPFP with the change output from their withdrawal transactions in the very rare case that 50 sats/vbyte doesn't confirm within a few hours when the mempool is currently empty.
They know users won't want to wait for a few hours or more than a block or two. CPFP is probably quite easy but as a user, I'll be quite unhappy to be waiting for an extended period of time after paying 0.0005BTC per withdrawal and they're choosing a very low fee, given that withdrawals are already batched. They can probably reduce the fees even more, or introduce a variable fee structure. Probably won't be happening though. |
|
|
|
Meaning what? CO2? All of us do it, planes do it, cars do it, nobody stops cars and planes from operating so what's the big deal?
And why do you think people don't try to stop essential services from operating under the guise of environmental change? Why don't they try to make use of that. The power plant discharges hot water so maybe you could build a swimming pool and a hot spring spa or whatever nearby and make money for free? You could divert some of the water towards residential buildings and heat them up for free.
Probably wouldn't be feasible.
Anyways, this isn't Bitcoin's problem. Mainstream media is trying to discredit Bitcoin to try to get clicks again. The fundamental problem here is NOT because of Bitcoin mining, it is how the plant operates. Blame the operators for the environmental impact, Bitcoin's demand for electricity isn't the main problem here. Fun fact, Google also uses seawater for the cooling systems for their data centre but they process it first to an acceptable temperature. It wouldn't be a problem if they did it as well to fit within the regulations. |
|
|
|
It was almost like the wallet was taking an average or something of what was in the block instead of looking at the fees.
Could be a bunch of lazy programming. Almost like adding the highest 10 fees that should you see going into the next block and add them to the lowest 10 fees you see going into the next block and divide by 20.
Services are almost always paying extra fees for their transactions. It is far easier to pay more and avoid any problems if the transaction stays unconfirmed for an extended period of time. After all, the users are footing the bill, no harm done to them. RBF is not possible with withdrawal transactions, not technically, just that it'll cause even more confusion. i remember this a couple of years ago when some people were actually discussing how to implement fee estimation based on the last block that was mined. it was based on the average fee that the block had, like saying min fee is the minimum fee in that block and average is the median fee, etc.
but i don't think we can make a conclusion that this is the case with the transactions you saw because it may easily be something like a gambling site paying its gamblers as they cash out with a higher fee.
Bitcoin Core groups the transactions from the mempool into a bucket, and tracks how long it takes for them to be included in a block. It lags behind the actual situation for me; predicting 10sat/vbyte for the next block with 2sat/vbyte being 1vMB from the tip. They tend to be more conservative with the fees, but there is a higher confidence for it to be included within the X blocks. |
|
|
|
I couldn't agree more. That is why visual representation of mempool such as https://jochen-hoenicke.de/queue/ are always the best for fee estimation. You can see the mempool size, the fluctuations and in times of fee growth you can even estimate the rate at which fee is rising. I disagree. Most people uses the mempool data wrongly, for eg. reading the chart after successive blocks gives a fee rate that is far lower. You can't predict the future, but it doesn't help if the user don't know what to do with the data. Simply telling them to aim for the top 1vMB of the chart with their fee rates is insufficient. If you know what you're doing, sure go with the mempool charts. If you don't, then it would often be a better idea to just follow the floating fees given by your client. Fees estimator, or estimation algorithms in general uses the data from the mempool, grouping them into buckets for analysis and showing an estimate to the user. It is really not as inaccurate as people think, though admittedly the way it works makes it less responsive than looking at the mempool yourself. At the start, Core's estimation wasn't great but I've seen quite an improvement over the past few versions (actually got better after 0.15 IIRC). It doesn't reflect the state of the mempool in real time, that isn't what floating fees should do. |
|
|
|
If I am not mistaken, the first address is easily searched through a search, which cannot be said about the second. In general, isn't it all the same how the address is displayed? There are only requirements of managers for companies that will be comfortable with this or that way of displaying the address. I do not care.  Both are treated the same way. Google or any search engine indexes the keywords and putting any keywords into a HTML code makes no difference to the search engine. Guys, what are the chances that someone would use a QR code to read the address? Most people don't use a Bitcoin wallet on their phone, and even if they do, it isn't so hard to make a QR code themselves. I would probably opt for the former, it looks neater that way. That, or use an URI so that people can click on it. |
|
|
|
You'll probably want to determine the size of the transaction first[1]. Since there is only one output, size with respect to that is fixed, though can vary dependent on the kind of unlocking script you have. Eg. P2PKH outputs are bigger than P2WPKH output by 3 byte. The GitHub code that you should be able to find gives you the size of the various kinds of inputs (including the signature) and outputs. -> Create the variables for the inputs and outputs to calculate the size. Afterwhich, you can relate it to the fees that you're going to pay. The fee rates you're going to decide on will determine the kinds of outputs that you're able to use. By limiting the total fees below 1000 sat, deduce the range of acceptable transaction size based on your desired fee rates*. Next, run through the permutations combinations of the inputs (and a fixed output), determine one that'll result in 0.03BTC as the output after deducting the estimated fees. Note that the signature size can vary slightly so I'll leave a few satoshi for the fees to compensate for the margin of error. *Strictly speaking, due to how vague the question is, you can choose a huge range of fees (at least 1sat/vbyte) or just use whatever is left after deducting 0.03BTC to be used as the fees. Since the question doesn't state whether the transaction has to be standard, just include a range of 0-1000 sat as the fees and permutate the value of the inputs.  [1] https://jlopp.github.io/bitcoin-transaction-size-calculator/Edited: Same mistake as above |
|
|
|
|
It isn't hard to see why he said that.
Initial iterations of Bitcoin were not meant to scale, even though the limit for block size was 32MB at the very start. Probably would've been bottlenecked by the bandwidth of the nodes at that time, and wouldn't be able to scale too. It was refined to a more reasonable 1MB thereafter.
Satoshi's prediction lies on the premise that better solution to scale will eventually be implemented and the computer hardware continually gets better. Bitcoin would then be a more viable currency and offers intrinsic values that the payment systems doesn't offer at that time. People would be more compelled to use Bitcoin rather than the other payment processors. That, or a superior replacement comes about or a catastrophic event destroys Bitcoin.
|
|
|
|
-What I understand from both replies that Bitcoin core doesn't allow transactions with total fee/cost less than dust value, but does NOT prevent u from creating dust UTXOS so they will be ( I mean still) stored burdening the system status (because the owner won't spend them) as the paper says.
You can't create and push a transaction that contains a dust output with Bitcoin Core. It's just that they're nonstandard and including it in a block almost always involves the participation of a miner. (This is again about my research proposal of classifying UTXOS into types, I just find it hard to believe no one did it before & no one is even convinced to do it; here I mean dust like burned not likely to be spent in the near future, why not accumulate their hashes separately?)
Dust are sometimes in fact spent by the user to get rid of them from their wallet so they won't spend it inadvertently down the line. You need to keep them in an index in case they get spent for whatever reason. Most of the time, it's spent to an OP_return, whenever it doesn't cost more to spend it. I don't think it is necessarily a bad idea to exclude them. I'd imagine the actual resource savings would be very low though. You might have to spend more time validating blocks if they ever get spent; you can't get them from the UTXO set directly. - For the mark "Unspendable" maybe the Samourai wallet was doing that in purpose, I mean preventing them from being included in any valid block as they know they're part of a hack?
(I'm just concluding from the article, I don't know for sure)
You can't prevent UTXOs from being spent, unless you're the only person that can spend it. It is intentionally marked that way to prevent it from compromising the privacy of their user. |
|
|
|
i get this:
mint@amint:~/.local/bin$ ./electrum
Error: at least one of ('pycryptodomex', 'cryptography') needs to be installed.
Then i run this to install pycryptodomex
$ sudo apt-get install build-essential python3-dev
$ pip install pycryptodomex
and this
$ pip install pycryptodome
The first command on the installation page installs python-cryptography which is the main dependency for Electrum. Pycryptodome isn't a requirement. Back to my original question, are these both commands python3 -m pip install --user & sudo pip3 do the same thing?
Yes. They're the same, except --user installs it for the current user that is running the command in the terminal. python3 and pip3 are the same?
No. pip3 is the package installer for python3. The other command also calls pip as well. And since the second command works for me, can i continue using Electrum installed that way, without compromising security or privacy? Will it work without conflicts with a setup i am planning to do: Core+Tor+Electrum+EPS+Trezor?
Yes. After many attempts installing and uninstalling electrum, then isntalling and updating python3, pip, pycryptodomex, pycryptodome and few others something happened to pyqt5. Before i could run Electrum without installing, just running it with command python3 Electrum-4.1.4/run_electrum
Now i get errors: ModuleNotFoundError: No module named 'PyQt5', Error: Could not import PyQt5 on Linux systems, you may try 'sudo apt-get install python3-pyqt5
Though i have latest Python 3.9.6 and ppip 21.1.3, and when i do as it says in error and run sudo apt-get install python3-pyqt5 i see that i already have it: python3-pyqt5 is already the newest version (5.14.1+dfsg-3build1),0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
.
Might be an issue with the pythonpath or the module itself. To check for paths, pass in the terminal to open up the python shell: >>> import sys
>>> print(sys.path)
>>> exit()
You should see one of the paths being /usr/lib/python3/dist-packages, navigate there and check if the dependencies are present. You can also try to purge the modules if needed: apt-get purge python3-pyqt5. I've been trying to replicate the issue with my own Linux Mint 20.10 but I can't replicate it at all. The commands listed are all working just fine. I'd say, if your current shortcut with the other installation guide works, then it is fine as well. As long as you can backup your seeds, then there shouldn't be a problem. |
|
|
|
No you misunderstood what I was saying, do not use /dev/urandom for cryptographic random number generation because when it runs out of hardware entropy it will use a PNRG to give you the rest of the bits. I recommend using /dev/random instead which will stall when hardware entropy runs out until more is made available.
FWIW: https://www.2uo.de/myths-about-urandom/. There seems to be quite a bit of a misconception about /dev/urandom and /dev/random. Bitcoin Core and many other wallets all uses /dev/urandom. There is absolutely nothing wrong with using SHA256, btw. The only important part is for the input to have sufficient randomness. |
|
|
|
|
Electrum 3.0.4 and below had an unprotected RPC. If you were to access any webpage and the webpage sends a CORS preflight request, then your seeds will get compromised.
Out of an abundance of caution, I would probably create a new wallet if you used your wallet before 3.0.5. After that, the vulnerability was the phishing through the rich text. If you didn't click on any links and download any files through Electrum, you're okay.
|
|
|
|
If we draw a Venn diagram of all the people who are willing to buy Tesla cars (that cause more global warming than anything else to be charged), and all the people who own bitcoin and all the people who are willing to spend a large amount of bitcoin we can see that the intersection of the 3 circles is a handful of people who may not even bother buying such an expensive car.
This has to tell us a lot about one of the main reasons why Tesla stopped accepting bitcoin payments!
Also when you look at Musk's tweets and how he was desperately investing in Doge coin and were trying to pump and dump it you get the other main reason why Tesla stopped accepting bitcoin payments!
Actually doesn't really make sense. Tesla declared more than a billion dollars that they've invested in Bitcoin. Suddenly withdrawing support and pulling out from it was a dumb move. Prices tanked and so did their stocks, it was bound to make a few heads turn. Why didn't they do their own due diligence before investing in it? Was the entire point from the start to buy Bitcoins and lose money on it? The market manipulation is quite obvious. Elon Musk was certainly not trying to profit from it though, it wouldn't have been worth his time. |
|
|
|
Where x the difficulty (which is fixed) and y the array of the distribution. The num variable can be passed through the function as y. I just wrote the above javascript code, it may not be mathematically proper. I'd really want someone to correct me.
Given an array num of the Bitcoin distribution and a difficulty of 14363025673660, we get centralization = 668.18.
If instead of 4 pools owning the 14.95%, 11.74%, 11.39%, 11.03%, 10.32%, we had one owning the 14.95% + 11.74% + 11.39% + 11.03% + 10.32% = 59.43% of the total computational power offered, we'd get centralization = 65971206.1.
Generally, centralization increases explosively if a pool approaches 0.5.
You cannot accurate measure the decentralization of Bitcoin or it's pool by taking the distribution of the hashrate at face value. There are a lot of factors to take into account when we're measuring the true decentralization of it. The top few pools are all located within the jurisdiction of PRC, which is known for their iron grip on the companies. Is Bitcoin decentralized if those pools owns a majority of the network's hashrate? While pools matters less for the miners, as they can switch out to another pool whenever they want, there lies the problem with the fact that miners are often concentrated in certain areas, which coincidentally, is China (though it's starting to change). There is also a lack of perfect information; taking the proportion of the pools isn't a good idea. Anyone can own a few large farms and split them across the pools. While it seems to make it seem more decentralized on the surface, an individual still owns a good proportion of it. Measuring how decentralized a network is by purely looking at the numbers will thus often be misleading. The nature of PoW encourages centralization. Having loads of resources or reducing your costs will maximize your profits. Either of them will encourage some sort of centralization. |
|
|
|
Note:This figure only considers blocks data. If we include chainstate and txindex, it might have crossed 400GB right now.
Most users don't require a txindex. Chainstate is about 7-8GB right now(?), certainly less than 10GB. Block data grows way faster than chainstate, the UTXO set is constantly having entries added and removed but the block data grows linearly. |
|
|
|
Which also means no concrete evidence that Bitcoin miners are using mostly fossil fuels and other power generation means that can result to releasing of green house gases into the environment, what I knew recently is that China is already moving towards the use of wind, nuclear, solar and properly constructed hydrogen electric power plants.
Then isn't it a bit strange to be giving a random figure without any concrete data? I think the Bitcoin mining council said they're using 56%, not a high number considering they're probably one of the few in the spotlight. Climate change or environmental damage isn't only caused by the electrical usage of Bitcoin. Ewaste and the production of the ASICs contribute immensely as well. Actually, not all renewable generation are particularly carbon neutral at all. It's quite a common fallacy to assume that just because you're using renewable energy, you're being green. That is rarely the case. Building the facilities and using it often comes in a fairly huge expense of the environment. Who says Bitcoin does not contribute to global warming, human activities generally contribute to global warming, but people will only exaggerate this while there are many companies and other human activities that contributes to global warming, and deforestation also resulting to global warming. Did you know how many gases the automobiles, non Bitcoin mining industries and other companies are releasing to the atmosphere alone which are potent green house cases that can lead to global warming? If miners are able to mine and pay electricity bill, I think it is also important as a means to generate more energy while government should focus on ways to generate green energy, green energy can be used to mine Bitcoin.
Unfortunately, most of the arguments appears to be centered on exactly that. I think I addressed the point about the lack of utility of Bitcoin and why it isn't a fair point to be comparing it to driving your cars. If you consider the issue of environmental degradation to be only about the direct electrical consumption, you're barking up the wrong tree. If the government really cared about the environment, we wouldn't be facing the whole issue of climate change today. Historically, government hasn't been as concerned with the environment as long as there is economic growth. Miners didn't care whether they're using 'green' energy or not as long as they're generating the most profits. |
|
|
|
Manipulating the market, bitcoin at the time uses 75% green energy.
No concrete data, AFAIK. 75% sounds quite unrealistic. Bitcoin contributes to global warming, simple as that. Manufacturing ASIC requires huge amount of energy, from mining the silicon, producing the wafer, etc. The entire process consumes a significant amount of energy as well. Sure, okay you compare Bitcoin to banking systems, different payment systems. That is hardly a fair comparison, the userbase of those are far greater than Bitcoin's with the transactions arguably far more useful, for their volume and utility. Use of Bitcoin in the real world remains fairly scarce as of now, and that isn't looking to be changed anytime soon. It's quite stupid to assert that Bitcoin doesn't contribute to global warming. Fact is, as much as you like to deny it, it does. Simple as that, your car, AC all contributes to global warming by producing demand for electricity and/or production of the said products. Do you think it'll be more reasonable to compare something that is far more useful to Bitcoin? Obviously, when Bitcoin becomes more useful than it is now, people would stop saying that it is a waste of electricity. Just like how people don't refer to those industries which produces more pollutant than Bitcoin as frivolous and wasteful use of electricity. They're mostly attacked by hardcore environmentalist rather than the general public which are often far more rational. |
|
|
|
I've never looked into that part of the mailing list, can't say anything about that. OP_return are the only outputs that aren't included in the UTXO set. It's stated some where in the paper that Bitcoin core defines dust value limit ( the curve marked "dust" in their figs), but does this means it's not stored from the beginning?  The dust limit serves as a threshold for the transaction to be considered non-standard, and thus invalid to be relayed. You can of course still create those outputs, they just won't get relayed. You can spend them with no problems but as the paper references, it costs more to consolidate and spend them as the extra input occupies extra space. -Because I remember in one of my questions to the Utreexo team they said the Bitcoin core does not store Unspendable TXOS, at that time I thought they meant whatever appears in OP_Return, now I wonder r those mentioned above included too? . They aren't. Core doesn't exclude dust outputs from the UTXO set. -One more question, does this means any user can mark an UTXO as Unspendable to save some memory? or just in Samourai wallets?
They cannot, and should not. Excluding any valid UTXO from your client's UTXO set will result in your client not accepting a block if the UTXO happens to be spent in that block. The missing UTXO will make Bitcoin Core invalidate the entire block. You don't mark UTXOs as unspendable, you "freeze" them to ensure they're left alone and never spent in the transactions that you're making. If it were to be spent in the transaction, the linkage will compromise your privacy. They are a cheap way to exploit the privacy. If I understand correctly, the dust limit is 546 satoshis so transactions lower than that won't even get relayed across nodes let alone stored.
Depends on the type of script it is locked to. Differs between Segwit and Legacy. |
|
|
|
I run the command the exact way it was in Electrum`s instructions, python3 -m pip install
So basically these both commands python3 -m pip install --user & sudo pip3 do the same thing?
python3 and pip3 are the same, they both are installing Electrum-4.1.4.tar.gz, just one does it for all users, the other for only one user? did i get it right?
If so then why the fist command from Electrum`s website doesnt work form me? even if it installs for other users how come i dont have acccess to it? I am the only one user on my laptop.
As i mentioned i am very new to Linux, can do things only if i have detailed instructions,
Oh, I think I got what's going on. You have to restart your Ubuntu OS after the first pip installation for the path variables to take effect. I reproduced this with 21.04 and found Electrum to be correctly installed in ~/.local/bin but you can't execute it in terminal without first navigating to that. Restarting Ubuntu after the installation fixes this. Weird, I've never had this problem with the older Ubuntu or other Linux distributions. If so then why the fist command from Electrum`s website doesnt work form me? even if it installs for other users how come i dont have acccess to it? I am the only one user on my laptop.
As i mentioned i am very new to Linux, can do things only if i have detailed instructions,
The reason why you're able to launch Electrum through the link you've followed is that you're directly executing Electrum. The icon that is created directly points to the Electrum that is installed for all users using pip. You could've used Electrum if you were to restart your computer and use terminal to launch electrum (by typing electrum in the terminal). pip doesn't create icons, so you're supposed to be executing through the terminal but in the guide you've linked, you're creating your own shortcut. |
|
|
|
I tried adding values as you said, and i do it one by one, only "oneserver": true, stays, other values get lost after i start electrum.
No matter how many times I've tried, I can't replicate the issue. Electrum reorganizes the sequence of the config during shutdown, could you check if you missed it due to the shuffling? (Sorry it might be a bit obvious but I suspect that might be the case.) Looks like this values ls important for me as I run prune node. "skipmerklecheck": true, <-- this is important if your node is pruned
I probably could ignore this value "server": "10.0.0.1:50002:s", <-- replace with your IP since my Electrum desktop icon already have this line --oneserver --server localhost:50002:s which i assume does the same.
I am not sure with other 3 value below, do i need them to run Core+Tor+Electrum+EPS
"auto_connect": false,
"confirmed_only": true,
"use_rbf": false
skipmerklecheck persists if I enter it at the end like this: "skip_merkle_check": true
Take care to not break the syntax of the config. Oneserver should disable autoconnect, if I'm not wrong (doesn't hurt to include). As long as you trust the server, you don't have to include confirmed_only either. The use_rbf depends on whether you want your transactions to have opt-in RBF. Edit: Okay anyways. Since you're explicitly running Electrum with -oneserver and the server you're connecting to, you don't have to include the two config variables for that. For confirmed_only = true, it would prevent you from spending any unconfirmed UTXO. Again, doesn't hurt to add them; your arguments will override the appropriate configs. |
|
|
|
|
Show Posts
