please delete | Bitcointalksearch.org

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: Fuserleer on February 05, 2015, 10:20:12 PM

You still need a lightweight consensus mechanism

Bitcoin's consensus mechanism isn't a consensus mechanism at all. It just gives a random node the power to decide what the next block is going to be and everyone is supposed to accept it. There is only one way to take a consensus and that is by directly obtaining the approval of every node. To reduce network load, I don't require nodes to announce their acceptance of receipts, only their objections. But I also use a reputation system that penalizes nodes who don't object to valid receipts but later refuse to accept new receipts based on them.

Quote from: Fuserleer on February 05, 2015, 10:20:12 PM

you still need a ledger of the most recent transactions so that you can apply that consensus algorithm,

The only thing required to validate a receipt is to make sure it was generating from a previously valid receipt. So I only need to keep a record of receipts going back one generation.

Quote from: Fuserleer on February 05, 2015, 10:20:12 PM

you still need a method to communicate data to a large set of nodes in the entire network efficiently.

I'm open to suggestions.

Quote from: Fuserleer on February 05, 2015, 10:20:12 PM

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.

All inputs and outputs in Bitcoin contain balances. My 'ledger' is already as short as it can be so, it will never be a blockchain.

Quote from: Fuserleer on February 05, 2015, 10:20:12 PM

if you are also planning on using this to reduce confirmation time, chains are about as useful as condoms after conception.

I agree. The main goals of my project is to create a stable, secure, and elastic internet coin that doesn't require a blockchain. Confirmation times depend entirely on network conditions.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: SirChiko on February 04, 2015, 01:18:42 PM

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

No.

That's why I share.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: cynicSOB on February 02, 2015, 10:06:54 AM

Quote from: ?? on ??

Quote from: Joe200 on January 30, 2015, 11:19:40 AM

Quote from: SapphireSpire on January 30, 2015, 10:07:15 AM

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.

lovely89

sr. member

Activity: 378

Merit: 250

How does it compare?

Credits
https://bitcointalksearch.org/topic/--614917

Decrits
https://bitcointalksearch.org/topic/decrits-the-99-attack-proof-coin-189239

Simcoin
https://bitcointalk.org/index.php?topic=561294.20

Fuserleer

legendary

Activity: 1050

Merit: 1016

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.

anderl

hero member

Activity: 714

Merit: 500

Quote from: cynicSOB on February 05, 2015, 08:09:43 AM

Quote from: SapphireSpire on February 04, 2015, 01:16:07 PM

Quote from: cynicSOB on February 02, 2015, 10:06:54 AM

Quote from: ?? on ??

Quote from: Joe200 on January 30, 2015, 11:19:40 AM

Quote from: SapphireSpire on January 30, 2015, 10:07:15 AM

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.

cynicSOB

member

Activity: 106

Merit: 10

yes, sometimes I'm a cynical SOB

Quote from: SapphireSpire on February 04, 2015, 01:16:07 PM

Quote from: cynicSOB on February 02, 2015, 10:06:54 AM

Quote from: ?? on ??

Quote from: Joe200 on January 30, 2015, 11:19:40 AM

Quote from: SapphireSpire on January 30, 2015, 10:07:15 AM

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.

SirChiko

legendary

Activity: 966

Merit: 1000

Quote from: SapphireSpire on February 04, 2015, 01:16:07 PM

Quote from: cynicSOB on February 02, 2015, 10:06:54 AM

Quote from: ?? on ??

Quote from: Joe200 on January 30, 2015, 11:19:40 AM

Quote from: SapphireSpire on January 30, 2015, 10:07:15 AM

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 Wink

spartacusrex

hero member

Activity: 718

Merit: 545

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 ?

cynicSOB

member

Activity: 106

Merit: 10

yes, sometimes I'm a cynical SOB

Quote from: ?? on ??

Quote from: Joe200 on January 30, 2015, 11:19:40 AM

Quote from: SapphireSpire on January 30, 2015, 10:07:15 AM

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.

nagatlakshmi

hero member

Activity: 616

Merit: 500

Practically it isn't possible.

Q7

sr. member

Activity: 448

Merit: 250

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...

claycoins

hero member

Activity: 518

Merit: 500

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

SirChiko

legendary

Activity: 966

Merit: 1000

Quote from: BIGbangTheory on January 31, 2015, 12:43:32 PM

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?

runpaint

sr. member

Activity: 518

Merit: 250

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

BIGbangTheory

member

Activity: 83

Merit: 10

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

bitcreditscc

hero member

Activity: 602

Merit: 501

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 ?
Cool

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.

bitcreditscc

hero member

Activity: 602

Merit: 501