Bitcoin Forum
December 06, 2016, 04:14:22 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: The "Bounty Swarm"  (Read 3373 times)
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 10, 2010, 10:31:23 PM
 #21

Are transactions allowed to have input addresses with a zero balance?
If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee.

I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks.  I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book.

I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin.  In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc).

And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction.  Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good.

How often do you get the chance to work on a potentially world-changing project?
1481040862
Hero Member
*
Offline Offline

Posts: 1481040862

View Profile Personal Message (Offline)

Ignore
1481040862
Reply with quote  #2

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

Posts: 1481040862

View Profile Personal Message (Offline)

Ignore
1481040862
Reply with quote  #2

1481040862
Report to moderator
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 10, 2010, 11:12:56 PM
 #22

Are transactions allowed to have input addresses with a zero balance?
If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee.

I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks.  I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book.

I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin.  In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc).

And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction.  Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good.


The micro transaction fee only applies to the the 'out' side.

By putting the 'return address' on the 'In' side, we can pass a specific return address if we want.

TXIn [ Return Address (0), Address with money (10) ]
TXOut [ Payee Address (9.95), Change Address (0.05) ]

The return transaction should be indistinguishable from any other transaction.

TXIn[ Some other Address (9.95 ) ]
TXOut[ Return Address (9.95) ]

Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 11, 2010, 12:02:33 AM
 #23

The micro transaction fee only applies to the the 'out' side.
Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules).  So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee.  TxIns don't contain a value, the value is in the corresponding TxOut...

Quote
Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.

But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right?

How often do you get the chance to work on a potentially world-changing project?
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 11, 2010, 12:39:31 AM
 #24

The micro transaction fee only applies to the the 'out' side.
Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules).  So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee.  TxIns don't contain a value, the value is in the corresponding TxOut...
Ok, that makes things more complicated again.
I suggest just using the first listed TxIn address as the return address + let peoples clients manipulate the transactions so the 'right' value is in that position. This may involve an initial transaction to yourself to put some(all) of the money in a 'refund possible from shop X' address, before the actual payment to shop X.
(Now you tell me transaction input order is not deterministic?)

Quote
Quote
Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.

But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right?

'refundtransaction' API call should make it difficult to refund 'bad' transactions.

Refunds should not be a common occurrence.

I can see how it might be a problem if you are instantly refunding a double spent coin with a 'good' coin.
but might it be a better solution to just queue the refund until the incoming transaction was sufficiently mature?
It's another convenience/privacy trade off.

(Should this discussion be in it's own 'Refunds' thread?)
Anonymous
Guest

August 11, 2010, 04:11:14 AM
 #25

The idea of semi anonymous bounties does seem possible after reading everyones replies.
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
August 11, 2010, 04:24:39 AM
 #26


One method of funding is using prediction markets to further the scientific and useful arts:

Prediction Markets For Promoting The Progress of Science and The Useful Arts
Tom W. Bell, 2006
http://www.tomwbell.com/writings/PredEx.pdf


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Anonymous
Guest

August 11, 2010, 05:29:40 AM
 #27


One method of funding is using prediction markets to further the scientific and useful arts:

Prediction Markets For Promoting The Progress of Science and The Useful Arts
Tom W. Bell, 2006
http://www.tomwbell.com/writings/PredEx.pdf



i think someone was working on a prediction market
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
August 11, 2010, 07:00:35 AM
 #28

One of the salient points of the paper is that you can provide a bounty swarm using a prediction market.  One of the key attributes of a prediction market is permitting insider trading, to add knowledge to the market.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
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!