A small remark about UI, maybe The Team would be able to fix that. The bug is annoying especially on MultiplyBTC page: after the browser window is resized (width is decreased), the blocks are 'rearranged' and the part with stats goes below 'configuration' parts. Unfortunately, when window becomes larger the parts does not come back to their original places, refresh is needed.
I just tried to replicate that using Chrome and Firefox browsers and it worked fine. Here is the screenshot from Firefox problem appears. After resize, MultiplyBTC blocks stays in "narrow" setting, making browser window wide does not revert the change.  |
|
|
|
I'm not expecting these sheep to have learned anything from this experiment, but if next time they unleash a shitcoin wave on a Layer 2 network, then at least that shows that the crypto community is collectively becoming a bit competent.
Or just a bad timing. Or maybe not enough twitter/youtube/tiktok experts were talking about that and as an effect it did not bring expected amount of $. If it was a bad timing, sooner or later it will come back. |
|
|
|
If smaller transactions ( smaller in size, and not in value), were charged a low efficiency fee, and larger ones had to pay quadruple ( say ) fees,
It depends on what you mean by "smaller and larger". It sounds like looking for a central decision. Today fee could be used as a 'priority' marker, if all the fees would be fixed, how would you estimate when transaction is going to be processed? Talking about ordinals - yes, we may say that after years of improvements how to make transactions smaller finally someone proposed something opposite  but at the end it is a feature and possibility, so why not to use it? If we focus on efficiency we would have to say that for example we should stop processing outputs from uncompressed addresses as there was enough time to switch to something more efficient. |
|
|
|
|
A small remark about UI, maybe The Team would be able to fix that. The bug is annoying especially on MultiplyBTC page: after the browser window is resized (width is decreased), the blocks are 'rearranged' and the part with stats goes below 'configuration' parts. Unfortunately, when window becomes larger the parts does not come back to their original places, refresh is needed.
|
|
|
|
a bitcheque is more semantically correct description
(...)
I like your reply very much, thanks! I agree that check seems to be more valid word, taking into account how things work. But when you think about a check in real world, it is kind of promise, which must be validated, while coin is something what you have "right now". I assume the "coin" just creates a better impression. |
|
|
|
If you want to calll Bitcoin as e-cash, digital cash, it is too late now after 14 years since 2009.
I do not want to I am purely curious. You cannot say that if something was created/written years ago we are not allowed (or at least we should not be interested) in understanding what was the author’s reasoning. It is like negation of literary studies. |
|
|
|
Bitcoin is only a name.
Exactly, that topic is purely about semantics. Not about technology behind, but about the name chosen and what could be alternative names (then and now). Is "coin" the only word which could be used? "note", "check", "bill"? I think these are worse. Checks depend on the authority of a centralized third party to be cashed in. Note or bill could work, but these words are not universal across the English speaking world. Coin is, on the other hand. I was thinking why not “dollar”, as in fact it isn’t one-country currency and we have several “dollars”, digital dollar would be a possible choice too (and somehow “closed” the name for centralized gov dollar). |
|
|
|
|
Do we know when the word "bitcoin" appeared for the first time? Are we 100% sure it was in THE PAPER?
I was wondering why it is "bitcoin". (Someone with more advanced linguistic skills could probably help a lot). "coin" seems be the easier part. It clearly indicates the thing has something to do with currency. Is "coin" the only word which could be used? "note", "check", "bill"? Maybe that could be interesting, as unspent output is usually an effect of many previous operations and depends on their result - any faulty previous operation makes the final result faulty.
Talking about "bit" I am not sure if it should mean the concept is related to IT (computers, digitalization etc) or it has something to do with computer bits as a unit. I think already a decade ago "e-" was used for "electronic" versions of given words, like e-mail or e-market. On the other hand I think "byte" was a more popular word related to computer thinks. And we have also the root of the whole concept, elliptic curve. If we would take "sec" from secp256k1, "seccoin" could be also extended to "secure coin".
I am curious what do you think about it, why these two words "bit + coin" were selected?
|
|
|
|
It depends on how you plan to use it.
If you start it up and forget about it, Fulcrum would be better since it can deliver better performance after it's synced.
If you plan to start it up every now and then when you need it and don't mind if a wallet with many transactions is not lightning fast to receive, Electrs is better choice.
The other question is if I really need it - I have electrs running and I really do not feel I must change it to something else. But you know - numbers in performance comparison are tempting. Maybe one day if I have nothing better to do... |
|
|
|
I've done my IBD on my main computer, with SSD and the data disk as external. Then I've moved everything to the final position.
PS. Initial sync of Fulcrum is also rather lengthy on HDD iirc.
Do you have any experience with Electrs and may you compare the performance? Because that article ( https://www.sparrowwallet.com/docs/server-performance.html) made my think if no to try Fulcrum... But would I really feel it as a simple user? |
|
|
|
I always forgot to check - is there any particular reason for 6 confirmations? Why 6 not 7 or 5? Why some services require only 2? I guess it is related to amount of work needed to create 6 blocks, but is there any correlation with amount transmitted?
Because with more confirmations, the possibility of the transaction to be reversed is more difficult. Yes, of course, but show me please the proof why 6 confirmations are safe and 5 not. Is it just a "unwritten standard"? Has it something to do with block rewards? Or with total hash-rate? |
|
|
|
The more the confirmation, the better the security. Although true, for most practical applications 1 confirmation is enough. If it's a very large amount, 6 is enough. I always forgot to check - is there any particular reason for 6 confirmations? Why 6 not 7 or 5? Why some services require only 2? I guess it is related to amount of work needed to create 6 blocks, but is there any correlation with amount transmitted? |
|
|
|
(-snip- unconfirmed transactions are merged (!!)).
May be caused by the setting " Batch unconfirmed transactions" in the 'New Transaction' settings icon. But the setting was available in the older versions' " Tools->Preferences->Transactions" settings ( disabled by default) Yes, exactly. I just wonder why, if I have used previous version and had my setting saved, it was ignored and new version by default enables it. I think we are just a victims of features lost somewhere on the way from highly customized client for fans to simple & user-friendly client for everyone. |
|
|
|
How about using coinb.in to make transactions and disable the RBF flag on the advance option to generate unsign hex transaction and sign and broadcast it to Electrum?
That's pity we must do kind of kung-fu not to lose functionality which was available a few weeks ago. What is more annoying, RBF is off for payments to LN, so it is not like they just deleted piece of code. There are also other annoying things in the latest releases (modified UI -> "hidden" settings, unconfirmed transactions are merged (!!) etc.). |
|
|
|
I have done it according to the directions (downloaded on the website) and entered the initial seed that I saved and managed to get version 4.4.2
The laptop already has two electrum.
Can I remove the 4.4.1 version?
Yes, sure. As there are no major version changes, I assume even if you open wallet in 4.4.2 and some kind of migration will be performed, it will be still possible to open it in older version if you would like to use older version for some reason (for example to control RBF). Of course you may prepare wallet file backup, but having your seed, you are fine. |
|
|
|
Otherwise as per mempool, the highest fee is 123 sat/vbyte and then 30 sat/vbyte is the lowest, which is crazy to think that a few months ago, we can transfer with the lowest fee of 1 sat/vbyte and get confirmed very quick.
Looking at hash rate chart ( https://www.blockchain.com/explorer/charts/hash-rate) we see that in general we have the highest hash rate in the history, but looking at the recent difficulty adjustments and average block time we see we are currently below average. At this moment we are 32 block behind expected, but in fact it would not change a lot, as we have around 180 blocks waiting (400k transactions pending). High priority fee 200 and purging below 17, wow! But as every wave I think sooner or later it will just be processed and we will come back to more "user-friendly" fees. |
|
|
|
I just want to say that if everyone only focuses on developing for GPUs just because they're faster, they might miss out on some cool speed hacks and math shortcuts that can be really helpful for people like me who don't have top-of-the-line hardware yet.
I fully support that. I think developers should work on slow computers (at least slower than average user's computer), it would force them to improve their code without relying on the latest/fastest hardware. |
|
|
|
Version 4.4.2 has been released, could you confirm your problem is solved? Looks like 4.4 was intended to be a major release, as changes are not trivial, but it caused many problems. On the other hand we have a 2nd patch just in 2 weeks, that's good we do not need to wait months for updates. # Release 4.4.2 (May 4, 2023)
* Qt GUI:
- fix undefined var check in swap_dialog (#8341)
- really fix "recursion depth exceeded" for utxo privacy analysis (#8315)
* QML GUI:
- fix signing txs for 2fa wallets (#8368)
- fix for wallets with encrypted-keystore but unencrypted-storage (#8374)
- properly delete wizard components after use (#8357)
- avoid entering loadWallet if daemon is already busy loading (#8355)
- no auto capitalization on import and master key text fields (5600375d)
- remove Qt virtual keyboard and add Seedkeyboard for seed entry (#8371, #8352)
- add runtime toggling of android SECURE_FLAG, to allow screenshots (#8351)
- restrict cases where server is shown "lagging" (53d61c01)
* fix hardened char "h" vs "'" needed for some hw wallets (#8364, 499f5153)
* fix digitalbitbox(1) support (22b8c4e3)
* fix wrong type for "history_rates" config option (#8367)
* fix issues with wallet.get_tx_parents (a1bfea61, 56fa8325) |
|
|
|
I heard that Bitcointalk is a great place to give away and there are quite a few people here who appreciate custom collectibles.
Betnomi recently launched several rounds of their Free Cold Wallet Raffle ( https://bitcointalk.org/index.php?topic=5446281.0) I guess you know whom to ask to organize raffle like that  For sure it may brings attention, as free items are always desired. My only concern is that I suppose hard-core mixer user would not want to reveal his home address (even to 3rd party like minerjones). But yes, at least for some time the brand will be more visible. Home delivery of wallet with ordered, already mixed coins, LOL |
|
|
|
|
All what was written about fees is correct, but just for record (and maybe for novice users):
Blocks are "mined" by miners which do some calculations based on the given difficulty set for some period of time. Difficulty is adjusted every 2000 blocks, just to have the average performance 1 block every 10 minutes. But, it is average speed, it does not mean transaction will be processed in max 10 minutes. Unfortunately we cannot tell when next block will be mined. For example in the current "evaluation period" we are statistically 20 blocks late and soon difficulty will be decreased by +- 1%.
As a consequence, you should be aware that it is possible to wait a long time for block and fee does not change anything. The risk is that if block is very late (it happens that we have 30, 40 minutes or 1h without block), fee which was sufficient 1 h ago, is not sufficient now, as your transaction will be removed from the 1st expected block as other users prepared lot of transactions with much higher fee.
I skip talking about low-fee transactions purged from mempool as we talk about high fees.
|
|
|
|
|
Show Posts
