Search content
Sort by
Showing 10 of 10 results by pokeybear
I will probably not bet on who will be the next pope, and I didn't bet this time, either. This form of betting is entertainment, and it can be fun. It is sad when people get carried away and lose too much money.
I was astonished that an American, Cardinal Robert Prevost, became pope. People who bet on a different pope probably thought they were taking a calculated risk. Yet surprises like this happen all the time in life. Not many people can predict the future, but we can expect the unexpected and are likely to lose when betting on it.
I was astonished that an American, Cardinal Robert Prevost, became pope. People who bet on a different pope probably thought they were taking a calculated risk. Yet surprises like this happen all the time in life. Not many people can predict the future, but we can expect the unexpected and are likely to lose when betting on it.
⭐ Merited by JayJuanGee (1)
I'd stay anonymous, too. For safety, I keep a small canister of pepper spray/tear gas in a hidden but easily accessible area of every room in my house. That way, if anything happens, no matter where I am, one will be handy. I can get to them in less than a second. Pepper spray in these small canisters is legal in my country and provides a non-lethal way to incapacitate an aggressive attacker and get to safety. I haven't needed to use one yet, but I'm glad they are available. Readily accessible pepper spray is not an option for people with children.
Re: Possible solutions for preventing bloat in the bitcoin blockchain
... Aside, the term is miner not minor-- the confusion is understanble, both are known to play with blocks.
Excellent catch! I went back and edited just the spelling of miner in my original post.I'll read through and ponder the rest of your post as soon as I can. There are great points in there! I am grateful to you and the others for discussing these ideas with me.
Re: Possible solutions for preventing bloat in the bitcoin blockchain
FWIW, cost to run Bitcoin full node is much lower than cost to run node for current top 100 altcoin by market cap.
Bitcoin rocks! I was distracted by altcoins when first finding out about bitcoin, and had to learn over time that bitcoin is still the best for many things.
While it's theoretically possible to propose extreme fork which do these,
1. Treat script OP_FALSE OP_IF ... OP_FALSE as invalid.
2. Add size limit to script size.
3. Treat OP_RETURN with data bigger than X bytes as invalid.
4. Treat new UTXO that contain less than X satoshi as invalid.
Such fork is very unlikely to be accepted. And if it does, some spammer will continue to add arbitrary data using fake address at higher cost.
In my opinion, that's a great feature of bitcoin. It prevents a lot of bad code changes from getting introduced.
Is it possible to detect transactions that contain large UTXOs, large numbers of public keys (some may be fake, and we don’t know which ones are fake), or other attributes that may identify a transaction as harmful?
AFAIK no. Although i recall there were few discussions here that talks about theoretician address format which make fake public key/address become more expensive.
I'll have to look for some of those discussions. It sounds interesting.
Re: Possible solutions for preventing bloat in the bitcoin blockchain
No good, easy to sybil attack. If someone wants it badly enough, they can spin up enough nodes to be 70% of the network.
I'm thankful you shared that. Such a solution would need to be paired with extra code for resistance to sybil attack, which might not be worth adding to get such a feature.
Mining is already a consensus mechanism, what you want is to change the consensus rules that everyone follows. There were a few ideas mentioned on the mailing list on this topic, but ultimately what it comes down to is trading the flexibility of script for rigidity in ensuring that all UTXOs can be spent. Essentially, the mechanism for doing this would be to require that every output also carry a proof that the output is spendable, i.e. a signature. However, this severely limits what script can do, to the point that script wouldn't really exist. I think there would be a lot of additional logistical nightmares as well (e.g. senders and receivers now need to coordinate in order for the sender to make a transaction).
Furthermore, this wouldn't even stop data storage in Bitcoin. Sure it would make it harder, but steganography is an entire field dedicated to hiding data in things that are not meant to store such data. It would still be fairly easy to shove data in bits and pieces into pubkeys and hashes, it just takes a little bit of work to grind a couple bytes of a hash or pubkey to be the data that you want to embed. And since this is extra inefficient, the instances of this data would result in massive/lots of transactions.
Lastly, just because a UTXO is spendable by someone doesn't necessarily mean that it will be spent. So even with such a scheme, we could have tons of UTXOs that encode some data inefficiently, and someone is able to spend them, but ... maybe they just don't, and they still have polluted the UTXO set.
Furthermore, this wouldn't even stop data storage in Bitcoin. Sure it would make it harder, but steganography is an entire field dedicated to hiding data in things that are not meant to store such data. It would still be fairly easy to shove data in bits and pieces into pubkeys and hashes, it just takes a little bit of work to grind a couple bytes of a hash or pubkey to be the data that you want to embed. And since this is extra inefficient, the instances of this data would result in massive/lots of transactions.
Lastly, just because a UTXO is spendable by someone doesn't necessarily mean that it will be spent. So even with such a scheme, we could have tons of UTXOs that encode some data inefficiently, and someone is able to spend them, but ... maybe they just don't, and they still have polluted the UTXO set.
It is good that mining already has a consensus mechanism, making sybil attacks cost more. It sounds like the solutions mentioned so far would not be worth adding due to creating more problems than they solve. Thank you for sharing.
Possible solutions for preventing bloat in the bitcoin blockchain
I am new to Bitcoin development but curious, interested, and happy to learn new things. I would like to discuss ideas for preventing and reducing blockchain bloat. Like many of you, I desire that Bitcoin remain as decentralized as possible. That means we probably want to make it easier to run full nodes that don’t require much more than 800 GB of storage space over the course of many years.
Other people mentioned that one issue in the Bitcoin network is that some minors will process non-monetary or harmful transactions directly for monetary rewards, especially if they are receiving millions of dollars to do so. People have unsuccessfully tried to convince minors to stop doing that. It seems the next best option to prevent abuse is a software change.
Do you think it’s possible to modify the Bitcoin Core and other software to make certain transactions go through a specific consensus of node operators before minors are allowed to process them? It seems like many people running nodes might be more reliable because there’s less chance of them getting monetarily incentivized to corrupt the blockchain.
Is it possible to detect transactions that contain large UTXOs, large numbers of public keys (some may be fake, and we don’t know which ones are fake), or other attributes that may identify a transaction as harmful?
I have an idea, and I don’t know if it is possible: If a transaction meets specific criteria before it gets sent from one node to the rest of the network, could it update a temporary approval count variable? Then, all the other nodes could see the approval value of the transaction and update the approval number if they agree the transaction is good. If the transaction’s approval number is high enough, and if there is a way to know that more than 70% of active nodes have approved it, then the transaction could proceed to be processed by a minor.
What do you think?
Other people mentioned that one issue in the Bitcoin network is that some minors will process non-monetary or harmful transactions directly for monetary rewards, especially if they are receiving millions of dollars to do so. People have unsuccessfully tried to convince minors to stop doing that. It seems the next best option to prevent abuse is a software change.
Do you think it’s possible to modify the Bitcoin Core and other software to make certain transactions go through a specific consensus of node operators before minors are allowed to process them? It seems like many people running nodes might be more reliable because there’s less chance of them getting monetarily incentivized to corrupt the blockchain.
Is it possible to detect transactions that contain large UTXOs, large numbers of public keys (some may be fake, and we don’t know which ones are fake), or other attributes that may identify a transaction as harmful?
I have an idea, and I don’t know if it is possible: If a transaction meets specific criteria before it gets sent from one node to the rest of the network, could it update a temporary approval count variable? Then, all the other nodes could see the approval value of the transaction and update the approval number if they agree the transaction is good. If the transaction’s approval number is high enough, and if there is a way to know that more than 70% of active nodes have approved it, then the transaction could proceed to be processed by a minor.
What do you think?
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...
There are fair amount of alternative Bitcoin full node software, but for better or worse Bitcoin Core is still very popular. I've tried few alternative in past, but still prefer Bitcoin Core.
Bitcoin should stay lean. If more data is needed, Layer 2's can batch it and use OP_RETURN more efficiently.
Bitcoin L2 isn't that popular though, with varied degree of trust/centralization[1] and even falsely pretending as Bitcoin L2/sidechain[2].
[1] https://www.bitcoinlayers.org/
[2] https://www.lxresearch.co/starting-to-define-layers-a-year-later/
Looks like Bitcoin Knots may be a good way to protest against this. It has Bitcoin Core functionalities and you are actively voting against this PR by running a node. We should do that but also try to stop this on Bitcoin Core itself from being merged. Bitcoin is not some experimental blockchain to host jpegs. It's clear to me now that the whole argument for this PR is, "the blocks are empty so we must come up with ideas to fill the blocks". This is just linear thinking. The demand for using BTC for it's real use case, which is to move and store money, will be an S curve, and when it happens, you don't want the blockchain cluttered with jpeg spam. This is a huge mistake and anyone involved will have their name next to this when it becomes evident.
Good videos:
https://www.youtube.com/watch?v=zgsiDAhq4d4
https://www.youtube.com/watch?v=o7kCqwR9x24
I agree with this and the OP. One of the things I love about Bitcoin is that it is decentralized, making it more difficult for governments, large companies, and giant entities to control it. Running nodes is a powerful way to help keep Bitcoin decentralized, and many people can help protect its decentralized nature by running one.
It seems that OP_RETURN is working as a good spam filter, and I'm not convinced that it should be removed. I can see how removing OP_RETURN will contribute to the bloating of the Bitcoin network's size over time, making it more challenging for a large number of people to run a node. The more people who can run a node, the healthier the Bitcoin network will be.
Folks, running Bitcoin Core already requires more than 600 GB of storage space! That's a huge amount, and it will prevent many people from getting involved to help protect Bitcoin decentralization.
Re: Should couples invest in Bitcoin together or keep separate portfolios?
It depends on the situation or personalities.
What if both of them are knowledgeable in crypto but have a different opinion on alt coins, or what if they are in a verge of breaking up?
It is good to have a partner with a similar mindset or have the same interest as you, you could both have your own investment or portfolio or just combine your investment to make it grow.
What if both of them are knowledgeable in crypto but have a different opinion on alt coins, or what if they are in a verge of breaking up?
It is good to have a partner with a similar mindset or have the same interest as you, you could both have your own investment or portfolio or just combine your investment to make it grow.
I agree with this. Sharing a Bitcoin account involves trust and knowledge of good custody practices. The couple might not be ready or in the same mindset about it.
Trust can also be challenging if one partner is not responsible with finances and frequently makes poor spending choices. What if your husband's financial habits put your family into thousands of dollars in debt, and you've paid down the debt on your own multiple times? Or, maybe your partner is responsible with finances, but has no interest in learning about Bitcoin. If they have no interest and are unwilling to learn about safe custody and how not to get scammed, I don't think it's good to share a self-custody wallet. Yet, I want my partner to inherit my bitcoin if something happens to me, and I still need to find a good way to do that.
Re: FreeBitco.in-$200 FreeBTC⭐Win Lambo🔥0.2BTC DailyJackpot🏆$32,500 Wager Contest
if you are not logged, the home page is working...
...
The funny thing is that the FUN token went up 50% in the last 24 hours
https://talkimg.com/images/2025/03/29/lsUPN.png
I bet the price of FUN recently rose because most of the holders use freebitco.in and are currently not able to sell their FUN. Other crypto crashed a bit, yesterday.
I've also been seeing the error on and off for the last week. Interestingly, when the website is working, if I keep a browser window open on the page (and if the window doesn't reload), then I can still click around on the tabs and play the Hi-Lo game when the site is technically down. It is good that they coded the website well to work on the client-side, and not hit the server with excessive reloads.
As a web developer, I've faced the dreaded 500 internal server error many times. It is one of the most frustrating problems, because the error is so descriptive, right? You check the error logs, as advised, and many times there is nothing helpful in there, either. Fun stuff! I learned to check file and directory permissions, and that solved a lot of the problems with my scripts. If it wasn't a permissions problem (99% of problems were file permissions for me), I'd comment out all the non-working code, and add stuff back in one section at a time until I found the culprit.
Internal Server Error can be caused by the following:
- Incorrect file and directory permissions
- Database problems - query errors, slow response
- Misconfigured web server - mistakes or issues with .htaccess files or virtual hosts
- Large files on website consuming too many server resources
- Too many users hitting the server at the same time, consuming too many resources
- Connectivity issues
- Conflicts between different software components (why can't programs play nicely together, right?)
Anyway, my heart goes out to the web developers. I hope they are able to figure out the problem and fix it, soon.
As a web developer, I've faced the dreaded 500 internal server error many times. It is one of the most frustrating problems, because the error is so descriptive, right? You check the error logs, as advised, and many times there is nothing helpful in there, either. Fun stuff! I learned to check file and directory permissions, and that solved a lot of the problems with my scripts. If it wasn't a permissions problem (99% of problems were file permissions for me), I'd comment out all the non-working code, and add stuff back in one section at a time until I found the culprit.
Internal Server Error can be caused by the following:
- Incorrect file and directory permissions
- Database problems - query errors, slow response
- Misconfigured web server - mistakes or issues with .htaccess files or virtual hosts
- Large files on website consuming too many server resources
- Too many users hitting the server at the same time, consuming too many resources
- Connectivity issues
- Conflicts between different software components (why can't programs play nicely together, right?)
Anyway, my heart goes out to the web developers. I hope they are able to figure out the problem and fix it, soon.