Bitcoin Forum

Why do the transactions need to be stored in the block chain?

Would it be possible to drop the transaction history from the block chain and just use it for the proof of work.

Basically making bitcoins self signed somehow, so we can save disc space and improve transaction speed/volume.

This would be possible if the bitcoins themselves are encrypted by each owner (like your wallet is now anyhow) and the p2p system only keeps track of who has how much "right now" instead of details about every historical transaction ever to occur.

Or am I missing something?

I think the new address for each payment is really a bad way to do anonymity and it's better to actually see from which account (address) the money originated from. The address (account) is still anonymous, just not uniquely anonymous.

Only two problems, rather big ones.

(1) How would we know how much each person has?  I know you are saying self-signed, but then I could say "I have 9001137 Bitcoins".

(2) How would you transfer the old transactions to the new system?

In reality, there is no practical way to do this.

It wouldn't be self signed. It would be p2p controlled, so nodes will ask my node in realtime if I really sent the coins and when enough (say 50, EDIT: this should be variable, so you can set it to 50 if you're in a rush or 100.000 if you're making a big purchase which is not time sensitive) has verified the transaction with me (in a secure manner, ie. they will know it's really me they are talking to) then the transaction is committed. registered and committed after say 500 of nodes have verified the transaction.

Transferring current funds is easy.

Only 1 big problem left: Your client HAS to be online when you make a transaction. I think it's a reasonable tradeoff seen we have to be able to compete with VISA and Mastercard which the current system (even if Moores law keeps up) has no chance in hell of delivering.

How would your node not just say you sent/did not send it to all 50?

No offense, but it seems to me you need to go read the wiki or some FAQ.

Ehh, ok I'm in a store, I WANT to buy something. I SEND the money becuase I want the store owner to give me say a Snickers. He's not gonna give me the Snickers unless he gets the money! I want all 50 to say: Ok, give him the Snickers.

Yes.. but according to your idea after this you throw away all records/transactions - so when you try to use the same money again at a different snickers store the same 50 nodes won't remember you have no money or maybe its 50 new ones.

So the store manager is cheated.


The whole point of the blockchain/BTC is to prevent this. Without saving all the linked transactions linked ultimately to the header, the headers are pointless.

The transactions aren't all recorded so we know everyone's balance. Yes, that would be inefficient.

They're all kept, forever, so we can prevent double-spends.

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.

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

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

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?

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!

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?

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.

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.

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.

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.

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?

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.

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.

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.

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!

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.

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

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.

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

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