Bitcoin Forum

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?

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.

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?

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

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


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


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


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.


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

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

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.

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.

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 ?




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.

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.

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?

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?

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

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

can u please tell me why wouldnt it work.

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.

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.

Hi Aritra,

The major problem with the approach that I can see is that it degrades to proof-of-work -- attackers with computational resources can produce blocks by brute-forcing the proof-of-work needed to create addresses and thus sybil the network by self-generating enough transactions to trigger block production. A second problem is that no-one is incentivized to propagate transactions.

If you are thinking along these lines, you might find Saito (http://saito.tech) interesting. It uses a proof-of-transactions approach that measures the work done by block producers in terms of the transaction fees they have collected. It is similar in the sense that it eliminates mining, but avoids these attack vectors.