Gold collapsing. Bitcoin UP.

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Doesn't this just show how long low-fee transactions can lurk around on the network until they get mined?
thats the takeaway from all this, one cannot assume a TX will never confrim or get dropped.
is this expected behavior?
I can only imagine how many poeple "paid twice" because they didnt send a high enough fee and then simply decide to send another TX after hours of waiting for a TX to go though...
 
  • Like
Reactions: bluemoon and Norway

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Before someone comes up with "this is why we need RBF", I just want to ask:
It is possible to send a transaction with the same inputs but higher fee without RBF (a.k.a. double-spend), right?

I imagine it's just that wallets make this difficult, but at least Peter Todd had such a script, didn't he?

And if so, is it the case that wallets don't offer this purposefully so that people don't attempt double-spends all the time? Why don't they just build in a feature where you can attempt a tx with same input after some minimum time, e.g. 6 hours?
 

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
It is possible to send a transaction with the same inputs but higher fee without RBF (a.k.a. double-spend), right?

I believe so. If it's expired from most of the mempools, I believe it should get relayed. In the case of XT, I believe it gets relayed even if it (a conflicting transaction) is still in the mempool.

I actually don't have much of a problem with RBF but I think the majority of the community does and their concerns should have been respected.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Johnny Dilley [...] former member of the Pantera Capital team stated:
The fact that there is considerable tension and the fact that a hard fork hasn’t happened is actually the most-encouraging, most-bullish sign for Bitcoin that there’s been in two years. It means that the system works.
I think, today, we’re still no closer to any short-term movement (six months to a year) on the block size issue.
To be clear, I’m the most bullish Bitcoiner I know.
:rolleyes:
Source: https://bitcoinmagazine.com/articles/blockstream-s-johnny-dilley-we-ll-eventually-have-an-adaptive-block-size-solution-1460997499
 

johnyj

Member
Mar 3, 2016
89
189

johnyj

Member
Mar 3, 2016
89
189
Suppose I have 10 pre-fork bitcoins, and after a fork into core chain and classic chain, in principle, I can spend them on both chains. However, if it is prohibited software wise, then the fork will not destroy the economy integrity of bitcoin, e.g. limited total money supply. Thus a hard fork will become much safer

So, when I spend those UTXO on core chain, the classic software would detect core transactions in the mempool and send them to an unspendable address on classic chain. And when it is spent on classic chain, the classic software will also broadcast a core transaction, spend it on core chain into an unspendable address

Of course this will require that classic software to monitor transactions on both network, need some extra design and coding, but then we can safely have the hard fork and greatly reduce the chance of a splitting economy

In that case, exchanges can run both software. However, the post-fork coins with less hash rate support will have less value, so that no one with pre-fork coins will be interested in spending on that minority chain, the coins mined on that chain will also worth much less, so that chain become economically unfeasible to sustain after a while
 

Dusty

Active Member
Mar 14, 2016
362
1,172
Before someone comes up with "this is why we need RBF", I just want to ask:
It is possible to send a transaction with the same inputs but higher fee without RBF (a.k.a. double-spend), right?

I imagine it's just that wallets make this difficult, but at least Peter Todd had such a script, didn't he?
Yes, it's simply a matter of creating the right transaction: for example you can use this tool to automate the operation: http://gangsta.dassori.me/ . I know people that (for testing) used it and it worked fine in the past.

The fact that segwit and other soft forks can be merged without any consensus indicated that the system is broken
I think it's simply impossible to avoid soft forks because there is no way to detect them: by definition, applying a stricter rule can't lose compatibility with old clients and hence you can't avoid them.
[doublepost=1461015691][/doublepost]
i'm surprised someone hasn't ddos'd this. "no longer maintained":
http://bitcoinrelaynetwork.org/
Yes, Corallo was working at the relay network (a very useful service) before being summoned by BS.
But you know, since then BS is telling us that we can't raise the block size due to problems in relaying big blocks so it has discontinued the very service that effectively allows to relay big blocks very efficiently (it uses a very similar technique used by BU, but faster).

I think that the BS game can't get clearer than this.
 
Last edited:

albin

Active Member
Nov 8, 2015
931
4,008
@Dusty

I like to think that soft forks are basically indistinguishable from any mining strategy that involves intentionally orphaning otherwise valid blocks (such as theoretically what selfish mining would be), or 51% attacks. The rule that the 51% or selfish miner would be adding to his own validation criteria is whether the block is made by him.

This comparison might not actually turn out to be theoretical, imagine if Classic has enough hashpower support to prevent SF segwit activation. There will surely be temptation to 51% attack Classic-version miners by orphaning all their blocks. I'm sure there is code already in the pipe ready to deploy at Blockstream HQ for this exact contingency.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
ridiculous kyletorpey backpedaling?:

"Updated at 6:51pm EST: Bitcoin angel investor Roger Ver contacted Bitcoin Magazine about the Beijing meeting but declined to go into any detail about what took place. However, he told Bitcoin Magazine, "I think everyone who actually attended the meeting would disagree with what was stated in the article [posted below]."

https://bitcoinmagazine.com/articles/supporters-of-mb-bitcoin-blocks-unable-to-convince-miners-to-hard-fork-in-beijing-meeting-1461004264
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
i'm surprised someone hasn't ddos'd this. "no longer maintained":

http://bitcoinrelaynetwork.org/
I've heard it's "no longer maintained" but that's hardly the truth, In fact the Blockstream developers are just trying to distance themselves from it as it's become a fundamental service that is centrally controlled by their employees. Bitcoin Core have the Relay network maintenance and Relay Network v2.0 as a technical project they are willing to fund - (I'm presuming the Core developers are collectively fundraising and donating money to the developers who don't want to donate code.) more likely it's TPTB the BS folks who want to bend bitcoin to their will.
[doublepost=1461029639,1461029035][/doublepost]
Yes, Corallo was working at the relay network (a very useful service) before being summoned by BS.
But you know, since then BS is telling us that we can't raise the block size due to problems in relaying big blocks so it has discontinued the very service that effectively allows to relay big blocks very efficiently (it uses a very similar technique used by BU, but faster).

I think that the BS game can't get cleared than this.
the relay network works very well at reducing orphan rate giving an advantage to those who chose to use a centralised service controlled by Blockstream employees (i wish they would turn it off and shelve it).

It's a perversion of the idea that Bitcoin is a decentralised P2P network, BU is not similar or less efficient as it uses the Bitcoin Network the relay network is not in the same calss. Core should be looking at ways to make it obsolete not to improve it. BU may not have the same ability to reduce orphan rate but it keeps the benefit decentralised and the incentive design in tact it is still part of the Bitcoin Network of nodes and universal available.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
Suppose I have 10 pre-fork bitcoins, and after a fork into core chain and classic chain, in principle, I can spend them on both chains. However, if it is prohibited software wise, then the fork will not destroy the economy integrity of bitcoin, e.g. limited total money supply. Thus a hard fork will become much safer

So, when I spend those UTXO on core chain, the classic software would detect core transactions in the mempool and send them to an unspendable address on classic chain. And when it is spent on classic chain, the classic software will also broadcast a core transaction, spend it on core chain into an unspendable address

Of course this will require that classic software to monitor transactions on both network, need some extra design and coding, but then we can safely have the hard fork and greatly reduce the chance of a splitting economy

In that case, exchanges can run both software. However, the post-fork coins with less hash rate support will have less value, so that no one with pre-fork coins will be interested in spending on that minority chain, the coins mined on that chain will also worth much less, so that chain become economically unfeasible to sustain after a while
i think this is wrong.

classic nodes cannot simply change the TX it sees on the core chain.
all it can do is rebroadcast that exact same TX on its own chain.
which is interesting
if i get a payment on the core chain, i could just take that TX and broadcast it on the classic chain and get the paid both classic and core coins!
 
  • Like
Reactions: Norway

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@adamstgbit :
if i get a payment on the core chain, i could just take that TX and broadcast it on the classic chain and get the paid both classic and core coins!
Yes, folks would need to seperate their coins on the two chains (by sending them to different addresses) to prevent this. This is in itself a problematic process since it requires access to miners which are guaranteed to mine transactions only on a particular chain.

Transactions which involve only pre-fork inputs that have not been spent can be replicated by bridge nodes.
It is hard if not impossible to prevent such bridge nodes - the only counter I can think of is to make the transactions untranslatable which would require the fork to run a different signature scheme.
 
  • Like
Reactions: Richy_T

Dusty

Active Member
Mar 14, 2016
362
1,172
the relay network works very well at reducing orphan rate giving an advantage to those who chose to use a centralised service controlled by Blockstream employees (i wish they would turn it off and shelve it).
Yes, the relay network is centralized but anyone can run their own, and most of all: the principle it uses to propagate the new blocks are very efficient.
My opinion is that the bitcoin p2p protocol should adopt those techniques natively, without having to rely on an external, centralized service.
In fact something like this is being done in BU (xtreme thin blocks etc), but the relay network has a more advanced tech that I hope it will be implemented in BU in the future: the client remembers the txs sent to every peer so to send personalized xtreme blocks for each one of them instead of the same one for every peer.
This comes with a cost in memory and cpu, of course, but it's a really nice improvement.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
The really sad thing about the whole big block movement is that it is a honest attempt to save the miners asses @Jihan . No one on their side esp in Classic core dev stands to benefit directly from some for profit company like Blockstream is trying to do on the 1MB side.
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
@johnyj

There is no problem with doubling the supply of coins to 42M from 21M due to Core and Classic ledgers both existing. Everyone still owns the same percentage of the total ledger by default (and you can check the math to see that this remains true automatically even if Corecoins and Classiccoins have totally different prices), which is all that matters in terms of sound money.

If that isn't clear, note that 1BTC is just a shorthand for some small percentage of the total Bitcoin ledger, and that percentage is unaffected by making more copies of the ledger. You could have 7 forks and 147M BTC but everyone's stake and purchasing power remains the same by default in every ledger and every combination of ledgers, regardless of price changes or the failure of any fork-prong.

I think @freetrader is correct that some kind of minor change in signature scheme would be necessary along with the fork so that transactions intended for one side of the fork wouldn't automatically happen on both sides of the fork.