- Aug 19, 2015
- 511
- 803
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
No. i said this correctly. Even if only BU implements the change, it does not affect the security of 0 conf transactions.
its not that only 10% will accept it. it is that the other 90% will actively throw it away. if an attacker relays a different tx 26 right here, it is still rejected by the 90% because the limit is 25 and there is no change.
As soon as the first 25 are mined, the 10% that still have tx 26 push it to the rest of the 90% again. this time the 90% will accept it.
if an attacker pushes a different transaction for number 26 to the 90% nodes right as the new block is mined, this is no different than if they pushed 2 different tx from the start. same race conditions. no change.
Only that in the regular case the race happens withing seconds where in the above scenario the attacker has 10 minutes.
It is the same.
lets say you push 25txs that are the same, and then 26 and 26p are differing transactions.
for the nodes that are not BU. they will not validate 26 or 26p once they realise it is past the 25 ancestor limit. it will not go into the mempool. it will not go into the orphan pool. it will be entirely discarded as if they never received it.
the BU nodes will have the normal race condition for the fist few seconds.
AFTER the next block is mined. 26 and 26p (which are now 1 and 1p since all ancestors are in a previous block) will be rebroadcast to the non BU nodes that initially threw them away. the same couple second race condition will ensue.
if instead, you wait to broadcast 26p right as that next block is mined, you still end up with a couple second race condition because the non BU nodes threw away 26 earlier and are now just receiving it.
If you still think the attacker has 10 minutes after that explanation, can you try to elaborate on why? Maybe i am not understanding where you think this extra 10 minutes is coming from.
He has 10 minutes where the tx has already been accepted by 10% of the network.
A node that has a connection to this 10% would also get the tx in its mempool (e.g. it could show up in a block explorer).
And after 10 minutes there is no guarantee that the 10% will immediately broadcast the old tx which could give the attacker more than enough time to send the double spend to the other 90% of the network without any danger of a race with the original tx.
Oh, i see. BU nodes forward txs when the nodes have become acceptable by the peer, not when they are accepted by the BU node. If the peer does not provide custom params for acceptance, the network defaults are used. As soon as a new block is mined, txs in chains that are longer than the default are relayed to peers immediately.
There is an explanation on this here: https://medium.com/ @g.andrew.stone/quasi-consensus-and-the-unconfirmed-transaction-chain-limit-22e74e33421d
had to add a space in that url because i was having issues pasting it into this comment
That's a great mitigation.
Anyways, it might behave very similar but it is not the same.
I'm not here to attack BU.
This all started by me pointing out that others attacked BU.
That's what was in the heart of my message.
I think we have wasted enough time on this.
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
i'd wager the Kleiman v. Wright case will be thrown out. it would seem Kleiman has no standing and the FL court no jurisdiction.
next up: McCormack, that fool.
next up: McCormack, that fool.
It's so nice that I use moneybutton more often than I check this thread or go to reddit..
I'd bet most BCH guys have significantly more daily twitter posts than actual lifetime BCH transactions.
I'd bet most BCH guys have significantly more daily twitter posts than actual lifetime BCH transactions.
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
is it possible that after the IFP abomination and the DAA debacle miners will continue to use ABC node software, similar to how the market continues to price BCH higher than BSV despite trailing in all objective metrics?
it certainly is possible, despite ABC cracking internally and BCH devs being entirely fed up with séchet's incompetent reign.
but let's see you shine, BCH! the dark night is passing, miners will act, collaborative devs will unite, a stable protocol will coalesce, an economy will rise, P2P cash for the world is around the corner, the only thing to fear is fear itself!
it certainly is possible, despite ABC cracking internally and BCH devs being entirely fed up with séchet's incompetent reign.
but let's see you shine, BCH! the dark night is passing, miners will act, collaborative devs will unite, a stable protocol will coalesce, an economy will rise, P2P cash for the world is around the corner, the only thing to fear is fear itself!
bitsko
Active Member
- Aug 31, 2015
- 730
- 1,532
I forget who it was in BU or flowbee that came up with the Op-code idea, but I did think that the reasons for the inclusion amounted to political maneuvering.
unfortunate dudes like @Wecx preaching the merits of the opcode for months on end, it was clear then as it is now. too bad for that crock of shit narrative and op_unimportant
Post automatically merged:
fuck off amaury too late
https://imgur. com/ba41lIQ
Last edited:
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
. . . and yet the urge to keep tooling with the protocol will not stop:
bitco.in
except when a protocol change proposed by someone else brakes an app you happen to be building, then the solution is to push for a ban of just that type of change:
bitco.in
@Jonathan Silverblood this way exhaustion lies.
BUIP149: Delimited OP_RETURNs
BUIP149: Delimited OP_RETURNs Submitted by: Jonathan Silverblood Date: 2020/06/27 Status: DRAFT PROPOSAL Summary The purpose of this BUIP is to get a commitment from Bitcoin Unlimited to support a proposal to change how OP_RETURN functions within Bitcoin Cash. Proposals I propose that we...
bitco.in
except when a protocol change proposed by someone else brakes an app you happen to be building, then the solution is to push for a ban of just that type of change:
BUIPxxx: Reject past-drift correcting DAAs
BUIPxxx: Reject past-drift correcting DAAs Submitted by: Jonathan Silverblood Date: 2020/07/29 Summary The purpose of this BUIP is to reject any DAA alternative implementation that corrects for past drift, including the Grasberg algorithm, for the Bitcoin Unlimited node software. Proposals I...
bitco.in
@Jonathan Silverblood this way exhaustion lies.
kostialevin
Member
- Dec 21, 2015
- 55
- 147
bitsko
Active Member
- Aug 31, 2015
- 730
- 1,532
At least this time the BCC ticker is free.
(in 2017 it was used for Bitconnect)
Post automatically merged:
s/Craig Wright/Amaury Sechet/g
Last edited:
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
ok . . . so this is how we negotiate: i'll take your DAA, you take my IFP, conversation over.
Grasberg is no more.
I guess the IFP is now only 8% instead of the previous 12.5% because all the other node implementations have fallen out of grace and will not get anything anymore.
But
Post automatically merged:
I guess the IFP is now only 8% instead of the previous 12.5% because all the other node implementations have fallen out of grace and will not get anything anymore.
79b79aa8
Well-Known Member
- Sep 22, 2015
- 1,031
- 3,440
and grasberg was just a 'negotiating' tactic, something to give up in order to impose IFP.
BCH was stillborn. bitcoin lives on.
BCH was stillborn. bitcoin lives on.
