 Show Posts
|
|
Pages: [1] 2 »
|
Anyone know of any AI programmes that produce good images ? There’s plenty out there that produce artistic images or random images, but I can’t seem to find any that produce an image that can be used , for example, adverts, SEO stuff etc. Thanks in advance  There's nothing useful for free, from what I have tried, compared to midjourney. To make images like that, you might want to buy professional plan from midjourney. AI is most progressive on the market at the moment. |
|
|
|
Hey @Cryptonex, you might want to edit or to do something your first post in this topic, because it looks outdated.
We hope you're enjoying our service and the benefits. I have never experienced any downtimes, I enjoy mobile app, staking and rates are fine for me. Keep up the good work! |
|
|
|
|
Hey @Cryptonex, you might want to edit or to do something your first post in this topic, because it looks outdated.
|
|
|
|
|
Regarding the specific situation in Hong Kong, it has been a major hub for crypto-related activities, including exchanges and blockchain projects. China invests a lot of resources in that.
Both China and the US have shown interest in blockchain technology, but their approaches and regulatory philosophies differ. The US has taken a more cautious and fragmented regulatory approach, with various regulatory bodies involved. China, on the other hand, tends to have a more centralized and controlled approach, mostly because of their politics.
China have some interesting statistics about producing almost 60% of world's goods, their perspectives are limitless imo.
|
|
|
|
- Operation Choke Point was an initiative by the U.S. government in 2013 to crack down on fraudulent activities by limiting access to banking services for certain high-risk industries. "Operation Choke Point 2.0" targeting crypto businesses is speculative at this point, and there is no confirmed information about such an operation being implemented.
- The relocation of major exchanges or businesses could lead to a temporary disruption, as it may impact liquidity and investor confidence.
|
|
|
|
|
In 2023 both support and service are online.
I have been a member for 3 years, staking is what's working fine for me.
|
|
|
|
I have become familiar with this topic by reading info at https://www.babypips.comI am not an employee of this service, but I want to recommend it because it is well written material. |
|
|
|
I tried getting Armory 96.5 working on my Qubes 4.1 machine (4.0 is really not supported any more), and all was well until this last part compiling was really the same as 94-96.x, using debian 10/buster toolchain, no issues dbLog.txt: -INFO - 18:09:08: (BlockUtils.cpp:915) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 18:09:08: (BlockUtils.cpp:916) lmdb dir: /home/user/.armory/databases
-INFO - 18:09:08: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 18:09:08: (BDM_Server.h:263) Listening on port 63221
-INFO - 18:09:08: (nodeRPC.cpp:57) RPC connection established
-INFO - 18:09:08: (BlockDataManagerConfig.cpp:919) waiting on node sync: 99.9997%
-INFO - 18:09:08: (nodeRPC.cpp:425) Node is ready
-INFO - 18:09:08: (BlockUtils.cpp:1108) Executing: doInitialSyncOnLoad
-INFO - 18:09:08: (BDM_Server.cpp:1121) registered bdv: 4a80c146a3552190f2b4
-INFO - 18:09:08: (DatabaseBuilder.cpp:199) Reading headers from db
-INFO - 18:09:25: (DatabaseBuilder.cpp:238) Found 723305 headers in db
-INFO - 18:09:33: (DatabaseBuilder.cpp:64) Rewinding 100 blocks
-INFO - 18:09:33: (DatabaseBuilder.cpp:71) updating HEADERS db
-INFO - 18:09:33: (DatabaseBuilder.cpp:493) Found next block after skipping 1660080bytes
...
-INFO - 18:09:35: (DatabaseBuilder.cpp:281) parsed block file #3599
-INFO - 17:53:09: (DatabaseBuilder.cpp:281) parsed block file #3600
-INFO - 17:53:11: (Blockchain.cpp:248) Organizing chain
-INFO - 17:53:18: (Blockchain.cpp:370) Organized chain in 6s
-INFO - 17:53:24: (DatabaseBuilder.cpp:76) updated HEADERS db in 908s
-INFO - 17:53:25: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 17:53:25: (DatabaseBuilder.cpp:1231) verifying txfilters integrity
-INFO - 17:54:06: (DatabaseBuilder.cpp:1314) done checking txfilters
-INFO - 17:54:07: (DatabaseBuilder.cpp:134) scanning new blocks from #723305 to #790065
...
-INFO - 18:06:46: (BlockchainScanner.cpp:852) scanned from block #789756 to #790065
-INFO - 18:06:46: (BlockchainScanner.cpp:214) scanned transaction history in 759s
-INFO - 18:06:47: (BlockchainScanner.cpp:1789) resolving txhashes
-INFO - 18:06:47: (BlockchainScanner.cpp:1848) 0 blocks hit by tx filters
-INFO - 18:06:47: (BlockchainScanner.cpp:1937) found 0 missing hashes
-INFO - 18:06:47: (BlockchainScanner.cpp:1982) Resolved missing hashes in 0s
-INFO - 18:06:47: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 18:06:47: (DatabaseBuilder.cpp:186) scanned new blocks in 760s
-INFO - 18:06:47: (DatabaseBuilder.cpp:190) init db in 1726s
-INFO - 18:06:47: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
-INFO - 18:06:53: (BlockchainScanner.cpp:857) scanned block #790066
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2086) BLKDATA DB does not have the requested ZC tx
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2087) (scrubbed_but_valid_hexdata)
-WARN - 18:10:17: (LedgerEntry.cpp:334) failed to get tx for ledger parsing subsequently, ArmoryDB only seems to perform "Wallet Properties" callbacks, most everything else produces errors in the qt log the ERROR line from lmdb_wrapper.cpp repeats dozens of times. And the gui reports "node offline" It seems that you are encountering an issue with Armory 0.96.5 where the BLKDATA DB does not have the requested ZC (Zero-Confirmation) transaction. This error message suggests that there might be a problem with the blockchain data stored in the database. - Verify blockchain data: Double-check if your blockchain data is complete and up-to-date.
- Rebuild databases: You can try rebuilding the Armory databases to ensure they are in a consistent state. This process will involve reindexing the blockchain data. In Armory, go to "File" > "Rebuild Databases" and follow the prompts.
- Check disk space and permissions: Ensure that you have enough disk space available for Armory to operate properly. Additionally, verify that the user running Armory has the necessary read and write permissions to access the Armory and Bitcoin data directories.
- Update Armory: Consider updating to the latest version of Armory, as newer releases often include bug fixes and improvements.
Let me know how it goes. |
|
|
|
Thanks for the info and provided links. Suprised to see it was indeed back in 2010. Did anything similar occure many years later by chance? "While the transaction does not exist anymore, the 0.5 BTC that was consumed by it does. It appears to have come from a faucet and has not been used since." (from https://en.bitcoin.it/wiki/Value_overflow_incident) Not sure if I am getting this corretly - did indeed some BTC (0.5) of this malicious block end up on the current blockchain? How is that possible if the original mined transaction was made void during a fork? The statement from the Bitcoin Wiki is referring to the fact that the 0.5 BTC input used in the malicious transaction was originally obtained from a faucet (a service that distributes small amounts of cryptocurrency for free). After the value overflow incident was discovered, a fix was implemented which invalidated the malicious transaction and any subsequent blocks built on top of it. The 0.5 BTC from the malicious transaction never became a permanent part of the blockchain and did not affect the current state of the Bitcoin network. [...] - The bug was fixed in Bitcoin Core version 0.3.10. The fix involved modifying the code to use a larger data type (64-bit integer) for handling transaction values, preventing similar overflow issues in the future.
[...] The oldest Bitcoin core version on Github is 0.10.0 - where did you get your info from? |
|
|
|
- The bug occurred in the code responsible for verifying transaction outputs (specifically, the CheckTransaction function) in the Bitcoin Core software.
- The bug was caused by an integer overflow error. When calculating the total value of transaction outputs, the software used a 32-bit integer variable that exceeded its maximum value due to a large output value.
- As a result of the overflow, the software incorrectly treated the transaction as valid, allowing for the creation of an excessive number of bitcoins.
- The bug was fixed in Bitcoin Core version 0.3.10. The fix involved modifying the code to use a larger data type (64-bit integer) for handling transaction values, preventing similar overflow issues in the future.
- The incident did not lead to the creation of any extra bitcoins. The excessive amount that could have been generated was merely a theoretical possibility resulting from the bug.
It's important to note that this incident highlights the robustness and decentralized nature of the Bitcoin network. If you're interested in more technical information about the bug and how it was resolved, you may want to refer to the Bitcoin Core software repository. |
|
|
|
The longer fork represents the consensus of the network, as it has accumulated more computational work and has a greater number of participants supporting it. This is not correct. As I explained above, the longest chain does not necessarily contain the most accumulated work. I could fork bitcoin right now, drop the difficulty to 1, and then churn out 10,000 blocks in a few minutes. My new chain would be far longer than the main chain, but have much less accumulated work because the number of hashes required to generate all 10,000 of my blocks would only be tiny fraction of the number of hashes to generate a single block on the main chain. The main chain, although shorter, would have the higher amount of work, and so everyone else would stay on that chain and not switch to my longer chain. By choosing the longer fork, miners align themselves with the majority, reducing the risk of their blocks being orphaned or invalidated in the future. No, they do this by aligning themselves with the chain with most work, which again, is not the same as the longest chain. That's a greate explanation and a pretty crucial point. So a difficulty comparison is done every time by just checking the zeros in front of the latest blockhash?Reading about the accidental-fork-by-miners issue, I remember there was one instance, maybe already 10 years ago, when this happened 6 or seven times in a row. It then became apparent that there was a bug causing this. Need to look up what happened there exactly. The difficulty of mining is determined by the network protocol and is adjusted periodically based on the target set by the protocol. In most blockchain systems, including Bitcoin, the difficulty adjustment algorithm takes into account the average time it took to mine a certain number of blocks in the past. If the blocks were mined too quickly, indicating that the network's total computational power exceeds the intended rate, the difficulty is increased. Conversely, if blocks were mined too slowly, the difficulty is decreased. This is designed to ensure that the average time to mine a block remains relatively constant over time. |
|
|
|
Miners should generally choose the fork with the longest length. This is wrong. Nodes will follow the chain which has the most accumulated work. This is not necessarily the chain with the longest length. Usually when we reorganize one or two blocks, then the blocks will obviously have the same difficulty and therefore represent the same amount of work, so the longest chain will be the chain with the most work. However, if a fork lasted long enough to significantly stretch beyond a difficulty retargeting and in to a new difficulty epoch, then blocks on each chain would represent a different amount of work and so the longest chain may not necessarily be the chain with the most work. Nodes will switch to a shorter chain if that chain has more accumulated work. This is also wrong, let me explain why I was not wrong. While a shorter and more difficult fork may offer higher rewards in the short term, it is important for miners to consider the long-term implications. The longer fork represents the consensus of the network, as it has accumulated more computational work and has a greater number of participants supporting it. By choosing the longer fork, miners align themselves with the majority, reducing the risk of their blocks being orphaned or invalidated in the future. It's worth noting that miners typically rely on consensus rules implemented by the network's protocol and the consensus of the majority of miners and nodes. Following these rules and aligning with the majority helps maintain the integrity and stability of the blockchain. |
|
|
|
When miner encountering a fork, one fork has less difficulty but longer in length, while the other fork is more difficult but short. Which fork should miners choose ? Miners should generally choose the fork with the longest length. In blockchain terminology, the length refers to the number of blocks on a particular fork. Choosing the longer fork ensures that the miner is contributing to the majority of the network's computing power, which enhances the security and stability of the blockchain. Visualization of a blockchain fork event: the network reconverges on a new longest chain: |
|
|
|
It seems like the error message you received indicates that the file you are trying to extract does not exist in the current directory. Double-check that you are in the correct directory where the downloaded file is located. If the file is in a different directory, you can either navigate to that directory using the cd command or provide the full path to the file in the tar command. For example, if the file is located in the Downloads directory, you can navigate to it using the command: and then run the tar command. Try this command to check whether specified file is in your current directory: Alternatively, you can provide the full path to the file in the tar command, like this: tar xzf /path/to/bitcoin-22.0-x86_64-linux-gnu.tar.gz I hope this helps. Let me know if you have any further questions or issues. |
|
|
|
|
By creating a UTXO that aggregates other UTXOs, you would be able to greatly reduce the size of the UTXO set on the blockchain. This could potentially lead to faster and more efficient transactions.
However, this approach may lead to increased complexity in the verification process. In order to verify that a UTXO is valid and can be spent, the blockchain would need to verify not only the inclusion proof of the aggregate UTXO, but also the inclusion proofs of all of the individual UTXOs that make up the aggregate UTXO.
Can you make up a solution to this problem?
|
|
|
|
|
Workers Day is indeed an important day to celebrate and appreciate the hard work and dedication of workers all over the world, regardless of whether they are paid or not. It's a time to recognize the contribution of workers to the growth and development of our society and economy!
In particular, I want to highlight the important role played by the Administrators/moderators of the bitcointalk community. Their efforts in ensuring that rules and regulations are observed by community members cannot be overstated. They work tirelessly to maintain order and ensure that the community remains a lively and interesting place for everyone.
Thank you and Happy Workers Day!
|
|
|
|
|
It's great to see that you have a positive attitude towards Bitcoin and its potential for the future [SO AM I]. It's true that Bitcoin and blockchain technology have come a long way, and there's still a lot of potential for growth and innovation. With each day, more and more people are beginning to see the potential benefits of using Bitcoin, and this trend is likely to continue in the years to come. So, if you believe in the potential of Bitcoin, and you have a possibility to invest, in my opinion, it's certainly worth considering investing in it and holding on for the long term, but don't do this bluntly, please research first.
|
|
|
|
MEV (Maximal Extractable Value) is a term used to describe the potential profit that can be earned by including and ordering transactions in a block in a specific way. MEV is primarily generated through transaction fees and can be obtained by miners or validators who have the ability to influence the ordering of transactions in a block. In the context of Ethereum staking, earning MEV is not directly related to staking rewards. Staking rewards are determined by the protocol and are distributed to validators based on the amount of ETH they have staked and the duration of the stake. The amount of MEV that can be extracted from a block is influenced by factors such as network congestion, gas prices, and the transaction ordering strategy. Validators can attempt to earn MEV by using various transaction ordering strategies to maximize transaction fees. Some popular strategies include: - MEV-Geth: A specialized Ethereum client that allows validators to extract MEV by reordering transactions before they are included in a block.
- Flashbots: A decentralized platform that allows miners and validators to extract MEV by submitting bundles of transactions in a specific order to the network.
- Archer DAO: A decentralized autonomous organization that offers tools and infrastructure to help validators extract MEV more efficiently.
It's important to note that extracting MEV can be a complex and technical process that requires advanced knowledge of the Ethereum protocol and network. Additionally, MEV extraction can also be seen as a controversial practice, as it can lead to increased centralization and unfair advantages for those with the resources and technical knowledge to extract it.
|
|
|
|
It is difficult to say that the current pump is due to Russian influence, as we know that the development of bitcoin users is increasing rapidly and in Africa there has been an increase of up to thousands of percent since 2021 so the pump is due to a significant increase in the number of users.
It is also possible that the pump is being driven by speculative activity, where investors are buying Bitcoin in anticipation of future price increases, rather than actual adoption or usage of the technology, or returning back to Russia. It's best to exercise caution when attempting to attribute market movements to any one specific factor, especially without concrete evidence. |
|
|
|
What is with these all knowing super-newbies? Is AI taking over bitcointalk?  iBaba has only 2 posts and creates a big wall article thread and then the other dude zezaiement comes up with a very detailed mega answer. Something is fishy here. Anyway.. PayPal is a company and it is centralized. Bitcoin is a commodity/payment system and it is decentralized. It is pretty clear who is the big guy here. Tldr; You can kill paypal, you cannot kill btc. I was trying to make an input in the conversation. My answer was triple smaller though.  |
|
|
|
|
