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

2014-10-05 Thread Sergio Lerner
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 * The freeze problem occurs if someone publishes a transaction with fees much higher than the bloc

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 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 you to some of the tool

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 > 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 using the BLS sh

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 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 came with a initial s

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 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 to aid the

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

2014-10-05 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. 2.

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 for

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 t

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

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 prefer

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

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 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 FRONT. I'm not

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