If certain privacy feature also manage to improve scalability (e.g. due to smaller TX size or faster time to verify the TX), i see no strong reason to against such privacy feature. What in the FUCK does Snowden know about cryptography and bitcoins blockchain. He was pro-bitcoin for a short while, then started talking a lot of shit about bitcoin years back.
I'd rather see him made constructive critic Bitcoin rather than exaggerate what Bitcoin can do. |
|
|
|
I just tried with some address from https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html and i have few thoughts. 1. Why do you bother list category with zero percentage?  2. Sometimes i got this kind of error. Although after i refresh the page, it shows the report correctly.  3. When i check address listed on https://ofac.treasury.gov/recent-actions/20220914, it shows 3 different risk (100%, 10% and Low). It would confuse people who use your service.  For reference, i tried checking address bc1qxhmdufsvnuaaaer4ynz88fspdsxq2h9e9cetdj which supposed belong to Foundry USA mining pool.
I got the same error message. I also tried few other addresses belonging to well know exchanges.. same error message. I assume their servers can not handle addresses that have a long transaction history! That makes sense, especially since currently anyone can use this service for free. |
|
|
|
It's also worth to mention higher total UTXO also require either more RAM or slower verification time (since you need to read the data from disk). It's especially slow during IBD process if you don't have enough RAM to store all UTXO on it.
the utxo set is only about 4GB apparently. Mozilla Firefox can eat up 1GB of RAM by itself maybe even more! So I mean, at some point people just have to bite the bullet and upgrade their computer. Because a new computer should be having 32GB of RAM at this point. If not you're getting the wrong computer! Also it might be time to upgrade from a hdd to an ssd because i heard they are alot faster. So maybe you could just store the utxo set on the ssd and not in ram. yes unfortunately, bitcoin like everything else grows with time and will demand more from the people who want to participate in it (run a full node)... 4GB? I think you saw very old stats. On my device, it's about 11.5GB for mainnet and about 9GB for testnet. And while i agree people ideally should upgrade their computer periodically, i think only Bitcoin enthusiast would upgrade their computer with primary goal to run Bitcoin full node smoothly. And as reminder, renting VPS with big RAM isn't exactly cheap. You're expecting receiver signature?
I was just saying that's a possible way to make sure that you don't have non-spendable transactions where the private key to the receiver's public key is not known. aka burn addresses. there's no point for utxos like that to be in the utxo set, is there? I get your point, although it makes sending Bitcoin become less convenient. |
|
|
|
i'm not sure why people complain so much about the size of the UTXO set Because it is the main thing, which decides about the size, which is required for running pruned node. Then, you have only the last N blocks, but also the full UTXO set. Which also means, that if such set is smaller, then it is easier to manage it, and then more people can afford running a full node with enabled pruning. Another story is Initial Blockchain Download, where if you want to simplify it, then you can use models like "assume UTXO", which is based on the UTXO set. And the smaller it is, the faster that kind of synchronization can be performed. It's also worth to mention higher total UTXO also require either more RAM or slower verification time (since you need to read the data from disk). It's especially slow during IBD process if you don't have enough RAM to store all UTXO on it. Including the coinbase transaction? Because then, you would have miner-only network, where each user would have to also be a miner, and where all transactions could generate new coins, based on their Proof of Work.
every transaction needs a sender and a receiver. they can be the same though. but they have to exist. sender key: receiver key: amount: sender signature: receiver signature You're expecting receiver signature? I think that require the receiver either, 1. Online and manually sending signature to sender. 2. Use service or run their own server which automatically sign and then send signature to sender. |
|
|
|
What do you mean with a disclaimer? - BTW, considering that more of these services are going to pop out in the future, perhaps you should consider adding a disclaimer to the footer area of the list in question.[/sup]
When he said "pop out", i think he means the service might no longer exist in the future. CMIIW. |
|
|
|
I was about to suggest you post this elsewhere, but it seems you already do that[1]. Anyway, i skimmed your idea and i have 2 thoughts. 1. How do you handle someone who intend to rent tons of GPU/ASIC at once to instantly mine all token? 2. Limiting to few hash type is probably better for maintainability sake. IMO 2 hash type, where the former can be mined with ASIC and the latter only can be mined with CPU/GPU should be good enough as starter. [1] https://github.com/ordinals/ord/issues/3739My idea is that each type of Rune can define a serial list of Hash functions. For example, I can define a PoW Rune , whose HashSequence consists of three different hash algorithms: SHA256, ETHASH, and SCRYPT. The calculation process during Minting would be as follows: hash1 := Sha256(blockHash + Nonce)
hash2 := Ethash(hash1)
hash3 := Scrypt(hash2)
Hash3 is the final PoW hash result used to calculate the Mint Amount. You also can etch a new Rune that includes 10 different HashTypes in it. Introducing multiple different Hash algorithms can effectively prevent GPU/ASIC. Combining multiple hash algorithm is clever idea. I doubt Rune token will remain popular for long time, so i doubt anyone would bother create specific ASIC. Although personally i have doubt about preventing massive GPU usage. |
|
|
|
That's true. But it could be opportunity for miner or mining pool to charge extra to include non-standard TX. For example, https://mempool.space/ currently recommend 13 sat/vB for high priority TX fee while https://slipstream.mara.com/ currently only accept TX with minimum fee rate 39 sat vB. And we should mention those service to those who angry over "censorship". If I'm not mistaken, MARA pool is one of those who first decided to censor transactions - but I don't understand why they only accept transactions that pay even 3-4 times more than those currently required for confirmation in the next block? As far as I can see, in the last 7 days they found "only" 36 blocks, while for example Via found as many as 124 blocks. Their business logic makes no sense to me, but I'm obviously missing something. On my previous post, i mention about idea which makes Ordinals TX become non-standard. Mara's Marathon Slipstream is service which let people submit their non-standard TX to Mara. What is Marathon Slipstream?
Slipstream is a service for directly submitting large or non-standard Bitcoin transactions to Marathon. It provides sophisticated users with a simple web interface and a transparent process for adding complex Bitcoin transactions to the blockchain. If your transaction meets Marathon’s minimum fee threshold and conforms to the consensus rules of Bitcoin, Marathon adds it to its mempool for mining.
So their business model is letting people submit their non-standard TX at higher fee rate. And here are few example usage i could think, - Include transaction with size more than 100 vKB.
- Include transaction which use SegWit address created with uncompressed public key.
|
|
|
|
When proof of stake
Probably never. when lighting network
It's already here and you can use it. Although it's still tricky to find service or merchant which accept Bitcoin on LN. when improved transactions speed and scability
It depends on your definition of scalability and transaction speed. When Will be full pos impemeted?
PoS (Proof of Stake)? probably never. |
|
|
|
Technically speaking, is what you wrote technically demanding or is it easy to implement and are there any negative implications for security or anything else when it comes to Bitcoin? It is easy to implement a rule that will make these particular transactions non-standard. The thing is: it doesn't invalidate them. The Ordinal users can still broadcast them to mining pools, and miners can still mine them normally. The only difference is that some upgraded nodes won't accept them in their mempool. Making non-standard only require change on full node software, so it shouldn't be that hard. I recall someone fork and edit Bitcoin Core source code which doesn't relay Ordinal TX. And looking at few PR and discussion on bitcoin-dev, developer have split opinion about whether to make Ordinals TX become non-standard.
The conclusion is that it is easy to do something that can force the ordinals to find an alternative solution, but that those who should implement such measures (miners) will certainly not give up something that (occasionally) brings them extra income. I am fundamentally against such things happening on the blockchain, but I also understand those who hesitate to take any step that can be interpreted as censorship. That's true. But it could be opportunity for miner or mining pool to charge extra to include non-standard TX. For example, https://mempool.space/ currently recommend 13 sat/vB for high priority TX fee while https://slipstream.mara.com/ currently only accept TX with minimum fee rate 39 sat vB. And we should mention those service to those who angry over "censorship". However, we still have the problem of how to explain it to someone who is an average Bitcoin user without too much technical knowledge, and who also uses Bitcoin perhaps on a daily basis for microtransactions. If today he can send his transaction for $1, and tomorrow he has to pay 20 or 50 times more, it looks quite confusing.
Yeah, it's definitely a problem. And saying vague explanation such as "due to high demand" or "too many unconfirmed pending" doesn't help much either. |
|
|
|
1. Did you use this calculator https://www.nicehash.com/profitability-calculator before you start mining on NiceHash? 2. Suggesting people to choose cloud mining over ASIC or platform like NiceHash is terrible suggestion. Cloud mining generally is scam or unprofitable. |
|
|
|
Could someone check post written by btc-1024mining? The post seems to be written on AI. In addition, he also recommend cloud mining and attempt to promote something called "1024mining" on few of the post. |
|
|
|
And the shitheads don't care a f*** bloating the UTXO set. It's unlikely Satoshi will come to rescue and consolidate all the coins thrown at the Genesis block and others. Sadly, it's pure madness.
I was told that Bitcoin Core at least culls provably unspendable UTXOs from its UTXO set in order to save memory. IIRC it's limited to OP_RETURN. Meanwhile, address which mine genesis block receive many dust. *Maybe* it might also be possible for a node operator to manually specify the kind of UTXOs that it wants excluded from the UTXO set.
That's just wasting their time. |
|
|
|
I was about to suggest you post this elsewhere, but it seems you already do that[1]. Anyway, i skimmed your idea and i have 2 thoughts. 1. How do you handle someone who intend to rent tons of GPU/ASIC at once to instantly mine all token? 2. Limiting to few hash type is probably better for maintainability sake. IMO 2 hash type, where the former can be mined with ASIC and the latter only can be mined with CPU/GPU should be good enough as starter. [1] https://github.com/ordinals/ord/issues/3739 |
|
|
|
It's very drastic action, when we could just make Ordinals TX (or rather OP_FALSE OP_IF usage) become non-standard which force spammer to either give up or ask miner to add their TX manually at high cost. And IMO hard fork should be used for far more important upgrade/change, rather than only to make Ordinals TX invalid.
Technically speaking, is what you wrote technically demanding or is it easy to implement and are there any negative implications for security or anything else when it comes to Bitcoin? If it's "so easy" to remove ordinal nonsense, I wonder if the developers are afraid to take such a step because the miners signal it to them, or if they just don't care that the fees skyrocket every now and then? Making non-standard only require change on full node software, so it shouldn't be that hard. I recall someone fork and edit Bitcoin Core source code which doesn't relay Ordinal TX. And looking at few PR and discussion on bitcoin-dev, developer have split opinion about whether to make Ordinals TX become non-standard. It's very drastic action, when we could just make Ordinals TX (or rather OP_FALSE OP_IF usage) become non-standard which force spammer to either give up or ask miner to add their TX manually at high cost. And IMO hard fork should be used for far more important upgrade/change, rather than only to make Ordinals TX invalid.
I`m curious, what kind of more important upgrade that needs to be done rather the Ordinals Few random example, - Fixing any critical vulnerability.
- Adding quantum resistant cryptography.
- Adding new opcodes (such as OP_CAT).
Although those example i mentioned could be added through soft fork instead. |
|
|
|
At this point I think the only remaining hope is for some third party creating a side-chain to create this garbage there and then pump it so that the gamblers actually bother going there. That way we can "transfer the cancer" out of Bitcoin and let it die there instead of it metastasizing here.
The "pumping" part is important...
In that case, we should encourage Blockstream to massively promote their Liquid network. After all, the feature is already exist. To me, this was acceptable until it reached thousands of OP_RETURN transactions per block. See Mempool Goggles. The larger spam transactions are now replaced by many more small transactions. It's still spam and takes up block space that could have been used by real Bitcoin users. you can't have it both ways. you either accept and support OP_RETURN and allowing people to store data on the blockchain or you say "No, I don't agree with OP_RETURN at all. Bitcoin was not meant for people to think of as any type of data storage." period the end. Why not? People opinion isn't limited to yes or no. That's why Likert scale (strongly disagree to strongly agree or 1 to 5) exist. the logic that you are going to introduce a special op code to store data so they won't abuse UTXOs is ridiculous in my opinion. but that's what we did and that's where we are. the end results of that...
The other choice is letting total UTXO explode, which leads to higher RAM requirement or faster disk speed to run full node. |
|
|
|
|
It's very drastic action, when we could just make Ordinals TX (or rather OP_FALSE OP_IF usage) become non-standard which force spammer to either give up or ask miner to add their TX manually at high cost. And IMO hard fork should be used for far more important upgrade/change, rather than only to make Ordinals TX invalid.
|
|
|
|
I see you fixed the link. Anyway, i just tested it, but it seems your website isn't working properly.  For reference, i tried checking address bc1qxhmdufsvnuaaaer4ynz88fspdsxq2h9e9cetdj which supposed belong to Foundry USA mining pool. |
|
|
|
|
First of all, nobody can give solid feedback when your tool got filtered by this forum. And since each exchange may use different way to determine whether certain coin is "tainted" not, people would question how useful is your tool.
|
|
|
|
I am using the portable version, not sure why it does not provide me with cmdline option - only gives a console through the GUI.
If you don't specify any argument, it'll open the GUI by default. But if you run electrum-4.5.4-portable.exe --help on cmd, it should show basic information about using CLI version. |
|
|
|
Bitcoin Client Software and Version Number: Bitcoin Core 27.0
Operating System: Windows 11 64-bit
System Hardware Specs: 3.60 GHz AMD Ryzen 5 3600 6-Core Processor with 16 GB RAM and 60 GB free SSD drive space.
Description of Problem:
1. How to enable pruning
2. Is it necessary to run the full node?
3. What benefits will I get if I run full node?
The first time you open Bitcoin Core, it'll display a " Welcome Screen", there you can set both prune settings and the custom data directory. This is best answer since it seems OP haven't run Bitcoin Core yet. And for reference, here's example screenshot of the welcome screen.  The apperance would be slightly different since i use Linux, while OP use Windows. And take note you'll need almost extra 12GB of free storage space to store folder called "chainstate", which is necessary to run prune node. Actually it's always better to run a full node if you can, since you are not going to be depending on a third party to verify a block and as mocacinno said it improve decentralisation of the Bitcoin network.
Pruned nodes are also full nodes. IMO it's up to debate. Although it's more important to state that pruned node doesn't depend on third party (aside from Bitcoin Core developer). |
|
|
|
|
Show Posts
