Your wife is right to not just accept a more secure claim easily.

I guess the greatest point to make is that the banking system is also heavily dependent on software and involves a lot of use of completely opaque software-- even opaque to the bank itself-- where subtle backdoors could be introduced and fraud could, in theory, be conducted which is indistinguishable from your normal activity, meaning that the banks normal 'fix it after the fact' might not work.   So I don't think it would be correct to say that traditional banking is necessarily in a superior position with respect to the particular attack vector of subtle software backdoors.

Bitcoin is completely open and transparent software updates to it are reviewed by a great many people. We have some evidence that critical intentional errors would be caught on the basis of the less serious accidental errors which have been caught.  Going further, even if a bad version is released, nothing pushes that onto users systems but the users themselves. New versions take a fairly long time to become widely deployed which allows time for additional review and analysis.

You're also right to point out that if there were some catastrophic failure which everyone agreed was a failure the community of Bitcoin users wouldn't just say "oh well, we have to live with it".  Actions external to the system could correct most things, though it's hard to reason about that because it's assuming the system failed and it'll be upto messy human politics to resolve things.

Ultimately I think the best description here would be to say that Bitcoin is differently strong from banks. It has different weaknesses-- it's believed to be more sensitive to software engineering and to end-user security, and it's believed to be less sensitive to political abuse, uncertain economic policy, and various kinds of uncasual fairness.  In practice Bitcoin could be either more or less secure than traditional banks, depending on your own practices and exposures (e.g. if you make large cash transactions you are more exposed to random seizures with banks, if you get malware on your computer you are more exposed to Bitcoin theft); and unpredictable activity going on in the wider world (compare vulnerabilities in Bitcoin software to the cyprus banking haircut).

From the perspective of straight computer security banks generally have awful security, but because they have almost limitless power to seize funds and reverse transactions in practice their security is usually okay. But not always--, the same unlimited seizure and reversal power contributes to many of the awful stories of completely unjustified civil forfeiture (and other kinds of adverse action without due process), or just the huge cost and collateral harm when the bank does make an error give reason to think carefully about how you manage your funds. The traditional banking system also leaves you exposed to monetary policy, where inflation continually devalues your money to the benefit of powerful third parties... Today, Bitcoin has substantial volatility risks and risks related to it being new and niche, but these and other reasons are points that may make it ultimately a productive and widely used tool for society.

Not so. There have been no soft forks related to that yet.
No. It is an intentional and useful feature, without it things like lighthouse would not be possible

Your personal growth and capabilities are not an appropriate subject matter for the development and technical subforum.

I implemented what is effectively 'split routing' for Bitcoin Core some time ago (just a switch that makes it not relay transaction; so an additional utility can getrawtransaction and handle it some other way).  But it's not currently compatible with the conflicted detection in Bitcoin core because the transaction says out of the mempool until its heard over the network and erroneously shows as conflicted, so I've been waiting for that to change.   If someone is interested in working on this in Bitcoin Core, feel free to lemme know and I can point out what needs to be done.  Primary difficulty is just in writing test harnesses and test cases, because this area of the software is under-tested currently so we're not comfortable taking changes without accompanying tests.

It would be straight-forward on top of that to provide a small sidecar daemon that handled your broadcasting for you (including by using fancy things like a high latency mix network).

The first is largely uninteresting (as explained in the linked thread), the second is irrelevant.

Both are off-topic for this subforum, at least in the above armwave and speculate form.

You bumped an old thread about issues that were fixed years ago, please don't do that.   You might want to try memtest86 on your machine, random corruption is usually due to a hardware failure.

That code was written at a time when it wasn't even possible through the user interface to end up with multiple payments to the same scriptpubkey. In the case where you're not reusing addresses existing code is the same as the linkage avoiding code.

Careful with your assumptions about linking, it's estimated that coinjoining is now fairly common, and it totally scrambles the results from that assumption.

Yes, the inputs first had to be coerced to the same size before they could be xored.  (I suppose OP_XOR could have been defined as narrowing instead of widening, but it wasn't).

Nothing about CoinJoin requires the party assembling the transaction to know the input/output mapping.

In the big splashy CoinJoin post I simplified it down a model where there was someone acting like a 'server' that did the join, but I'd described it a year before in a more complex form that had perfect privacy and DOS resistance (though of course privacy is limited to the anonymity set size; though by building a CLOS network it can be arbitrarily large).

I simplified it because no one was picking up and running with the more complex and complete description-- doing so seems to have been a huge success, recent research suggests that coinjoins are now a pretty substantial chunk of the activity on the network.

Indeed you could use a non-private version with multiple stages such that at least one of them is completely trusted by each of the members, but I think the more complete protocols are a better way to get there.

No system for improved privacy is perfect, the important thing is just to make progress.

It was insecure. Pretty much any of the operations which could allocate memory were.

They're handled in a slightly different way than generic unhandled opcodes, so they can't be completely removed (they are tested even when the machine is not executing due to an untaken branch). But they're 99.99% removed, I suppose the labels could be removed too.

They work fine.

2015-03-19 01:40:05 136 addresses found from DNS seeds


Setspecial returns false if the thing being checked is not an onion name and the rest of lookupintern runs normally.

Bitcoin has implemented the single use addresses since the very first version. Actually in the earliest versions is was impossible to reuse addresses  due how the software worked.

Non-reuse of addresses is fundamental to the Bitcoin privacy model as is covered in the Bitcoin whitepaper.  A basic level of privacy is an essential feature of a money like system, few would chose to use a money which made their suppliers and costs open to their customers, their balance open to thieves, and their customer lists and volumes open to competition. The open public ledger needed to prevent double spending is difficult to reconcile with the basic need for privacy, but it can be with pseudonymous identities.

Unfortunately, most implementers of wallet software outside of Bitcoin core and most users of bitcoin are seemingly unaware of this; and many users are basically forced into reusing their identifiers, but this is not something that the reference implementation has ever done.

The page you're citing seems to be misleading you about the history and simply mistaking the low traffic of yesteryear relative to today for a lack of activity. The whole description of "zero balance" is at odds with how the Bitcoin system works at a technical level. (Bitcoin does not have a model of account balances in its design).

An unvalidated getblock was implemented by Luke-JR previously. It didn't meaningfully improve performance. Latency in the system doesn't come from verification because practically all the data is already verified.

The 'transaction index' that you're describing sounds like it would have have more overhead just to relay one chunk than Matt's relaynetwork protocol typically needs to relay a whole block.

Block verification is not needed a DOS protection, indeed, but it's arguably important that the verifying network censor invalid blocks to avoid exposing SPV clients to them who will not be able to verify them in order to maintain strong incentives against producing invalid blocks.

At the other end of the spectrum there are ideas that can give basically perfect parallelism and perfect efficiency relative to already transmitted data, but they're certainly more complex.

Not in any practical sense.

If something was broken that did do that on his system, both execution traces would be the same.

In this case the posts just clearly appeared to be an excuse to encourage people to run backdoored private key generating code (which I've removed from the thread).

Change over time is interesting, e.g.

http://bitcoin.sipa.be/pruning-tx.png

http://bitcoin.sipa.be/pruning-txout.png

http://bitcoin.sipa.be/pruning-size.png

There is no form of additional "broadcast it widely" work beyond the ordinary operations of the network that meaningfully reduces the probability of a double-spend.

This specific question was previously discussed on bitcoin-development in the thread there.

DNS can't simply be used over Tor. What it does is it "connects" to the DNSseed names like they were regular peers and gets addrs from them and disconnects, causing the tor network to do the dns resolution and randomly select endpoints.  It's not great.

There is an open PR on making it use separate tor circuits to reduce the incidence of using the same exit node (but not preventing it: there isn't a way to prevent it without having a very low level interface with tor, AFAIK).  I think we previously got sidetracked with discussion on how to avoid breaking non-tor proxies. (The way you get different circuits for different connections in tor is to send different usernames; which doesn't work so well if you're using a non-tor socks proxy and it won't accept a username). I'll be in the next release in any case.

Progress is progress, perhaps that'll convince the cpu/chipset makers to stop price discriminating on ECC capability. That said-- internal ECC doesn't protect the data on the bus or in a number of failure points along the way, so it's not a complete replacement.

It's also, from what I've seen, not clear how much protection ECC actually provides... all data covered by the protection is in the same domain for row aliasing, and typical protection only provides single error correction; soo...

Ever since the first paper on this subject was published I've been running hosts doing anything important with overspec memory running underclocked, as an additional mitigation. A couple percent performance isn't worth any risk of corruption.

Yep. Just so.

It can't setup a hidden service for itself. We've asked the tor project for some kind of ability to control HS setup from socks and/or the control port and they have a feature request for it (and have for a number of years), but it isn't there yet.

Same reason you need to tell bitcoin what your onion address is: there is no way for Bitcoin to find out on its own... only systems with effective access control (e.g. stock tor install on most Linux distros) it can't even read the relevant files to go find out for itself.

The file doc/tor.md included with Bitcoin Core describes the settings.

Once set up it will do automatic discovery just fine. There is no need to use that fallback node list on the Bitcoin wiki ever.