Bitcoin Forum
April 25, 2024, 03:38:02 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Priority Transactions; What Are The Implications?  (Read 1047 times)
gogxmagog (OP)
Legendary
*
Offline Offline

Activity: 1456
Merit: 1009

Ad maiora!


View Profile
November 20, 2015, 08:38:12 PM
Last edit: November 20, 2015, 08:48:44 PM by gogxmagog
 #1

I was just reading about how BTCC is offering priority tx to users. If they want faster confirmations they pay extra and get pushed to the next block. BTCC has 13% of the network so I guess this method might work pretty good (for speeding up the tx in question) but I fear that all manner of negatives will come with it. If BTCC can make profits at this more parties will start doing it, pools and groups will form, it will be like mining where there is an arms race. Then it is all over the place and regular little tx fee transactions will take forever (like when stress testing)

I realize not all transactions require super fast confirmation but some types are dependant on it. Is this going to kick off a new arms race? What can be done to stop this before it gets out of hand? Bigger blocks? Are we finally going to see btc's inability to scale?

I've got a bad feeling about this but I don't understand the tech enough. Need I worry?

EDIT I just saw a thing on the Lightning Network which I didn't 100% understand but get enough of to see it is different than this (off chain) would Alan not be the perfect remedy to prioritized tx?
1714059482
Hero Member
*
Offline Offline

Posts: 1714059482

View Profile Personal Message (Offline)

Ignore
1714059482
Reply with quote  #2

1714059482
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714059482
Hero Member
*
Offline Offline

Posts: 1714059482

View Profile Personal Message (Offline)

Ignore
1714059482
Reply with quote  #2

1714059482
Report to moderator
elliwilli
Sr. Member
****
Offline Offline

Activity: 307
Merit: 250


et rich or die tryi


View Profile WWW
November 20, 2015, 09:03:28 PM
 #2

I don't really like it.
Like, its great for "Casual" users but it kind of defeats the point of the openness of the protocol, having priority transactions would not be good for the network and therefore by extension decrece the value of bitcoin.
There is a lot to be said for the intangible value that all transactions have equality in bitcoin.

2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1065



View Profile
November 20, 2015, 09:54:55 PM
 #3

Well, some people didn't learn from the history about cross-subsidizing. So the time to start learning is about now.

https://en.wikipedia.org/wiki/Conglomerate_(company)

Edit: one more Wikipedia link that is relevant both historically and currently:

https://en.wikipedia.org/wiki/Hong_(business)

I wonder if it is possible to produce any theoretical results on the conglomerates:

1) mining pool integrated with an exchanger
2) mining pool integrated with a service provider
3) two or more mining pools (one bitcoin, other alt-chains) joined together through an exchange

Cross-subsidies may be a new frontier. Conglomerates became popular after 1960 to deal with the variance in the dividend income. They still exist in a vastly narrower range, primarily to extract the additional profits from cross-promotion and unified bargaining.

Using your terminology a conglomerate would convert the green line to a green plane: high risk and high variance wouldn't be the opposites but a pair of coordinates on a plane.

Limiting block size creates an inefficiency in the bitcoin system.  Inefficiency = profit.  This is a basic law of economics, though it is usually phrased in such a way as to justify profits by pointing out that they eliminate inefficiencies.  I am taking the other position, that if we want mining to be profitable then there needs to be some artificial inefficiency in the system, to support marginal producers.  Of course that profit will attract more hashing power thus reducing/eliminating the profit, but at a higher equilibrium.  However, I am not too worried about this aspect of large block sizes.  It is a fairly minor problem and one that is a century away.
This is fairly common misconception that the only way to pay for the space in a mined Bitcoin block is with fees denominated in bitcoins. But this is not true when a miner is integrated with an exchange, because an exchange can shave commissions on both sides of the transactions.

Imagine for a moment that Bitfury branches out into Consolidated Furies and spawns Hryvnafury, Roublefury, Eurofury, DollarFury, etc.; all of them being exchanges. It can then easily outcompete pure Bitcoin miners because it can directly funnel fiat commissions into electric utility bills without having to go twice through the fiat<->coin exchange.

Edit: In fact opportunities for integration are not limited to mining + coin exchange. Imagine for example Marijuanafury which does two things demanding lots of electricity: Bitcoin mining and indoor marijuana growing. If only somebody could come up with new optical ASIC technology that is pumped with energy via photons at the same wavelength that stimulate photosynthesis...


Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
lottoshares
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
November 20, 2015, 11:09:54 PM
 #4

<snip>
EDIT I just saw a thing on the Lightning Network which I didn't 100% understand but get enough of to see it is different than this (off chain) would Alan not be the perfect remedy to prioritized tx?

The impression I have of the Lightning Network is that it will be centralized and therefore open to regulation. It might suit off chain high frequency micro transactions, but exchanges do that anyway and most of them are being regulated. Prioritized transactions will also be channeled through a centralized pool, and I wonder if that too will be open to regulation by whatever country the owners reside in.
droark
Sr. Member
****
Offline Offline

Activity: 525
Merit: 282


View Profile WWW
November 21, 2015, 02:37:08 AM
 #5

<snip>
EDIT I just saw a thing on the Lightning Network which I didn't 100% understand but get enough of to see it is different than this (off chain) would Alan not be the perfect remedy to prioritized tx?

The impression I have of the Lightning Network is that it will be centralized

Huh Where did you get that impression? I suppose that, due to routing preferences, a lot of people could use a node supplied by a company subject to KYC/AML laws. The concept is definitely not designed around centralization, though.
piggybank
Newbie
*
Offline Offline

Activity: 49
Merit: 0


View Profile WWW
November 21, 2015, 06:57:21 AM
 #6

BTCC prioritizing transactions feels like a bad development. I've always been somewhat on the fence about increasing the blocksize, but if the result of not increasing the blocksize is transactions being prioritised based on their 'background', who they know or where they are from (let's coin this 'transaction racism' - that's sufficiently silly and serious to spark some controversy) then I have to say I'm definitely swinging more towards increasing blocksize.

We’ve always known there no defined order to transactions getting accepted, but to add ordering based on origin or some predetermined contractual agreement between companies in a conglomerate (+1 @2112) feels like a very bad direction to be heading.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
November 21, 2015, 06:03:52 PM
 #7

I am boggling at people making a big deal about this.

Exchanges and such getting priority handling is nothing new: MTGox was doing it in 2011 (giving hosting to eligius in exchange for priority handling); and many other miners do as well. I understand F2Pool even has a paid access API. Being able to directly prioritize transactions is one of the reasons to participate in mining.

If you google 'gmaxwell out of band fees' you'll find many examples of me pointing out this-- e.g. making sure that fee estimation code isn't confused by it.

This doesn't change anything about fee market behavior: a fee is a fee regardless of how you pay it, including if its paid with service or in-kind.  They'll be less need for this sort of thing once RBF is deployed with 0.12, because there will be a uniform mechanism for everyone to revise their fees.

Prioritizing transactions is also a maintained, documented and supported feature in Bitcoin Core, and has been for years:


prioritisetransaction <txid> <priority delta> <fee delta>
Accepts the transaction into mined blocks at a higher (or lower) priority

Arguments:
1. "txid"       (string, required) The transaction id.
2. priority delta (numeric, required) The priority to add or subtract.
                  The transaction selection algorithm considers the tx as it would have a higher priority.
                  (priority of a transaction is calculated: coinage * value_in_satoshis / txsize)
3. fee delta      (numeric, required) The fee value (in satoshis) to add (or subtract, if negative).
                  The fee is not actually paid, only the algorithm for selecting transactions into a block
                  considers the transaction as it would have paid a higher (or lower) fee.

Result
true              (boolean) Returns true

Examples:
> bitcoin-cli prioritisetransaction "txid" 0.0 10000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "prioritisetransaction", "params": ["txid", 0.0, 10000] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


So effectively people are making a fuss about a miner using a feature of Bitcoin Core thats been around forever in entirely the expected way.  Weird.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!