please delete

[SapphireSpire]

nothing to see

[fenghush]

You can do this with bitcoin already? I'm sorry I fail to see where you're going with this.

[fenghush]

You can do this with bitcoin already? I'm sorry I fail to see where you're going with this.

The Vault is much smaller than the blockchain, and it's more anonymous.

So basically your idea is a pre-defined blockchain?

[fenghush]

You can do this with bitcoin already? I'm sorry I fail to see where you're going with this.

The Vault is much smaller than the blockchain, and it's more anonymous.

So basically your idea is a pre-defined blockchain?

It's not a blockhain. There is no transaction history, just balances with keys.

Ah I see. I will draw some visio graphs and get back to you. Sounds interesting but it needs to be analysed properly for any possible attacks, flaws etc.

[JJB]

You can do this with bitcoin already? I'm sorry I fail to see where you're going with this.

He's lost me with this idea. It doesn't really seem that much different from bitcoin to be honest, but then again most alts arent.

[Joe200]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

[bitcreditscc]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

point number 1

[bitcreditscc]

i don;'t want to knock down your idea, but allow me to give you some pointers so that you can really think your idea through.

1) How do you prove ownership of a balance? especially without a transaction history?
2) how do we verify that database?
3) is the ledger distributed or centralized?
4) how to prevent double spending?
5) what key features does it fix/ produce to create a system that has use and/or is better than existing systems?
6) How are transactions transmitted?
7) is it secure ?
how does the system compare to existing centralized and decentralized systems?
9) what provides the value of the system and how is the value distributed?

Just to make it clear what i am asking

distribution of rewards in BTC is tied to helping secure the system by means of a public ledger that uses sequential data, transactions can be verified and proof of ownership of specific outputs is proven by privkeys. Double spending and most security concerns all lead into a single word "CONSENSUS".


i am not knocking down your plane, please consider what i have asked and if your system actually addresses this then you may be onto something.

[BIGbangTheory]

just a pipe dream or you're actually working on this?

[runpaint]

I use one called bitcoin, it works pretty well so far

[SirChiko]

just a pipe dream or you're actually working on this?

Just an concept, i doubt OP has enought skills to do this alone. Otherwise it would be annouced by him already no?

[claycoins]

How would you start it off? What gives the initial balances/values?

[Q7]

I'm trying to grasp the whole idea which brings me to the question on who is going to maintain the database? And how can we trust the database is the actual one. Just wondering...

[nagatlakshmi]

Practically it isn't possible.

[cynicSOB]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

They only thing you can do is accept the most popular version. But, if someone is conducting a 51% attack,
the most popular version will have an unusually low percent of corroboration, closer to 50%. So the data is only acceptable
while it has a high degree of corroboration - very close to 100%.

BS! most popular version? how is that defined?
if I set up a lot of nodes then I can decide which the most popular version is. Depending on network topology and the location of a node, the most popular version can vary from one node to another.

[spartacusrex]

The mini-blockchain scheme, as used in Cryptonite, uses a ledger of account / amount entries, so storing a distributed database is known to work.

It uses POW to secure the chain and then throws the txns away, keeping the database and the block headers(as a proof chain). The hash of the database is added in each block header to ensure everyone agrees.

Is this similar to your idea ?

[SirChiko]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

The only thing you can do is accept the most popular version. But, if someone is conducting a 51% attack,
the most popular version will have an unusually low percent of corroboration, closer to 50%. So the data is only acceptable
while it has a high degree of corroboration - very close to 100%.

BS! most popular version? how is that defined?
if I set up a lot of nodes then I can decide which the most popular version is. Depending on network topology and the location of a node, the most popular version can vary from one node to another.

You'll need enough nodes with unique IP addresses to get the minimum consensus.
But the minimum consensus will scale up as the network grows.
With 1,000 nodes or less, the minimum consensus is 95%. You'll need to add 20,000 impostor nodes. But...
With 10,000+ nodes, the minimum consensus increases to 96%. You'll need to add 240,000 impostor nodes. But...
With 100,000+ nodes, the minimum consensus increases to 97%. You'll need to add 3,333,333 impostor nodes. But...
With 1,000,000+ nodes, the minimum consensus increases to 98%. You'll need to set up 50,000,000 impostor nodes. But...
With 10,000,000+ nodes, the minimum consensus increases to 99%. You'll need to set up 1,000,000,000 impostor nodes. But... etc.

Network topology and geographical location only effects latency between nodes, not their ability to communicate. Conflicts between nodes will be settled in seconds.

You have actuall coding skills to realise this? Why not gather an team and try it yourself? It may catch on

[cynicSOB]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

The only thing you can do is accept the most popular version. But, if someone is conducting a 51% attack,
the most popular version will have an unusually low percent of corroboration, closer to 50%. So the data is only acceptable
while it has a high degree of corroboration - very close to 100%.

BS! most popular version? how is that defined?
if I set up a lot of nodes then I can decide which the most popular version is. Depending on network topology and the location of a node, the most popular version can vary from one node to another.

You'll need enough nodes with unique IP addresses to get the minimum consensus.
But the minimum consensus will scale up as the network grows.
With 1,000 nodes or less, the minimum consensus is 95%. You'll need to add 19,000 impostor nodes. But...
With 10,000+ nodes, the minimum consensus increases to 96%. You'll need to add 240,000 impostor nodes. But...
With 100,000+ nodes, the minimum consensus increases to 97%. You'll need to add 3,233,333 impostor nodes. But...
With 1,000,000+ nodes, the minimum consensus increases to 98%. You'll need to add 49,000,000 impostor nodes. But...
With 10,000,000+ nodes, the minimum consensus increases to 99%. You'll need to add 990,000,000 impostor nodes. But...
etc.
etc.
etc.

Network topology and geographical location only effects latency between nodes, not their ability to communicate.

Yes, it does affect they communicate, or do you want each node to be connected to other 10M nodes and share tx data with everyone? That doesn't work because it requires too much bandwith. The number of nodes each node connects to must be limited (I think it's 125 in BTC)
Also, any ISP can easily own the network.

[anderl]

All balances are stored on a shared database called the vault.

When this database is updated, how do you reach consensus on the correct version of the new database?

The only thing you can do is accept the most popular version. But, if someone is conducting a 51% attack,
the most popular version will have an unusually low percent of corroboration, closer to 50%. So the data is only acceptable
while it has a high degree of corroboration - very close to 100%.

BS! most popular version? how is that defined?
if I set up a lot of nodes then I can decide which the most popular version is. Depending on network topology and the location of a node, the most popular version can vary from one node to another.

You'll need enough nodes with unique IP addresses to get the minimum consensus.
But the minimum consensus will scale up as the network grows.
With 1,000 nodes or less, the minimum consensus is 95%. You'll need to add 19,000 impostor nodes. But...
With 10,000+ nodes, the minimum consensus increases to 96%. You'll need to add 240,000 impostor nodes. But...
With 100,000+ nodes, the minimum consensus increases to 97%. You'll need to add 3,233,333 impostor nodes. But...
With 1,000,000+ nodes, the minimum consensus increases to 98%. You'll need to add 49,000,000 impostor nodes. But...
With 10,000,000+ nodes, the minimum consensus increases to 99%. You'll need to add 990,000,000 impostor nodes. But...
etc.
etc.
etc.

Network topology and geographical location only effects latency between nodes, not their ability to communicate.

Yes, it does affect they communicate, or do you want each node to be connected to other 10M nodes and share tx data with everyone? That doesn't work because it requires too much bandwith. The number of nodes each node connects to must be limited (I think it's 125 in BTC)
Also, any ISP can easily own the network.

good catch.  if you have to wait for 95+% approval how long would it take to get those responses? and 10 million incoming acks?  Would be a great way of taking down the Internet lol.

[Fuserleer]

Our channeled ledger tracks balances, but it's not as simple as you propose.

You still need a clever, lightweight consensus mechanism, you still need a ledger of the most recent transactions so that you can apply that consensus algorithm, you still need a method to communicate data to a large set of nodes in the entire network efficiently.

I've seen a few of these "track the balance" ideas over the past couple of years since I first proposed it, and while its sound in principle (of course )  its a lot more work than people think.

Additionally, if you are planning on using this to reduce the ledger size, but apply this to a blockchain type ledger, there are MUCH easier ways to achieve that goal without messing with balances.  BTC's input/output approach works just fine.

Secondly, if you are also planning on using this to reduce confirmation time/increase transaction through put....chains are about as useful as condoms after conception.