|
FWIW, I just removed a nearly year old post with a .bitcoin directory download that would have stolen all your bitcoins.
Case in point as to why these "download the blockchain" links are a disaster. God knows how many people got robbed due to it.
|
|
|
|
i dont know about this, can anybode tell me what is this? if i download it, can i access blockchain offline? and what happens next? i don't under stand with it. what is the benefit im downloading that file?
It is used by of Bitcoin Core wallet for faster network synchronizing. If you download the blocks using Bitcoin Core itself, it'll take you days if not week to fully sync the wallet. With this, it'll only takes a day or less to download depending on your internet speed. You also need to consider your computer specs before downloading this massive-size blockchain. Unless you have a very fast connection downloading the blockchain and importing it will take longer than just letting it process as normal, because if you download in advance you cannot process and download at the same time. This has been true since version 0.10 or so. |
|
|
|
It is a criminal offense claiming copyright if not the original developer.
A criminal offence with a maximum $2500 fine. $2500 + $55 vs how many millions from the BSV pump/dump? Seems to me that Wright had a great ROI on his latest fraud. ... even better if the US government never bothers prosecuting, AFAICT they never have before. |
|
|
|
Assuming this gets added to Bitcoin Core soon, would you say that it is likely that the default connectivity would also be increased?
Maybe not at the same time because there are other things like per-connection memory usage that need to be optimized too... but eventually, sure. Probably you'll see per connection memory usage get improved, then the default inbound connection limit get increased, and only after that's well deployed would the default outbound level get increased. |
|
|
|
I disagree. The current guidelines are extremely clear.
I don't agree that they're clear for handling airdrops/spinoffs. The simplest interpretations result in absurd consequences. Some people have advocated that a spin-off is income at the time it came into existence at its market prices. Following that kind of absurd interpretation to its absurd ends means that we could bankrupt Warren Buffet, for example, by creating a bitcoin spinoff that traded at $1/coin and also included an output paying 100 trillion coins to his website's SSL cert key... causing him $100 trillion in taxable income. Someone you have no relationship with handing you cryptocurrency you never asked for and expecting nothing in return -- potentially entirely without your knowledge or even any reasonable way for you to discover it-- should never create an income tax obligation. It certainly shouldn't create an income tax obligation based on some absurd highly illiquid scamcoin market last trade price. I do agree that its clear otherwise, although _significantly_ inconvenient for general usage. Fixing that will likely take an act of congress: IRS is unlikely to wave tax obligations for small cryptocurrency transactions on their own. Some of the things people are asking for, like being able to use like-kind exchange to cover swapping between bitcoin and ethereum seem flat out absurd to me. IRS might permit something like that but only if they can't resist showing how ignorant they are about cryptocurrency. The model of treating Bitcoin largely like stock is a generally workable one, and you sure as heck can't do like kind exchanges between unrelated stocks! |
|
|
|
Is transaction broadcast really a problem that needs to be solved?
Erlay reduces node bandwidth usage by 38%, or by 75% if connectivity is increased from 8 to 32 for attack robustness reasons. And won't this solution affect decentralization of transactions broadcast?
The opposite: transaction relay is more decenteralized and robust if nodes have more connections. Erlay allows having more connections without using significantly more bandwidth. |
|
|
|
In a follow-up to the ideas discussed in https://bitcointalk.org/index.php?topic=1377345.0Hi all, We are making public our latest work on Erlay, an efficient transaction relay protocol for Bitcoin. It is available here: https://arxiv.org/abs/1905.10518The main idea is that instead of announcing every transaction to every peer, announcements are only sent directly over a small number of connections (only 8 outgoing ones). Further relay is achieved by periodically running a set reconciliation protocol over every connection between the sets of withheld announcements in both directions. The set reconciliation protocol uses error correcting codes to communicate a set of transactions to a peer with an unknown but similar set using bandwidth only equal to the size of the difference and not the size of the sets themselves. Results: we save half of the bandwidth a node consumes, allow increasing connectivity almost for free, and, as a side effect, better withstand timing attacks. If outbound peer count were increased to 32, Erlay saves around 75% overall bandwidth compared to the current protocol. This work uses Minisketch, an efficient library for set reconciliation, which we made public before: github.com/sipa/minisketch. Some of you may already know about it from discussions with me, Scaling Bitcoin 18, or CoreDev in Tokyo. Our proposal has become more precise since then. The next step here is to receive more feedback, have a broader discussion, and then write a BIP along with improving reference implementation. We are looking forward to hearing your suggestions or concerns regarding this work. This protocol is a result of work by myself, Gregory Maxwell, Pieter Wuille, and my supervisors at UBC: Ivan Beschastnikh and Sasha Fedorova. I would like to thank Tim Ruffing and Ben Woosley for contributions to the write-up, and Blockstream for supporting my work on this protocol. – gleb |
|
|
|
|
Craig Wright is a scammer who has published a bunch of obviously fake evidence trying to connect himself with the creation of Bitcoin but he has no connection.
|
|
|
|
People are weirdly confident in this issue. Guess we all should be having plan B incase this doesnt go our way instead of focusing more on contesting with people who don't really believe in bitcoin ideals or wants bitcoin under their control.
How will the community react if he wins this? Respond in fire bridged manner, launch an excellent plan B or run away with tails behind your legs?
I demand you transfer all your property to me. Little do you know, but your parents sold you to me while you were an infant for a magic bean. I could easily demonstrate some evidence truth of this claim, but I won't because you're not worthy of me. Instead I'll make up some easily disproved fake evidence: Your parents have blue hair and signed using the blood of ghandi, since he is your godfather. No one will hold these obvious lies against me, because they're simply there to protect me from having to pay taxes on this highly profitable trade I made all these years ago... Now I will include some genealogical and legal terms to prove my expertise (imagine these being screamed): lineage, naturalization, pedigree, hypothecate, fideicommissum, demurrer. Oh wait, you're suddenly so confident that my absurd story is bullshit and you refuse to go along with it? Funny that. |
|
|
|
It only costs $55 to challenge it but it is a crime to do a false claim.
No. It cost $55 to file a claim (false or not). It's technically a crime to make a false claim but the maximum penality is $2500 and as far as anyone has determined so far, no one has ever been charged under it. The fact is this registration can legally be challenged, basically an open invitation. Unfortunately this isn't true. If wright tries to take any action he would simply lose because he is an enormous scammer, but it would be his move so he simply won't do it. Only the government can enforce the law against making a false registration, but presumably they won't because they haven't bothered before. Fortunately, the copyright registration has absolutely no effect other than just helping wright defraud people. -- just like it had no effect when someone previously did it (if you search you'll see there is another one for bitcoin done by a prior scammer back in 2016). https://bitcointalk.org/index.php?topic=4519202.0 |
|
|
|
|
This thread is really about Ethereum which deservedly gets the vast majority of David Gerard's sneer.
David Gerard makes a name for himself being contrary. He's often right about the things he criticizes, but like anyone else who makes their opposition part of their identity he can often be wrong too.
There is a _ton_ of outright fraud in this space, especially around Ethereum.
If you're feeling exposed by him, perhaps you should reconsider your actions (and "investments")?
[Kinda funny that these newbie account vaguely threatening posts start up right when the target starts ripping into Wrights latest false claims...]
Bitcoin is strong enough to take a bit of mud thrown its way and come out the better for it-- various premined scamtokens? ... not so much.
|
|
|
|
For the record I don't have any association with Samourai. Back then I wanted to build Wasabi Wallet for Samourai, but they were not interested/responding my messages and nagging, so I went ahead alone.
Repeated dishonesty from Samourai have barred them from ever receiving a payout from the bounty as far as I am concerned: I will not be signing a transaction paying them. Evaluating the privacy of systems is difficult even when the involved parties are honest and easy to work with, it is far too difficult when they are actively misleading. Personally, I would urge my friends to not use that wallet. As far as other stuff, there has been efforts in progress to do some awarding for a couple months now. It takes time to evaluate things and work with the recipients. If it didn't this bounty would have been gone years ago when "darkwallet" demanded the whole thing then mobbed us with unreasonable demands (including public campaigning which was vigorous to the point of harassment) to pay it all to them when the result didn't provide the advertised privacy and didn't even stay available due to the operating model. |
|
|
|
I have one with first transaction back in 2012: 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
Message: "Oldest i have"
Signature: "HJhVCVulX2Ezm8441dwXgay67ozUB3Zx7ugZ+uIjxGI5ad1+9D7jkFvHIHl+7vCS5w9FCDoyVdzxAj8NVGDSrJE="
That's amazing! I've got the same combination on my luggage!
$ ./bitcoin-cli verifymessage 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN "HEvt5MuLizA33qqIU5RGKY5XLLSmdnf8TpoD3jRtlViQHDgeDmmyTT0owamGdI2tssr30QDy/hcpvt75YK8Ai8I=" "How do you do, fellow kids?"
true
Don't be stupid and go deanonymizing yourself for some silly forum thread posted by someone who not only was faking being a long time user, but for which 2012 was the best he could do. |
|
|
|
Why the Windows binaries are signed by different signer and root authority? First it was Bitcoin Foundation, now it is bitcoincoresigningsomething.org
I can get my own certificate for bitcoin-something named entity and sign malicious bitcoin executables that steal coins. Get your shit right! Settle once and forever on single entity that is signing binaries and stick with that!
As you note, the windows signatures mean essentially nothing-- anyone can get one and there is no real way to verify them. You could very likely get one called "Bitcoin Foundation", at most you'd just have to incorporate an entity with that name. The recommended procedure is to check the GPG signatures and keys, which have been consistently the same since 2013 or so. Back when windows and windows AV started punishing software for not purchasing a cert the Bitcoin Foundation offered to take care of it. They went on to exploit the author indication to make people believe they were responsible for releasing Bitcoin... not really a great outcome. They subsquiently went up in a ball of cretinous glory. Several of them ending up in prison, others backing an obvious scammer. Eventually the certificate expired, as all centralized certs eventually do. It was replaced with a key assigned to an entity that doesn't do anything else, to hopefully reduce the odds of future stupidity. Regardless, you're still best off checking the PGP signatures. |
|
|
|
|
Why is it that when suckers that fell for wright finally start to get a clue they grab on to the next bit of fakery wright puts out?
It's like some kind of gamblers fallacy for dishonesty: "The last 100 things Wright told me were lies, so this next one has to be true for sure!".
|
|
|
|
I think this is the topic you intended to reply to, no need to create another one. I split it: it was bumping an old thread with an off-topic tangent (the tangent started in that thread but no need to continue it). No need to reopen an old discussion to ask a new question. |
|
|
|
|
Can y'all please stop derailing this thread?
|
|
|
|
Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality. One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you. The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed. I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads.  -- why must this kind of concern be conserved for sane proposals where it doesn't really apply? |
|
|
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.htmlHello everyone, Here are two BIP drafts that specify a proposal for a Taproot softfork. A number of ideas are included: * Taproot to make all outputs and cooperative spends indistinguishable from eachother. * Merkle branches to hide the unexecuted branches in scripts. * Schnorr signatures enable wallet software to use key aggregation/thresholds within one input. * Improvements to the signature hashing algorithm (including signing all input amounts). * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support batch validation. * Tagged hashing for domain separation (avoiding issues like CVE-2012-2459 in Merkle trees). * Extensibility through leaf versions, OP_SUCCESS opcodes, and upgradable pubkey types. The BIP drafts can be found here: * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawikispecifies the transaction input spending rules. * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawikispecifies the changes to Script inside such spends. * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawikiis the Schnorr signature proposal that was discussed earlier on this list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html) An initial reference implementation of the consensus changes, plus preliminary construction/signing tests in the Python framework can be found on https://github.com/sipa/bitcoin/commits/taproot. All together, excluding the Schnorr signature module in libsecp256k1, the consensus changes are around 520 LoC. While many other ideas exist, not everything is incorporated. This includes several ideas that can be implemented separately without loss of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT, which we're working on as an independent proposal. The document explains basic wallet operations, such as constructing outputs and signing. However, a wide variety of more complex constructions exist. Standardizing these is useful, but out of scope for now. It is likely also desirable to define extensions to PSBT (BIP174) for interacting with Taproot. That too is not included here. Cheers, -- Pieter
|
|
|
|
|
Show Posts
