Quote from: nutildah on April 30, 2025, 04:44:33 PM

OK, this guy is out of control. Some of his posts look like he knows what he's talking about but many of them are just text-spun & "humanized" versions of the posts they are quoting.

BADERO

--snip--

Thanks for mentioning this user. Upon detailed reading, this user fit this thread.

User: BADERO

Additional information (optional):
* Many of his post have many poor usage punctuation, capitalization and grammar, which makes it not easy to understand.

List of post:

Quote from: BADERO on April 30, 2025, 02:24:09 PM

Quote from: pooya87 on April 30, 2025, 01:40:43 PM

I'm afraid this PR is a lot worse than what it appears at first. It is not just removing the OP_RETURN limit (which is bad enough on its own since bitcoin is not a cloud storage!), but also it is removing the option user had to set/change that limit as well. In other words if this PR is merged and if you run the next version of bitcoin core you will no longer be able to choose which OP_RETURN size you want to relay (that choice should be yours to make), and instead you will be forced to use what the default setting is!

In fact things like this are the reasons why I've argued for the benefits of having a strong alternative implementation of the Bitcoin protocol to be used instead of core... At some point when the core devs keep refusing to fix exploits like what allows the Ordinals Attack to take place and then limit users' ability to set their own standard rules, the benefits of having an alternative implementation outweighs the disadvantages of it...

To be honest, this PR is worse than it first appears it eliminates not only the OP_RETURN size limit, which is already dubious because Bitcoin isn't designed to be a cloud storage service, but also the node operators' ability to set that limit themselves. That is significant until now, the -datacarriersize option allowed users to specify the type of data they wanted to relay. You will have no choice but to accept whatever default Core decides if this PR is merged. A decentralised system shouldn't operate that way
This directly connects to the bigger issue Core developers have demonstrated a lack of willingness to handle spam like attacks (such as Ordinals) and now they are also limiting the options available to node operators to defend against such misuse. For this reason, I've been arguing for some time that we need significant alternative Bitcoin implementations, not just as a backup plan but also as a practical check on Core's centralised decision making.

1. For most parts, his post only rephrase @pooya87 post.
2.

Code:

-datacarriersize

isn't used to speficy type of data that want to be relayed. It's used to set maximum size of arbitrary data that want to be relayed.

Quote from: https://developer.bitcoin.org/devguide/transactions.html

The -datacarriersize Bitcoin Core configuration option allows you to set the maximum number of bytes in null data outputs that you will relay or mine.

Quote from: BADERO on April 29, 2025, 10:18:47 PM

Quote from: nochkin on April 27, 2025, 11:04:37 PM

Quote from: LoyceV on April 12, 2025, 08:26:30 PM

When you encrypt it, it creates new private keys.

Unless I misunderstood you, are sure this is the case?
I just tried to create a new wallet and then dumped the keys. Then I encrypted it and dumped the keys again. I see the same private keys.

The current private keys in a Bitcoin Core wallet are not created when it is encrypted instead, they are encrypted and secured by a passphrase bitcoin Core does not remove, replace, or regenerate the key material when you encrypt the wallet it only secures the already existing key material. This expected behaviour is confirmed by your test, which involves dumping the keys before and after encryption and noting that they are identical. The original keys remain unaltered only subsequent keys created after encryptio for example, when creating new addresses are encrypted with the passphrase.

1. When you encrypt wallet on Bitcoin Core, it definitely create new set HD seed where new HD seed used to generate new private keys.

Quote from: https://bitcoincore.org/en/doc/29.0.0/rpc/wallet/encryptwallet/

** IMPORTANT **
For security reasons, the encryption process will generate a new HD seed, resulting
in the creation of a fresh set of active descriptors. Therefore, it is crucial to
securely back up the newly generated wallet file using the backupwallet RPC.

Quote from: BADERO on April 29, 2025, 09:55:43 PM

Quote from: Accardo on April 25, 2025, 02:05:51 PM

It's probably pointless to launch the attack, unless they want to proceed with a 'griefing attack, that screw up network operation. The 51% attack would help improvise enough testnet to generate a great number of blocks in a little time - James Lopp created 165000 blocks in a week using this attack and slowed down the network. The good part of it is that it hurts the functionality of testnet marketplaces, and the delay it causes the workflow of developers who are running their applications on the testnet, is certainly the bad side of the attack, although the action has no benefits for the attacker, it really pisses off developers.

Although it is essentially useless from a financial standpoint, a 51% attack on the Bitcoin testnet, such as the one that Innopolis Tech could carry out with its 51.76% hash rate, can be a useful griefing attack. An attack like this enables the entity to mine blocks quickly this technique was once used by Jameson Lopp to create 165,000 blocks in a week interfering with regular network operations time sensitive processes like time locks and Lightning based apps are disrupted the blockchain is overloaded the chain size is bloated, and mempool instability results by slowing down workflows postponing testing and impairing the functionality of testnet marketplaces it seriously hinders developers who depend on the testnet even though it offers no real advantage to the attacker it's an inexpensive method of annoying and upsetting the Bitcoin development community without putting the mainnet at risk

1. For some parts, this post is rephrase of @Accardo post.
2. While on theory testnet coin supposed to have no value/price, several exchange (AltQuick is most popular ones) makes 51% attack have a bit of financial standpoint.

Quote from: BADERO on April 27, 2025, 09:52:56 AM

Quote from: Felicity_Tide on April 27, 2025, 09:45:48 AM

I successfully completed the update in the early hours of this morning, and it’s working fine. At some point, I was wondering what extra benefits this latest version (v29.0) offers, until I noticed that the "progress increase per hour" shows a better percentage improvement compared to the previous version. Though, I strongly believe that my device specifications aren't high enough, and the process doesn't seem entirely efficient or smooth. I would like to know what additional benefits the latest version offers. Does it work more efficiently with the allocated dbcache, or it does something different?.

Quote from: promise444c5 on April 26, 2025, 04:05:35 AM

Quote from: nc50lc on April 26, 2025, 01:09:54 PM

Quote from: BADERO on April 25, 2025, 09:31:11 PM

If your RAM permits, you should increase the size of the dbcache setting to further speed up your device with v29.0 if you have at least 4GB of RAM you should ideally set dbcache=2048 (2 GB) in your configuration file if not, it's safer to set it to about 512 MB this significantly reduces slow disc reads by allowing more of the blockchain data to remain in memory to save resources reduce resourceintensive features like indexing and background apps while syncing ,to speed up processing if you have multiple CPU cores, use par=2 or par=3 to enable parallel validation threads, if your client permits it. syncing and validation on an SSD are significantly faster than on a disc even though dbcache helps lower disc pressure

1. User @Cricktor explain why changing default value of par isn't good idea/

Quote from: Cricktor on April 27, 2025, 01:35:33 PM

Quote from: BADERO on April 27, 2025, 09:52:56 AM

... to speed up processing if you have multiple CPU cores, use par=2 or par=3 to enable parallel validation threads, if your client permits it.

I don't think it's necessary to fiddle with this option. The default is par=0 which means Bitcoin Core allocates automatically the number of threads/cores it needs. Depending on what other tasks your node device might have, a negative value for par tells Core to leave that number of cores free for other processes than Core's.

Quote from: https://jlopp.github.io/bitcoin-core-config-generator/

# Set the number of script verification threads. (1 to CPU_CORES, 0 = automatic, less than 0 = leave that many cores free).
par=0

A reasonable value for dbcache without inducing memory pressure to the system has likely a better effect on performance than trying to tweak the par option.

Disclaimer: I've only played with dbcache, never touched par, so you should take my comments as an educated guess only.

2. dbcache used to store UTXO, not blockchain data.

Quote from: https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md

-dbcache=<n> - the UTXO database cache size, this defaults to 450. The unit is MiB (1024).

Quote from: BADERO on April 25, 2025, 09:08:43 PM

Give ACINQ support the specifics of the problem, such as the fact that it began following a Lightning transaction just in case, you can also look through any notebooks, password organizers, or pictures where you may have previously stored the seed

And in the meantime you can download an emulator on your PC to check whether the problem comes from your device or your account after the transaction (I recommend using BlueStacks 5

Phoenix wallet is non-custodial wallet for Android, so there's no thing such as account.