Topic: Microsoft Researchers Suggest Method to Improve Bitcoin Transaction Propagation - page 5. (Read 17557 times)

Yup.  Often providing payment perverts incentives too.  forwarding txn is so damn cheap that lots of people will do it for 'free' (just the compensation of helping the network overall).... once you start paying people won't forward txn that have too many hops for them to get paid on anymore.

Another thing not discussed in the embodiment of the payment chain.   Here is how it would have to work:

Today you construct SIGN_A(TX()) and that gets flooded. Under this system you'd have to instead construct   SIGN_A(TX()+PEER_X)  for each of your X peers. Then, peer B for example would construct   SIGN_B(SIGN_A(TX()+PEER_B)+PEER_C)  .. and C would construct SIGN_C(SIGN_B(SIGN_A(TX()+PEER_B)+PEER_C)+PEER_D)  ... and so on.  So each hop would now require $HOPS expensive signature validations, plus an expensive signing operation per next-hop peer, and would also add ~130 bytes of data (the next public key and a signature).  Just two hops would easily more than double the computational and storage cost of the transaction.

It's a neat area of research, but I'm doubtful that its actually applicable to bitcoin.

Um it isn't that hard.  A node is only a node when the client is running.   If you have 100K users but they on average only have the client running for 2 minutes a day then in effect at any particular time you only have a couple hundred nodes running.  It has nothing to do w/ a govt attacking Bitcoin. 

Not running client all the time? This generally is similar to Bitcoin network geting attacked by large goverment or probably even ANO and only one or two nations have Bitcoin network in operable state. The network are resistant to such attacks as I read long time ago. Does simply not running Bitcoint client all the time affects the network at all?

I think Microsoft's assumption of a directed graph oversimplifies things to the extent that in invalidates their research.  In short, a node always has an incentive to try and follow the chain back towards the source to insert themselves higher in the chain and to shorten it.  This gives them a larger reward.

Acording to their  paper, each node in the chain up to a depth of 'H' gets a reward B.  The node that solves the block gets a fixed reward plus some additonal reward based on how much shorter than H the chain was "1+(H-L+1)B"  This means the shorter the chain is, the greater the reward that goes to  the miner.  For simplicity, lets take H to be 4 and a chain of the full length:

NodeA
NodeB
NodeC
NodeD

NodeD solves the transaction so gets a reward of 1+(4-4+1)*B = 1+B. The total reward would be B for NodeA, NodeB, and NodeC and 2B for NodeD for a total of 1+4B.  However, if NodeD were able to contact NodeA directly the chain would be:

NodeA
NodeD

Node D again solves the transaction but this time its reward is 1+(4-2+1)*B = 1+3B with nodeA getting the remaining B, the total reward is still 1+4B.

Initially NodeD doesn't know how to contact NodeA, it only has a public key not an IP address, however, over time, as NodeD sees more transactions it will be able to associate particular keys with particular IP addresss.  For instance, in the first example, NodeD learned what NodeC's ip address is since it got the transaction directly from it.  In the event that NodeD didn't know how to contact any other nodes in the chain, it would be to its advantage to contact every node it knows and ask for the transaction in the hopes that one peer would be part of a shorter chain, this could greatly increase the amount of traffic that goes over the network.

The stated goal of the paper was to incentivise forwarding of transactions by paying intermediate nodes.  Intermediate nodes, however, would be cut out of the chain fairly quickly so would have the same incentive they have today (which is none, but that may not stop them from forwarding).

This scheme could have a perverse effect though.  Right now you can't gain any real advantage by trying to monopolize the connections a node has.  Under this proposal you would.  If all the nodes connected to a particular originating node were controlled by you, you couldn't be cut out of the chain since no one would know how to contact the originating node.  Instead of encouraging more peers by providing them with fees, it would encourage more centralization.

Your own impact on the breaking of the network is near zero. The impact of all the nodes is what matters - think about it: why would you waste time voting in an uncompetitive election that it is clear who will win?

I don't agree completely, as humans are irrational. But a bloc of robots using bitcoin will, unless utilizing superrationality strategies, suppress broadcasting the average transaction.

Hmm... I don't rebroadcast transactions in order to keep more of the fees for myself. But fees are denominated in... BTC. By not supporting the network and eventually breaking it, BTC will tend to have value of... right, zero. So, I don't really have an incentive to maintain cooperating node?

Confused.

I think if some miners started actually behaving like this (not relaying transactions) then people would notice and they would get a bad reputation.
So at least for mining pools there would be disincentive to do this (which make up the bulk of the hashing power).

It is just the same with the buyer... I'll paraphrase your above mentioned statement:


This is why the buyer and the seller have exactly the same interest broadcasting the tx they have made!

Or they simply don't use the client at all.  Or only leave it running when they want to send/receive a transaction.  The number of nodes online has been declining for some time.

i skimmed through the original paper.  lotsa mathematics attempting to model human behavior.  its impossible.  if it were, the quants on Wall St would never sustain losses.  people do all sorts of unpredictable things depending on the situation.  this is why investing is so difficult.

Incentive to send or don't send transactions. You are talking like there is option in Bitcoin client to chooze that behaviour. Someone actually need to write the modified version of Bitcoin client and majority of users need to download and install that version instead of original. There is modified DC++ clients available that does not share anything they are pretending to share, but 99.8% users run well behaving DC++ and are sharing the files.

this is not a question of the relative value of the merchandise vs the btc used to buy them.  it is about the seller having every reason to ensure that the "money" used to buy his goods is real and not already spent elsewhere thus his motivation to broadcast the tx as widely as possible as soon as possible with or w/o a fee attached in order to get the tx verified into his receiving address.

This is just another way of saying that bitcoins are more precious than goods purchased with those bitcoins. What about the "marketability" of goods purchased with bitcoins?

If you've ever attempted a double spend, you'll know that transactions matter long before they make it into the block chain.  It's the feasibility of a successful double spend that decreases as a transaction becomes more deeply embedded in the block chain, but a double spend is still tricky to pull off even without the block chain.  So, indeed, a transaction is a transaction from the moment it is broadcast to the p2p network.
No, what I'm saying is that the recipient of bitcoins has an incentive to get that transaction into the block chain because that improves the marketability of those bitcoins.  The sender certainly cares about the transaction because presumably they are receiving something from the other party in exchange for their bitcoins, but the sender has no reason to distrust themselves and therefore no need to have the transaction appear in the block chain.

A transaction is a transaction if only it is included in the block chain. All the rest is just expressed intention for a transaction... What you basically say is that the seller is more interested in a transaction than the buyer?! Sorry, I can't agree.

This is an irrational fear.  Mining pools do not control the actual mining hardware.  All that's necessary is close monitoring the behavior of the pools with regard to transaction inclusion and better mining software that can automatically switch between pools or start mining solo if a pool goes offline or starts behaving in a manner inconsistent with the goal of securing bitcoin transactions.

I think an important point that this paper misses is that while there is an incentive for miners to keep fee bearing transactions to themselves, all non-mining nodes (which presumably exist to either send or receive bitcoins) have a very strong incentive to relay both blocks and transactions.  As the recipient of bitcoins, what matters to you is that you can later spend those bitcoins.  For that reason, you will want to make sure you stay in sync with the rest of the network and that the rest of the network stays in sync with you.  For transactions that are generally broadcast into the network, I have no doubt that they'll quickly propagate to the vast majority of nodes, including miners…again, there is a strong incentive for "transactional" (non mining) nodes to do this.  In fact, were it not for the need to break ties regarding conflicting transactions, bitcoin wouldn't need miners or a block chain (ignoring the need to introduce new coins into circulation).  In such a block-chainless world, all you would care about is "checking in" with your favorite merchants and exchanges to make sure they recognize a transaction as being valid.  Again, a strong incentive to relay transactions and stay in sync with the network.

As Mike Hearn points out, it is the recipient of bitcoins that has an incentive for a transaction to be included in a block…the sender doesn't care.  For this reason, I think we'll eventually get to a point where most fee bearing transactions are the second in a sequence of two transactions.  The first transaction is the actual transfer to the recipient and does not include a fee, the second transaction is a spend back to one's self with a fee attached.  For transactions between trusted parties, this second transaction may never be created because the parties don't really care how long it takes for it to appear in a block since they trust each other.  In cases where the two parties don't trust each other, fees will be used to ensure the transaction is included in a block in a timely manner.  Since these transactions are spends back to one's self, you can create multiple versions of the second transaction with differing fees.  They would conflict with one another, but since they are all sending funds back to yourself, you don't really care…you just want one of them to make it into a block as soon as possible.  Why you might want to do this is explained in the following paragraph.

Large mining pools that might want to charge a premium to have transactions included in their blocks may provide an interface to directly submit transactions.  They will certainly keep those transactions for themselves.  However, nothing stops the submitter from broadcasting that transaction to other pools, or broadcasting a conflicting transaction that pays a lower fee to other pools (or to the network in general).  In fact, it is advantageous if the pool doesn't forward the transaction since it provides an opportunity for the originator of the transaction to create multiple variations of the same transaction that award lesser or no fees.  Another miner could pick up one of the lesser fee transactions and it would have the affect of reducing the overall transaction costs.  Larger pools could command higher fees up to a point where the fees become so great that people stop submitting transactions to that pool.  Miners will gravitate to the pools that optimize their fee structure such that they consistently payout the highest rewards.  Pools could even have a fee schedule such that they sit on lower fee transactions for a period of time before including them.  As the fee goes higher, they include the transactions sooner.

So, I guess to sum it up…not only do I think it's not a problem that miners do not have an incentive to forward fee bearing transactions, I think it might actually be necessary to create a real marketplace for transaction processing.

problem: you can't keep it to yourself.
why: its broadcasted.

also the bitcoin network its in its baby state right now. in the future, we might see that we are connecting directly to miner pools, are send them the transactions. or sending txs to hubs, that are connected to alot of miners.
remember that bitcoin has just begun.

For normal transactions, maybe not. But if I ran a miner, and got a transaction with a fee of 50 bitcoins, I would surely keep it to myself. Which is a bit counterproductive, given that such a high fee is intended to get fast verification...

Satoshi was aiming at CPU power, not GPU power!

Every monetary system not only serves real economy but is an economy of its own. This is valid for the bitcoin network as well. Giving the control in the hands of a dozen of mining pools is not different to giving the control of current fiat money monetary system in the hands of a dozen bank cartels. The bitcoin protocol should be changed to discourage pool mining! Never forget, bitcoin is about decentralization not centralization!