Nanopayments - Revision history

JonathanCross: /* Notes */ Fix typo

2018-02-15T06:09:57Z

Notes: Fix typo

← Older revision		Revision as of 06:09, 15 February 2018
Line 49:		Line 49:
	[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]		[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

	Although probabilistic payments were considered for the Lightning Network, the current lnd implementation does not. Instead, [https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L13-L18 it just rounds down to the nearest satoshi] when a channel is closed.		Although probabilistic payments were considered for the Lightning Network, the current lnd implementation does not use them. Instead, [https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L13-L18 it just rounds down to the nearest satoshi] when a channel is closed.

JonathanCross: /* Notes */ Adding info about lnd and probabilistic payment implimnetation

2018-02-15T05:31:21Z

Notes: Adding info about lnd and probabilistic payment implimnetation

← Older revision		Revision as of 05:31, 15 February 2018
Line 48:		Line 48:

	[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]		[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

			Although probabilistic payments were considered for the Lightning Network, the current lnd implementation does not. Instead, [https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L13-L18 it just rounds down to the nearest satoshi] when a channel is closed.

JonathanCross: /* Technical stuff: How can probabilistic transactions be created? */ Improving header formatting

2018-02-15T05:16:42Z

Technical stuff: How can probabilistic transactions be created?: Improving header formatting

← Older revision		Revision as of 05:16, 15 February 2018
Line 11:		Line 11:
	Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.		Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.

	=====Technical stuff: How can probabilistic transactions be created?=====		=== Technical stuff: How can probabilistic transactions be created? ===

	Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.		Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.
Line 25:		Line 25:
	If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.		If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.

			=== What if Alice tries to [[double-spending\|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain? ===
	''What if Alice tries to [[double-spending\|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain?''

	If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.		If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.
Line 32:		Line 31:
	She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.		She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.

			=== What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time? ===
	''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''

	This may not be a big enough problem to matter for most casual, low value uses.		This may not be a big enough problem to matter for most casual, low value uses.
Line 43:		Line 41:
	A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.		A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.

			== Notes ==

	This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.		This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

Ysangkok: link tadge dryja talk

2017-06-24T11:24:00Z

link tadge dryja talk

← Older revision		Revision as of 11:24, 24 June 2017
Line 47:		Line 47:

	The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.		The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.

			[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

Occupy paul st: Add a link to the bitcoin-nanopayment project on Github

2015-09-05T16:05:52Z

Add a link to the bitcoin-nanopayment project on Github

← Older revision		Revision as of 16:05, 5 September 2015
Line 45:		Line 45:

	This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.		This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

			The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.

Sgornick: /* Technical stuff: How can probabilistic transactions be created? */ Make reference to double spending be a link to the article.

2012-06-18T17:18:03Z

Technical stuff: How can probabilistic transactions be created?: Make reference to double spending be a link to the article.

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


	''What if Alice tries to double spend her 1 BTC out from under Bob before he gets his successful transaction into the block chain?''		''What if Alice tries to [[double-spending\|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain?''

	If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.		If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.

Jevon at 20:45, 4 April 2012

2012-04-04T20:45:59Z

← Older revision		Revision as of 20:45, 4 April 2012
Line 44:		Line 44:


	This article is ~~based on an idea posted by casascius:~~ [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments]		This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

Jevon: added important keyword Micropayments for search engines

2012-04-03T19:00:50Z

added important keyword Micropayments for search engines

← Older revision		Revision as of 19:00, 3 April 2012
Line 1:		Line 1:
			''a.k.a. Micropayments''

	Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.		Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.

Line 33:		Line 35:
	''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''		''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''

	This could be solved with hub servers that nanopayment ~~receivers~~ would use to announce coins currently in use to other nanopayment ~~receivers~~.		This may not be a big enough problem to matter for most casual, low value uses.

			If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients.

	When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.		When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.
Line 40:		Line 44:


	This article is based on an idea posted by casascius [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments]		This article is based on an idea posted by casascius: [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments]

Jevon at 17:20, 3 April 2012

2012-04-03T17:20:47Z

← Older revision		Revision as of 17:20, 3 April 2012
Line 33:		Line 33:
	''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''		''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''

	This could be solved with hub servers that nanopayment receivers would use to announce coins currently in use.		This could be solved with hub servers that nanopayment receivers would use to announce coins currently in use to other nanopayment receivers.

	When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.		When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.

Jevon at 17:07, 3 April 2012

2012-04-03T17:07:50Z

← Older revision		Revision as of 17:07, 3 April 2012
Line 28:		Line 28:
	If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.		If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.

	She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already ~~have a big head start (~~[https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 ~~Satoshi: Fast Transactions~~]). If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.		She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.