Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-08 Thread Mike Hearn
Yes, you're right. I didn't consider that case. But the problem is that this is not automatic. Currently there is a clear division between miners how will not take the kickback (irrrational) and miners who will (rational). This seems to come up a lot. Your definition of rational is a short

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner
On 06/10/2014 08:43 p.m., Tom Harding wrote: On 10/5/2014 4:00 PM, Sergio Lerner wrote: If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect the

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Gregory Maxwell
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote: Using the my previous terminology, automatic fee-sharing (ORBS) is a solution to the freeze problem (FRONT) but opens the windows to CHAKIDO double-spending. and CHAKIDO double-spending is a much worse problem than

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Sergio Lerner
On 07/10/2014 04:16 p.m., Gregory Maxwell wrote: Then I spend the output of the fraudulent spend nlocked one block higher, and spend the output of that one again, nlocked one block higher, and so on... each step paying fees. Yes, you're right. I didn't consider that case. But the problem is

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Alex Mizrahi
I've heard about this idea from TierNolan. Here's some quick an dirty analysis: Suppose the last known block claimed a large tx fee of L. A miner who owns 1/N of the total hashrate needs to choose between two strategies: 1. Mine on top of that block and win usual reward R with probability 1/N.

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Mike Hearn
the block size being lower than the instant offered demand (there is always a backlog) are both things which address the concern of this thread. :) I'm skeptical such a situation can ever be stable. People have no incentive to create a transaction that will remain stuck in the backlog

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Tamas Blummer
Note that the problem might arise also by a bug / accident and not as an attack. Since value spent is not part of the signature it is easy to create an arbitrary fee by a defective wallet software. Collecting that huge fee might provide a higher incentive to miner than the block subsidy on the

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Sergio Lerner
Comments between lines... On 06/10/2014 03:42 a.m., Alex Mizrahi wrote: . This doesn't require protocol changes(*) and can be simply incorporated into a piece of code which decides what to do when a transaction with unusually large fee appears. (I.e. it will automatically share the fee,

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Tamas Blummer
Sergio, you can call this an ORBS attack or an attempt of ad-hoc coalition forming for a fork. Preparation Step: Include a transaction sending a sizable amount between two of your own addresses in every block. Miner can do this at zero cost in their own blocks. Execution: Embed into the

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com wrote: I would like to share with you a vulnerability in the Bitcoin protocol I've been thinking of which might have impact on the future of Bitcoin. Please criticize it! The Freeze on Transaction Problem I should point

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com I should point you to some of the tools that have been discussed in the past which are potentially helpful here: Ah, I should also mention a somewhat more far out approach which helps here as a side effect: If transactions were

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io wrote: In any case, it is interesting to think about this things since mining subsidies will eventually disappear and then transaction fees will ALWAYS be higher than subsidies. You can imagine that instead of subsidy Bitcoin

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Jorge Timón
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Something you might want to try to formalize in your analysis is the proportion of the network which is rational vs honest/altruistic. Intuitively, if there is a significant amount of honest hashrate which is refusing