Casascius Bitcoin POS system/Protocol - Revision history

Sgornick: /* confirmed */ Make reference to double spending be a link to the article.

2012-06-18T17:15:36Z

confirmed: Make reference to double spending be a link to the article.

← Older revision		Revision as of 17:15, 18 June 2012
Line 110:		Line 110:

	===confirmed===		===confirmed===
	Tells the terminal that a payment now has a different number of confirmations, or that it has been invalidated due to a double-spend.		Tells the terminal that a payment now has a different number of confirmations, or that it has been invalidated due to a [[Double-spending\|double-spend]].

	It's up to the host to decide how many confirmations to report, but no more than 100 is recommended.		It's up to the host to decide how many confirmations to report, but no more than 100 is recommended.

2011-10-23T05:12:18Z

querynonce

← Older revision		Revision as of 05:12, 23 October 2011
Line 79:		Line 79:

	===querynonce===		===querynonce===
	Used so the terminal to follow up on a transaction attempt in case the transaction was sent out but no response was successfully received. Allows the terminal to determine whether a transaction did or did not happen, and if it did not, poisons the nonce so the transaction can't ~~accidentally~~ be committed later.		Used so the terminal to follow up on a transaction attempt in case the transaction was sent out but no response was successfully received. Allows the terminal to determine whether a transaction did or did not happen, and if it did not, poisons the nonce so the transaction can't somehow be committed later.

	From terminal to host:		From terminal to host:

2011-10-23T05:11:14Z

checkin

← Older revision		Revision as of 05:11, 23 October 2011
Line 26:		Line 26:
	* Adjusted market sell rate		* Adjusted market sell rate
	* Alerts with unique ID greater than ''lastalert''		* Alerts with unique ID greater than ''lastalert''
	* ~~256~~ bytes of cryptographically random data that is used by the terminal to build its entropy pool.		* Some bytes of cryptographically random data that is used by the terminal to build its entropy pool.

	===getaddress===		===getaddress===

2011-10-23T05:10:23Z

queryaddress

2011-10-23T04:40:34Z

RPC calls

← Older revision		Revision as of 04:40, 23 October 2011
Line 26:		Line 26:
	* Adjusted market sell rate		* Adjusted market sell rate
	* Alerts with unique ID greater than ''lastalert''		* Alerts with unique ID greater than ''lastalert''
			* 256 bytes of cryptographically random data that is used by the terminal to build its entropy pool.

	===getaddress===		===getaddress===

2011-10-23T04:39:36Z

dispense

← Older revision		Revision as of 04:39, 23 October 2011
Line 67:		Line 67:
	* amount to dispense		* amount to dispense
	* method		* method
	* bitcoin address		* bitcoin address (if blank, server should generate one)
	* authcode		* authcode
	* nonce (so terminal can determine success from alerts in case no response received)		* nonce (so terminal can determine success from alerts in case no response received)
Line 74:		Line 74:
	* successflag		* successflag
	* bitcoin transaction ID		* bitcoin transaction ID
			* bitcoin address
			* bitcoin private key (if requested server-side generation)

	===querynonce===		===querynonce===

2011-10-23T04:37:58Z

Alerts

← Older revision		Revision as of 04:37, 23 October 2011
Line 106:		Line 106:
	* original nonce provided in original associated ''sweep'' command, if applicable		* original nonce provided in original associated ''sweep'' command, if applicable

	===~~confirm~~===		===confirmed===
	Tells the terminal that a payment now has a different number of confirmations, or that it has been invalidated due to a double-spend.		Tells the terminal that a payment now has a different number of confirmations, or that it has been invalidated due to a double-spend.

2011-10-23T04:37:41Z

Alerts

← Older revision		Revision as of 04:37, 23 October 2011
Line 114:		Line 114:
	* bitcoin transaction ID		* bitcoin transaction ID
	* new number of confirmations (-1 = transaction invalidated)		* new number of confirmations (-1 = transaction invalidated)

	~~===dispensed===~~
	~~Acknowledges that a dispense transaction was successful.~~

	~~Alert fields:~~

2011-10-23T04:37:15Z

confirm

← Older revision		Revision as of 04:37, 23 October 2011
Line 107:		Line 107:

	===confirm===		===confirm===
	Tells the terminal that a payment has ~~received~~ a ~~confirmation~~, or has been invalidated due to a double-spend.		Tells the terminal that a payment now has a different number of confirmations, or that it has been invalidated due to a double-spend.

			It's up to the host to decide how many confirmations to report, but no more than 100 is recommended.

	Alert fields:		Alert fields:

2011-10-23T04:36:08Z

Alerts

← Older revision		Revision as of 04:36, 23 October 2011
Line 88:		Line 88:

	==Alerts==		==Alerts==
	An alert is a message to the terminal that tells it that a transaction has occurred.		An alert is a message to the terminal that tells it that a transaction has occurred. They should be kept by the host in a database so that they can be queried sequentially by the terminal.

	Each alert is given an incrementing unique ID. The same number pool might be used system-wide, so the numbering won't be contiguous. What's important is that later alerts have higher numbers than earlier alerts, so when the terminal says it has heard about alert ''n'', it has also heard about all alerts before it as well.		Each alert is given an incrementing unique ID. The same number pool might be used system-wide, so the numbering won't be contiguous. What's important is that later alerts have higher numbers than earlier alerts, so when the terminal says it has heard about alert ''n'', it has also heard about all alerts before it as well.