Bitcoin Forum
July 20, 2024, 10:58:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 463
1  Bitcoin / Development & Technical Discussion / Re: How do miners solve the knapsack problem? on: Today at 12:35:29 PM
other miners who don't have that set ready would likely reach a new set of "best" combination before you do, because you added extra steps to the process, besides, new transactions keep coming in every second so you are always going to be rotating transactions, so preparing anything before hand is unlikely going to work, and again, given that most bitcoin transactions have the same size, a cutting edge method to chose transactions isn't really needed, maybe at some point in the future as you mentioned.
I understand where you're coming from. But I'm wondering if there are any benefits to running a solver after having a solution given by getblocktemplate; concurrently, we can solve for a better solution while it is running. Hence, the tradeoff is minimal, if you get a better solution from your lp, then use it. Else, just use whatever is provided by getblocktemplate.

Part of my interest is also seeking to narrow the search space. I understand the entire mempool is far too big, but considering the tip of the mempool might have a slower rate of growth, which means we don't have to run a solver too often. Since considering less fee rate transactions would most likely not yield a better maxima. Also, the need of implementing it is definitely far from necessary, since difference is likely to be negligible.

Interestingly, while searching to see the discrepancy between mining pools and GBT, I found this site by 0xb10c: It definitely doesn't tell the full story due to a myriad of factors affecting the selection of transactions but some of the pools are definitely selecting transactions themselves: High discrepancy between GBT and the actual mining pool, F2Pool has an average of 99.95% compared to the rest which averages around 99.85% with regards to total capacity.

Most of them are just a hypothesis and I think experimenting and simulating it might or might not tell a different story.

2  Bitcoin / Bitcoin Discussion / Re: Why is "consolidating inputs" considered to be profitable? on: Today at 09:12:59 AM
i think one of the assumptions people make is that you HAVE to spend your bitcoin when the fees are at 60 sat/vbyte and that the only alternative would have been to consolidate utxos when fees had been lower. i call that an incorrect assumption. someone that didn't plan ahead like that has another option: wait until the fees go back down to a reasonable level. thus keeping their total BTC balance intact.
The truth is, I probably have to at times. I do certain deals with other people both on and off the forum. Not paying them immediately, and using fees to justify so is a good way to lose business.
that's a very tiny difference currently. maybe $2 vs $5. the time it takes to actually go through the entire consolidation process and attention given to it by the user, maybe their time is worth more than that. maybe they get paid $30 per hour at their job.
Simple example, and it's probably worse as we see periods of high peaks and drops throughout. Regardless, that wouldn't be a good assumption to make. I would love to save $3 if it takes seconds of my time. I hate to pay so much for small transactions.

I believe that a lot of your points are founded on mistakes when making transactions. Those can happen anytime and if you think that it may happen to you, then you might need to be more careful with how you pay.

- Clipboard malware or any malware is going to steal your Bitcoins even if you don't make any consolidation transactions.
- You can copy and paste an address wrongly whenever you're making payments.

Even if you speculate that fees may drop to 1sat/vbyte instead of remaining at 2sat/vbyte, that is fine the loss vs benefits is fairly small. Besides, we don't tell people to consolidate when fees are high. We tell them to do so when it is relatively low.
3  Bitcoin / Bitcoin Discussion / Re: Banks, Airlines, and Hospitals are all down today on: Today at 09:03:40 AM
If Bitcoin Core is updated, isn't it obligatory for all nodes to update their Core to the new version? Or can it still work on the old version without problems? Is upgrading optional?
There are different tiers of updates and they can be a mandatory, or an optional update. However, that would not be the main reason to dissuade users from updating immediately.

Bitcoin Core goes through multiple iterations of release candidates with multiple unit and functional test cases built in during the compilation phase. This sort of errors would've been caught before merging and they should not be present in the stable releases. Other than that, enterprise systems requires computers to be able to receive OTA updates and have them done automatically. If not, you would have the IT dept running around to update every computer for every minor update.
4  Bitcoin / Bitcoin Discussion / Re: Why is "consolidating inputs" considered to be profitable? on: Today at 05:19:03 AM
It is not profitable, you can't make more Bitcoins this way. Your consideration seems to revolve around user error or looking at it from a short term and constant fee perspective.

Barring the human error, which shouldn't be a factor in your consideration, your main consideration would be if you're able to save more on fees when the network is experiencing bouts of high fees. Consolidating numerous inputs when the fees are low allows the user to spend less when the fees are high. Consolidating inputs essentially means that instead of spending from 10 of them, you only need to spend from 1 of them.

Note that people who are using Bitcoin aren't always able to spend as and when they need. By doing so, they can save more on the fees if they need to transfer them when the fees are high. You can do your calculation in the following scenario and come up with the cost:

Given 10 inputs and a period where fees are 2sat/vbyte and another where the fees are 10sat/vbyte:

Consolidation Transaction (721.5vbytes): 1430sat
Actual Transaction (140.5vbytes) 1405sat

Total: 2835sats

Actual Transaction (721.5vbytes): 7215sats.
Total: 7215sats.
5  Bitcoin / Bitcoin Discussion / Re: Banks, Airlines, and Hospitals are all down today on: Today at 04:17:36 AM
I think it is unfair to compare it to Bitcoin, or generally the benefits of decentralization because it would be an apple-to-orange comparison.

Firstly, this issue should have never happened, whether it concerns CrowdStrike, Apple or any centralized services. Updates that can obviously crash critical infrastructure should not have made it past QA, let alone been pushed. Likely poor CI/CD practices and this is an internal problem for them to solve. OTA updates are a necessity for enterprises because it is difficult for critical patches to be made manually by the millions of computers running it. Bugs have surfaced in Bitcoin as well and we're lucky that it was mostly handled swiftly and efficiently.

Secondly, this is an enterprise software and it probably can't be decentralized or open source. They have contracts and agreements with the various companies for providing services. Having an open codebase does nothing good for a security company to say the least.
6  Bitcoin / Development & Technical Discussion / Re: How do miners solve the knapsack problem? on: Today at 03:39:14 AM
Knapsack problem is basically ensuring that you maximize the items with most value. Miners can maximize profits straightforwardly by choosing transactions with the highest fees subjected to size.
That would be the Greedy Approach, which rarely grants you a local maxima. The issue with knapsack lies predominantly with the size of each item that is supposed to be packed in a bag of a certain size. Hence, the problem of which to pack becomes a key decision to make. In operations research, we usually formulate it as a DP approach which would probably gain better results than Greedy.
Using complex and sophisticated LP solvers will actually just slow down a miner which is not ideal.
Transaction selection can be done concurrently, and this is independent of the miners because blocktemplates are not built by them. The way that miners work now is that they will build an empty block upon receiving a new block, before consolidating the transactions together. An easy way to think of a profit maximization would be to attempt to increase the value by selecting another set of transactions on-top of the Greedy method. As fees becomes the main revenue for miners, I expect marginal gains to be the priority.

LP solvers are actually sufficiently fast. However, if they are slow because you have too many items to consider, then you can narrow your search size. Given how much the size varies, majority of your set of items lies within the first Xmb of the tip, which probably becomes less than 10,000 transactions.
7  Alternate cryptocurrencies / Altcoin Discussion / Re: How Are Transactions Made Through Merkle? on: July 19, 2024, 01:05:18 PM
I know this is supposed to be a Bitcoin section, but it happened in an ETH explorer. I was windering if Merkel applies to ETH as in BTC. I intentionally used low fee for it before using a normal fee. The low fee tx didn't even show up initially:
That is not relevant to Bitcoin. Merkle is a service for Ethereum and their tokens: It does not apply to Bitcoin and if you're able to see it on blockexplorers then it won't be 'private' anymore.

Actual private transactions are broadcasted directly to Bitcoin mining pools, but serves no advantage unless it is a non-standard transaction.
8  Bitcoin / Development & Technical Discussion / Re: Are there any threats when a user translates exposed mnemonic words? on: July 19, 2024, 02:50:42 AM
Efforts to add new languages to the BIP39 official wordlist repository have also ground to a halt because nobody is merging those changes into the BIP repository, and in many cases, comments and communication have simply ceased.
It's quite a chore to review all of the phrases between the languages, getting them peer-reviewed and then merging them. The criteria for the mnemonics are strict and the process of building and checking those can't be automated. On top of that, having wallets supporting those. It's no surprise that this would receive little traction and they have repeatedly said that it isn't recommended to be using anything other than English.
9  Bitcoin / Development & Technical Discussion / Re: How to add add payment button to website and check if transaction was successful on: July 19, 2024, 02:44:34 AM
Without any knowledge of programming, Iíll just drop you how I feel this could work and you can sort help with a programmer to see you through the set up.

I guess your challenge isnít just having to put in place a payment media as that could be done easily but, itís confirmation. That is where you would need a programmer to link your website to some program that constantly refresh your payment history by minutes as payment notifiers does come in and process transaction through its reference ID.

When it comes to putting in place a payment media with regards to Bitcoin, having a scannable bar code address or the alphanumeric address configured to your hope page or payment media could help out while, using same step as above, you instruct your programmer to honor transactions with at least 2 confirmations on it. Be open to more advice but, this is my thought on the issue here.
Each transaction should be paying ideally to its own unique address. Using the same address for multiple users or multiple transactions would inevitably cause some confusion and ambiguity. Confirmations, or accepting payment is not the hardest part but the systems design of it is more difficult.
10  Bitcoin / Development & Technical Discussion / Re: How do miners solve the knapsack problem? on: July 18, 2024, 10:19:01 PM
There is no way to know; each miner has their own proprietary mining software and no one can probably give you an answer besides the usual reference implementations and the ones that are open source. Validating this idea would be quite difficult, since we don't have a way to get the exact same mempool as the miners and that it is difficult to see which transactions miners are not in their mempool.

I would probably go on a limb and assume that most miners are selecting transactions by fee rates greedily, aka. Greedy Algorithm. For example, Bitcoin Core selects by ordering transactions with the highest fee rates to the lowest fee rates and selecting the transactions accordingly. I'm assuming that this could possibly give somewhat a decent tradeoff; miners cannot afford to spend too much time to consolidate the best combination of transactions and given how small Bitcoin transactions are, you can probably fill the blocks pretty much full.

This is the first time that I heard knapsack problem I did a bit of research and according to some responses that I found it talks about infinite block size.

If you are mining with Bitcoin I don't think you can develop something that you can select which if you want to include in the block you mine.
I don't think there is a called Gurobi or LP-solver in mining BTC maybe if you own a pool with huge hashrate power then you can choose and optimize what transactions you want to add to the block you mine.
Knapsack problem is exactly a problem that miners would face, because block size is not infinite. Knapsack is quite tricky because it is NP-hard and in our case the mempool has tons of transactions. It considers the optimization of fees with the pool of transactions of differing sizes and attempting to fit them into a block in a way such that you're able to maximize your profits. OR-Tools (Python) is quite flexible in this regard, and it would probably be easy to formulate something where (naively, but do consider the other stuff such as sigops)

Max z = x1(y1) + x2(y2) + ... + xn(yn)
 4 = x1 + x2 + ... xn

Where x is the size of transactions in vbytes and y is the fee rates for the transaction.

Just to add-on: There are a few edgecases too and one of which concerns the fact that including child-transactions might yield a higher overall revenue and hence optimizing according to groups of transactions might be better.
11  Bitcoin / Development & Technical Discussion / Re: Are there any threats when a user translates exposed mnemonic words? on: July 18, 2024, 12:09:07 PM
Which assume Mr. B aware that BIP 39 words also provide non-english wordlist. In addition, not all wallet which support BIP 39 provide full support for non-english word list. Website mentioned by OP support all 10, while Electrum 4.5.5 seems only to support 5[1].

That is a good point that should be emphasized more. BIP39's proposal actually strongly discourages using any language other than English simply because most wallets don't bother with other languages; BIP39 does have 10 wordlists but you'll probably have people asking why not more.

Besides that, do not ever translate your passphrase because it can potentially introduce tons of ambiguity and headache; one word in English can have many different permutations in Chinese and most of which are 2 words instead of 1. Dependency on wordlist is cited as a motivation for the Electrum wordlist and the fact that they're not so fond of BIP39 also makes sense for a less comprehensive implementation.
12  Bitcoin / Development & Technical Discussion / Re: Are there any threats when a user translates exposed mnemonic words? on: July 18, 2024, 05:06:23 AM
That's not how BIP39 works. BIP39 works by having mnemonics encode the entropy. The way that it is done per BIP39's specification is that each word is an index on their respective wordlist and the order of which isn't ordered by their meaning. Hence, they're not a direct translation, but independent wordlists.

If you were to translate one, then it would likely fail, either having invalid checksum or invalid mnemonics entirely. If an attacker were to find a mnemonic, there is no reason whatsoever for them to translate it into their own language. You should not be translating sensitive information, that is a poor security practice.
13  Bitcoin / Development & Technical Discussion / Re: How to add add payment button to website and check if transaction was successful on: July 17, 2024, 01:43:09 PM
Generally, you would want to configure it with Bitcoin Core and the relevant RPCs. The process would go like this: Customer goes to the payment page -> You generate a unique address for them and set a callback using Bitcoin Core's RPCs -> Listen for callbacks for X confirmations and subsequently confirm their transaction and send whatever goods you're selling.

The easy part is implementing this, but the difficult part is ensuring that it doesn't run into any errors, ie. Bitcoin Core crashing, attackers gaining access to your backend, etc, etc. The easiest way, by far is to just use BitPay as a POS and have them handle it for you. They do have integration with plenty of languages.
14  Bitcoin / Bitcoin Discussion / Re: Linux Inventor Says He Doesnít Believe in Crypto on: July 17, 2024, 01:35:19 PM
It shouldn't be a reason to dissuade people from using Linux. Linus is great at his field and he has said plenty of controversial stuff, for which some I agree and some I don't. He was talented in his own field to develop Linux with his team and I don't think his opinion would ever discount that. Besides, Linus maintains the Linux project, but isn't the main person handling it.
15  Bitcoin / Bitcoin Technical Support / Re: Is the 'fee estimation currently not possible' problem getting worse? on: July 16, 2024, 11:53:43 AM
Based on my past experience which doesn't accept incoming connection, 300MB mempool isn't the problem. The problem is rate of received unconfirmed transaction could be slow (less than 20 TX/s), which is problematic when there are so many unconfirmed transaction. For example, currently state there are about 177K TX with 759MB mempool (about 70K with 300MB mempool). I haven't checked whether it's also happen with newest version of Bitcoin or if you accept incoming connection.
It depends on how well-connected, or how loose your peer's mempool policies are. Johoe and are very well-connected and are likely to have transactions that would otherwise be purged from the reference nodes with default settings.

Other than that, Bitcoin Core uses inv messages to notify their peers of the blocks and the transactions that they have. For which, each node will subsequently request for the transactions that they're not aware of using getdata. I'm not exactly sure what is the exact limit, I don't recall exactly seeing a limit for that. and others are displaying the new transactions that are being relayed, as opposed to ones that are offline for too long.

Regardless, by how Bitcoin Core estimates fees, you don't actually have to know the entire mempool to get a good estimate. This is further compounded by the fact that you're only looking at the higher quantiles, which is pretty much guaranteed by the minfees limit set by mempool.
16  Bitcoin / Bitcoin Technical Support / Re: Is the 'fee estimation currently not possible' problem getting worse? on: July 16, 2024, 04:35:28 AM
Is your Bitcoin Core fully synchronized? This error pops up if your client doesn't have enough transactions in the mempool to make any estimation (ie. still being synchronized), or if you've got sufficient transactions but Bitcoin Core hasn't seen them being confirmed yet to build a reasonable estimate for their priority system.

This problem should go away if you're fully synchronized, and you've let the client run for a short period of time.
17  Bitcoin / Bitcoin Discussion / Re: Why use decentralized bitcoin in a centralized way? on: May 21, 2024, 03:33:53 AM
There is an assumption that Bitcoiners wants decentralization. That is false, most of them are in it for the money unfortunately. When you're in it for the gains, you think less about the other intrinsic benefits that Bitcoin offers.

Pin this on the centralized services because that is the first point of contact for many and they stop right there. If you truly want them to take control of their own funds, we have to abandon the regulations and the licensed exchange and services. We all know that is not happening anytime soon.
18  Bitcoin / Bitcoin Technical Support / Re: file location after bitcoin-core installation on: May 21, 2024, 03:30:47 AM
I had various issues with the Snap package of Bitcoin Core in my Ubuntu LTS 22.04.x, particularly it didn't work properly with Tor installed and running. I think it was when Bitcoin Core 23 or 24 was the current version. I could pinpoint the issue that the snap package wasn't configured properly but I lacked the knowledge to fix this Snap quirk.

Maybe the current Snap package is fine, but back then I simply installed Bitcoin Core from the tarball and all was fine and working smoothly.
Was it a connection issue, or a data directory issue? I just started running a few nodes on Ubuntu via Snap and all was okay. Did the logs say anything?


Snap configures everything for you and you just need to run the app. If not, then you just have to navigate to the snap/bin folder and execute it. A default data dir will be in ~/snap/bitcoin-core/common/.bitcoin
19  Bitcoin / Bitcoin Technical Support / Re: Help with a full node on: May 21, 2024, 03:22:36 AM
Do note LoyceV reply before mine as I think that it's an interesting path to explore if you're willing to. I recommend the second approach (VPS with OpenVPN) and you can follow this[1] guide in order to have it up and running.

How about a VPN with port forwarding (or a cheap VPS with OpenVPN installed)?
Most well regarded VPN providers - such as Mullvad or IVPN - have removed the ability to do port forwarding. Proton still allows it[1] but you have to be a paid subscriber and you also get the port chosen by the program and you have to change it each time you restart the VPN connection. Considering that I personally do not trust other VPN providers, my recommendation would be the second option (VPS with OpenVPN installed).
Generally VPN over VPS is rather slow, and also more expensive with insufficient benefits to the network. Instead of having one hop, data goes through your VPS and then to your computer. Cheap ones are generally quite slow and likely wouldn't have sufficient bandwidth for a very large node. 1TB upload is probably not very sufficient if you have a VPN running through it and nodes connecting to it.

It shouldn't be an issue if you're unable to accept inbound connections. If you want an easy to setup and a free solution, then you can route it through Tor.
20  Bitcoin / Bitcoin Technical Support / Re: file location after bitcoin-core installation on: May 15, 2024, 09:26:56 AM
You don't have to. During the initialization, if Bitcoin Core doesn't detect a data directory then it would prompt the user to specify a data directory. Else, it would automatically create a data directory for you in the default data directory path.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 463
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!