Topic: MAVE: Digital Signature Protocol for Massive bulk verifications (Read 3984 times)

Another "Troll" here:

On the minus side of the ledger, Gavin omitted to mention the X.509 privacy-destroying functionality for the unaware that has been implemented as the default behavior of the "payment protocol" in 0.9 clients.

To get a better sense of the worldwide fallout that has occurred at a real economic level to companies in Silicon Valley as a result of the NSA's and gov'ts desire to "track" everything, watch this video from 2 days ago:

http://blogs.vmware.com/vmware/tag/melissa-lee

I think the conclusions can be extrapolated to Bitcoin.

Edit : watch the first panel discussion with Andreesen.

The definition of a  true money is that's its widely accepted and is a unit of account. For the latter to happen, we have to think in Bitcoin and the former must happen. The former can't happen until or unless even the black markets can privately accept Bitcoin, as they are markets that exist in the trillions of USD. Note that I already believe that Bitcoin has become a medium of exchange and a store of value.

Note that the US gov't understands this principle completely otherwise they'd be working to ban the USD for all the problems it causes in money laundering, drugs, child porn, and terrorism.

If Gavin wants Bitcoin to expand to the tune of tens of thousands transactions per second, it won't happen without privacy as even no corporation or consumer wants their private finances monitored, let alone entities in the black markets.

I haven't asked any questions.

marcus_of_augustus asked one, and Kristov Atlas asked another.

I'll break my "don't feed the trolls" rule:

You need two things to get private bitcoin transactions:

1) An anonymous connection to the Internet.  Bitcoin Core does a good job of this, working nicely through Tor and/or as a hidden service (thanks to Pieter Wuille for writing that code).

2) A privacy-aware wallet.

The Bitcoin Core wallet needs to be completely rewritten, not just for privacy but to get rid of the Berkeley DB dependency, implement HD keys, implement multisig, CoinJoin, etc etc etc....

Nobody has stepped up to do that, so it hasn't happened; in fact, we are going in the opposite direction, moving wallet functionality out of Core (and we might eventually drop wallet functionality entirely to concentrate on transaction validation and blockchain handling).

Why do you ask?

Marcus is right.

Two years later, Gavin still won't answer this question:

https://twitter.com/anonymouscoin/status/471177928097554433

https://twitter.com/anonymouscoin/status/471748516323528705

As far as singular transactions go, one on one you are right, it is the right and moral thing to do, but the overall effect on the currency system itself will ultimately be fatal. I. e, how many transaction steps down the chain do you think it is appropriate to re-integrate tainted coins? You cannot hold every person who uses those coins from then on responsible for the sins of the the previous users of the coins. After a certain number of transaction cycles, any digital token system that has endless tracing trails will end up with money that was at any point involved in "illegal activities" contaminating the whole system, locking it up. Much like we are witnessing with the current central bank fiat digital chits that have recently implemented detailed tracking maybe?

In the end, money is an information technology and like any other technology, amoral, bitcoin cannot be held responsible for the activities of the users of the technology. In my opinion, it is not a function of the money to know if it has been involved in "illegal activities", you obviously disagree. But it is well known that good money is fungible and you would be going against all evidence to the contrary to implement successfully something that wasn't. The free market will decide as soon as we get a truly anonymous (digitally fungible) competitor unit into the marketplace, it maybe a spectrum of anonymity is acceptable and it comes at a range of pricing as Segio is suggesting.

Out of interest, given the choice and all others things being equal, which would you rather hold a pseudo-anonymous digital currency or a totally anonymous currency?

Of course fungibility is important.

But fungibility isn't all-or-nothing, and, in my humble opinion, it isn't all-important. Refusing to accept dollar bills or bitcoins that you believe were obtained illegally makes them less fungible, but so what?  It's the right thing to do.

I'm inclined to disagree. Anonymity, in the context of money, is strongly correlated to fungibility, e.g. "I don't want those dirty coins from XYZ terrorists, pornographers, bogey-man, etc." Already Mt. Gox and others are using "green-list" btc addresses, demonstrating how fungibility is lacking on bitcoin. Good money is fungible, therefore in the digital realm it needs anonymity to fulfill that important property.

Unless you want to argue that fungibility is not related to anonymity of digital tokens, or that fungibility is not an important property of money.

Anonymity and privacy are two different but somewhat related things.   Banks are very private in a conventional sense.  Bitcoin (and MAVEPAY as described) can not have that kind of privacy— but what bitcoin does is uses weak pseudo-anonymity to provide the privacy that was lost.

This is fairly effective—  although it's not strong enough by itself to hide my activities from concerted attackers it can successfully prevent awkward questions from snoopy inlaws who are angry about you buying contraception when they want grandchildren— and in Bitcoin as as designed it's largely free, and the account level historical summarization that the related design precludes could only shrink the stored data by some constant factor.

I don't particularly think that anonymity is all that important a property, but I think that privacy certainly is — perhaps you can come up with some clever way to regain some privacy in your system.

Ok, thanks for clearing that up. I had read your earlier blog posts and assumed that MAVEPAY was "the one". I'm more interested in the total anonymous system is why I just briefed through MAVEPAY papers. Seems to be obvious, in hindsight, that there will be a trade off between anonymity and system performance, yet interesting never-the-less, once the details are fleshed out.

No. I specifically left Total anonymization out of the MAVEPAY paper, since anonymization gos against performance in every protocol I´ve seen. MAVEPAY aim is to have the best performance, and so pseudo-anonymous transactions are more expensive in MAVEPAY and total anonymization is not granted by the protocol.

I´m working on the paper of a system with total anonymization as the design rule. I´ve already designed it. Nevertheless, it uses a lot of PK crypto (signatures, trapdoor mixes, universal re-encryption, zero knowledge proofs). I think its performance would be 10 tps (and the bottleneck would be hard disk block chain storage).

Sergio.

Interesting.

Do you cover the specifics of any total anonymity possibility for MAVE? (I didn't see it briefing through the papers).

Dear gmaxwell,
 Some comments on Bitcoin were favor to it, and not against. The fact that Bitcoin has no free-rides is a pro and not a con!
MAVEPAY, on the contrary, has the DRAWBACK that it cannot allow fees to be paid in all types of messages. Bitcoin is better in this respect: you can (if you want) pay fees in every message, so that the network has a incentive to include them in a mining block.

The sentence  "Every transaction can (and usually must) pay a fee" is somehow misleading, and you're right I should have said  "Every transaction can (and generally do) pay a fee".

Regarding the issue of eternal storage of transactions you're completely right: it's not a problem of the protocol but a problem of the implementation. I know there are now strong efforts to formally describe the protocol (as in the thread "Satoshi Client Operation: Overview"). Nevertheless still Satoshi Bitcoin client source code is the main reference for the description of the protocol.

Last but not least, I want to thank gmaxwell of reading the paper and make these useful comments. Since the published paper is preliminary, I will correct them in the final one.

Regards,
 Sergio.

The paper would be a lot more readable if it didn't constantly make factually incorrect statements about Bitcoin, it makes it somewhat irritating to read.

Some examples,  (though there are a great many— I think, in fact, the majority of the comments about the bitcoin system are arguably incorrect or misleading— including things as simple and factual as transaction sizes)


This is incorrect, and you could have verified in just a couple minutes that an overwhelming super-majority of transactions pay _no fee at all_ right now.

Though fees are one mechanism bitcoin uses for anti-dos— resulting in a _reusable proof of work_ system which is arguably superior to any one-shot POW system, at least so long as mining is creating substantial amounts of coin,  Bitcoin also uses coin-immobility-time as an anti-dos mechanism— and the effectiveness of this is why most txn don't carry fees.


I'm not even sure how you're making this error.  It simply isn't true.  Transactions must spend a previously existing transaction, and they exhaust it in the process thus making duplicates of that transaction invalid. Nodes do remember transactions they've already forwarded to peers to avoid excessive rapid retransmission, but there is no protocol requirement of this and the storage is purely in memory not eternal.

Perhaps it would be better in the future to describe your system without constant incorrect references to the Bitcoin system.

[I don't mean to be entirely negative—  the PoW-Chain-staggered-commitments as signatures is quite clever.  I'm not convinced as to it's use in currency systems, especially since ecdsa signatures (esp with the proper curve selected and bulk validation) are not that much slower, nor are lamport signatures that much bigger... but it's still a neat idea]

As I promised, I’m publishing the preliminary paper on how to apply MAVE-3 to P2P cryptocurrency. I spent some time re-thinking everything and meanwhile (at 2 a.m.) I designed a new one-time digital signature algorithm with 320 bits signatures, and 80 bit public keys, that is faster than RSA.  Better than Lamport’s but probably not better than Merkle-Winternitz. Every time I think I’ve finished something, I start a new thing…

Apart from the description of the new protocol, you’ll find interesting proposals for Bitcoin evolution such as:

•     Combining Multiple Digital Signature Algorithms into a single P2P currency
•     Protection from Miners selfishness
•     Adding a Proof-of-work for every Bitcoin transaction, and how the network can deal with this.
•     Free market and the principle of Least Required Security (LRS) to optimize network resource usage.
•     How to achieve more advanced transaction fee rates.
•     Hybrid systems
•     The hidden costs of maintaining a Bitcoin client.

Download the paper from: http://bitslog.wordpress.com/2012/04/16/mavepay-a-new-lightweight-payment-scheme-for-peer-to-peer-currency-networks/

 

Enjoy it!

I´l like the term "proof-of-poker", whatever that mean!  

Note: MAVEPAY is not about poker, but It could be used for paying bets, since payments are really lightweight. (comment: though confirmation time is an issue)

There are two fast-tracks for bootstrapping a p2p coin:

1. Black market.
2. unregulated but secure poker gambling.

The remaining uses can also bootstrap a cryptocoin, but much slowly.

Doing (2) is quite challenging, but it can be done. I spent a year (before Bitcoin was created) to research on a new method to solve the mental poker problem. I´ll post the paper afterwards, so you can check it (it´s almost 70 pages long though)

But I would prefer MAVEPAY to some time in the future be included in Bitcoin and to form an hybrid, and in the paper I describe how to do it. It could be done in such a way that it don´t break older clients, but older clients won´t see the money going back and forth between Bitcoin and MAVEPAY (only money going out of Bitcoin).

Anyway, instead of talking and talking about it, I should go to TeXnicCenter and finish the damn paper!

Bye!

No, I didn't finish it yet, I was busy last night and will be busy for the next few days too. I'll post here when I've finished reading it.

I'm sure the underlying concept seems simple to you, but the paper is quite long and lays out several variants of the same algorithms with different sets of tradeoffs and constraints. I need to not only fully understand what you're proposing but think about ways it could go wrong.

Probably, it'll be easier to see how it all fits together once the MAVEPAY paper is out.

Looking forward to it.

On a side note, it would be interesting to have an initial currency distribution system arranged around.poker free rolls and subsidized pay to enter poker tournaments. It would.be.novel to.do poker p2p, but not essential.  Txn Verification could be done using another system. Distributing the currency via proof-of-poker could go viral and build up a user base interested in its functionality for non-subsidized gambling.

How to build a user base is a big challenge, regardless of the technological sophistication of the currency design.