Topic: Simplify Bitcoin (Read 2387 times)

No need for you to dive into the code, MultiBit is based on BitcoinJ. Electrum is another great thin client.

I'll start playing around with the java client from google... maybe i'll learn something...

I assume it will be when it becomes a problem for the majority of users. There are more pressing issues at hand. If you're not able to run a full node than try one of the thin clients.

Ok, but when will this be implemented? My SSD is running out of space!

The current implementation keeps all transaction around, yes, but Bitcoin is designed from the start to allow "pruning", removing transactions which are old and fully spent already. This is described in Satoshi's paper. It's certainly not true that fully verifying nodes need to keep every transaction around forever.

I agree, but there must be some other way of globally synchronizing transactions that nobody has thought of yet, or is supernodes the only way?


You are talking about supernodes of sort, I'm looking for a atomic solution... but if you wan't this then we could just make the pools into these supernodes, they already 'are/can be' if you leave your money there, but I don't think any pool admin would like that responsibility...

One other way is to make the destination node encrypt the transaction with something that the origin node "doesn't know" but that the verifying nodes can read in real-time to make sure the balance of the origin is up-to-date... if we trust the destination to embed a timestamp... hmm, I'm just throwing ideas at the browser here.

What we have now is a complete register of every transaction, what I'm trying to achieve is to have shorter history of transaction for each user and by rolling back every transaction until everyone has the latest transaction somehow making the transactions synchronized even if it makes you able to only send one transaction per day...

Or we could make it the block winning nodes job to track who owns what part of that block... messy!

Together with others I developed a (EDIT: theoretical) scalable swarm client.

1. Each client does part of the work and watches only a part of the chain.
2. Each node works like a full node in that it trusts no one and it does verification.
3. The swarm network would be able to communicate with the normal BTC network, no fork needed.
4. To avoid security problems the swarm nodes would use public keys to communicate over instead of hijackable IPs. Avoids the isolation attack I think the regular client was also susceptible to before the recent fix.

Its slightly complicated, but it would scale infinitely and require zero trusted super nodes. Fees would also be near zero. Smartphones could run a full node like swarm node.

No one has found a flaw behind it yet... except that "it's hard to program"... I kid you not.

This would be a great way to make use of my idea awhile back for establishing trust by provably and publicly throwing coins away, either by transferring it to the null address (all zeros) or by spending it in fees to miners. If Ultra is charging fees for the service, it'd be worth it's while to be honest if acquiring the reputation is sufficiently expensive.

For a straight-up bank role the analysis is easy: the bank's identity is tied to the root of a deterministic wallet, and interested parties can then audit the blockchain to ensure that the bank isn't at any one time holding more bitcoins than the identity is worth. (albeit this is difficult with future transaction volumes and pruning)

With Ultra's only being able to destroy coins, rather than steal them, I'm not really sure how you would value it. I mean, griefers can be quite irrational, although rarely that rich. For micropayments though I can see the idea definitely working.

I think Bitcoin is already perfectly capable of scaling up.  Here's one half-baked idea for how to do it:
  http://gavintech.blogspot.com/2012/07/off-chain-transactions.html  (pasted below to save you a click):

---

The problem: is there a safe and secure way to make Bitcoin transactions without relying on the block-chain but, instead, relying on some semi-trusted third-party?

If there is, then Bitcoin is more easily scalable; most transactions could happen off the block chain, with in-the-block-chain transactions happening every once in a while to "settle up" off-chain transactions.

So here is the half-baked idea:

Use multisignature transactions to split the ownership of some bitcoin value between a customer (lets call her Alice) and a transaction service (lets call it "Joe's UltraTransactions" -- Ultra for short).

Alice deposits 100 bitcoins into her Ultra wallet, and what actually happens behind the scenes is Alice's software generates a new keypair, gets a public key from Ultra, and coins are sent into a 2-of-2 transaction.

Alice withdrawing the bitcoins (getting them out of the UltraTransaction system) is the boring case-- she'd generate a transaction, sign her half, then ask Ultra to sign the other half (and there would be some sort of authentication check-- maybe Ultra sends Alice an SMS to approve the withdrawal).

Now Alice wants to pay Bob 10BTC, who also happens to be an UltraTransaction customer. This is where things could get interesting.

Instead of generating a block-chain transaction, Alice could just give Bob her private key. Both Alice and Bob would sign a message with the private key saying "Alice is sending 10 bitcoins to Bob; she's given him the private key that she generated."  Bob would send the message to Ultra, which would send Alice an SMS to make sure she approves, and then any withdrawal involving those 10 bitcoins associated with that private key would require Bob's authorization instead of Alice's.

Alice would still know the private key, but won't be able to spend what is now Bob's money (Ultra would only let her send/withdraw 90 of the 100 bitcoin tied up with that private key).

Ultra is only semi-trusted; it never has the private key, so can't spend the coins without either Alice or Bob's aproval. Joe can't decide to run off with everybody's coins when the Ultra wallet is worth a few million dollars.

Alice and Bob do have to trust that Ultra keeps track of who owns what accurately, and that Ultra will be around to sign it's half of the transaction when they want to withdraw some coin. And Bob has to trust that Alice did generate the private key, didn't share it with Ultra, and isn't actually Joe trying to trick him.

That's quite a lot of trust required, but the ability to instantly transfer value between Ultra customers with zero Bitcoin-block-chain transaction fees might outweigh the risks. And there are probably variations on this idea that would minimize trust in Ultra (maybe there's a semi-trusted service that Ultra pays to keep offline, "use-only-if-we-go-out-of-business" backups of their private keys).

And it scales beautifully; one UltraTransaction server cluster could easily handle hundreds or thousands of transactions per second, and you could imagine companies popping up all over the world, handling most transactions outside the blockchain.

D&T I realized that idea was total crap, but the earlier one works... I'm trying to simplify, but I went too far.

So how would you fix the scalability issues of BTC?

LOLZ.  That has to be the most idiotic thing I read today.  New idea anyone proposing to "fix" Bitcoin is required to pass a test on how Bitcoin actually works first.

Sure you can, the destination checks the origins balance it has against the new transaction if the balance don't match there is no transaction.

So, I'm still trying to figure this out, but signing the current transaction verification with the last transaction would work no?

This system is synchronized by forcing each account to be slow (1 transaction at the time) and allowing the network as a whole to be fast.

You cannot have global real-time consensus. Just the fact that the speed of light is finite prevents communication from being instantaneous. Whatever limitation you build on accounts or transactions or wallets or addresses, you'll always be able to create two conflicting transactions, and only tell part of the world about each.

Bitcoin has addresses, but in this system it's real-time synchronous transactions between accounts, because the current system will not scale.

I just answered, in this system one account can only have 1 transaction at the time. And furthermore one client should have only one account, many clients can have the same account though.

Bitcoin does not have "accounts". It has coins, and each transaction consumes, merges, splits and reassigns coins.

And you haven't provided an answer for what happens when someone releases two conflicting transactions simultaneously. Transfer time is not instantaneous, so not every node will hear about the same one first. They will disagree about which was first. Which one is considered valid?

This is easy to solve, all nodes keep the latest transaction for every account it verifies a transaction for and uses that to verify the current transaction. ie. only up to date nodes can verify the last transaction!

The whole point of the block chain is to create a globally-agreed-upon order of transactions. If not for the possibility of double spends, we wouldn't need a block chain. In Bitcoin, initial introduction of new currency is tied to the production of blocks, but I'd call that a nice side effect rather than its core function.

Assume I was an attacker, and create two conflicting transactions (spending the same input coin), and I emit both in different places of the network. Some nodes would hear about one first, and others would hear the other first. Obviously they cannot agree, but how will they get to an agreement about which was first/valid/true?

You can already do instant transactions with many existing ewallet services.

This, my friend, is wrong; and yes, it's VERY inefficient!

Double spends are easily avoided by another limitation: you can only make one transaction until all nodes are updated OR you force some of the nodes that verified the first transaction to verify the second.

EDIT: This is easy to solve, all nodes keep the latest transaction for every account it verifies a transaction for and uses that to verify the current transaction. ie. only up to date nodes can verify the last transaction!

PS. It's not the storemanager that's cheated, it's you; and it's called inflation, your current currency has it! DS.