 Show Posts
|
|
Pages: [1] 2 »
|
|
If the private key is recoverable through reused R values, then all keys and addresses in that account is vulnerable.
|
|
|
|
Did you wipe your previous DB before building with 0.90.99.5? Not yet, will try. |
|
|
|
|
The generic term is Secure Multiparty Computation (usually abbrevated as MPC). I've been thinking of doing all kinds of round-based games this way together with Bitcoin and optionally with anonymizing networks like I2P. All kinds of cools things could be done this way, including reputation tracking and setting up tournaments. If done right it could practically be cheat proof. (It would however be harder to verify that somebody with 1000 wins haven't been playing against his own 1000 fake accounts.)
|
|
|
|
I've got an idea for how to use notaries and P2SH addresses with multisignature transactions to make zero-confirmations transactions secure for merchants. The full text is here: http://roamingaroundatrandom.wordpress.com/2013/11/30/bitcoin-idea-temporary-notarized-wallets-secure-zero-confirmation-payments-using-temporary-notarized-p2sh-multisignature-wallets/1The thread on Reddit: http://www.reddit.com/r/Bitcoin/comments/1rsg78/bitcoin_idea_temporary_notarized_wallets_secure/The TL:DR (kind of); Using the scripts feature and pay-to-script-hash addresses, you create an address that for the first 24 hours only allow you to spend if a notary sign your transaction. Notaries have no incentive to enable a doublespend since it would be discovered nearly instantly and can be easily proven causing a total loss of trust. A merchant that trust the notary in use can accept transactions from these addresses with zero confirmations if there's about an hour or more left of the time window for notarization requirement, as they can be confident that no doublespend transactions will be accepted by the network as it won't have a valid signature, so they can be confident that the notarized transaction with the payment to them will be confirmed in the blockchain long before the buyer has any chance of making a doublespend transaction. After 24h there's no longer any notary signature requirement, so if the notary shuts down your money isn't lost. |
|
|
|
|
You should add Shamir's Secure Sharing Scheme support for additional security AND loss/destruction prevention.
|
|
|
|
Sarchar: That can be added easily. You could simply rent out storage space.
To whom? Who's responsible for fulfilling the payments? How do you fairly get paid for that storage? Your node offers storage space for a price. Clients pay. You store the files. You can integrate proof of storage and more and use Bitcoin's scripts to make sure neither side is at a significant risk of getting screwed over. It's not like it can't mimic most of the features of Bitstorage. |
|
|
|
|
Sarchar: That can be added easily. You could simply rent out storage space.
|
|
|
|
Please look up Tahoe-LAFS, and how it can be used with I2P! Tahoe-LAFS is developed by experienced computer scientists and cryptography experts. I2P is an anonymization network. The combination is a far more flexible and advanced decentralized storage system than Freenet, and is under active development with flexible access control features. https://www.i2p2.de and https://tahoe-lafs.org |
|
|
|
It isn't certain that you'd be able to tell WHICH input that the attacker used, at least not with my scheme where you hide who's using what input. Revealing who's using what input might not be optimal if a user want to use inputs already tied to himself AND some inputs that aren't already, and doesn't want the unlinked ones to become linked to him.
Send all inputs to one key first. I don't see how that solves anything. You just openly linked your own inputs together yourself, then. Someone previously proposed using Secure Multiparty Computing before to implement CJ, but one must realise that SMC is only a set of tools. E.Z.Yang proposed one specific implementation using sorting, which is a cool idea, but according to Yang himself is currently not feasible in practice. In his own words, "The big obstacle is that secure multiparty sorting is somewhat difficult to implement with large keys (since integer comparison operations tend to only handle a few bits at a time)." The hunt is still on to find an efficient way to use SMC to solve the problem.
I am quite excited that people are working on making this work and will be trying the programs proposed here when I can.
General SMC/MPC (myself I usually abbreviate it as SMPC) does exist. But it seems to be less efficient than specific ones like for sorting. I am eagerly waiting for efficient general SMPC to become usable for average joes.  |
|
|
|
|
Why have servers at all? With I2P it would also be really easy to use DHT to set things up. Instead of a unique URL you could have a unique random string of any kind. Or even fully random peer selection.
|
|
|
|
|
Backdoor covenant - Normally like a regular coin, but an arbitary payload can be attached to it at any point in time through a transaction by the creator of the covenant. When spending it, there's a check for the lastest signed payload for it in the blockchain, and that is then executed.
Viral Proof-of-Work-Verified Payload Backdoor Covenant - Like the above, but here you are required to attach the covenant to another coin when spending this one, and *anybody* can attach a payload to it through proof-of-work, where the payload with the computationally hardest proof-of-work generated so far is the one who is executed when you spend the coin. The proof-of-work is of course individual for each instance of the VPoWVPBC.
|
|
|
|
The risk of DoS in many of these cases could make the entire scheme unusable for as long as it's decentralized, as you can't really effectively ban the attacker. If the attacker can run 20x as many fake nodes as there are real nodes and abuse the scheme to only spend a trivial amount of computing power and bandwidth, while making the real users waste lots of it, then the system is trivially rendered unusable. Just throw a botnet at it and it's dead. That's why I'm thinking hard on DoS prevention. Edit: Also, regarding change addresses: You should split up your change in several parts. If everybody does that and thus generally also refers to multiple inputs for the transaction as a result, then correlation based on the BTC sums is much harder. Edit: https://bitcointalk.org/index.php?topic=12751.msg315793#msg3157931 - So somebody else had the same basic idea over 2 years ago. Although my version (who originally was almost identical to his) now accounts for various types of possible attacks. |
|
|
|
|
It isn't certain that you'd be able to tell WHICH input that the attacker used, at least not with my scheme where you hide who's using what input. Revealing who's using what input might not be optimal if a user want to use inputs already tied to himself AND some inputs that aren't already, and doesn't want the unlinked ones to become linked to him.
Also, it's hard to convince other that the attacker maliciously broke the scheme where none of the participants has any long-term pseudonym, thus it's hard to blacklist that one input. Also, a single input can STILL be used many times simultaneously, even if not many times in a row.
I don't have enough experience with programming, and absolutely not of crypto implementations, to be able to make a proper proof-of-concept of this, sorry. I'm hoping that somebody else *who does* will find this interesting enough to implement.
So far I'm thinking that my two-round version SMPC scheme with initial PoW before starting SMPC would be pretty decent, where you'd remember which pseudonyms that mixing has worked with in the past. Participants that don't supply PoW is ignored, and to stop a sybil attack where many nodes don't do PoW to try to make you calculate PoW for nothing you'd connect to multiple dozens of random nodes at once.
Edit: If the SMPC was given bad inputs, it would also reveal who it was that gave it the bad inputs (if it were to finish, but giving bad inputs + interupting the SMPC is just wasteful from an attacker's point of view).
And by the way, I'm one of those who wants the system to be as solid as possible in advance. Nobody deploys bad encryption algorithms and try to patch the algorithm as flaws is found. Not that I think that the other suggestions is bad, but I don't want people to get screwed over because somebody forgot to consider a simple attack that a little bit more analysis would have revealed and maybe shown how to stop.
|
|
|
|
|
Ok, so coin age would be your DoS countermeasure?
Note that attackers don't actually have to spend that input if they disrupt the protocol. They can use the same one over and over, even many times simultaneously.
PoW could be an option where participants can set a minimum PoW accepted and a maximum PoW they're themselves willing to perform. So for example if 10 people all have 2^15 work within their range of acceptable PoW (one has 2^15 as their lowest, another as their highest, they'll all generate a common input for PoW and start working on it. Then they start this scheme with the SMPC. That would indeed make the attack costly for somebody trying to break the scheme for as many as possible (DoS) and would make Sybil very costly.
|
|
|
|
using the input coin itself as the identity I don't see how that would help countering DoS, you won't likely be reusing inputs so there can't be reputation tracking. A specialized for doing a meet in the middle auction (e.g. a few comparison operations and an arithmetic average) is a whole other of magnitude less complex than running a complete transaction processing program in it. Going and figuring out where the state of the art is in that space has been on my todo list. It was a bit more than that IIRC. It was highest bid wins, with winner paying the price set by the second highest bid, and it was NOT just two or three participants, it was a LARGE auction. A very large amount of offered goods and bids. Besides for risk of sybil+correlation attacks (which can be partially countered through reputation tracking), I like my SMPC scheme. |
|
|
|
|
