Bitcoin Forum
December 04, 2016, 12:00:10 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Collaboration between pools could make accepting 0-confirmation transaction safe  (Read 2005 times)
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
June 20, 2012, 07:22:49 AM
 #21

Adding to what Serith already said, one of the clauses of the contract could contain a limit of how many blocks deep the double-spend is. If it's deeper than X, then the miner would stop trying to counter it.

Please keep in mind that the "valid block policy" only concerns blocks with "illegal" contents (double-spends concerning previous blocks, wrong signatures, syntax problems etc). There's no policy concerning which transactions a miner will accept, or on top of which block he'll mine.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
1480809610
Hero Member
*
Offline Offline

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

1480809610
Report to moderator
1480809610
Hero Member
*
Offline Offline

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

1480809610
Report to moderator
1480809610
Hero Member
*
Offline Offline

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

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

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

1480809610
Report to moderator
1480809610
Hero Member
*
Offline Offline

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

1480809610
Report to moderator
1480809610
Hero Member
*
Offline Offline

Posts: 1480809610

View Profile Personal Message (Offline)

Ignore
1480809610
Reply with quote  #2

1480809610
Report to moderator
wabber
Member
**
Offline Offline

Activity: 85


View Profile
June 20, 2012, 09:00:50 AM
 #22

Please keep in mind that the "valid block policy" only concerns blocks with "illegal" contents (double-spends concerning previous blocks, wrong signatures, syntax problems etc). There's no policy concerning which transactions a miner will accept, or on top of which block he'll mine.

but by adding another illegal content (the type of transaction i paid not to include) I'm effectively changing the valid block policy which isn't a good thing imho.
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
June 20, 2012, 09:40:18 AM
 #23

I don't see this proposal adding any rule to the protocol. Miners are already free to try not to build on top of any block they don't want to. They should just be conscious that if they implement such thing as a "hard rule", they'll actually be forking the chain. So it'd better be a "soft rule".

There's no way to enforce miners to build on top of the longest chain.

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
Serith
Sr. Member
****
Offline Offline

Activity: 269


View Profile
June 23, 2012, 09:36:39 PM
 #24

Instead of saying your idea is wrong, maybe I can contribute to it.

One of the things gmaxwell pointed out was that mining pools may be around now but there is no guarantee they will be around later, in fact he thinks they probably won't. So depending on them as fundamental architecture is probably a bad idea all around.

But imagine miners (both solo and pools) included a IP:Port calling card in the coinbase of their block. The calling card would convey the message: I am a miner, you can contact me via udp directly at (ip:port), send me your transaction, and if it looks valid, I will give you a signed promise (signed by coinbase key) that I accept and plan to confirm this transaction.

One would know what percentage of the mining pool any given calling card represents just by the number of recent blocks containing it.

Someone wanting a miner commitment on a transaction would blast out that transaction via UDP to all of the miners whose calling cards appear in the last 1000 blocks.  That sounds extreme, but we're only talking a few hundred kilobytes total, with the total going to each miner being under 1-2KB.

By using UDP instead of TCP, one could blindly blast out a bunch of simultaneous requests into the internet on a "best effort" basis with low overhead, knowing most of them will arrive and many won't and that that's OK.  The responses would arrive the same way.

Either the sender or the recipient of a transaction could immediately contact thousands of miners with a blast of udp packets and rapidly get an accurate feel for how much mining power supporting the transaction has just by gauging the udp responses that come back within the following 10 seconds.

If it is a supermajority you have success.

Such could be the standard practice for accepting zero conf transactions.  It could be an excellent revenue generator for the mining community as a whole in the form of a for-pay service (example, all miners could stipulate that this UDP confirmation service is only available if transaction fee [in the transaction being zero-confirmed] is meets a far more generous criterion than the satoshi client minimum)

To address gmaxwell's rightfully placed fear that I could pay "you" and then use the premium service to pay the doublespend to myself... if getting zero-conf is a fee-based service paid by the payer, then "you" could demand, as a condition of giving me goods with zero conf, that I include a fee big enough to ensure that you can click a button in your client and enjoy the confirmation service yourself, prepaid.

I agree with you and the second part of gmaxwell's post, that my proposal brings more centralization, and that's not ideal. You are thinking about making 0-confirmation tnx accepted in decentralize or less centralized way, that would be great if it's possible. I see problems with your proposal, but I am not ready to discuss it yet.
Pages: « 1 [2]  All
  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!