4 ms·

It's a permissioned system. A bank, basically.

infogulch 5y ago
So, validators are centrally controlled? I guess that'll be nice for existing real-world institutions or Ripple or something.
- f7ebc20c97 5y ago
  Yeah. The developers hardcode (eg) 100 validators into the client. Transactions need to be signed by 67 of them. Why not require only 51? Maybe there could be a permissionless way to get all clients to deterministically agree on who the validators are...maybe using something called proof of work... I've considered a completely different system called proof-of-fee that has no miners or stakers: - Each transaction pays a fee (that is either redistributed or burned) - The best blockchain is the one with the most fees paid - Each transaction signs the previous block - The blockchain length is limited to 1 block per 15 seconds - Nodes put their own transactions into the current block or make a new block with it (depending on if the blockchain length is maxed out) and broadcast it. No miners or stakers, everyone's equal. Therefore, in order to replace a buried transaction (to double-spend), you'd need to pay more fees than all the transactions in blocks that were burying your old one. This would be unprofitable for deeply buried transactions. There would be a lot of reorganization going on around the blockchange time at the 15 second mark, but that's an engineering problem.
  - javert 5y ago
    Wouldn't this make double spend attacks very practical? I mean, if I spend $X, someone is incentivized to steal if the fee I pay is less than $X. I realize this gets better as more blocks are added to the end of the chain. But it seems like this system would never work for relatively large payments. It may work fine for small value payments. It's illustrative to think about the amount of bitcoin transferred in a block vs. the amount of fees paid. The former enormously dominates the latter. I say this not to criticize, but to continue the discussion. Your idea is interesting.
    - f7ebc20c97 5y ago
      It gets better as more transactions are added to the end of the chain (in any later blocks). If fees are fixed at 0.1%, the average transaction only has to be buried by 1000 more average transactions. Most transactions are smaller than average, so they don't have to wait that long. This also means that transactions are buried faster the more heavily the blockchain is used. For example, you'd only have to wait one block if there were 1000 transactions in it. The only problem is if the double-spender is trying to double-spend 100 transactions at the same time...
      - javert 5y ago
        I appreciate the mathematical precision there. Still, my intuition is that it wouldn't work very well for large payments. I mean, if the average payment is $1 or $5 worth of value, but sometimes someone wants to buy a car or a house, how does that work out? I suppose it would be possible to write a simulation to try to figure it out, although there may be a more elegant and mathematical way to think about it. Have you thought about creating a whitepaper or some sort of website, or actually starting this kind of project? Or is it just a fun idea?
        deleted 5y ago
        [deleted]
        f7ebc20c97 5y ago
        Basically, how big of a payment you can do depends on how much volume there is. It's a positive feedback loop, though. There will be a distribution of transaction values with a median less than the mean, as seen in credit cards, swift, and all other payment systems. There's a long tail of large value transactions that would have to wait longer. So if you buy a car you'd have to wait for the equivalent of 1000 more car-valued transactions to occur, but this is helped by the ton of smaller-valued transactions backing you up. If the maximum someone is willing to wait for a transaction to be confirmed is 1 hour, then the ceiling of acceptable transaction value is 0.1% of the sum of total value transacted per hour, but this gradually rises as the system gets more popular. If you think about it, a similar phenomenon happens in any payment scheme, more or less. Even Bitcoin would make you wait a long time for a trillion dollar transaction because the cost of mining a double-spend would take a long time to reach a trillion dollars. In the early days you wouldn't trust it with even a $10,000 transaction because anyone could farm out a huge mining operation. I had some funding, worked on it for a year solid, built working prototypes, learned a lot, prepared for a whitepaper, but then I realized that an attacker could still profitably double-spend if they made a ton of small payments at the same block to different people. This would show up as a suspiciously-large transaction volume though... I think it means that (worst case) to accept an avg payment you'd have to wait for 1000 avg blocks instead of 1000 avg transactions...? If the fee was 1%, instead, though, you'd only have to wait 100 blocks, so it becomes reasonable? I'm kind of stuck and have nobody to talk to about it... Edit: You've inspired me to again work on this! Thanks! Let's consider this "worst-case" scenario with 100% of txs are made by the same attacker with an intent to double-spend. Before generalizing, let's fix the amounts to 1000 txs/block with a payment price of $100/tx with a $1 fee/tx. Block 1: The attacker sends 1000 txs (the "payments") worth $100 each to 1000 different merchants. He pays $1000 in fees. He stands to have revenues of 1000 x $100 = $100,000 if he can double-spend the payments. His payments are currently buried by 1000 x $1 = $1000 in their own fee costs, for a net profit of $99,000 if the merchants accept his payments right now. The merchants are cynical and rationally choose to wait until this block is buried by 1000 x 100 x $1 fee/tx = $100,000 in fees before accepting the payments. (It doesn't even matter if they know he's trying to double-spend or not). Block 2: The attacker sends 1000 loopback txs to himself to bury his payments in another 1000 x $1 = $1000 of fees. $98,000 to go... Block 3, 4, 5, ... 100: The attacker sends 1000 loopback txs to himself per block for 98 blocks to bury his payments in another 1000 x $1 x 98 = $98,000 of fees for a total of $100,000 in costs. The merchants are now satisfied with the payments and accept them as honest transactions. The merchants send the attacker $100,000 in goods. At this point, the attacker replaces block 1 with another block that is just full of loopback txs to himself rather than payments to the merchant. He then replaces blocks 2-100 with a new set filled with loopbacks. Then he makes block 101 with one loopback tx to himself so as to outbury the old blockchain with an extra $1. The attacker's current revenues are $100,000 in goods, but he had to pay $100,001 in fees to do it. We can generalize this to mean that to trust a transaction, worst-case, you have to wait until the the total payment value of the block itself is buried by its own value in transaction fees. Therefore, you'd have to enforce minimum % fees because, if you allow low transaction fees then an attacker could send a huge loopback transaction that makes everyone else in the block to have to wait a long, long time until enough fees bury that block. Maybe you could solve this using fixed block sizes that force transactions to have to bid for a spot. I guess you have to do that anyway, though...

So, validators are centrally controlled? I guess that'll be nice for existing real-world institutions or Ripple or something.

f7ebc20c97 5y ago
Yeah. The developers hardcode (eg) 100 validators into the client. Transactions need to be signed by 67 of them. Why not require only 51? Maybe there could be a permissionless way to get all clients to deterministically agree on who the validators are...maybe using something called proof of work... I've considered a completely different system called proof-of-fee that has no miners or stakers: - Each transaction pays a fee (that is either redistributed or burned) - The best blockchain is the one with the most fees paid - Each transaction signs the previous block - The blockchain length is limited to 1 block per 15 seconds - Nodes put their own transactions into the current block or make a new block with it (depending on if the blockchain length is maxed out) and broadcast it. No miners or stakers, everyone's equal. Therefore, in order to replace a buried transaction (to double-spend), you'd need to pay more fees than all the transactions in blocks that were burying your old one. This would be unprofitable for deeply buried transactions. There would be a lot of reorganization going on around the blockchange time at the 15 second mark, but that's an engineering problem.
- javert 5y ago
  Wouldn't this make double spend attacks very practical? I mean, if I spend $X, someone is incentivized to steal if the fee I pay is less than $X. I realize this gets better as more blocks are added to the end of the chain. But it seems like this system would never work for relatively large payments. It may work fine for small value payments. It's illustrative to think about the amount of bitcoin transferred in a block vs. the amount of fees paid. The former enormously dominates the latter. I say this not to criticize, but to continue the discussion. Your idea is interesting.
  - f7ebc20c97 5y ago
    It gets better as more transactions are added to the end of the chain (in any later blocks). If fees are fixed at 0.1%, the average transaction only has to be buried by 1000 more average transactions. Most transactions are smaller than average, so they don't have to wait that long. This also means that transactions are buried faster the more heavily the blockchain is used. For example, you'd only have to wait one block if there were 1000 transactions in it. The only problem is if the double-spender is trying to double-spend 100 transactions at the same time...
    - javert 5y ago
      I appreciate the mathematical precision there. Still, my intuition is that it wouldn't work very well for large payments. I mean, if the average payment is $1 or $5 worth of value, but sometimes someone wants to buy a car or a house, how does that work out? I suppose it would be possible to write a simulation to try to figure it out, although there may be a more elegant and mathematical way to think about it. Have you thought about creating a whitepaper or some sort of website, or actually starting this kind of project? Or is it just a fun idea?
      - deleted 5y ago
        [deleted]
      - f7ebc20c97 5y ago
        Basically, how big of a payment you can do depends on how much volume there is. It's a positive feedback loop, though. There will be a distribution of transaction values with a median less than the mean, as seen in credit cards, swift, and all other payment systems. There's a long tail of large value transactions that would have to wait longer. So if you buy a car you'd have to wait for the equivalent of 1000 more car-valued transactions to occur, but this is helped by the ton of smaller-valued transactions backing you up. If the maximum someone is willing to wait for a transaction to be confirmed is 1 hour, then the ceiling of acceptable transaction value is 0.1% of the sum of total value transacted per hour, but this gradually rises as the system gets more popular. If you think about it, a similar phenomenon happens in any payment scheme, more or less. Even Bitcoin would make you wait a long time for a trillion dollar transaction because the cost of mining a double-spend would take a long time to reach a trillion dollars. In the early days you wouldn't trust it with even a $10,000 transaction because anyone could farm out a huge mining operation. I had some funding, worked on it for a year solid, built working prototypes, learned a lot, prepared for a whitepaper, but then I realized that an attacker could still profitably double-spend if they made a ton of small payments at the same block to different people. This would show up as a suspiciously-large transaction volume though... I think it means that (worst case) to accept an avg payment you'd have to wait for 1000 avg blocks instead of 1000 avg transactions...? If the fee was 1%, instead, though, you'd only have to wait 100 blocks, so it becomes reasonable? I'm kind of stuck and have nobody to talk to about it... Edit: You've inspired me to again work on this! Thanks! Let's consider this "worst-case" scenario with 100% of txs are made by the same attacker with an intent to double-spend. Before generalizing, let's fix the amounts to 1000 txs/block with a payment price of $100/tx with a $1 fee/tx. Block 1: The attacker sends 1000 txs (the "payments") worth $100 each to 1000 different merchants. He pays $1000 in fees. He stands to have revenues of 1000 x $100 = $100,000 if he can double-spend the payments. His payments are currently buried by 1000 x $1 = $1000 in their own fee costs, for a net profit of $99,000 if the merchants accept his payments right now. The merchants are cynical and rationally choose to wait until this block is buried by 1000 x 100 x $1 fee/tx = $100,000 in fees before accepting the payments. (It doesn't even matter if they know he's trying to double-spend or not). Block 2: The attacker sends 1000 loopback txs to himself to bury his payments in another 1000 x $1 = $1000 of fees. $98,000 to go... Block 3, 4, 5, ... 100: The attacker sends 1000 loopback txs to himself per block for 98 blocks to bury his payments in another 1000 x $1 x 98 = $98,000 of fees for a total of $100,000 in costs. The merchants are now satisfied with the payments and accept them as honest transactions. The merchants send the attacker $100,000 in goods. At this point, the attacker replaces block 1 with another block that is just full of loopback txs to himself rather than payments to the merchant. He then replaces blocks 2-100 with a new set filled with loopbacks. Then he makes block 101 with one loopback tx to himself so as to outbury the old blockchain with an extra $1. The attacker's current revenues are $100,000 in goods, but he had to pay $100,001 in fees to do it. We can generalize this to mean that to trust a transaction, worst-case, you have to wait until the the total payment value of the block itself is buried by its own value in transaction fees. Therefore, you'd have to enforce minimum % fees because, if you allow low transaction fees then an attacker could send a huge loopback transaction that makes everyone else in the block to have to wait a long, long time until enough fees bury that block. Maybe you could solve this using fixed block sizes that force transactions to have to bid for a spot. I guess you have to do that anyway, though...