In short, If this material is supposed to be some of a devastating leak, it was a complete air-ball IMHO.
Looks like his computer was compromised, including his PGP key; those are all private emails. In two instances people have tried to use webbugs on this forum, as well as the foundation forum, in discussions about blacklists - I took that as a sign that people are resorting to some pretty ugly tactics. This just confirmed my suspicions. John had expressed concerns to me about the safety of himself and his family, which I guess I might as well quote given it is one of the leaked emails: Just so you know this stuff about Tor has me worried... Please don't make this
public, but my day job involves intelligence, and I'm in a relatively high
position. You know, I went into the job years ago with very different thoughts
about it than I do now. The last, well, decade really has changed a lot of
minds in this field, in totally different ways. Myself I am on the side of
Snowden and Assange, but... lets just say when you have a family your
willingness to be a martyr diminishes. The same is true of many of my
colleagues. Hopefully my support for Bitcoin can help undo some of the damage
we've done, but I do have to be careful and it's tough to take all the
precautions I need to to be able to communicate. If it was found out that I was
involved with Bitcoin that way I have been, let's just say there would be
consequences...
So who knows, maybe this is more to do with him than anything else. Regardless I'm taking it as a sign that we need to be more careful about our computer security - though I dunno, I always had the impression that John was a very smart man who understood crypto and computer security well, yet he still got hacked. |
|
|
|
This isn't even remotely close to being true. Miners do not vote on rule changes.
One of the recent videos Vessenes in one of his public talks said people should mine because it allows them to vote on protocol changes. Vessenes is correct in practice, and somewhat correct in theory. SPV clients, which many expect the majority of Bitcoin users will use, do no validation of transactions, leaving the protocol rules up to miners to decide by majority vote. In practice even users of full clients can be forced to follow whatever protocol rules miners decide upon, because without a majority of miners the blockchain isn't secure. Now would the people with mining hardware make a protocol change that the economic majority were opposed too? If they did, what would happen? We don't really know - that's a political, sociological and economic question, not a technical question. |
|
|
|
I can very well understand Luke's motivation for publishing and implementing this patch as a counterweight to CoinInvalidation and similar awfulness. Admittedly, my poor brain hasn't had time to sort through all the pros and cons here. But: Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable.
Er, not so. If you're arguing from the standpoint of a profit-driven business in a competitive landscape or from the standpoint of an individual burdened by increasingly pervasive financial surveillance, you're right, but those are not the only use cases for a currency. There are lots of people around the world continuously pushing for more and more transparency in government finance, the logical endpoint of which is real-time, globally-visible transactions records for state treasury accounts. Most inputs (taxes, fines, fees, etc.) blinded for privacy reasons, and most outputs (salaries, goods, services, etc., but not, for example, welfare payments) required to be explicitly linked to an identity, for transparency and accountability purposes. Want to work for the state or one of its corporate appendages/owners? Be transparent and accountable. The non-profit sector, and donors to it, would also benefit from such radical transparency. Charities that can prove that they're not blowing donor funds on exorbitant executive pay, corporate jets, fancy hotels and catering, for example, and are actually delivering real benefits to people in need (or at least working diligently toward what they've promised to donors), globally visible (at least up to the fiat interface or the real-world-goods/services interface), supplant and, er, out-compete, those which waste so much on overheads. For them and for donors, globally visible public records are a desirable feature, at least for the ones that survive the transition to a cryptocoin economy. As another example, I operate a Bitcoin legal defense fund for the accused Dread Pirate Roberts (link in my sig). The transaction record to the fund's sole address shows that I've disbursed nothing of what's been given, and it needs to stay that way until I can properly justify an expenditure. All of these models, and others, can benefit from reusing addresses tied to individual and/or institutional identity, and address re-use carries a massive benefit in simplicity ("donate here" QR codes on paper flyers? yes we can!), despite the known drawbacks. Deprioritizing or (especially!) filtering transactions seems to raise the costs for implementing such models, significantly. (At another level, all of this sums down to mining pool centralization as systemic risk, but that's another discussion entirely.) I what's important to remember is what Luke is doing with Eligius is a: just a one block delay, and b: can be easily changed later. Right now we have a serious problem with address re-use - doing what we can to stop it makes a lot of sense even if what we do isn't necessarily the perfect solution. Even if reusing addresses was 100% banned and it was impossible to re-use an address ever, with appropriate tools all those examples of transparency that you cite would still be possible using BIP32: rather than achieve transparency by publishing the address, publish a BIP32 pubkey seed and derive all the addresses where funds are stored from it. In many cases this is an even better solution, because you now have the option to be selective about who you are transparent too. On the other hand if you truly are trying to be globally transparent re-using a single fixed address has an advantage over the BIP32 option: it lets other people know that your transactions are not anonymous. If I receive funds in a transaction where the change address is the same as the address the funds were originally at, I know the funds I've received are not as anonymous as they could be, and I might want to take steps in response. But again, in this case a minor one-block delay does no real harm. tl;dr: I fully support what Luke is doing in the here and now, and we can and should monitor the situation to determine if the strategy needs to be changed in the future. |
|
|
|
I am to the point where I would take a serious look at a codebase released from a group of people I trust to evolve the protocol in a healthy direction which rectifies some of the deficiencies. gmaxwell, retep, and adam3us come to mind.
Ideally releases from the more desirable codebase would track and inter-operate with releases blessed by the Bitcoin Foundation. Until they didn't.
You already have a codebase released from that group, the one at http://github.com/bitcoin/bitcoinIf it is changed in a way that is seriously objectionable, as opposed to minor disagreements about engineering tradeoffs, believe me, you will see alternative releases from myself and many others pop up. |
|
|
|
Does anyone have any idea why that would be happening?
EDIT: The commenter just posted the Mt Gox error: "This address is not on the right network"
Armory and Mt Gox, and all bitcoinj-derived wallets, don't support P2SH addresses yet. Electrum does support P2SH, and so does Bitcoin-QT. P2SH was added about two years ago - about time wallets upgrade... |
|
|
|
Game theory wise that is one of the reasons I think for users it is better to have the fee fixed (or as low as we can go)
We could get into a situation where people start rewarding miners (by increasing their fees) for NOT including transactions. All users lose if we have to pay to 'jump ahead in the queue'.
Read the analysis that Michael Gronager and myself have been doing on optimal block sizes: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03209.htmlhttp://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03230.htmlIncluding transactions in blocks absolute does have a cost to miners due to orphans, and that cost is based on the hashing power of the miner and the time it takes for blocks to propagate around the network. Michael has derived a rough estimate that the 0.1mBTC/KB fee assumed by many wallets is something like ~8-4 times too small to be profitable. What's interesting about the analysis is how the cost is in terms of Bitcoins, not dollars, because the inflation subsidy is huge right now. (~$30 USD/tx) In any case, fixed fees just won't work. First of all because it's a competitive market, and secondly because if you set them too low miners have no incentive to include transactions at all. |
|
|
|
Fantastic idea. I hadn't even thought of using coinjoin for cleaning up dust. I'll have to do modification to the code base to support SIGHASH_ANYONECAN pay, but it'll be worth it. I wanted to implement the other SIGHASH types anyway.
Thanks! I'm not sure that a central server is in fact the right approach - might be better to just broadcast tx fragments spending each individual txin one at a time - but regardless the SIGHASH_ANYONECAN will useful for other stuff too so it'd be effort well spent. |
|
|
|
The following is a dump of full HTML files (identifying parts removed) of private Bitcoin Foundation discussions on Bitcoin blacklisting, transaction reversing, and create a new proof of work called "proof of sacrifice" for asset forfeiture.
Proof-of-sacrifice has nothing to do with asset forfeiture. It's an idea I came up with last year, which was subsequently developed further by myself and Mike Hearn among others for various applications. It's just a way of making a (potentially) anonymous crypto-identity expensive to obtain, which is useful for things like controlling spam on (pseudo-)anonymous discussion forums or making it possible to have anonymous financial services. For instance BitMessage could have used it in favor of direct proof-of-work. OP: Please correct your post. |
|
|
|
I must remark that I am very concerned that we do not introduce further incentives for miners to spam the network with transactions carrying fees in order to increase their own profits at the expense of everyone else. One important metric for the health of the network is the number of zero-fee transactions in blocks.
I haven't had time to read your proposal in detail, but why not make the tie-breaking rule be to favor the block with the least fee-paying transactions? That's what aligns with miner's rational self-interest to have fee-paying transactions available for them to mine. Of course, both versions can be somewhat gamed by miners accepting out-of-band fee payment. |
|
|
|
Thanks D&T, I think we'll start investigating and detailing what it means to do merged mining for Mastercoin.
Merge mining Mastercoin is an awful idea and will make Mastercoin significantly less secure. Unfortunately merge mining just means that attacking your chain becomes something miners can do for free - unless you have a majority of hashing power merge-mining your chain you are not safe. I strongly recommend that Mastercoin stick with the current, secure, design. |
|
|
|
|
+1 Very clever.
And fighting crime aside, remember that without financial privacy, you're giving every single person you pay information that invites crime, such as how many Bitcoins they can take from you by force.
|
|
|
|
|
People need to understand that blacklists fundamentally damage privacy, and decentralization. The only way to achieve even moderate financial privacy in Bitcoin is to mix and swap your coins with others with protocols like CoinJoin and CoinSwap. Those protocols can't work if blacklists are common and people can't risk accidentally mixing their coins with tainted and blacklisted coins; remember that a coin can and will be blacklisted after the fact and you may be the one left holding the bag.
Blacklists and whitelists are inherently sources of centralization: some of them will get the official approval of regulators in your jurisdiction, and the way laws are written guarantees that you will be forced to use those approved lists.
We as a community need to ensure that privacy technologies like CoinJoin are deployed ASAP to ensure that the basic Bitcoin infrastructure and the fundemental way wallets work makes blacklists useless. If we don't do this before people like Yifu Guo and Mike Hearn get their way, we risk losing our chance to deploy this technology, and losing the privacy and fungibility of our Bitcoins.
|
|
|
|
As far as the ability to bump an existing transaction there have been two approaches, ... "parent pays for child" and "replace by fee", however neither is targeted for inclusion in any specific upcoming release.
Are either of these closer to implementation? Here is the status of my work on tx replacement: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03126.htmlThat particular version is the "zeroconf safe" version that only lets you replace a transaction if all outputs are paid in the replacement with equal or greater value. I also wrote a pure replace-by-fee version months ago. What's left to be done is the hard and risky work of fixing the wallet code. Note that John Dillon has offered 4BTC to whomever gets it done - if anyone wants to take on the wallet side of things it'd fix some outstanding issues and I think the effort would deserve 95% of the funds. |
|
|
|
|
I work as an electronics designer and I can tell you getting PCB's made is dead easy and cheap these days. There's lots of really cheap PCB manufacturers are out there with turn-key service for incredibly low prices - I routinely do projects where the one-off PCB is one of the cheapest parts even though it's custom and I'm only buying 2-3 of them. Good Bitcoin ASICs shouldn't need much routing, so you could probably even get away with 2 layer boards, and these days 4 layer isn't such a big deal. (which it doesn't look like that printer can do anyway)
The other issue is that for an ASIC implementation, indeed almost any serious circuit, having your PCB made out of a "conductive" 3d printed material just isn't good enough - you need real copper. Again, this is especially important for ASIC designs where you want actual copper to both get current into the chips efficiently, and conduct heat away.
Having said that if someone can add that conductive material to a fully 3d printer there's some really interesting uses for 3d circuits to solve all kinds of packaging problems; last I checked those applications are still being held back by the stupidly high cost of prototyping them. (it also doesn't help that the CAD tools are immature and expensive)
|
|
|
|
This is extremely saddening to hear and utterly destroys many of the cool things "smart contracts" promised.
So this will never be a feature in Bitcoin?
If you're thinking of the 'Contracts' page on the wiki, almost none of them use tx-replacement, and the ones that did were insecure because tx replacement is just another type of zero-conf transaction. For micropayments specifically a much better and secure mechanism that doesn't use tx-replacement was developed and is what bitcoinj implements. Note that nLockTime'd transactions are only non-standard until the locktime expires, at which point they can be broadcast and mined normally. Frankly nSequence-based replacement shows that Satoshi was human just like the rest of us... it's an awful mechanism that just can't be made secure and opens up DoS attacks if you try. |
|
|
|
Ummmm... isn't this attack protected by the fact that people are encouraged to use one of the "official" bitcoin clients and not a modified client which allows the bad nodes to get together and exploit the network in some way? Inviting people to use a purposely malicious client is ridiculous and proves nothing because the security of Bitcoin is based on the assumption that the majority of nodes are going to be running good clients.
Yup. Just like how as a Canadian I leave my keys in my unlocked car and protect it with a post-it note saying: "WARNING! If you steal this car I will politely ask you to apologize!" |
|
|
|
I've been arguing for ages that miners don't have an incentive to broadcast their blocks to more than 50% of the hashing power; seems that my initial analysis was wrong and the threshold is actually only 29.3%: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.htmlThink you could add this to your simulator? Simplest version is to just create a single miner with, say 35% of the hashing power and see if they get more blocks than the others. (per unit hashing power) If that proves true, we can try simulating this by failing to relay blocks, large blocks etc. |
|
|
|
The high-frequency-trading industry begs to differ.
The high frequency trading industry operates within a few mile radius, because what they do is sensitive to speed-of-light delays. That doesn't work as effectively when mining is spread out all over the globe. Wrong: the high-frequency-trading industry is building dedicated low-latency networks all around the globe, using the minimum distance routes possible to run dedicated oceanic fiber lines for the industry. They're even making use of point-to-point microwave and laser connections because the speed of light in glass fiber is significantly slower than the speed of light in air. They're also making use of oceanic datacenters to reduce latencies when trading between two points; currently only in existing oil rigs and similar facilities, but there are plans for purpose built facilities as well. I pointed out on IRC how anyone who already had access to such a network would be able to also use it for Bitcoin mining for little additional cost given the low overall bandwidth requirements of mining - implementing the selfish mining protocol and using it for actual mining for profit would be an excellent training exercise for a junior team that needed real world experience, with real but affordable consequences, prior to being set loose on the full-scale trading environment where mistakes can be disastrous. |
|
|
|
The interesting points of this solution are to minimize the advantage of the low latency connection of the selfish miner. When the part of a block that must be rapidly broadcast is reduced to less than 100 bytes (regardless of the actual size of the block), propagation times are going to be so low that selfish miner will have a more difficult time responding in time to pull off the attack. The high-frequency-trading industry begs to differ. |
|
|
|
|
Show Posts
