Bitcoin Forum
January 22, 2022, 09:11:27 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Electrum / Re: Reused R values on: December 23, 2014, 05:17:18 PM
If the private key is recoverable through reused R values, then all keys and addresses in that account is vulnerable.
2  Bitcoin / Bitcoin Discussion / Re: 1,000,000 bits = 1 bitcoin. Future-proofing Bitcoin for common usage? VOTE on: May 02, 2014, 04:50:31 PM
xbit

Because the sourceforge mailing list archive seems broken:

https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04918.html
3  Bitcoin / Development & Technical Discussion / Re: [BOUNTY] Help test next major release of Armory! [0.01 BTC per bug!] on: April 03, 2014, 01:17:15 AM
Another 99% crash.

http://imgur.com/XdpxWRy

Did you wipe your previous DB before building with 0.90.99.5?

Not yet, will try.
4  Bitcoin / Development & Technical Discussion / Re: [BOUNTY] Help test next major release of Armory! [0.01 BTC per bug!] on: April 01, 2014, 11:28:48 PM
Another 99% crash.

http://imgur.com/XdpxWRy
5  Bitcoin / Project Development / Re: Distributed/Decentralized Poker Proposal on: December 09, 2013, 10:03:52 AM
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.)
6  Bitcoin / Development & Technical Discussion / Re: New paper: Accelerating Bitcoin's Trasaction Processing on: December 06, 2013, 05:34:42 PM
Are anybody interested in a notary based system with temporary pay-to-script-hash wallets (P2SH) using multisig transactions?

My scheme requires no Bitcoin protocol change, and requires very limited trust in notaries which can be replaced quickly and where malice is easy to prove (just show two conflicting transactions that both got signed, these can be distributed globally in seconds to everybody that has set their clients to trust that notary). This means that notaries has practically nothing at all to gain on an attack, and still makes 0-confirmation transactions trustable.

http://roamingaroundatrandom.wordpress.com/2013/11/30/bitcoin-idea-temporary-notarized-wallets-secure-zero-confirmation-payments-using-temporary-notarized-p2sh-multisignature-wallets/
7  Bitcoin / Development & Technical Discussion / Secure zero-confirmations payments w/ 24h notarized P2SH multisignature wallets on: November 30, 2013, 10:35:58 PM
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/1

The 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.
8  Bitcoin / Project Development / Re: [ANN] Next-gen Brainwallets : Multisignature P2SH in the browser on: November 30, 2013, 10:15:40 PM
You should add Shamir's Secure Sharing Scheme support for additional security AND loss/destruction prevention.
9  Bitcoin / Project Development / Re: Project OtherCoin - off-chain payment system using tamperproof chips on: November 30, 2013, 10:06:08 PM
The technical part of it sounds a lot like my idea about a generic crypto device that I've written about before. Although I want it to have a screen and input of it's own. Posted it on reddit on /r/crypto and /r/netsec, but can't find a link...

Edit: found it: http://www.reddit.com/r/crypto/comments/yjxdo/device_concept_universal_personal_cryptography/
10  Bitcoin / Project Development / Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network on: November 27, 2013, 05:43:37 PM
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.
11  Bitcoin / Project Development / Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network on: November 27, 2013, 05:09:52 PM
Sarchar: That can be added easily. You could simply rent out storage space.
12  Bitcoin / Project Development / Re: [ANNOUNCE] Whitepaper for Bitstorage - a peer to peer, cloud storage network on: November 27, 2013, 04:53:47 PM
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
13  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: September 09, 2013, 11:55:09 PM
There's actually an efficient MPC protocol now that appears to be as secure as my scheme requires! (Which I personally use to call SMPC = *secure* multiparty computation)

http://phys.org/news/2013-09-breakthrough-cryptography-result.html - also links to it's paper

Hopefully it will be released as open source as well.
14  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: September 01, 2013, 09:15:35 PM
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. Smiley
15  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 28, 2013, 12:04:47 AM
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.
16  Bitcoin / Development & Technical Discussion / Re: CoinCovenants using SCIP signatures, an amusingly bad idea. on: August 27, 2013, 12:04:32 AM
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.
17  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 26, 2013, 10:31:53 PM
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.
18  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 26, 2013, 09:28:18 PM
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.
19  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 26, 2013, 09:10:34 PM
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.
20  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: August 26, 2013, 08:51:54 PM
Quote
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.

Quote
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.
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!