Contract - Revision history

Barakshani: correction to the atomic swap example

2023-09-29T02:31:50Z

correction to the atomic swap example

← Older revision		Revision as of 02:31, 29 September 2023
Line 206:		Line 206:
	# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.		# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.
	# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.		# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
	# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much ~~larger~~ than the lock time for 'A'. Both sides of the trade are now pending but incomplete.		# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much smaller than the lock time for 'A'. Both sides of the trade are now pending but incomplete.
	# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').		# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').

Furunodo: -ripple

2020-06-06T13:52:32Z

-ripple

← Older revision		Revision as of 13:52, 6 June 2020
Line 231:		Line 231:
	See [[Atomic cross-chain trading]] for details.		See [[Atomic cross-chain trading]] for details.

	Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa)~~, see the [[Ripple currency exchange]] article for more information~~.		Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa).

	Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.		Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.

JonathanCross: /* Theory */ Adding "SIGHASH flags" header.

2019-02-25T21:21:44Z

Theory: Adding "SIGHASH flags" header.

← Older revision		Revision as of 21:21, 25 February 2019
Line 25:		Line 25:

	Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.		Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.

			==== SIGHASH flags ====

	Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:		Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:

Jhfrontz: /* Trust minimization: trusted hardware */ link to TPM

2018-11-29T20:40:35Z

Trust minimization: trusted hardware: link to TPM

← Older revision		Revision as of 20:40, 29 November 2018
Line 185:		Line 185:
	===Trust minimization: trusted hardware===		===Trust minimization: trusted hardware===

	Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).		Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the [[trusted platform module \| TPM]] chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).

	===Trust minimization: Amazon AWS oracles===		===Trust minimization: Amazon AWS oracles===

Belcher: /* See Also */ added link to fidelity bonds

2017-08-10T20:15:42Z

Ysangkok: /* Example 7: Rapidly-adjusted (micro)payments to a pre-determined party */ link payment channel and lightning network

2017-06-24T14:25:49Z

Example 7: Rapidly-adjusted (micro)payments to a pre-determined party: link payment channel and lightning network

← Older revision		Revision as of 14:25, 24 June 2017
Line 247:		Line 247:
	For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.		For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

	~~To do this,~~ the following protocol ~~can be used~~. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.		One solution would be [[payment channel]]s like in the [[Lightning Network]].

			Another alternative is the following protocol. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.

	We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.		We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.

Flix: /* See Also */

2016-09-24T21:33:25Z

See Also

← Older revision		Revision as of 21:33, 24 September 2016
Line 278:		Line 278:
	* [[Script]]		* [[Script]]
	* [[Binary options]]		* [[Binary options]]
			* [[Oracle]]

	[[Category:Technical]]		[[Category:Technical]]

Flix: /* See Also */

2016-09-24T21:25:57Z

See Also

← Older revision		Revision as of 21:25, 24 September 2016
Line 277:		Line 277:

	* [[Script]]		* [[Script]]
	* [[Binary ~~Option~~]]		* [[Binary options]]

	[[Category:Technical]]		[[Category:Technical]]

Flix: /* See Also */

2016-09-24T21:25:30Z

See Also

← Older revision		Revision as of 21:25, 24 September 2016
Line 277:		Line 277:

	* [[Script]]		* [[Script]]
	* [[Binary ~~Options~~]]		* [[Binary Option]]

	[[Category:Technical]]		[[Category:Technical]]

Flix: /* See Also */

2016-09-24T21:25:21Z

See Also

← Older revision		Revision as of 21:25, 24 September 2016
Line 277:		Line 277:

	* [[Script]]		* [[Script]]
			* [[Binary Options]]

	[[Category:Technical]]		[[Category:Technical]]

← Older revision		Revision as of 20:15, 10 August 2017
Line 281:		Line 281:
	* [[Binary options]]		* [[Binary options]]
	* [[Oracle]]		* [[Oracle]]
			* [[Fidelity bonds]]

	[[Category:Technical]]		[[Category:Technical]]