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
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
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
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
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
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.
>
> 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
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
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
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
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
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
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
>
> 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
14 matches
Mail list logo