Bitcoin Forum
December 08, 2016, 08:32:34 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Simplify Bitcoin  (Read 2067 times)
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 08:31:46 PM
 #1

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
1481229154
Hero Member
*
Offline Offline

Posts: 1481229154

View Profile Personal Message (Offline)

Ignore
1481229154
Reply with quote  #2

1481229154
Report to moderator
1481229154
Hero Member
*
Offline Offline

Posts: 1481229154

View Profile Personal Message (Offline)

Ignore
1481229154
Reply with quote  #2

1481229154
Report to moderator
1481229154
Hero Member
*
Offline Offline

Posts: 1481229154

View Profile Personal Message (Offline)

Ignore
1481229154
Reply with quote  #2

1481229154
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481229154
Hero Member
*
Offline Offline

Posts: 1481229154

View Profile Personal Message (Offline)

Ignore
1481229154
Reply with quote  #2

1481229154
Report to moderator
1481229154
Hero Member
*
Offline Offline

Posts: 1481229154

View Profile Personal Message (Offline)

Ignore
1481229154
Reply with quote  #2

1481229154
Report to moderator
danieldaniel
Hero Member
*****
Offline Offline

Activity: 854


View Profile
July 03, 2012, 08:42:18 PM
 #2

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.

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 09:03:21 PM
 #3

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Realpra
Hero Member
*****
Offline Offline

Activity: 819


View Profile
July 03, 2012, 09:06:24 PM
 #4

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) 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 registered and committed.
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.

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 09:08:52 PM
 #5

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Realpra
Hero Member
*****
Offline Offline

Activity: 819


View Profile
July 03, 2012, 09:17:21 PM
 #6

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.

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
westkybitcoins
Legendary
*
Offline Offline

Activity: 980

Firstbits: Compromised. Thanks, Android!


View Profile
July 03, 2012, 09:29:56 PM
 #7

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.

Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
...
...
In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber
...
...
ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)
...
...
The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 09:55:25 PM
 #8

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.

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! Wink DS.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 09:58:21 PM
 #9

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

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

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Luceo
Sr. Member
****
Offline Offline

Activity: 350


Per aspera ad astra!


View Profile
July 03, 2012, 11:30:28 PM
 #10

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

Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 03, 2012, 11:34:23 PM
 #11

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?

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 03, 2012, 11:43:35 PM
 #12

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!

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 04, 2012, 12:07:32 AM
 #13

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?

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 04, 2012, 12:15:32 AM
 #14

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 04, 2012, 12:26:13 AM
 #15

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 04, 2012, 12:33:34 AM
 #16

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.

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
July 04, 2012, 12:36:49 AM
 #17

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.

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.
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
July 04, 2012, 12:43:38 AM
 #18

So, I'm still trying to figure this out, but signing the current transaction verification with the last transaction would work no?
D&T I realized that idea was total crap, but the earlier one works... I'm trying to simplify, but I went too far. Smiley

So how would you fix the scalability issues of BTC?

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 04, 2012, 02:00:39 AM
 #19

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.

How often do you get the chance to work on a potentially world-changing project?
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1064


View Profile
July 04, 2012, 02:55:14 AM
 #20

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.

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!