Satoshi, in his invention of the blockchain, had given us the inch, what is preventing other bodies or organization from taking the ell?
I think you need to tell us what is "ell" in this context. Does it mean no coin hosted on the blockchain will gain mass adoption enough to bypass the users of bitcoin?
Nobody knows. It's possible another coin will become more popular than Bitcoin. The government own billions of population
I don't know what exactly you mean, but as reminder not everyone live under dictator. Last question please forgive me, what stops them from building a coin on the block chain that'll bypass the total sum of bitcoin users, and regulate it?
Nothing can stop anyone can create regulated/centralized coin. Although i doubt it'll surpass Bitcoin in terms of total users/owner. |
|
|
|
I recall you run Bitcoin Core. Have you used estimatesmartfee with various parameter (e.g. estimate_mode) to get some data? Why do you need many APIs?
The larger the datas collected and used, the closer it is to accuracy. As long as you don't use poor data source. I recall in past there was website which always extremely high fee which considered as overpay. |
|
|
|
Bitcoinj was never popular in here and there's not much discussion about Coinomi since it's become soruce. So you might also want to ask question on Bitcoinj issue page[1] or one of Coinomi social media[2]. Hello, I am trying to decrypt a Coinomi wallet. I found out that it uses bitcoinj library + AES-256-CBC with scrypt key + protobuf. When Protos.Wallet.parseFrom(new FileInputStream(walletFile)) I get the error protobuf - 'Protocol message end-group tag did not match expected tag'. What can be the problem?
From quick search based on error message, the common problem is the file (in this case coinomi wallet file) is corrupted or the library used to read the file is bugged[3]. [1] https://github.com/bitcoinj/bitcoinj/issues[2] https://www.coinomi.com/en/, scroll down to bottom of page. [3] https://stackoverflow.com/a/22108170 |
|
|
|
Can't believe there are 3 good news for Bitcoin and cryptocurrency community within short time interval. "We actually only just found out about it but it was at the end of end of last year, [the] Supreme Court refused permission for Craig Wright's appeal," said Rupert Cowper-Coles, a partner at law firm RPC who represents McCormack. "So they're very pleased that judgment stands - [the] one pound nominal damages award, which Craig has tried to appeal twice unsuccessfully."
Twice? He really trying hard, which fortunately doesn't result anything. 3. In that respect I want to continue to be a force for good by encouraging the open commercialisation of technologies in a competitive and fair market where intellectual property rights are respected and exploited. It is therefore my intention to ensure that the relevant Bitcoin Core ("BTC"), Bitcoin Cash ("BCH") and ABC Bitcoin ("ABC") databases and assets can operate and compete fairly in parallel with BSV, which I hope can compete in the global community going forward.
I stopped reading faketoshi offer after this part. Saying Bitcoin Core ("BTC") is huge disrespect, which reminds me of how BCH community attack BTC in past. Using term "database" also sounds weird to me. In addition, there's no thing such as ABC Bitcoin. Faketoshi doesn't even know he actually refer to eCash (name of the cryptocurrency) where Bitcoin ABC is one of full node software for eCash. |
|
|
|
It would be interesting to read what a developer thinks is or is not possible about altering the supply cap.
we are a very tiny minority (here on this forum) of all the people using bitcoin. the more popular bitcoin becomes, the more tiny we get. and the public at large wouldn't even know anything about how bitcoin works. so if that's the type of audience that the core devs have to work with then they might be able to sneak in a max supply increase. it wouldn't really affect them (the public) anyway to the extent that they would really notice (not at first!). if the government can print money out of thin air then i guess bitcoin can too.  There'll be always technical people and group who watch Bitcoin Core development though. It's also worth to mention such change can't be done stealthily since not everyone use Bitcoin Core. not to get too far OT but isn't that what all this Bitcoin ETF is about, pretending like you're buying bitcoin on a stock exchange but in reality no one really knows if that bitcoin really exists...so in a sense, there's some overinflation possibility already. but its fake overinflation but that can still hurt people.
Yeah, but such problem is outside of Bitcoin network. Although people who buy Bitcoin through ETF wouldn't even think about it. |
|
|
|
Im really happy that you made this post.
By the days, ive just realized that this forum is much more than just a talk about bitcoin.
As you can see, all my post over the days after that are pretty regular and do not have anything to do with AI. What i did not know, i asked and people here were friendly and helpful.
If it does counts, im truly sorry about using AI to help me interact in some kind of posts, that definitely i do not know a sh*t about. But yes, i thank you for making me see that this is not the way, and this community has a lot to make grow up not only about crypto, but as a human.
Did you read the whole thread? The main problem is false/fake/unhelpful information. Whether it's written by human or AI matters little to me. |
|
|
|
At very least, BTCPay doesn't use Tor by default and in certain cases i expect to detect whether it's deanonymization attempt or network problem. Tor is used by default for the WabiSabi coinjoin plugin in BTCPay Server. There's 0 mention of keyword "tor" or "onion" on it's documentation though https://docs.btcpayserver.org/Wabisabi/. Although i didn't watch included youtube video. |
|
|
|
A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters. As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other. A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner. As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts. Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user. If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with. Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay. Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.
Clients abandon rounds after multiple successive failures as a basic way to prevent this. That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack. At very least, BTCPay doesn't use Tor by default and in certain cases i expect to detect whether it's deanonymization attempt or network problem. I know you didn't mention it, but I disagree with this conclusion in section 7 of the WabiSabi paper: Denial of service is not costless because unspent transaction outputs are a limited resource. This is incomplete because the marginal cost of a DoS attack is zero if you are going to spend your UTXO anyways. Is that from section 7.1.2? What exactly do you mean by marginal cost? |
|
|
|
In my previous post I didn't say anything against paper wallets as this was not what the OP was asking for. But I feel the need to add here that I consider paper wallets obsolete and prone to errors and security issues. We have good and secure hardware wallets (I don't speak of Ledger crap) which provide better security and safety for your coins if used properly.
I would like to discuss this with you. I do not think so. If you think about it, even the paper (steel, aluminum, rock, etc.) wallet could be called a "hardware wallet". The only difference between the paper wallet and the USB wallet is the format in which the key is written: in the paper wallet the key is written in a human readable format, in the USB wallet it is written inside a delicate electronic chip readable only from a compatible device. So speaking of security in saving the key, it is decidedly safer to write the key in the simplest format, i.e. the one that can be read directly by a human being instead of adding unnecessary electronic complexity. You mistook security with simplicity. Some hardware wallet have ability to limit brute-force (either with time delay or erasure after several failure), while paper wallet doesn't. Plus, it is evidently insecure to use javascript for generating private keys. I'm mentioning this, because often times, it is an abandoned project like bitaddress.org which offers the option for paper wallet.
Can these bugs really be used by someone to one day discover my own key? Are these bugs so serious that they even force me to trust and pay (hundreds of dollars) a closed source key generator centrally developed by a private company and shipped by Amazon or some other unknown forwarder? It's not just bitaddress.org, there are also other sites and GitHub projects that allow you to generate paper wallets for all bitcoin address formats (P2PKH, P2SH, P2WPKH, etc...). It heavily depends on the bug itself. Here's an example, https://davidgerard.co.uk/blockchain/2018/04/11/javascript-securerandom-isnt-securely-random-most-web-wallets-affected-and-the-bug-was-warned-of-five-years-ago/. But you don't have to use hardware wallet when you could use /dev/urandom instead. This is first time i heard this software. Have you tried it in past? |
|
|
|
Okay, I will make this question short.
If I'm to receive like 30 different deposits from 30 different wallets into one wallet, which will make all these transactions appear like separate outputs if I want to send them all at once to one wallet,
So my question is, is there any possible way of sending all the transactions out as one output to a new wallet in order for it to be smaller in size and the transaction fee to be lower?
I know about coin control using electrum, which I can control and send bit by bit, which will also cost me a fee.
When receiving many small deposits in different wallets, sending them all at once to a new wallet may not significantly reduce fees. Use a wallet with fee optimization for better cost efficiency when combining multiple inputs into one output. Creating a transaction which spend all UTXO and send it to an address almost always best way to reduce TX size and fees. OP doesn't mention he has UTXO with very small amount of Bitcoin which could make my previous sentence incorrect. And there's no thing such as wallet with fee optimization. What you can find is wallet which suggest fee rate and let you set custom fee rate. |
|
|
|
That would be great, but I think every time fees start to approach that level, someone will say, "Oh, now's the perfect time to inscribe my series of byte-perfect CryptoDickButts."
Is that seriously a thing now? Oh yeah, it was first a thing on Ethereum, and they're actually quite expensive: https://opensea.io/collection/cryptodickbutts-s3For 1.25 ETH, you can own this bad boy right now:  They look terrible, lol. I still think CryptoPunks look terrible, but you can't say that in my world, its verboten. Why spend 1.25 ETH when you can just screenshot it  . Anyway, i agree people would create their Bitcoin TX with better mempool condition. Surely some of us plan to consolidate UTXO. |
|
|
|
Yes, indeed fuse2 is needed atm. What do you mean by electron-sandboxing (4)? Electrum does not use electron. Do we really need that sysctl? I have never seen a problem with that before. I include electron-sandboxing (4) as example of common AppImage (not Electrum AppImage) problem. Should've explicitly mentioned that. |
|
|
|
Look man, I don't know what you're trying to do here. Don't you have enough with 15 neutral color tags but basically saying you're a piece of shit? Now you want to open a rational debate by quoting someone who is going to die? If it's because Wasabi pays you to represent them on the forum, the best thing you can do is stop doing it. Otherwise you're just going to inspire more hate.
I somewhat agree. People will just assume you shill Wasabi.
- Can WabiSabi be traced?
Not unless you are the biggest whale in a coinjoin round with insufficient liquidity. Even outputs that do not have matching amounts cannot be traced to an owner on the input side - it’s even possible that the output changed hands as a payment to someone who did not own any funds on the input side at all:
--snip--
Have you checked WabiSabi paper from https://github.com/zkSNACKs/WabiSabi/releases/latest/download/WabiSabi.pdf and read section 7? A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.
A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.
Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.
Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.
To be specific, what do you think about sentences i quoted above? |
|
|
|
I don't mind you promote your website/blog post, but you might want to mention the fact you accept cryptocurrency as payment method. Anyway, since i never hear your website i have 1 question. How can we know that we receive legit/real copy of the e-book where publisher/writer receive portion of the money? The same with Andreas Antonopoulos' Mastering Bitcoin. I wonder why it isn't on the list. I have time and again read that it is probably the best guide in technically understanding Bitcoin.
While that book is great, i'd guess OP aims for non-technical cryptocurrency users. |
|
|
|
When in doubt, you might want to use this assessment, ▁ ▂ ▄ ▅ ▆ Cloudmining 101 (ponzi risk assessment) ▆ ▅ ▄ ▂ ▁. Anyway, i visited Infinity Hash websites where i didn't image/video proof of ASIC used for it's service and their FAQ doesn't mention whether you can sell share you bought. Can't say it's scam, but i obviously can't trust them. |
|
|
|
It doesn't
With a hard drive of 2-4 Tb, you'll have no issue storing blockchain data for a long, long time. And it doesn't cost you up to $50
Remember on top of that, I'm paying a higher fee on the mempool because of that Ordinals/NFT. 50$ is a lot in poor countries and we need people running nodes in all parts of the world, not only North America and Europe. If running Bitcoin full node burden their financial, then IMO they should doing that and focus to improve their financial condition. With a 1Tb hard drive, anyone would be able to run a full node now. Bitcoin has been around 15 years and the total data space it's taking is just above 500gb
I used the 2-4TB to show that what you need to run a full node for many decades to come.
Yeah, but the spammers are increasing more and more. When this will stop? But with block size limit, there's upper limit of blockchain size growth. the difference is YOU are foolishly adding in the word FULL to nodes that are not offering full network service
the emphasis is the word FULL means FULL
YOU imply something less then full service is still full
Conventionally, the community has always agreed that full nodes are the opposite of SPV clients and that full nodes are just nodes that validate each block and transactions. Sounds like you’ve blown the issue out of proportion. Just look at the historical usage of the term. But term "full node" already exist before any full node software offer prune mode. So personally i would keep using term "full node" (store all blocks) and "pruned node" (store recent blocks). And i recall term "archival node" comes from ETH community. |
|
|
|
That CT article would be accurate if word "Bitcoin devs" replaced with "anyone". I'm sure this comes as a huge relief for all of you guys.
Not really, anyone who somewhat familiar with Bitcoin technical detail would just say it's something obvious. Sometimes I feel like cointelegraph articles are written by artificial intelligence.
Actually it's one of less worse CT articles i've read. My only major complaint is they treat Bitcoin Core source code as source of truth when it's supposed to be reference implementation. |
|
|
|
If you're looking for something ready to use, there are commercial heater brand such as Heatbit ( https://heatbit.com/) which use mining chip to generate heat. While their chip is more efficient than S9, it's still expensive compared with regular heater. |
|
|
|
|
Show Posts
