So far the only evidence I see that this is "debt-based" is from the posters in this thread. In fact, the OP even quotes part of the article where it says "you earn credit by offering goods and services."

Telling people to buy bitcoin when they can't buy food because they have no euros has got to be some of the most short-sighted shit I've ever seen on here. And you claim somebody "doesn't get it."

how are we in violation of it? it's for a form of cryptography that bitcoin doesn't use

i found this on the google: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=56&ved=0CEcQFjAFODI&url=http%3A%2F%2Farchive.unctad.org%2FTemplates%2FDownload.asp%3Fdocid%3D13150%26lang%3D1%26intItemID%3D5420&ei=ucuOT67YM8zmggf8k-SPCg&usg=AFQjCNHSOlE-ob1fsm9lDX42Zq5bOSdPeg

man I am getting sick to fucking death of this google link spam

anyways, this pdf basically says "we will bow down to the banking overlords and do whatever they tell us"

"the BitMint team constructed a solution based on equivocation which allows for cryptographic money that is theoretically resistant to even brute-force cryptanalysis; resistance that does not erode with time."

I'd be really interested to hear how they solved that. I think the entire cryptography world would be interested.

I don't follow this logic. If the market cap grows by 100, all other things being equal (very unlikely), the price per coin will multiply by 100. Only 2 or 3x people will start mining and everyone else will leave the 33-50x profit to miners?

here you go: http://www.emsec.rub.de/media/crypto/attachments/files/2010/04/da_szerwinski.pdf

point multiplication on the NIST P224 curve for 8800GTS: 1412.6/s
point multiplication on an intel Pentium II 400MHz: 950.6/s

better watch out for those 10 year old processors, they might one day rule the world

You know, I have tried to be civil. But when somebody is insulting in the face of their own stupidity, it gets harder and harder.

Logic breakdown:

A) SHA-256 hashing is capable of being highly parallelized
B) It is unknown* whether or not ECDSA is capable of being highly parallelized
C) SHA-256 and ECDSA have the fact that they are forms of cryptography in common but are otherwise unrelated
D) Therefore, ECDSA is capable of being highly parallelized
*) It is probably well-known among people who are proficient in this sort of thing. And additionally, as ECDSA is a far more intensive process than a one-way hash function, it is highly likely that businesses with significant use of digital signature algorithms would have investigated this. You know, since it's kinda the whole point of CUDA and OpenCL.

BZZt. WRONG. FAIL. EPIC FAIL. DO NOT PASS GO. DO NOT COLLECT $200. GO DIRECTLY TO THE JAIL OF PISS POOR LOGIC.

You made a gross leap in logic and used that to draw a conclusion based on no evidence of any kind. Then threw insult after insult at me for pointing out this logical fallacy.

PS BRO-


I elected not to point out the gross error in your logic of 100 tps being 100 kbps. This, unfortunately, only holds true if you have 1 incoming connection and 0 outgoing connections. If this were the case for the network, there would be no network. There is the reason the wiki comes up with 8Gbit/s for 4,000 tps instead of 4Mbit/s.

Bandwidth, imo, has always been the greater bottleneck of the bitcoin system. You are correct to point out bandwidth caps and throttling and that computational power is likely to grow faster than bandwidth. Even if it isn't, you can always build "up" with more processors or computers, whereas you cannot just lay down an extra pipe of fiber to your house.

Each situation where a random peer needs to be picked will be slightly different, but I will give a possible example for this situation.

A SupplyNet peer completes a coin creation transaction. This transaction is (level 2) approved a few minutes later. I did not update the wiki about how level 2 works now, but I think I posted something in the v4 thread. Basically level 2 happens when 50% of the reputation has signed a transaction. So if there were 50 TradeNet groups, it would take approximately 250 seconds (10 seconds x 25 tngs) to level 2 approve a transaction, assuming the reputation is fairly evenly spread. Anyways, the hash of the transaction block in which the tx appeared will be used as a kind of seed modulo to determine from the remaining available peers whom is the next peer to be given a coin creation problem. This way everyone agrees or will eventually agree on who is the next peer. Every piece of randomness will always be based on information that everyone agrees on but can not be predicted in advance.

Any comments or questions on the stable value part?

Yes, the block chain is a transaction ledger. That's why you need an account ledger. It would actually be pretty simple to implement in a bitcoin-derivative, and it obviates the need for merkle trees and pruning and all the bloat. And you could safely delete an entire chunk of the block chain after it is buried deep enough.

You add a big, secure hash of a balance of all accounts to each block. Transactions do not need to reference inputs, only {amount, from, to, signature}. Things are slightly more complicated if you wish to continue to use RIPEMD160 on the ECDSA public keys, but not much at all. When adding a transaction to a block, a miner references the account ledger that they keep locally (and update via the tx log in each block, and ensure their hash agrees with the balance hash) and puts the tx in the block if the account has enough available. Txes simply add and subtract from balances. No change required, insanely less data used per transaction, a lot less data needed for the block chain, etc.

Now I don't know what you are trying to accomplish with this proposal, but I spent a lot of time addressing issues like deflation, early adopter problem, transaction acceptance problem, scalability problem, waste of electricity, and combined all this into the proposal for encoin. I don't particularly see the value of a currency where 230G credits becomes worth 50k credits in a year. If you like the idea of money having a price to store (like GMWG), this is called demurrage and freicoin is working on implementing this. But, encoin promotes a system similar to what demurrage tries to achieve by "threatening" hoarders with new coin creation when the value of coins exceed their cost to produce. And this is without charging a fee for holding on to money, which is I think a significant hindrance to adoption by the general public.

Perhaps your proposal is the next big thing. But you've got your work cut out for you, especially when you talk about using floating points in the block chain.

*le sigh*

Moonshadow, there are a dozen or so other algorithms that compete with SHA2. SHA2 is just the US government sponsored algorithm.

Your "known path" argument is bunk. Any change to the double SHA2 hash breaks bitcoin. Every client would have to upgrade. Whichever chain gets bigger is irrelevant. Clients will not accept an apparently invalid chain just because it's longer.

Now I'm not saying that this is an impossible process, but it is certainly not modular.

how is bitcoin modular exactly? besides the fact that you can hack on an altchain rather easily.

according to the wiki, it links this post: https://bitcointalk.org/index.php?topic=191.msg1585#msg1585

where satoshi basically says "yeah we'll just fork it if something goes bad"

Stratum cannot implement mave as mave would have to be secured in some way

So the likely best option is to make an altchain that implements mave and uses bitcoin as its coin via inter-chain transactions.

This is probably a terrible idea to do for anyone that you don't trust, and you can't trust people because they have posts on a messageboard. I wouldn't be surprised if you get caught in the middle of this and end up holding the bag for some of this money. Slippery slope, imo.

You won't get too far insulting the protocol that is too holy around here.

If you're interested in something different, this is the latest thread on encoin: https://bitcointalk.org/index.php?topic=76750.0

I was actually looking into one-time signatures (or the hash tree based ones that have many but limited sigs) as well as NTRUsign/encrypt to obtain a QC-proof protocol. It appears that you have designed something that is fast and has both small public keys and signatures, a combination of which is not really possible with hash tree sigs and NTRU. I'm not a cryptographer though so it is hard for me to grasp everything just based on a whitepaper.


tps is not bottlenecked by hashing, it is bottlenecked by ECDSA. They operate very differently and openCL/APUs will not help this.


ECDSA doesn't need to prove itself, it needs to stay resistant to cryptanalysis finding a direct vulnerability. Bitcoin won't do anything to change the odds of this happening as it is a tiny, tiny percentage of ECDSA use at large.
In the same vein, MAVE is simply using one-way hashing functions, so any vulnerability in MAVE would be either based on the fact that it uses truncated hashes, or a vulnerability in SHA2 itself. I'm not a cryptographer, but they should be able to figure out whether or not MAVE is vulnerable because of truncated hashes just based on the whitepaper. SHA2 is in the same boat as ECDSA.

well I believe Caesar has a minimum of $200 or so before needing to file, but for the most part, yes

I know what zero sum means, but explain why you brought it up or why this is something significant to even mention, I guess.


Ok, I see that you just want to say "it's inflationary" because that's a dirty word around here.

hobby income still requires taxes be paid on it

except that, IIRC, your account won't actually be deleted for a very long time.

mwave is still using less bandwidth than bitcoin on a per-transaction basis so I don't see how that's disingenuous. Bitcoin is horribly inefficient with its bandwidth.

http://www.hindawi.com/journals/ijrc/2011/836460/

I don't know how to get ebats to give ms but this guy wrote that a core 2 duo 1.4ghz (is that highly oudated? I don't keep up with hardware) can verify in 2.2ms which is 455/s * 15% = 68/s.
off by a bit but not an order of magnitude.

I believe he is trying to compare apples to apples. If bitcoin were limited to 10 tps, what could mavepay do with the same cpu/bandwidth requirements. Though I don't think he did the greatest job of explaining that.