Topic: Are we stress testing again? - page 13. (Read 33190 times)

What do you want it to do? hold tx's in mempool for longer time increasing memory requirements exponentially across the network? The real value of using the system is for VALID transactions. Ofcourse people are free (not literally) to try to fraudulently create bad tx's but that is the beauty of the consensus protocol that doesn't allow these to be entering the network and creates the value of what we call Bitcoin.

In software speak, I suggest we follow KISS which is what it is. A clear seperation of concerns and not worry about holding metadata or increasing tx lengths because of another small use-case of analytically drawing conclusions from that dataset that does not strongly correlate with the true intention of Bitcoin.

Quote from: SebastianJu on July 17, 2015, 07:32:04 AM

Indeed. There's a balance to be struck in any such risk/reward scenario. I can't see how the cost required would outweigh the relatively small benefit of having an extended record of the mempool. And if we did keep a record of anything that doesn't make it into the blockchain (i.e. errors and omissions) , how do you then make that record decentralised and tamper-proof? We'd have to have a new blockchain that records what doesn't go into the original blockchain, heh.

I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference.

Anyway, for non code monkeys, the longer explanation is as follows:

There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run.

Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up.

Wow. Jumping to conclusions much?

a) Not a coder. Can just about cope with basic HTML and CSS.
b) Saying "obviously" doesn't make your baseless (and frankly insane) accusations sound any more credible.
c) If you want people to take you seriously, this isn't how you go about it.

I'm sorry that someone on the internet disagreed with you because they thought your idea didn't sound practical. Try not to take it personally.

malykii

newbie

Activity: 43

Merit: 0

Quote from: achow101 on July 16, 2015, 12:09:21 PM

Quote from: malykii on July 16, 2015, 10:57:41 AM

Interesting. So it is potentially possible that BitPay never gets that transaction, and I receive what I purchased for free.

Yes, but the merchant should never ship their products without having at least 1 confirmation.

Though thats not how bitpay works. They only wait until they see the transaction and they have huge turnovers. I wonder two what will happen. They will have huge amounts of coins that dont reach at the moment.

My transactions still have no confirmations, and nothing has been communicated to me from the merchant or BitPay. I am going on almost 36 hours since the initial transaction happened.

SebastianJu

legendary

Activity: 2674

Merit: 1083

Legendary Escrow Service - Tip Jar in Profile

Quote from: achow101 on July 16, 2015, 12:09:21 PM

Quote from: malykii on July 16, 2015, 10:57:41 AM

Interesting. So it is potentially possible that BitPay never gets that transaction, and I receive what I purchased for free.

Yes, but the merchant should never ship their products without having at least 1 confirmation.

Though thats not how bitpay works. They only wait until they see the transaction and they have huge turnovers. I wonder two what will happen. They will have huge amounts of coins that dont reach at the moment.

canth

legendary

Activity: 1442

Merit: 1001

Quote from: sidhujag on July 16, 2015, 07:03:46 PM

I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference.

Anyway, for non code monkeys, the longer explanation is as follows:

There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run.

Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up.

There is a point in storing unconfirmed transactions in RAM. As a miner, nodes are holding those transactions in memory as the basis for forming the next block. Once the block is mined it needs to be broadcast - if the data is on disk then it adds extra latency to retrieve the data from disk before broadcasting it to the network. Yes, SSDs are very fast but for a miner there's no reason to introduce any latency in a system where speed is relevant and contributes to profitability.

turvarya

hero member

Activity: 714

Merit: 500

What do you want it to do? hold tx's in mempool for longer time increasing memory requirements exponentially across the network? The real value of using the system is for VALID transactions. Ofcourse people are free (not literally) to try to fraudulently create bad tx's but that is the beauty of the consensus protocol that doesn't allow these to be entering the network and creates the value of what we call Bitcoin.

In software speak, I suggest we follow KISS which is what it is. A clear seperation of concerns and not worry about holding metadata or increasing tx lengths because of another small use-case of analytically drawing conclusions from that dataset that does not strongly correlate with the true intention of Bitcoin.

Quote from: 2112 on July 16, 2015, 02:31:46 PM

Indeed. There's a balance to be struck in any such risk/reward scenario. I can't see how the cost required would outweigh the relatively small benefit of having an extended record of the mempool. And if we did keep a record of anything that doesn't make it into the blockchain (i.e. errors and omissions) , how do you then make that record decentralised and tamper-proof? We'd have to have a new blockchain that records what doesn't go into the original blockchain, heh.

I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference.

Anyway, for non code monkeys, the longer explanation is as follows:

There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run.

Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up.

Great lets exponentially increase bandwidth+storage requirements at 0 cost because fraud attempts knowingly will pay 0 fees and won't get in to a block but will be stored on the harddrives of their victims causing the whole network to shutdown in just a few days.

You don't know what you are talking about. Move along.

I guess not everybody would have to store such transactions, if there is a bureau that wants this data, they can store it them self.
I also don't see the concern about tempered records. You can't make a fake "address A tried to send money to address B"-transaction, since it still would have to be signed with the private key of address A.

Syke

legendary

Activity: 3878

Merit: 1193

Speaking in the Bitcoin terms:

The (financial) value of analyzing 'mempool' is significantly higher than analyzing 'blockchain (as stored on the disk for the "longest chain"'.

The great thing about bitcoin is all that information is public. If you think fraud, double-spend, abuse malleability, etc. are important, you're quite welcome to write a node that analyzes those issues. Sounds like an excellent project.

sidhujag

legendary

Activity: 2044

Merit: 1005

What do you want it to do? hold tx's in mempool for longer time increasing memory requirements exponentially across the network? The real value of using the system is for VALID transactions. Ofcourse people are free (not literally) to try to fraudulently create bad tx's but that is the beauty of the consensus protocol that doesn't allow these to be entering the network and creates the value of what we call Bitcoin.

In software speak, I suggest we follow KISS which is what it is. A clear seperation of concerns and not worry about holding metadata or increasing tx lengths because of another small use-case of analytically drawing conclusions from that dataset that does not strongly correlate with the true intention of Bitcoin.

Indeed. There's a balance to be struck in any such risk/reward scenario. I can't see how the cost required would outweigh the relatively small benefit of having an extended record of the mempool. And if we did keep a record of anything that doesn't make it into the blockchain (i.e. errors and omissions) , how do you then make that record decentralised and tamper-proof? We'd have to have a new blockchain that records what doesn't go into the original blockchain, heh.

I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference.

Anyway, for non code monkeys, the longer explanation is as follows:

There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run.

Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up.

Great lets exponentially increase bandwidth+storage requirements at 0 cost because fraud attempts knowingly will pay 0 fees and won't get in to a block but will be stored on the harddrives of their victims causing the whole network to shutdown in just a few days.

You don't know what you are talking about. Move along.

2112

legendary

Activity: 2128

Merit: 1073

What do you want it to do? hold tx's in mempool for longer time increasing memory requirements exponentially across the network? The real value of using the system is for VALID transactions. Ofcourse people are free (not literally) to try to fraudulently create bad tx's but that is the beauty of the consensus protocol that doesn't allow these to be entering the network and creates the value of what we call Bitcoin.

In software speak, I suggest we follow KISS which is what it is. A clear seperation of concerns and not worry about holding metadata or increasing tx lengths because of another small use-case of analytically drawing conclusions from that dataset that does not strongly correlate with the true intention of Bitcoin.

Indeed. There's a balance to be struck in any such risk/reward scenario. I can't see how the cost required would outweigh the relatively small benefit of having an extended record of the mempool. And if we did keep a record of anything that doesn't make it into the blockchain (i.e. errors and omissions) , how do you then make that record decentralised and tamper-proof? We'd have to have a new blockchain that records what doesn't go into the original blockchain, heh.

I kinda knew it that my post is going to attract some code monkeys and their attempts to burn the strawmen. I'm just going to quote them for the future reference.

Anyway, for non code monkeys, the longer explanation is as follows:

There's absolutely no point of storing the unconfirmed transactions in RAM. As any competent software engineer will explain you it is sufficient to store a cache (or map, in CS terms) of transaction hash to single bit, meaning "transaction was seen and it is known to be 'valid' or 'invalid'". The 'valid' transactions will ultimately get promoted to the permanent blockchain, the 'invalid' transactions are mostly of the forensic interest to investigate errors and attempted frauds. The transaction not in cache are neither 'valid' nor 'invalid', they just need the full verification run.

Obviously, some of those code monkeys are in the employ of the fraudsters who explicitly rely on their fraud attempts to get no permanent record on the blockchain. That's why I quoted them above, we'll see what fraud they will try to cook up.

DooMAD

legendary

Activity: 3934

Merit: 3190

Leave no FUD unchallenged