Of more important note, I think I forgot to mention: There should probably be a single command to cancel all pending jobs ASAP, for use on block changes.
There are different kinds of cancellations however. It's useful to be able to distinguish "really, don't bother, anything more you have queued will be completely worthless, cancel even if its a pipeline flush that loses work" from "I have new work for you to start on as soon as you can without disrupting the pipeline". ... The latter you should be able to call as fast as the communication bus allows without losing hashrate as a result. |
|
|
|
If you put in anonymity Nothing being discussed here is a "put in", this thread is about existing functionality which is fundamental to Bitcoin and has been there since day one, if not widely recognized. while also having the ability to do record keeping, then if there is an incident then Alice has detailed records of all her transactions and what she purchased which she can give to Gordon to prove her innocence. If she does not have this information then she cannot prove her innocence to Gordon and that is an existential danger to Alice. I'm interested in lowering the risk to Alice
I don't think it's even possible to construct a system in the context of Bitcoin that doesn't have a property of permitting strong personal record-keeping. It would certainly be difficult to accomplish, and I don't think anyone currently wants such a system. I agree with you that the ability to keep records is important, and the fact that users can (and should) keep their own private records which could potentially be discovered as part of some lawful process is, in fact, one of the arguments that I give as to why privacy does not have an excessive risk of harm to society. But it is dangerous to privacy, because if dust sent to multiple different addresses is gathered together into one account, that could be taken for evidence that the different addresses are in fact controlled by the same person?
Do I understand the threat right?
The correct solution then for the account holder, is to use the 'dust' and the 'old account' with the same key both as txin for a new transaction, with a single output. There is no harm in letting someone know that the money has not been lost and that its owner is still paying attention, but consolidating the dust together with the account whose key it shares should do no harm to privacy.
Is there any reason why that solution would be the wrong thing for the account holders to do?
You understand the concern there. And your proposed solution is a correct one but for two issues: It doesn't reflect the behavior of current wallet software, and making additional payments in that 1:1 manner takes more space and pays more transaction fees. A third option of just ignoring unsolicited payments, though this would have some long term adverse impacts on the system. |
|
|
|
The original nonce update code: if ((++tmp.block.nNonce & 0x3ffff) == 0)
{
CheckForShutdown(3);
if (tmp.block.nNonce == 0)
break;
if (pindexPrev != pindexBest)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (!fGenerateBitcoins)
break;
tmp.block.nTime = pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
}
An interesting characteristic here is that it only checked for new pindexPrev every 2^18 hashes performed locally. This may have resulted in work with higher least-significant-byte nonces ending up orphaned more often. MakeNewKey() was called at the start of the mining process outer loop, and then the key only saved if a block was found. On this basis, I'd say that anyone using their nonce for deduplication was confused or using very different bitcoin block creation (not just mining) software. Though it would have been very easy to change the starting value and increment. |
|
|
|
|
The nonce uniquing to avoid collisions seems unlikely to me. The blocks are already made unique by paying to different public keys. If nonce-index were the method used to unique a cluster of machines we would have expected to see pubkey reuse, but we do not. It could have both used the LSB and the pubkey, but I don't know why it would. It may have also been rolling the nonce early in order to test the extranonce rolling.
I'd suggest looking at the actual code and see what it does… If the initial release has the same behavior "mystery solved".
|
|
|
|
|
The idea of looking at the nonce to determined endianness wouldn't have occurred to me when you consider how thoroughly little endian the reference Bitcoin software is, it doesn't even come close to running on a BE machine and never has...
As far as the distribution of the lowest byte goes: The counter starts at some value and gets reset when there is a new block or when you exhaust it. If you mine at some constant speed which isn't some large multiple of 2^32/600 hashes per second you would expect your found nonces to be highly non-uniform— not just (most obviously) in the MSB but in all of the bytes.
Not sure if it explains the data there, but thats what I'd look for.
|
|
|
|
What about Namecoin? The .bit domain may be censorship resistant, would the ISPs be able to block transactions by refusing connections if you already have the addresses?
I just recently found out about Namecoin and am quite intreagued by the possibilities of a distributed DNS system.
At the moment, the design of namecoin means that a secure "lite" node resolver is not really possible. So in order to resolve namecoin names you need the whole namecoin blockchain & history. If you ask someone to resolve one for you they can give you a undetectable fake NXDOMAIN or a stale result. This is fixable, along with other challenges... but namecoin isn't getting a ton of active development. (Last I checked it also had a pile of serious vulnerabilities inherited from, and now fixed in, Bitcoin— but they've been working on forward porting the codebase to be v0.8 based). |
|
|
|
or do you maybe trade Bitcoin testnet coins already?  People have, and we've had to reset the testnet multiple times and make some minor changes to undermine the security of it. But even if you do this, someone will just copy the code into FooNinjaRealUltimateCoin... so you can't get what you want there. This has resulted in several occasions of altcoins cropping up 'competing' with Bitcoin by copying code from the Bitcoin core team which was just not mature enough yet to deploy in Bitcoin... greenfields are much easier and faster to deploy into. It's like the Microsoft "Embrace, Extend, Extinguish" business model but supercharged since you can just extend by copying code written by your competition! But hey, if something based on Bitcoin that has ZC is preferred over Bitcoin by the public— then perhaps thats what should happen. The costs of ZC, especially without network-pseudo-interactive cut-and-choose to make the proofs smaller, make this seem unlikely to me. Certainly introducing non-consensus features via an alternative coin is improved in terms of obtaining consent then just merging it in an existing coin. |
|
|
|
|
Bitcoin specific malware is a point and click choice now in malware authoring tools. I do not see much value in anti-malware data entry, especially since it penalizes users from choosing passphrases which are long enough to withstand strong guessing attacks.
|
|
|
|
It's much more efficient to use the merged mining root for this: see https://github.com/goblin/chronobitPetertodd has his own protocol which is like you describe called opentimestamps, but — as you note— the non-uniqness of putting it in transactions has a flooding hazard where something which should be O(1) becomes O(N).  |
|
|
|
Sorry for the confusion. This comment is referring to the timeout mechanism for oracle-based system.
Oh, gotcha. Indeed, oracle based timeout means that prior parties to the transcript can make you waste your time. Though if the horizon of it is set further than some likely lifetime of the coin, it's moot— and mostly serves the reduce the motivations someone might have in shutting down the oracles. "You can kill these things, but if you to all you'll have successfully done is made their users wait a bit then waste some effort." |
|
|
|
|
Are you running debian's package or did you pull bitcoin from git?
If it's debian's package then thats very alarming that they are shipping untested git snapshots.
If you are building it yourself, type "git checkout v0.8.4rc2" and build that. I am _very_ interested in hearing from you about how things are working for you, as we believe there may be problems with a dependency in debian unstable, so please follow up.
|
|
|
|
|
The messages you're quoting existing only in bitcoin's git master, as you can see— it's a little prone to crying wolf and not ready for release yet.
What version of bitcoin are you actually running, where did you get it from, what OS? and can you look for INVALID in your debug log and post the few lines before and after the first instance of that?
|
|
|
|
This will allow any previous owners to DoS the latest owner by forcing him to redeem the coin on the blockchain.
Hm? You'd still have to provide a transcript that shows the coin being directed back to bitcoin via sending it to a special destination. You provide such a transcript to redeem the coin. Someone else can provide a conflicting transcript but only if its of a longer conflicting chain. So you can dos, but only if you're also reorganizing the secondary chain (or at least producing more POW than that chain). |
|
|
|
"network isolation" is exactly the term I want to use. I just find a possible solution to mitigate this problem. For a low value transaction (say 0.1BTC), one may believe it is economically prohibitive to do a certain amount of PoW (say 4000PHash, which should give 250BTC reward if one mines honestly) just to steal it. So the SCIP script will require the tx to be buried by at least 4000PHash of work.
Thought?
Less obvious that it works once the subsidy is small. Proofs of transaction fees in our current protocol are also enormous (every txn in the block, then every txn referenced as an input and tree fragements to connect to potentially thousands of fragments in distinct blocks), but without them I can make fake blocks that appear to have a kajillion in transaction fees. But in general, sure, there is some level of POW which probably provides adequate security for some transaction value. Did you see what I was suggesting with respect to making spends provisional? E.g. you provide a header fragment to redeem, the txout moves to a new txout which is released to you after some span of time— or, alternatively, can be updated by someone else providing a longer conflicting chain of headers. The idea is that rather than you going out to seek the chain's information, some interested party (e.g. real owner of the coin) brings it to the blockchain. |
|
|
|
b) the distinguishability of the coinjoin transaction is equal to its weakest link.
that is, if two people in a coinjoin tx use input addresses that have been reused and can be linked to their identity, then the whole coinjoin tx has been busted.
Interesting point... though it depends on the specifics: Perhaps the transactions linking them to their identities were the CJ ones and the later apparent CJ is just a single person. Don't let me overstate the indistinguishably too much, there are many potential transaction pattern side channels (e.g. from the use of compressed or uncompressed public keys, for example, down to what times of day transactions happen) but at a low level these transactions are not fundamentally unusual. i also wonder whether building a decentralized coinjoin system is as easy as some people here believe it is.
i think it's a good idea to design it and state its threat model before standarizing coinjoin.
otherwise, we will be stuck with the centralized coinjoin variant, where anyone can join the public channels and log the mixes.
I think it's pretty hard, not in the overall components but in all the details. My expectation is that there will be multiple systems for some time, if not forever, offering differing properties and tradeoffs. The harm from the anonymity set reduction that would result from that may be partially addressed by users that use multiple tools, and from them making their transactions look externally indistinguishable. Even in the centralized model think it can be fairly easily arranged so that random non-participating observers can't tell what txins are in flight, e.g. a meeting point host is selected an inputs are only revealed to it. Maaku has also already implemented chaum blinded signatures, so the input-output correspondence can be hidden from the meeting point. I think there are different application and threat models in flight here. For me the most important in the short term are the weakest ones— just getting a non-trivial number of joint transactions in use in order to disrupt the analysis for all users (including ones who've never used CJ) will be a big practical improvement. |
|
|
|
Bitcoin makes _two_ fundamental security assumptions, one of them people talk about all the time: that conspiring badguys don't get control of a near-majority hashpower; the other is that "information [is] easy to spread but hard to stifle": If nodes can't communicate without partitioning they can't come to a consensus, or any consensus they think they have may be false and erased once communication is restored. So in one sense Bitcoin is potentially very vulnerable to censorship. But at the same time: Bitcoin works great without using the public internet at all— at least if you're using the reference software. There is a whole network of hidden service Bitcoin nodes that communicate over tor without using exits. Connecting out to this network is as simple as installing Tor and pointing Bitcoind / Bitcoin-qt's proxy settings at it. Receiving connections in on takes a couple more lines of configuration and is a good idea to do because we can only support a lot of hidden service using nodes if there are a lot of hidden service offering nodes. Tor has been at the anti-censorship game for a while now and has a fair amount of resources to throw at it and there are some benefits to sharing a network with other kinds of usage... I don't think there is any real concern with censorship in most of the world, but I like my backup plans to have backup plans, and so it's good that there is a health hidden service infrastructure in advance of needing one. Since I also like the backups of my backups to have backups: More fundamentally, the blockchain validity rules limit the maximum long term average data rate of Bitcoin to only about 14kbit/sec. Because of this low rate there are lot of steganographic techniques that could be employed to keep hosts connected very surreptitiously ("blockchain over cat pictures"), at least if the user isn't mining and can tolerate fairly high latency (Mining is much more sensitive, however, and to keep latency down needs bandwidth a large multiple of the average rate). Beyond steganography over the internet, the low rate means that we could not-unreasonably broadcast Bitcoin data world wide over relatively inexpensive satellite channels or HF or even VLF radio (well, at least headers over VLF). Perhaps a hardfork changes the block size limits in the future, but at least for now in a censorship war I think Bitcoin would fair very well. So, even though breaking the flow of information breaks Bitcoin fundamentally, our narrow requirements for information and the nature of our communication (broadcats) means that to block Bitcoin, given a community of adaptive users and developers, probably requires blocking damn near everything. I don't consider censorship a critical risk given our current network parameters, but it's something we could be preparing a little better for, especially making sure that big "hash colocation points" and mining pools aren't big censorship targets that are too conspicuous to vanish. |
|
|
|
The logic for that is that you don't want a key added to your wallet without your explicit permission.
No, it's a bug and it's already fixed in git and will be in 0.9. (It's pulling keys from the keypool in any case, after the fix it will only prompt if the keypool becomes empty) I was shocked that it had gone unreported for so long! |
|
|
|
SPV requires a user to monitor the network, look for the longest PoW chain, and verify whether a transaction is adequately buried in the longest chain.
Fair enough. There is ambiguity in what SPV means— e.g. go see what electrum, which does not monitor the network, calls itself or the BitcoinJ clients which get their peers exclusively via DNS. Can you suggest a better name for "SPV with high risk of network isolation"?  It would probably be a good name to have. |
|
|
|
|
You can do this sort of thing with accounts, but its highly inadvisable: there is no live replication for the database, so it's possible for you to fail and lose all the moves since your last backup.
Normally the advice is that for anything serious you should be doing the accounting in your own system and just letting bitcoind notice when payments come in.
|
|
|
|
|
Show Posts
