Bitcoin Forum
November 18, 2019, 11:13:02 AM *
News: 10th anniversary art contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Proof of waiting better than proof of stake and proof of work  (Read 354 times)
Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 18, 2018, 05:20:56 AM
Merited by ETFbitcoin (1)
 #1

I got this idea which has been revolving around my brain for over a year.
I was thinking of a new cryptocurrency which would achieve consensus not by processing but by waiting. What I mean by waiting is that the network would wait until x number of transactions are broadcasted and grouped together into a block. It might sound confusing but I would try my best to explain it. This is how this cryptocurrency would work.
•   Every computer would store the entire list of public addresses of every user (not in a blockchain)
•   To generate a new address, an user has to do some proof of work.
•   Once its done, the user can broadcast this new address to the network and all the other computers in the network can add this to their list of
         addresses
•   The computers also store the balance of each address
•   To make a transaction, the sender should broadcast the amount being sent and the receiver should broadcast the receiving amount (similar to how Raiblocks or nano works)
•   Now here comes the main part, the computers in the network would make a list of transactions being done. The list should contain x number of transactions, once that many transactions are broadcasted, the nodes can then use this list to update the previous list of balances.

Would this new consensus mechanism work?
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
1574075582
Hero Member
*
Offline Offline

Posts: 1574075582

View Profile Personal Message (Offline)

Ignore
1574075582
Reply with quote  #2

1574075582
Report to moderator
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2092

Use SegWit and enjoy lower fees.


View Profile WWW
October 18, 2018, 07:31:29 AM
 #2

There are many major problems such as :
1. Block time would be inconsistent (either too slow or too fast) which makes transaction confirmation feels very long. Additional requirement such as minimum & maximum block time interval would help the problem a bit.
2. Since anyone can make block with low/no-cost, this would create block orphan because each nodes have different transaction on mempool because transaction propagation (such as node receive TX B before TX A even though TX A was broadcasted first).
3. Blockchain size would be bloated since HD wallet generate tens to thousand address at once. Even worse since HD (Hierarchical Deterministic) one-time address principle is commonly used by most wallet.
4. What stopping attacker to reverse the block or manipulate history?

So, your idea won't work in reality.

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 18, 2018, 12:58:03 PM
 #3

you don't need a blockchain, that's the point

To generate a new address, the user should specify the public address in a file and calculate the nonce. The difficulty level would be set in such a way that an average computer would take about an hour to compute the nonce. Then the user would broadcast this file to the entire network. All the computers which are online in the network would then add this new file to their list of addresses (probably a folder which contains the files). To make a transaction, the network would first check if the address the user is using is present in the list. If the address is not present in the list, the transaction would fail. If the address is present, then the network would agree upon the transaction and the transaction wouldn’t fail. The network would trust the computer which has the longest list. As generating a new address would require a computer to compute the nonce, it would be impossible for an attacker to generate a list long enough for the network to agree upon.
Now here comes the transaction part:
Every computer in the network would also store the balance of every address. These balances would be stored in form of a file in a separate folder. Let’s take a look at a transaction between a sender and a receiver.
Sender
•   The sender would broadcast a file (called a transaction file) which would contain the address of the sender and the receiver and the amount being transacted.
•   The sender would then digitally sign the file and broadcast it to the network.
•   The network would then check if the address of the sender and the receiver are there in the list of public addresses. If yes, then the transaction would be considered valid. If no then the transaction would fail.
•   The transaction would then be added to another list. The network would wait until there is x number of transactions in the list. Once there are that many transactions, this list would then be broadcasted.
•   The computers in the network would then update their list.
Receiver
•   The receiver would then the make a receiving transaction. The receiver would then follow the above-mentioned steps.
•   Until the receiver makes a receiving transaction, the transaction would be counted as pending.
By following this mechanism, there would be no need for proof of work. The waiting time would be utilized by processing smart contracts. This would also be scalable as the network would become faster if the number of transactions increases. The proof of work algorithm would only be used once because it would be used to create a public address and not for the transactions. There are no blockchains used. No transactions are recorded. Only the balances are stored. I hope this clears the doubts.
HeRetiK
Legendary
*
Offline Offline

Activity: 1288
Merit: 1143


the forkings will continue until morale improves


View Profile
October 18, 2018, 04:05:25 PM
 #4

[...]

To generate a new address, the user should specify the public address in a file and calculate the nonce. The difficulty level would be set in such a way that an average computer would take about an hour to compute the nonce. [...]

How would the network know what difficulty is required to ensure so that an average computer needs about an hour until an address is generated?

NeuroticFish
Legendary
*
Offline Offline

Activity: 2030
Merit: 1362


There are no mistakes. Only opportunities wasted.


View Profile
October 18, 2018, 04:08:08 PM
 #5

First of all, the user generates the address and broadcast it. Then everybody has a DB with all those addresses. When somebody would be able to hack that database, he will be able to send all the money to himself.
Keeping the addresses in DB is like keeping passwords in the DB; nobody does that in 2018 because it's proven to be a bad idea. Everybody keeps hashes of the passwords...
I see this already a very weak point. Also with some skill people could forge transactions, since the code is in the wallet, I see no check for authenticity.

Then block time. If you want to get your transaction done, you just generate a number of useless transactions and they get all coupled. No waiting.


Sorry, I don't think the idea would work...

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2092

Use SegWit and enjoy lower fees.


View Profile WWW
October 18, 2018, 04:13:39 PM
Merited by suchmoon (4)
 #6

I hope this clears the doubts.

Sorry, but based on my understanding, your explanation don't clear any of my doubt/question. In fact, now i have more doubt/question.

you don't need a blockchain, that's the point

Then you shouldn't said "...grouped together into a block", it makes people confused.

The difficulty level would be set in such a way that an average computer would take about an hour to compute the nonce.

This is ridiculous since one-time address has become standard to improve privacy. Most HD wallet also generate lots of addresses in advance.

The network would trust the computer which has the longest list. As generating a new address would require a computer to compute the nonce, it would be impossible for an attacker to generate a list long enough for the network to agree upon.

--snip--

No transactions are recorded. Only the balances are stored.

High computational power required to generate an address won't stop the problem. There are few critical questions such as :
1. What stopping attacker from double-spend attempt (example : attacker make 2 transactions (from an address contain 1 coin) where 1st transaction is sent 1 coin to Bob & 2nd transaction is sent 1 coin to Alice)?
2. How do new nodes verify the balance is valid and not comes from thin air? Even ETH which uses Balance model (not UTXO like Bitcoin) still require storing transaction.

This would also be scalable as the network would become faster if the number of transactions increases.

You meant transaction would have faster confirmation time if the number of transactions increases. It's not really scalable since time required to verify the transaction and bandwitch to broadcast the transaction/list are growing linearly (O(n))

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 19, 2018, 06:19:59 AM
 #7

First of all, the user generates the address and broadcast it. Then everybody has a DB with all those addresses. When somebody would be able to hack that database, he will be able to send all the money to himself.
Keeping the addresses in DB is like keeping passwords in the DB; nobody does that in 2018 because it's proven to be a bad idea. Everybody keeps hashes of the passwords...
I see this already a very weak point. Also with some skill people could forge transactions, since the code is in the wallet, I see no check for authenticity.

Then block time. If you want to get your transaction done, you just generate a number of useless transactions and they get all coupled. No waiting.


Sorry, I don't think the idea would work...


the database stores the public keys, not the private keys
u cannot generate useless transactions because u will be allowed to do one transaction at a time until that list gets broadcasted. U cannot generate new address(public key and private key) because it would require u to do some proof of work
Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 19, 2018, 06:31:05 AM
 #8

Quote
High computational power required to generate an address won't stop the problem. There are few critical questions such as :
1. What stopping attacker from double-spend attempt (example : attacker make 2 transactions (from an address contain 1 coin) where 1st transaction is sent 1 coin to Bob & 2nd transaction is sent 1 coin to Alice)?
2. How do new nodes verify the balance is valid and not comes from thin air? Even ETH which uses Balance model (not UTXO like Bitcoin) still require storing transaction.

1. The user won't be able to do a 2nd transaction until the list gets broadcasted.
2. They would check if the digital signature is valid.
NeuroticFish
Legendary
*
Offline Offline

Activity: 2030
Merit: 1362


There are no mistakes. Only opportunities wasted.


View Profile
October 19, 2018, 06:35:13 AM
 #9

the database stores the public keys, not the private keys

So the user wallet also has a private key and the broadcast contains actually a signed message? Then (surprisingly) this part could be fine. You'll have to ensure that every broadcast contains signed message, not just address.

However, as I also wrote, anybody can override the waiting by just making a couple of extra transactions. And yeah, as others said, the propagation can be a problem too (some nodes could see different number of transactions at a certain time and this could give the chance for double spend). So there are things that maybe can be polished.

bob123
Legendary
*
Offline Offline

Activity: 1078
Merit: 1575



View Profile WWW
October 19, 2018, 07:03:04 AM
Merited by bones261 (2)
 #10

Quote
1. What stopping attacker from double-spend attempt (example : attacker make 2 transactions (from an address contain 1 coin) where 1st transaction is sent 1 coin to Bob & 2nd transaction is sent 1 coin to Alice)?
1. The user won't be able to do a 2nd transaction until the list gets broadcasted.

Who is stopping the user to make this transaction ? What mechanism ensures that nobody can create a 2nd transaction EVER ?
How can anyone know whether i have already created a transaction if i didn't broadcast it yet ?

The only one in this scenario who knows this.. is me (and my client). And i have full control over my client.

So.. who is stopping me from creating a 2nd transaction ?



Quote
2. How do new nodes verify the balance is valid and not comes from thin air? Even ETH which uses Balance model (not UTXO like Bitcoin) still require storing transaction.
2. They would check if the digital signature is valid.

A signature is valid if the private key used to sign matches the public key.
I can sign 1000 transactions. And all of them would have a valid signature. But 999 of them won't be accepted, because they are double-spent. The only way to know this is an immutable synchronized 'storage' (which in bitcoins case is a blockchain).



You seem to lack the basic knowledge regarding public key cryptography and networks/IT.
While your idea might be sweet, it is not feasible at all.

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 20, 2018, 02:09:16 PM
 #11

Quote
Who is stopping the user to make this transaction ? What mechanism ensures that nobody can create a 2nd transaction EVER ?
How can anyone know whether i have already created a transaction if i didn't broadcast it yet ?
Well, If the user tries to do a second transaction, he would have to use his public address again. The network would just scan the entire list. If it finds a repetition in the use of the address, then it would know that the address was used the second time.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2092

Use SegWit and enjoy lower fees.


View Profile WWW
October 20, 2018, 02:19:26 PM
Last edit: October 20, 2018, 02:51:45 PM by ETFbitcoin
 #12

Quote
Who is stopping the user to make this transaction ? What mechanism ensures that nobody can create a 2nd transaction EVER ?
How can anyone know whether i have already created a transaction if i didn't broadcast it yet ?
Well, If the user tries to do a second transaction, he would have to use his public address again. The network would just scan the entire list. If it finds a repetition in the use of the address, then it would know that the address was used the second time.

You should learn a bit about network propagation, gossip protocol and game-theory in general.

Attacker could make 2 transaction and broadcast each transaction to different nodes. In theory, half of all nodes would get different transaction from same address before get the other transaction.
This would make each nodes have different list due to propagation delay and thus leads to split-chain.



Very simple visualization made by me with draw.io

Legend :
Ellipse = Node
Light Gray = attacker
Blue = node which receive transaction A first
Green = node which receive transaction B first
Red = node which receive transaction A and B at almost/same time.

In my visualization, verification and propagation time to each nodes are exactly same, so few nodes will receive both transaction A and B at same time. So, how do you solve this problem / what will red nodes do?

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 20, 2018, 02:45:45 PM
 #13

Quote
Attacker could make 2 transaction and broadcast each transaction to different nodes. In theory, half of all nodes would get different transaction from same address before get the other transaction.
This would make each nodes have different list due to propagation delay and thus leads to split-chain.
Well, we can borrow some of the architecture IOTA uses. A user with an unverified transaction has to conform and broadcast other user's transaction.
For example: If I send some money to someone else, then i would have to check the transaction of another user whose transaction isn't checked and verified. Someone else has to do the same thing to my transaction. The selection of which user has to verify my transaction would be done in random. Now I believe that you know how IOTA works so that i wouldn't have to explain the entire concept.

Does this solve the problem?
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2092

Use SegWit and enjoy lower fees.


View Profile WWW
October 20, 2018, 03:04:18 PM
 #14

Quote
Attacker could make 2 transaction and broadcast each transaction to different nodes. In theory, half of all nodes would get different transaction from same address before get the other transaction.
This would make each nodes have different list due to propagation delay and thus leads to split-chain.
Well, we can borrow some of the architecture IOTA uses. A user with an unverified transaction has to conform and broadcast other user's transaction.
For example: If I send some money to someone else, then i would have to check the transaction of another user whose transaction isn't checked and verified. Someone else has to do the same thing to my transaction. The selection of which user has to verify my transaction would be done in random. Now I believe that you know how IOTA works so that i wouldn't have to explain the entire concept.

Does this solve the problem?

I only know architecture of IOTA in general, but i think attacker could make few non-conflicting transaction which contain check/verification result of 2 different conflicting transaction made by attacker. I'm assuming the attacker modify random user/transaction selection (from wallet source-code) & i hear IOTA Tangle looks diversed/splited when visualized because those attacker.

So, that doesn't solve the problem IMO.

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 20, 2018, 03:19:16 PM
 #15

Well, according to the IOTA protocol, the attacker doesn't make the choice of which transaction it should verify. The other users do the selection. The other users select the attacker, not the attacker to other users. So, if the attacker changes the source code, it wouldn't matter because the attacker doesn't make the decision. The other users would randomly select the attacker and check the transaction

so, does this solve the problem?
bob123
Legendary
*
Offline Offline

Activity: 1078
Merit: 1575



View Profile WWW
October 21, 2018, 10:47:15 AM
 #16

[...]
Does this solve the problem?

[...]
so, does this solve the problem?


Why are you trying to 'fix' your concept by hook or by crook ?
You goal shouldn't be to have an idea with almost no technical details, and trying to 'solve' problems people find by thinking about this idea for a few minutes.

If you are serious with your approach, think properly about your idea, look for attack vectors, create a whitepaper.. and publish it.
But beginning with a small idea (which theoretically doesn't actually work) just to later add 'fixes' to it isn't that great..

Aritra Pramanik
Newbie
*
Offline Offline

Activity: 8
Merit: 1


View Profile
October 21, 2018, 01:59:33 PM
 #17

I am not trying to fix it up hook by crook.
Its just that I am explaining it in an easier language. U gyus asked questions and i answered
You can say that its polishing up the idea than fixing it up like that.
 its really different thinking of an idea and than to write it down.

and as u mentioned
Quote
But beginning with a small idea (which theoretically doesn't actually work) just to later add 'fixes' to it isn't that great..

can u please tell me why wouldnt it work.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2092

Use SegWit and enjoy lower fees.


View Profile WWW
October 21, 2018, 02:50:34 PM
Last edit: October 21, 2018, 06:06:20 PM by ETFbitcoin
 #18

Well, according to the IOTA protocol, the attacker doesn't make the choice of which transaction it should verify. The other users do the selection. The other users select the attacker, not the attacker to other users. So, if the attacker changes the source code, it wouldn't matter because the attacker doesn't make the decision. The other users would randomly select the attacker and check the transaction

so, does this solve the problem?

No, because as i mentioned previously, attacker can change IOTA client source code to verify transaction he want to. IOTA protocol (i assume you're talking about documentation) only mention how it works normally.

There are many articles/news about IOTA's double attack problem including their official blog at https://blog.iota.org/attack-analysis-the-simple-parasite-chain-42a34bfeaf23 and about non-default transaction selection attack at https://cryptonomist.ch/en/2018/07/12/tangle-technology-2/.

Quote
But beginning with a small idea (which theoretically doesn't actually work) just to later add 'fixes' to it isn't that great..

can u please tell me why wouldnt it work.

Because you clearly either don't have the basic or haven't done enough research for your consensus method. It's shown since your idea still have critical vulnerability.

I don't believe in asking people to show-up with a full-fledged idea/proposal to be the best we could do. As I understand, op got some idea and tries to share it with us, it is great and I appreciate it.

That being said, I have to thank you @Etfbitcoin and @Heretik,  @bob123, ... for contributing to this discussion, you guys did great job too. Unfortunately I'm personally overloaded with other projects and couldn't participate, but I'm following this thread and have found nothing harmful here.



I never ask something that hard, do i sound like that?

aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 718

always remember, remember the cause


View Profile WWW
October 21, 2018, 04:46:59 PM
 #19


Quote
But beginning with a small idea (which theoretically doesn't actually work) just to later add 'fixes' to it isn't that great..

can u please tell me why wouldnt it work.

Because you clearly either don't have the basic or haven't done enough research for your consensus method. It's shown since your idea still have critical vulnerability.
I don't believe in asking people to show-up with a full-fledged idea/proposal to be the best we could do. As I understand, op got some idea and tries to share it with us, it is great and I appreciate it.

That being said, I have to thank you @Etfbitcoin and @Heretik,  @bob123, ... for contributing to this discussion, you guys did great job too. Unfortunately I'm personally overloaded with other projects and couldn't participate, but I'm following this thread and have found nothing harmful here.

seoincorporation
Legendary
*
Offline Offline

Activity: 1526
Merit: 1518


BtcBoss


View Profile
October 22, 2018, 05:32:26 PM
 #20

I got this idea which has been revolving around my brain for over a year.
I was thinking of a new cryptocurrency which would achieve consensus not by processing but by waiting. What I mean by waiting is that the network would wait until x number of transactions are broadcasted and grouped together into a block. It might sound confusing but I would try my best to explain it. This is how this cryptocurrency would work.
•   Every computer would store the entire list of public addresses of every user (not in a blockchain)
•   To generate a new address, an user has to do some proof of work.
•   Once its done, the user can broadcast this new address to the network and all the other computers in the network can add this to their list of
         addresses
•   The computers also store the balance of each address
•   To make a transaction, the sender should broadcast the amount being sent and the receiver should broadcast the receiving amount (similar to how Raiblocks or nano works)
•   Now here comes the main part, the computers in the network would make a list of transactions being done. The list should contain x number of transactions, once that many transactions are broadcasted, the nodes can then use this list to update the previous list of balances.

Would this new consensus mechanism work?


Hello Aritra, I think that's a good idea, but we don't have enough power to run it... But it's a crazy big idea.

The main issues I see:

1.- What will happen if a user decides to send a spam attack, let's say 1,000,000 of 1 satoshi transaction every 10 seconds, that would be a lot of blocks in a short period of time.
2.- How many transactions are the right number to have on each block, and that's a hard question because banks with their credit and debit cards have 100,000 transactions per second. But if you make a 100,000 transactions block then would be boring to wait for a confirmation at the start.
3.- Let's think about the 1 transaction block, It would be possible with this system, but that means a crazy big blockchain.

.BitDice.               ▄▄███▄▄
           ▄▄██▀▀ ▄ ▀▀██▄▄
      ▄▄█ ▀▀  ▄▄█████▄▄  ▀▀ █▄▄
  ▄▄██▀▀     ▀▀ █████ ▀▀     ▀▀██▄▄
██▀▀ ▄▄██▀      ▀███▀      ▀██▄▄ ▀▀██
██  ████▄▄       ███       ▄▄████  ██
██  █▀▀████▄▄  ▄█████▄  ▄▄████▀▀█  ██
██  ▀     ▀▀▀███████████▀▀▀     ▀  ██
             ███████████
██  ▄     ▄▄▄███████████▄▄▄     ▄  ██
██  █▄▄████▀▀  ▀█████▀  ▀▀████▄▄█  ██
██  ████▀▀       ███       ▀▀████  ██
██▄▄ ▀▀██▄      ▄███▄      ▄██▀▀ ▄▄██
  ▀▀██▄▄     ▄▄ █████ ▄▄     ▄▄██▀▀
      ▀▀█ ▄▄  ▀▀█████▀▀  ▄▄ █▀▀
           ▀▀██▄▄ ▀ ▄▄██▀▀
               ▀▀███▀▀
        ▄▄███████▄▄
     ▄███████████████▄
    ████▀▀       ▀▀████
   ████▀           ▀████
   ████             ████
   ████ ▄▄▄▄▄▄▄▄▄▄▄ ████
▄█████████████████████████▄
██████████▀▀▀▀▀▀▀██████████
████                   ████
████                   ████
████                   ████
████                   ████
████                   ████
████▄                 ▄████
████████▄▄▄     ▄▄▄████████
  ▀▀▀█████████████████▀▀▀
        ▀▀▀█████▀▀▀
▄▄████████████████████████████████▄▄
██████████████████████████████████████
█████                            █████
█████                            █████
█████                            █████
█████                            █████
█████                     ▄▄▄▄▄▄▄▄▄▄
█████                   ▄█▀▀▀▀▀▀▀▀▀▀█▄
█████                   ██          ██
█████                   ██          ██
█████                   ██          ██
██████████████████▀▀███ ██          ██
 ████████████████▄  ▄██ ██          ██
   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ██          ██
             ██████████ ██          ██
           ▄███████████ ██████▀▀██████
          █████████████  ▀████▄▄████▀
[/]
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!