What AV is this? (as an aside, have you reported the false positives?)

Anything that is actively scanning the leveldb files in real time is going to be very bad for performance.

Yea, VMC has been around for a long time. It set off my scam-dar very very hard, so I stayed clear of it and I expect a lot of people did to. The last drama around december was that they were talking about being ready to ship only to turn around and post that their design partnership feel through and that they were "almost done" with RTL. This turn of events is quite perplexing.

Greetings. I had a much delayed CoinTerra IV show up without prior notice... and while I'd love to add it to my collection— the CT units are awesome on P2Pool— I'm currently out of room.  The unit is new-in-box and located in Mountain View, California.

I'm looking to sell it immediately for USD (in person) or BTC.

It looks like these units-in-hand go for about $8k on ebay, but I'm willing to negotiate. An ideal buyer would be willing to pick it up tomorrow, in person, in mountain view and pay cash, basically minimizing my time in fussing with it.

PM on here or reach me at nick gmaxwell on freenode, or via email at greg<at>xiph.org.

(Also— if any in-person buyers is interested in some historic early batch 1 avalons that mine at about 80GH/s, feel free to inquire. )

I stuffed some AV definitions into the testnet chain years ago and _no one_ has ever reported an AV hit on it. Obviously we can obscure the blockchain from things like that, but so far there appears to be no reason to do so.

Do you actually have evidence of some AV software noticing signatures inside the blockchain files?

AFAICT you don't. Even if it were to occur only a fraction of bitcoin nodes run on windows/mac systems with that kind of nutty AV software, so we could simply deploy an update which obfuscated the block files if it ever were an issue. You should take more care with your claims of doom, chicken little.

As far as anyone yet knows our parameters were not selected by "The NSA".  In any case, choice of the generator was discussed extensively. The most we could come up with is that perhaps someone could convince you that a particular pubkey was a 'nothing up my sleeve' pubkey when it really wasn't.

Any payouts would need to be discussed with the other signers, but my thinking had been to pay most of it to to the most substantive complete and usable implementation, and partial amounts to smaller efforts (e.g. people who built toy tools and things only a developer could love).  I had also planned on doing the payout itself as a coinjoin, and using a small bit of the funds to pay people to join into the coinjoin.

They note in the paper that it's possible to do the dealing step in a distributed manner where no one party learns the key (indeed, the proposed protocol does something like that internally for sharing shares of the ECDSA nonce) but they don't go into detail about it. I think any practical implementation would want to do this simply due to the difficulty in obtaining a single device whos security you can be confident of...

The differences I'd make between this and multisig is that it requires a synchronous protocol to both establish keys initially (assuming a distributed dealer) and to sign.  E.g. it might be harder to make a signature using N offline wallets as you'd have to shuttle data back and forth to the offline wallets multiple times. It's also harder to 'show' that an address is multisig— e.g. for the purpose of making your policy public, though I'm not sure how much this matters since you can 'fake' multisig too. It also requires a more complex signer software. On the plus side it's much more efficient in the blockchain, esp with high N, and the transactions are indistinguishable from non-multisig which is good for privacy.

BC.i is just broken, yet again.

This is a _bitcoin_ subforum, it's not a subform for altcoin stuff.  This is already the established practice, and I think it's already unambiguous.

TX_3 is created and announced by Carol.  Alice can't collect TX_3's output without making X public (as TX_3 requires X to be in the signature). The TX_0_Refund is nlocked for the future: "TX_0_refund must have a further future locktime than TX_1_refund. Otherwise Bob can delay step (I.) in the protocol until the refunds become valid and then announce TX_3 while Alice announces TX_0_refund in order to try to cause Alice to get refunded while Bob still gets paid."  (I believe thats describing what you're thinking about there)

Alice does, and it's perfectly fine that alice knows it first.  It might help you to try to describe the attack you're feeling might be there in concrete terms.

I expect that an LCD display would see only fairly modest use, after spending many years working for an network equipment maker that shipped LCDs on its products I can only think of a couple incidents where I'm aware that it was actually useful beyond displaying the device name— but a network triggerable "identify unit" light would be insanely useful (along with lights for power and 'actively mining', of course).  I think, in general, most people would prefer more cost optimization over a fancier display. If an LCD doesn't make it on, I hope at least a set of indicator LEDs does.

The original post claims to contain a signed message by a third party auditor who is independent from Kraken, rather than any cryptographic proof. (As an aside: I am unable to verify the author of the message because the PGP key is not obviously connected to the strong set or signed by any key I directly recognize. I am also unable to verify the Independence of the auditor.)

I am unclear as to why this is being described as a "Cryptographically Verifiable Proof of (100%) Reserves" since the security of the audit ultimately rests on the honesty, integrity, and computer security of the auditor (while operating from inside Kraken's offices) and not cryptography.  The audit is also apparently not complete: until a non-trivial portion of customers "verify using open-source tools that your balance at the time of the audit is part of this root hash". I am unable to find instructions for customers to perform this step.

TX_0's output is a 2-of-2 multisignature output. It can't be spent unilaterally, the other user must sign it too. Does that answer your question?

As you say— they were probably solves for the same height. What do you expect it to do with them?  It should discard them.

Here is self-modifying code: http://eprint.iacr.org/2013/879

The class of techniques is universal up to the parametrized runtime limit, as you note— while that technically makes it non-universal— well, in a finite universe everything has a finite tape .
I'm told electrum now connects to multiple servers, which helps. Some of the things I was discussing here is SPV but counts on other people to go out and find and get mined the evidence of a longer chain, maybe arguably in-better.  SPV could— in theory— be boosted to full security compactly if you were able to have SNARKs for block validity as the block headers could carry proofs that they were a result of validating a faithful history though the engineering gap to verify such large computations is pretty big.

Somewhat relevant on the subject of the SPV tying of external systems is the abstract I submitted to an upcoming bitcoin workshop (and the citations it includes): http://0bin.net/paste/vkc4NWr3BeXwgO6O#TzYCxardJ3U4lkQAoP8mv+/nDJWZZk6TZeWKrMQ1Gcc=

Even if it were the case that there was some extreme chip excess and diverting the supply did nothing to delay your orders those chips showing up on the network is adverse to your interest— because it raises the difficulty ahead of you and reduces your income (for the products you haven't received yet as well as any miners you're already running).
 

Almost three days later after the original post, should someone call emergency response to wake Mr. Kinevel from his slumber?

Sure, and you can have that— conflict it with an alternative spend and then it cannot happen.

I now have a tracking number for the review/test unit being sent to me and it looks like it's on its way.