On Tue, Feb 28, 2012 at 17:48, Pieter Wuille wrote:
> Hello all,
>
> I've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible. The change is backward compatible in the same way BIP16
> is: if a supermajority
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille wrote:
> I've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible. The change is backward compatible in the same way BIP16
> is: if a supermajority of mining power
>I am not following you here, can you explain what you're thinking?
If I mine a duplicate coinbase of an old block (whether spent or not)
if that block is then invalidated DisconnectBlock() will erase both
the coinbase of the new block and of the old block. This leaves the
blockchain is in an inco
On Thu, Mar 01, 2012 at 01:09:02PM +, Ben Reeves wrote:
> One more thing to add. The implementation in the reference patch fixes
> the blockchain forking issue however by still allowing spent coinbases
> to be disconnected patched clients are still vulnerable to blockchain
> corruption. While n
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves wrote:
> One more thing to add. The implementation in the reference patch fixes
> the blockchain forking issue however by still allowing spent coinbases
> to be disconnected patched clients are still vulnerable to blockchain
> corruption. While not an imm
One more thing to add. The implementation in the reference patch fixes
the blockchain forking issue however by still allowing spent coinbases
to be disconnected patched clients are still vulnerable to blockchain
corruption. While not an immediate issue it would mean
LoadBlockIndex() would error on
Yes you are right. Any fix in DisconnectBlock() has the same potential issues.
I think the exchanges and major merchants need to be made aware that
they must also upgrade. Maybe bundle both BIP16 and BIP30 in 0.6 and
issue an advisory stating that this is a mandatory upgrade for
everyone.
It also
On Wed, Feb 29, 2012 at 11:00:42PM +, Ben Reeves wrote:
> I'm not sure. What if they use a coinbase of a block that has already matured?
Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old
coinbase.
The 100-blocks maturity will not help against is.
I'm not sure how
I'm not sure. What if they use a coinbase of a block that has already matured?
On Wed, Feb 29, 2012 at 10:46 PM, Gavin Andresen
wrote:
> On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves wrote:
>> A malicious miner can produce a duplicate coinbase which the majority
>> of clients will accept but the m
On Wed, Feb 29, 2012 at 5:05 PM, Ben Reeves wrote:
> A malicious miner can produce a duplicate coinbase which the majority
> of clients will accept but the majority of hashing power won't.
> Spending the coinbase output after
That can't happen until the coinbase matures, which takes 100 block
In other words when we roll out the update, we have to make sure we have
>>50% not just 50%. Something like 60%-75% should do fine (IMHO). In
other words we just have to be very, very vocal about the change when it
happens and make sure miners are all on board.
Matt
On Wed, 2012-02-29 at 22:05
Assuming 50% of hashing power adopts BIP30 but the actual client
install base is relatively low the patch will likely result in a
"hard" blockchain split if someone takes advantage.
A malicious miner can produce a duplicate coinbase which the majority
of clients will accept but the majority of has
> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in f
tcoin-development] Duplicate transactions vulnerability
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
>
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
> to figure it out for themselves. I, however, have the "niceness
> energy" to think ab
Could you spell out the attack explicitly? Presumably there aren't a
lot of people with the "malice energy" to perform the attack but not
to figure it out for themselves. I, however, have the "niceness
energy" to think about it for a few minutes but not to figure it out
for myself. If in your opini
I might be wrong but I think perhaps it would help to get this fix out before
the p2sh protocol change. Otherwise a miner could combine a duplicate coinbase
and an invalid P2SH transaction to create a block which can have excellent
network propagation and still be guaranteed to be orphaned. Thi
On Tue, Feb 28, 2012 at 01:23:01PM -0500, Luke-Jr wrote:
> Has it been verified to make even rocconor's complicated transaction-based
> version impossible?
Yes, he tried it on testnet against a patched node.
> > The purpose of this mail is asking for support for adding this rule to
> > the proto
On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
> A simple way to fix this, is adding an extra protocol rule[1]:
>
> Do not allow blocks to contain a transaction whose hash is equal to
> that of a former transaction which has not yet been completely spent.
>
> I've written about
>
> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in
On Tue, Feb 28, 2012 at 18:12, Brautigam Róbert
wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>
>> Do not allow blocks to contain a transaction whose hash is equal to
>> that of a former transaction which has not yet been completely spent.
>
> I don't know whether I
On 02/28/2012 05:48 PM, Pieter Wuille wrote:
> Hello all,
Hi,
> as some of you may know, a vulnerability has been found in how the
> Bitcoin reference client deals with duplicate transactions. Exploiting
> it is rather complex, requires some hash power, and has no financial
> benefit for the atta
Hello all,
as some of you may know, a vulnerability has been found in how the
Bitcoin reference client deals with duplicate transactions. Exploiting
it is rather complex, requires some hash power, and has no financial
benefit for the attacker. Still, it's a security hole, and we'd like
to fix this
23 matches
Mail list logo
