Bitcoin Forum
September 29, 2016, 08:26:02 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transaction Overload Solution  (Read 1304 times)
bytemaster
Hero Member
*****
Offline Offline

Activity: 728

BitShares


View Profile WWW
August 05, 2010, 04:05:07 PM
 #1

In another thread I posted the comment below, but I felt that it was an important enough flaw that it should be addressed asap before bitcoin is overrun with huge numbers of automated non-micro payments.

The real issue is that even a simple legitimate automated payment negotiation system could overload bitcoin by introducing more transactions than the credit card system currently uses.   The net result is that block sizes could become HUGE.

In my use case you have a P2P system where they pay *anonymous users* for priority downloads.   Assume you have a single "torrent" file with 100,000 people all seeding and downloading.  That could easily generate 100,000 payments greater than 0.01 per minute.  Now clearly, the program would only have to use BTC in the event that upload != download between two clients.  But you never know what kind of crazy ideas people will eventually come up with.

Such a system would be distributed and thus there would be no easy way to identify "spam" from legitimate usage.    Even using my solution of transferring 1+ BTC at a time and giving change if the balance is greater than 0.01 could cause a transaction bloat writ large.

I suspect that the "cost" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.  

The only solution to this problem is to make broadcasting of a transaction "non free".  Namely, if you want me to even *attempt* to include it you have to pay me whether or not I succeed in getting it in first.  The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block.   In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.

The implication is that you may not even receive notice of payment until a node that you paid to receive your transaction and *attempt* to integrate it into a block manages to do so.  This means that you would not even see 0/unconfirmed and that a transaction must make it into a block before anyone that wasn't paid to *attempt* to integrate it even knows it exists.   You are protected against people taking your payment and then not even attempting to integrate it because they must find away to get your payment to them integrated or they don't even get paid and it would cost more for them to "forward" the generation transaction fee to another node than they could get by having the transaction go through.  

This structure would encourage pay-to-ip systems because that make the receiver of the payment responsible for paying to get it integrated.   Either they run their own bitcoin generators *or* they pay to send the transaction to someone who is.  

The "winner take all" transaction fee requires that I incur the cost for receiving and attempting to integrate transactions yet I would only get paid 1 time every couple of weeks if I was lucky and *if* my internet connection could handle receiving every transaction that occurred.  

People should pay others to generate whether or not the generation was the first one to integrate your transaction into a block.    What are the technical challenges to implementing this.

https://steemit.com  Blogging is the new Mining
1475137562
Hero Member
*
Offline Offline

Posts: 1475137562

View Profile Personal Message (Offline)

Ignore
1475137562
Reply with quote  #2

1475137562
Report to moderator
1475137562
Hero Member
*
Offline Offline

Posts: 1475137562

View Profile Personal Message (Offline)

Ignore
1475137562
Reply with quote  #2

1475137562
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475137562
Hero Member
*
Offline Offline

Posts: 1475137562

View Profile Personal Message (Offline)

Ignore
1475137562
Reply with quote  #2

1475137562
Report to moderator
1475137562
Hero Member
*
Offline Offline

Posts: 1475137562

View Profile Personal Message (Offline)

Ignore
1475137562
Reply with quote  #2

1475137562
Report to moderator
bytemaster
Hero Member
*****
Offline Offline

Activity: 728

BitShares


View Profile WWW
August 05, 2010, 04:14:00 PM
 #2

The downside to a non "broadcast" system is that it makes it easier to double-spend and in fact your payment to generate would be a prime candidate for double spending. 

I am not sure that the system can stand such delays in the broadcast system.  I suppose those worried about double spending would pay to have the transaction "vetted" by more nodes and those that can handle a loss would take the risk.   


https://steemit.com  Blogging is the new Mining
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 05, 2010, 05:38:21 PM
 #3

I can't think of a way to implement that.  All the transaction fees would be additional transactions.  What about the transaction fees for the transaction fee's transaction?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 16, 2010, 05:11:47 PM
 #4

http://bitcointalk.org/index.php?topic=287.msg7698#msg7698

The transaction fee transaction would be designed to be a completely predictable consequence of the main transaction and hopefully any fee for processing the main transaction would also take into account the need for a fee transaction too. In other words the fee transaction would contain its own fee. This therefore seems to be a manageable aspect of the problem.

ByteCoin
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!