https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Transisto&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T09:57:19ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Talk:Bech32_adoption&diff=69036Talk:Bech32 adoption2021-11-30T18:13:51Z<p>Transisto: </p>
<hr />
<div>I don't think we need "Other Services: Casinos, marketplaces, etc that let users withdraw money" here. It just attracts businesses that will want to add their link here. This doesn't add value to the wiki. [[User:Furunodo|Furunodo]] ([[User talk:Furunodo|talk]]) 09:32, 2 July 2020 (UTC)<br />
<br />
Apparently Crypto.com, which is considered by many a wallet and an exchange doesn't support BECH32 --[[User:Transisto|Transisto]] ([[User talk:Transisto|talk]]) 18:13, 30 November 2021 (UTC)</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Talk:Bech32_adoption&diff=69035Talk:Bech32 adoption2021-11-30T18:13:26Z<p>Transisto: </p>
<hr />
<div>I don't think we need "Other Services: Casinos, marketplaces, etc that let users withdraw money" here. It just attracts businesses that will want to add their link here. This doesn't add value to the wiki. [[User:Furunodo|Furunodo]] ([[User talk:Furunodo|talk]]) 09:32, 2 July 2020 (UTC)<br />
<br />
Apparently Crypto.com, which is considered by many a wallet and an exchange doesn't support BECH32</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Category_talk:Block_chain_browsers&diff=68147Category talk:Block chain browsers2020-08-20T05:01:52Z<p>Transisto: </p>
<hr />
<div>about 50% of these are dead<br />
<br />
here's some that works<br />
<br />
bitinfocharts.com/bitcoin/explorer/<br />
blockchains.io/<br />
blockonomics.co/<br />
blockseer.com/<br />
btc.bitaps.com/<br />
chain.localbitcoins.com/<br />
chain.so/<br />
chainflyer.bitflyer.jp<br />
https://bitaps.com/<br />
https://blockpath.com/<br />
https://blockstream.info/<br />
https://btc.com/<br />
https://chaindex.com/blockchain/<br />
https://explorer.btc21.org/<br />
https://learnmeabitcoin.com/explorer/node/<br />
https://live.blockcypher.com/<br />
https://oxt.me/<br />
https://sochain.com/btc<br />
https://www.kycp.org/<br />
https://www.localbitcoinschain.com/<br />
https://www.oklink.com/<br />
https://www.smartbit.com.au/<br />
https://yogh.io/<br />
insight.bitpay.com<br />
live.blockcypher.com/btc/<br />
scorechain.com/<br />
tradeblock.com/blockchain<br />
orange - local electron app<br />
http://blockchainsql.io/</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Category_talk:Block_chain_browsers&diff=68146Category talk:Block chain browsers2020-08-20T04:58:21Z<p>Transisto: Created page with "about 80% of these are dead here's some that works bitinfocharts.com/bitcoin/explorer/ blockchains.io/ blockonomics.co/ blockseer.com/ btc.bitaps.com/ chain.localbitcoins.co..."</p>
<hr />
<div>about 80% of these are dead<br />
<br />
here's some that works<br />
<br />
bitinfocharts.com/bitcoin/explorer/<br />
blockchains.io/<br />
blockonomics.co/<br />
blockseer.com/<br />
btc.bitaps.com/<br />
chain.localbitcoins.com/<br />
chain.so/<br />
chainflyer.bitflyer.jp<br />
https://bitaps.com/<br />
https://blockpath.com/<br />
https://blockstream.info/<br />
https://btc.com/<br />
https://chaindex.com/blockchain/<br />
https://explorer.btc21.org/<br />
https://learnmeabitcoin.com/explorer/node/<br />
https://live.blockcypher.com/<br />
https://oxt.me/<br />
https://sochain.com/btc<br />
https://www.kycp.org/<br />
https://www.localbitcoinschain.com/<br />
https://www.oklink.com/<br />
https://www.smartbit.com.au/<br />
https://yogh.io/<br />
insight.bitpay.com<br />
live.blockcypher.com/btc/<br />
scorechain.com/<br />
tradeblock.com/blockchain<br />
orange - local electron app<br />
http://blockchainsql.io/</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Talk:BIP_0021&diff=67012Talk:BIP 00212019-11-17T01:43:37Z<p>Transisto: /* Feed partially signed transactions for wallet to sign */</p>
<hr />
<div>Marian on IRC reports: "The BNF [here] is erroneous, regarding the params, it says [ "?" bitcoinparams ] while bitcoinparams is just *bitcoinparam, thus with that BNF there are no separators between the parameters". --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:04, 23 April 2013 (GMT)<br />
<br />
--> ([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013) So should it rather be written something like this (I am not a BNF expert, just following my logic):<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparam [ bitcoinparams ] ]<br />
bitcoinparams = *bitcoinparamamp<br />
bitcoinparamamp = "&" bitcoinparam<br />
<br />
<br />
== Suggesting usability enhancement in BIP 0021 for paying tips in restaurant/bar conveniently ("tips w/o taps") ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013)<br />
<br />
I am suggesting a simple downward compatible enhancement of BIP 0021 to allow effortless tipping in restaurants, bars, pubs, etc.<br />
<br />
When watching bitpay's mobile checkout demo video "http://www.youtube.com/watch?v=YZ-pqo0cLcE" it is clear that paying tips is somewhat cumbersome for the customer with today's wallet and merchant solutions. This can be dramatically improved with some support by the client app and a minor enhancement of BIP 0021.<br />
<br />
<span style="color:#0000FF">'''Enhancement proposal'''</span>:<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Actually, "tipparam" is just a special case of "otherparam", hence completely downwards compatible.<br />
<br />
The tip can be specified in BTC or in percent of the amount, and it acts as a recommended or default tip setting in the customer's wallet app.<br />
<br />
'''Examples''' for the following scenario:<br />
:Request 0.567 BTC from the customer of a restaurant and make the customer's bitcoin app show an advanced send dialog that allows adding a tip:<br />
<br />
Ex. 1a) The pre-set tip value in the send dialog is undefined (user must specify) or set to the client's pre-configured default tip value:<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip='''</span><br />
<br />
Ex. 1b) The pre-set tip value in the send dialog is explicitly set to zero (this restaurant is on "service charge included in 'amount'" policy and informs the client about this explicitly by "tip=0" in the URI):<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0'''</span><br />
<br />
Ex. 2) The pre-set tip value is 15% of 0.567 BTC, i.e. 0.08508 BTC:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0.08505'''</span><br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span><br />
[URI code of the percentage character is "%25"]<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%'''</span><br />
["lazy" notation, omitting the "25". Actually, this is NOT correct, not URI compliant (RFC 2396), hence such an URI<br />
should not be generated. But it is proposed that the wallet app that has to decode the URI is implemented to understand<br />
this "lazy" syntax in the "tip" field anyhow, as safeguard to avoid errors in case that the merchant app generates such<br />
a "lazy" URI]<br />
<br />
Ex. 3) The pre-set tip value is 0.08508 BTC, and the "notes" field in the client app is pre-occupied with the name of the restaurant:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span>&message=Charly%27s%20Bar<br />
<br />
Explanation:<br />
* The new parameter has no "req-" prefix, i.e. if an old bitcoin client app does not know it, it can safely ignore it.<br />
* Otherwise, the customer's bitcoin client will not open the normal but an enhanced send dialog where the customer can specify a tip that will be added to the bill to be paid. In examples 2 and 3 above the tip shall be pre-configured with the amount specified in the URI, so the customer can most conveniently just accept it by a simple tap, if the client app is well-written.<br />
<br />
The details are of course dependent on the client app implementation, a best practice-example is demonstrated in the following images.<br />
<br />
Standard send dialog (no tips):<br />
<br />
[[File:bitcoin-app-tipOFF_BIP_0021.png|border]]<br />
<br />
<br />
Advanced send dialog for giving tips:<br />
<br />
[[File:bitcoin-app-tipON_BIP_0021.png|border]]<br />
<br />
Discussion: It has been argued that the described improvement of the user experience for the scenario "make payment with a tip" can be achieved by sole improvement of the wallet app, without any protocol change.<br />
<br />
But this is only partly true. Certainly enhancement of the wallet app to provide an advanced "send" dialog for easy tipping is crucial. However, with the legacy BIP 0021 the wallet app cannot know whether it shall display the standard send dialog (no tip) or the advanced send dialog (with tip option) to the user. So the user has to select this manually. With the optional "tip" parameter in the URI, the wallet app can readily display the appropriate send dialog without extra user interaction, thereby providing ultimate user experience.<br />
<br />
== Further enhancement for paying tips in restaurant/bar: "tip address" ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 9 Sept 2013)<br />
<br />
Further enhancement: Sending billing amount and tip to separate addresses:<br />
<br />
(Note: This feature is typically invisible in the GUI of the customer's wallet app)<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> <span style="color:#E20074">'''tipaddrparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
<span style="color:#E20074">'''tipaddrparam = "tipaddr=" bitcoinaddress'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25</span><span style="color:#E20074">&tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
The "tipaddr" parameter specifies that if the wallet app sends a tip in addition to the "amount", it shall '''''preferably''''' send it to the specifed "tip address". However, this is not mandatory (because it is an optional parameter w/o "req-"), so if the wallet app sends amount and tip to the main address, the merchant shall still be able to figure this out.<br />
<br />
If the merchant cannot handle tips sent to the same address as the billing amount, he shall instead make use of this parameter:<br />
<br />
<span style="color:#a20024">'''reqtipaddrparam = "req-tipaddr=" bitcoinaddress'''</span><br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25&</span><span style="color:#a20024">&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
In this case, the wallet app is guaranteed to send the tip to the separate address, or will otherwise reject the complete URI. Upon rejection, the waiter knows that the customer has a non-compliant wallet app and can start a second try showing the URI without any tip parameters (or with "tip=0"). The tip can then be paid in a separate transaction (or classically by cash).<br />
<br />
== Short parameter tags yielding shorter URIs for QR codes ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 10 Sept 2013)<br />
<br />
Another proposal: Allow short forms for the parameter tags, to shorten the URIs.<br />
<br />
This is not important for URIs when used in links on web pages, but it can become relevant when generating QR codes. The longer the URI, the more difficult it will be to scan and decode the QR code by a smartphone due to smaller QR code block size or lower error protection level.<br />
<br />
Hence a simple table of equivalent ALIASES is proposed, to shorten the URI:<br />
<br />
'''Parameter Tag Alias'''<br />
amount= a=<br />
label= l=<br />
message= m=<br />
tip= t=<br />
tipaddr= ta=<br />
req- -<br />
req-tipaddr= -ta=<br />
req-aal= -aal=<br />
<br />
Hence, for example the following URIs are fully equivalent:<br />
<br />
155 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
129 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?a=.567&t=15%25&-ta=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&m=Thank%20You&l=Charly%27s%20Bar</nowiki><br />
<br />
== Critical Improvement of BIP 0021 for "req-" param ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
One aspect of current BIP 0021 is critical:<br />
<br />
It says that wallets that do not know one or several "req-" keys in the URI should reject (i.e. not process) the complete URI, to avoid doing anything in the wrong way.<br />
<br />
However, very old wallet apps may have not even implemented this rule and may still process the "known part" of the URI, thereby causing an unwanted result.<br />
<br />
The solution to the problem is to specify BIP 0021 in a way that, in case that at least one "req-" key is used, some other details of the URI must be modified too, such that it becomes "incompatible" and "undecodable" by older apps.<br />
<br />
The concrete proposal here is to append "R-" directly after "bitcoin:". Then a string with a "req-" parameter would look like this:<br />
<nowiki>bitcoin:</nowiki>'''R-'''<nowiki>175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&</nowiki>'''req-'''<nowiki>tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
<br />
The BFN Syntax then looks as follows:<br />
bitcoinurn = "bitcoin:" '''[ "R-" ]''' bitcoinaddress [ "?" bitcoinparams ]<br />
where "R-" is mandatory as soon as at least one "reqparam" is used.<br />
<br />
== Paying to Multiple Outputs ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
Another Enhancement relates to the "Humble Bundle" scenario: Paying one transaction with multiple outputs, specifying a dedicated amount for each output address.<br />
<br />
This scenario allows to specify additional pairs of addresses and amounts. Optionally, also further labels can be specified. We call the new parameter "'''req-aal'''" for '''a'''ddress-'''a'''mount-'''l'''abel, and we specify it as a '''req'''uired parameter because procesing an incomplete URI would result in sending only a partial amount.<br />
<br />
bitcoinparam = amountparam | labelparam | '''reqaalparam |''' messageparam | tipparam | tipaddrparam | otherparam | reqparam<br />
reqaalparam = "req-aal=" bitcoinaddress ":" *digit [ "." *digit ] [ ":" *pchar]<br />
<br />
Example:<br />
<nowiki>bitcoin:R-175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&label=book&req-aal=1tZdShH7b38klseWrTZm5sE8PrtZPwqdK:0.123:game&message=Thank%20You</nowiki><br />
<br />
<br />
<br />
== Feed partially signed transactions for wallet to sign ==<br />
<br />
Example <nowiki>bitcoin:ANYaddress?presig=45505446ff0002000000000101beee3e40b018f740df8a88ddb411862abf5a634................1231e61c33b4d6992fb61871a2ec711e7b5793c69632b22ea342804110000050054aedf370900 </nowiki></div>Transistohttps://tests.bitcoin.it/w/index.php?title=Talk:BIP_0021&diff=67011Talk:BIP 00212019-11-17T01:43:03Z<p>Transisto: </p>
<hr />
<div>Marian on IRC reports: "The BNF [here] is erroneous, regarding the params, it says [ "?" bitcoinparams ] while bitcoinparams is just *bitcoinparam, thus with that BNF there are no separators between the parameters". --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:04, 23 April 2013 (GMT)<br />
<br />
--> ([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013) So should it rather be written something like this (I am not a BNF expert, just following my logic):<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparam [ bitcoinparams ] ]<br />
bitcoinparams = *bitcoinparamamp<br />
bitcoinparamamp = "&" bitcoinparam<br />
<br />
<br />
== Suggesting usability enhancement in BIP 0021 for paying tips in restaurant/bar conveniently ("tips w/o taps") ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013)<br />
<br />
I am suggesting a simple downward compatible enhancement of BIP 0021 to allow effortless tipping in restaurants, bars, pubs, etc.<br />
<br />
When watching bitpay's mobile checkout demo video "http://www.youtube.com/watch?v=YZ-pqo0cLcE" it is clear that paying tips is somewhat cumbersome for the customer with today's wallet and merchant solutions. This can be dramatically improved with some support by the client app and a minor enhancement of BIP 0021.<br />
<br />
<span style="color:#0000FF">'''Enhancement proposal'''</span>:<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Actually, "tipparam" is just a special case of "otherparam", hence completely downwards compatible.<br />
<br />
The tip can be specified in BTC or in percent of the amount, and it acts as a recommended or default tip setting in the customer's wallet app.<br />
<br />
'''Examples''' for the following scenario:<br />
:Request 0.567 BTC from the customer of a restaurant and make the customer's bitcoin app show an advanced send dialog that allows adding a tip:<br />
<br />
Ex. 1a) The pre-set tip value in the send dialog is undefined (user must specify) or set to the client's pre-configured default tip value:<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip='''</span><br />
<br />
Ex. 1b) The pre-set tip value in the send dialog is explicitly set to zero (this restaurant is on "service charge included in 'amount'" policy and informs the client about this explicitly by "tip=0" in the URI):<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0'''</span><br />
<br />
Ex. 2) The pre-set tip value is 15% of 0.567 BTC, i.e. 0.08508 BTC:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0.08505'''</span><br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span><br />
[URI code of the percentage character is "%25"]<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%'''</span><br />
["lazy" notation, omitting the "25". Actually, this is NOT correct, not URI compliant (RFC 2396), hence such an URI<br />
should not be generated. But it is proposed that the wallet app that has to decode the URI is implemented to understand<br />
this "lazy" syntax in the "tip" field anyhow, as safeguard to avoid errors in case that the merchant app generates such<br />
a "lazy" URI]<br />
<br />
Ex. 3) The pre-set tip value is 0.08508 BTC, and the "notes" field in the client app is pre-occupied with the name of the restaurant:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span>&message=Charly%27s%20Bar<br />
<br />
Explanation:<br />
* The new parameter has no "req-" prefix, i.e. if an old bitcoin client app does not know it, it can safely ignore it.<br />
* Otherwise, the customer's bitcoin client will not open the normal but an enhanced send dialog where the customer can specify a tip that will be added to the bill to be paid. In examples 2 and 3 above the tip shall be pre-configured with the amount specified in the URI, so the customer can most conveniently just accept it by a simple tap, if the client app is well-written.<br />
<br />
The details are of course dependent on the client app implementation, a best practice-example is demonstrated in the following images.<br />
<br />
Standard send dialog (no tips):<br />
<br />
[[File:bitcoin-app-tipOFF_BIP_0021.png|border]]<br />
<br />
<br />
Advanced send dialog for giving tips:<br />
<br />
[[File:bitcoin-app-tipON_BIP_0021.png|border]]<br />
<br />
Discussion: It has been argued that the described improvement of the user experience for the scenario "make payment with a tip" can be achieved by sole improvement of the wallet app, without any protocol change.<br />
<br />
But this is only partly true. Certainly enhancement of the wallet app to provide an advanced "send" dialog for easy tipping is crucial. However, with the legacy BIP 0021 the wallet app cannot know whether it shall display the standard send dialog (no tip) or the advanced send dialog (with tip option) to the user. So the user has to select this manually. With the optional "tip" parameter in the URI, the wallet app can readily display the appropriate send dialog without extra user interaction, thereby providing ultimate user experience.<br />
<br />
== Further enhancement for paying tips in restaurant/bar: "tip address" ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 9 Sept 2013)<br />
<br />
Further enhancement: Sending billing amount and tip to separate addresses:<br />
<br />
(Note: This feature is typically invisible in the GUI of the customer's wallet app)<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> <span style="color:#E20074">'''tipaddrparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
<span style="color:#E20074">'''tipaddrparam = "tipaddr=" bitcoinaddress'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25</span><span style="color:#E20074">&tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
The "tipaddr" parameter specifies that if the wallet app sends a tip in addition to the "amount", it shall '''''preferably''''' send it to the specifed "tip address". However, this is not mandatory (because it is an optional parameter w/o "req-"), so if the wallet app sends amount and tip to the main address, the merchant shall still be able to figure this out.<br />
<br />
If the merchant cannot handle tips sent to the same address as the billing amount, he shall instead make use of this parameter:<br />
<br />
<span style="color:#a20024">'''reqtipaddrparam = "req-tipaddr=" bitcoinaddress'''</span><br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25&</span><span style="color:#a20024">&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
In this case, the wallet app is guaranteed to send the tip to the separate address, or will otherwise reject the complete URI. Upon rejection, the waiter knows that the customer has a non-compliant wallet app and can start a second try showing the URI without any tip parameters (or with "tip=0"). The tip can then be paid in a separate transaction (or classically by cash).<br />
<br />
== Short parameter tags yielding shorter URIs for QR codes ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 10 Sept 2013)<br />
<br />
Another proposal: Allow short forms for the parameter tags, to shorten the URIs.<br />
<br />
This is not important for URIs when used in links on web pages, but it can become relevant when generating QR codes. The longer the URI, the more difficult it will be to scan and decode the QR code by a smartphone due to smaller QR code block size or lower error protection level.<br />
<br />
Hence a simple table of equivalent ALIASES is proposed, to shorten the URI:<br />
<br />
'''Parameter Tag Alias'''<br />
amount= a=<br />
label= l=<br />
message= m=<br />
tip= t=<br />
tipaddr= ta=<br />
req- -<br />
req-tipaddr= -ta=<br />
req-aal= -aal=<br />
<br />
Hence, for example the following URIs are fully equivalent:<br />
<br />
155 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
129 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?a=.567&t=15%25&-ta=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&m=Thank%20You&l=Charly%27s%20Bar</nowiki><br />
<br />
== Critical Improvement of BIP 0021 for "req-" param ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
One aspect of current BIP 0021 is critical:<br />
<br />
It says that wallets that do not know one or several "req-" keys in the URI should reject (i.e. not process) the complete URI, to avoid doing anything in the wrong way.<br />
<br />
However, very old wallet apps may have not even implemented this rule and may still process the "known part" of the URI, thereby causing an unwanted result.<br />
<br />
The solution to the problem is to specify BIP 0021 in a way that, in case that at least one "req-" key is used, some other details of the URI must be modified too, such that it becomes "incompatible" and "undecodable" by older apps.<br />
<br />
The concrete proposal here is to append "R-" directly after "bitcoin:". Then a string with a "req-" parameter would look like this:<br />
<nowiki>bitcoin:</nowiki>'''R-'''<nowiki>175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&</nowiki>'''req-'''<nowiki>tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
<br />
The BFN Syntax then looks as follows:<br />
bitcoinurn = "bitcoin:" '''[ "R-" ]''' bitcoinaddress [ "?" bitcoinparams ]<br />
where "R-" is mandatory as soon as at least one "reqparam" is used.<br />
<br />
== Paying to Multiple Outputs ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
Another Enhancement relates to the "Humble Bundle" scenario: Paying one transaction with multiple outputs, specifying a dedicated amount for each output address.<br />
<br />
This scenario allows to specify additional pairs of addresses and amounts. Optionally, also further labels can be specified. We call the new parameter "'''req-aal'''" for '''a'''ddress-'''a'''mount-'''l'''abel, and we specify it as a '''req'''uired parameter because procesing an incomplete URI would result in sending only a partial amount.<br />
<br />
bitcoinparam = amountparam | labelparam | '''reqaalparam |''' messageparam | tipparam | tipaddrparam | otherparam | reqparam<br />
reqaalparam = "req-aal=" bitcoinaddress ":" *digit [ "." *digit ] [ ":" *pchar]<br />
<br />
Example:<br />
<nowiki>bitcoin:R-175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&label=book&req-aal=1tZdShH7b38klseWrTZm5sE8PrtZPwqdK:0.123:game&message=Thank%20You</nowiki><br />
<br />
<br />
<br />
== Feed partially signed transactions for wallet to sign ==<br />
<br />
bitcoin:ANYaddress?presig=<br />
<br />
Example <nowiki>bitcoin:ANYaddress?presig=45505446ff0002000000000101beee3e40b018f740df8a88ddb411862abf5a634................1231e61c33b4d6992fb61871a2ec711e7b5793c69632b22ea342804110000050054aedf370900 </nowiki></div>Transistohttps://tests.bitcoin.it/w/index.php?title=Talk:BIP_0021&diff=67010Talk:BIP 00212019-11-17T01:42:36Z<p>Transisto: </p>
<hr />
<div>Marian on IRC reports: "The BNF [here] is erroneous, regarding the params, it says [ "?" bitcoinparams ] while bitcoinparams is just *bitcoinparam, thus with that BNF there are no separators between the parameters". --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:04, 23 April 2013 (GMT)<br />
<br />
--> ([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013) So should it rather be written something like this (I am not a BNF expert, just following my logic):<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparam [ bitcoinparams ] ]<br />
bitcoinparams = *bitcoinparamamp<br />
bitcoinparamamp = "&" bitcoinparam<br />
<br />
<br />
== Suggesting usability enhancement in BIP 0021 for paying tips in restaurant/bar conveniently ("tips w/o taps") ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013)<br />
<br />
I am suggesting a simple downward compatible enhancement of BIP 0021 to allow effortless tipping in restaurants, bars, pubs, etc.<br />
<br />
When watching bitpay's mobile checkout demo video "http://www.youtube.com/watch?v=YZ-pqo0cLcE" it is clear that paying tips is somewhat cumbersome for the customer with today's wallet and merchant solutions. This can be dramatically improved with some support by the client app and a minor enhancement of BIP 0021.<br />
<br />
<span style="color:#0000FF">'''Enhancement proposal'''</span>:<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Actually, "tipparam" is just a special case of "otherparam", hence completely downwards compatible.<br />
<br />
The tip can be specified in BTC or in percent of the amount, and it acts as a recommended or default tip setting in the customer's wallet app.<br />
<br />
'''Examples''' for the following scenario:<br />
:Request 0.567 BTC from the customer of a restaurant and make the customer's bitcoin app show an advanced send dialog that allows adding a tip:<br />
<br />
Ex. 1a) The pre-set tip value in the send dialog is undefined (user must specify) or set to the client's pre-configured default tip value:<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip='''</span><br />
<br />
Ex. 1b) The pre-set tip value in the send dialog is explicitly set to zero (this restaurant is on "service charge included in 'amount'" policy and informs the client about this explicitly by "tip=0" in the URI):<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0'''</span><br />
<br />
Ex. 2) The pre-set tip value is 15% of 0.567 BTC, i.e. 0.08508 BTC:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0.08505'''</span><br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span><br />
[URI code of the percentage character is "%25"]<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%'''</span><br />
["lazy" notation, omitting the "25". Actually, this is NOT correct, not URI compliant (RFC 2396), hence such an URI<br />
should not be generated. But it is proposed that the wallet app that has to decode the URI is implemented to understand<br />
this "lazy" syntax in the "tip" field anyhow, as safeguard to avoid errors in case that the merchant app generates such<br />
a "lazy" URI]<br />
<br />
Ex. 3) The pre-set tip value is 0.08508 BTC, and the "notes" field in the client app is pre-occupied with the name of the restaurant:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span>&message=Charly%27s%20Bar<br />
<br />
Explanation:<br />
* The new parameter has no "req-" prefix, i.e. if an old bitcoin client app does not know it, it can safely ignore it.<br />
* Otherwise, the customer's bitcoin client will not open the normal but an enhanced send dialog where the customer can specify a tip that will be added to the bill to be paid. In examples 2 and 3 above the tip shall be pre-configured with the amount specified in the URI, so the customer can most conveniently just accept it by a simple tap, if the client app is well-written.<br />
<br />
The details are of course dependent on the client app implementation, a best practice-example is demonstrated in the following images.<br />
<br />
Standard send dialog (no tips):<br />
<br />
[[File:bitcoin-app-tipOFF_BIP_0021.png|border]]<br />
<br />
<br />
Advanced send dialog for giving tips:<br />
<br />
[[File:bitcoin-app-tipON_BIP_0021.png|border]]<br />
<br />
Discussion: It has been argued that the described improvement of the user experience for the scenario "make payment with a tip" can be achieved by sole improvement of the wallet app, without any protocol change.<br />
<br />
But this is only partly true. Certainly enhancement of the wallet app to provide an advanced "send" dialog for easy tipping is crucial. However, with the legacy BIP 0021 the wallet app cannot know whether it shall display the standard send dialog (no tip) or the advanced send dialog (with tip option) to the user. So the user has to select this manually. With the optional "tip" parameter in the URI, the wallet app can readily display the appropriate send dialog without extra user interaction, thereby providing ultimate user experience.<br />
<br />
== Further enhancement for paying tips in restaurant/bar: "tip address" ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 9 Sept 2013)<br />
<br />
Further enhancement: Sending billing amount and tip to separate addresses:<br />
<br />
(Note: This feature is typically invisible in the GUI of the customer's wallet app)<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> <span style="color:#E20074">'''tipaddrparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
<span style="color:#E20074">'''tipaddrparam = "tipaddr=" bitcoinaddress'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25</span><span style="color:#E20074">&tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
The "tipaddr" parameter specifies that if the wallet app sends a tip in addition to the "amount", it shall '''''preferably''''' send it to the specifed "tip address". However, this is not mandatory (because it is an optional parameter w/o "req-"), so if the wallet app sends amount and tip to the main address, the merchant shall still be able to figure this out.<br />
<br />
If the merchant cannot handle tips sent to the same address as the billing amount, he shall instead make use of this parameter:<br />
<br />
<span style="color:#a20024">'''reqtipaddrparam = "req-tipaddr=" bitcoinaddress'''</span><br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25&</span><span style="color:#a20024">&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
In this case, the wallet app is guaranteed to send the tip to the separate address, or will otherwise reject the complete URI. Upon rejection, the waiter knows that the customer has a non-compliant wallet app and can start a second try showing the URI without any tip parameters (or with "tip=0"). The tip can then be paid in a separate transaction (or classically by cash).<br />
<br />
== Short parameter tags yielding shorter URIs for QR codes ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 10 Sept 2013)<br />
<br />
Another proposal: Allow short forms for the parameter tags, to shorten the URIs.<br />
<br />
This is not important for URIs when used in links on web pages, but it can become relevant when generating QR codes. The longer the URI, the more difficult it will be to scan and decode the QR code by a smartphone due to smaller QR code block size or lower error protection level.<br />
<br />
Hence a simple table of equivalent ALIASES is proposed, to shorten the URI:<br />
<br />
'''Parameter Tag Alias'''<br />
amount= a=<br />
label= l=<br />
message= m=<br />
tip= t=<br />
tipaddr= ta=<br />
req- -<br />
req-tipaddr= -ta=<br />
req-aal= -aal=<br />
<br />
Hence, for example the following URIs are fully equivalent:<br />
<br />
155 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
129 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?a=.567&t=15%25&-ta=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&m=Thank%20You&l=Charly%27s%20Bar</nowiki><br />
<br />
== Critical Improvement of BIP 0021 for "req-" param ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
One aspect of current BIP 0021 is critical:<br />
<br />
It says that wallets that do not know one or several "req-" keys in the URI should reject (i.e. not process) the complete URI, to avoid doing anything in the wrong way.<br />
<br />
However, very old wallet apps may have not even implemented this rule and may still process the "known part" of the URI, thereby causing an unwanted result.<br />
<br />
The solution to the problem is to specify BIP 0021 in a way that, in case that at least one "req-" key is used, some other details of the URI must be modified too, such that it becomes "incompatible" and "undecodable" by older apps.<br />
<br />
The concrete proposal here is to append "R-" directly after "bitcoin:". Then a string with a "req-" parameter would look like this:<br />
<nowiki>bitcoin:</nowiki>'''R-'''<nowiki>175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&</nowiki>'''req-'''<nowiki>tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
<br />
The BFN Syntax then looks as follows:<br />
bitcoinurn = "bitcoin:" '''[ "R-" ]''' bitcoinaddress [ "?" bitcoinparams ]<br />
where "R-" is mandatory as soon as at least one "reqparam" is used.<br />
<br />
== Paying to Multiple Outputs ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
Another Enhancement relates to the "Humble Bundle" scenario: Paying one transaction with multiple outputs, specifying a dedicated amount for each output address.<br />
<br />
This scenario allows to specify additional pairs of addresses and amounts. Optionally, also further labels can be specified. We call the new parameter "'''req-aal'''" for '''a'''ddress-'''a'''mount-'''l'''abel, and we specify it as a '''req'''uired parameter because procesing an incomplete URI would result in sending only a partial amount.<br />
<br />
bitcoinparam = amountparam | labelparam | '''reqaalparam |''' messageparam | tipparam | tipaddrparam | otherparam | reqparam<br />
reqaalparam = "req-aal=" bitcoinaddress ":" *digit [ "." *digit ] [ ":" *pchar]<br />
<br />
Example:<br />
<nowiki>bitcoin:R-175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&label=book&req-aal=1tZdShH7b38klseWrTZm5sE8PrtZPwqdK:0.123:game&message=Thank%20You</nowiki><br />
<br />
<br />
<br />
== Feed partially signed transactions for wallet to sign ==<br />
<br />
bitcoin:ANYaddress?presig=<br />
<br />
Example `bitcoin:ANYaddress?presig=45505446ff0002000000000101beee3e40b018f740df8a88ddb411862abf5a634................1231e61c33b4d6992fb61871a2ec711e7b5793c69632b22ea342804110000050054aedf370900`</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Talk:BIP_0021&diff=67009Talk:BIP 00212019-11-17T01:41:22Z<p>Transisto: pass pre-signed transaction to wallet.</p>
<hr />
<div>Marian on IRC reports: "The BNF [here] is erroneous, regarding the params, it says [ "?" bitcoinparams ] while bitcoinparams is just *bitcoinparam, thus with that BNF there are no separators between the parameters". --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:04, 23 April 2013 (GMT)<br />
<br />
--> ([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013) So should it rather be written something like this (I am not a BNF expert, just following my logic):<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparam [ bitcoinparams ] ]<br />
bitcoinparams = *bitcoinparamamp<br />
bitcoinparamamp = "&" bitcoinparam<br />
<br />
<br />
== Suggesting usability enhancement in BIP 0021 for paying tips in restaurant/bar conveniently ("tips w/o taps") ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 8 Sept 2013)<br />
<br />
I am suggesting a simple downward compatible enhancement of BIP 0021 to allow effortless tipping in restaurants, bars, pubs, etc.<br />
<br />
When watching bitpay's mobile checkout demo video "http://www.youtube.com/watch?v=YZ-pqo0cLcE" it is clear that paying tips is somewhat cumbersome for the customer with today's wallet and merchant solutions. This can be dramatically improved with some support by the client app and a minor enhancement of BIP 0021.<br />
<br />
<span style="color:#0000FF">'''Enhancement proposal'''</span>:<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Actually, "tipparam" is just a special case of "otherparam", hence completely downwards compatible.<br />
<br />
The tip can be specified in BTC or in percent of the amount, and it acts as a recommended or default tip setting in the customer's wallet app.<br />
<br />
'''Examples''' for the following scenario:<br />
:Request 0.567 BTC from the customer of a restaurant and make the customer's bitcoin app show an advanced send dialog that allows adding a tip:<br />
<br />
Ex. 1a) The pre-set tip value in the send dialog is undefined (user must specify) or set to the client's pre-configured default tip value:<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip='''</span><br />
<br />
Ex. 1b) The pre-set tip value in the send dialog is explicitly set to zero (this restaurant is on "service charge included in 'amount'" policy and informs the client about this explicitly by "tip=0" in the URI):<br />
<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0'''</span><br />
<br />
Ex. 2) The pre-set tip value is 15% of 0.567 BTC, i.e. 0.08508 BTC:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=0.08505'''</span><br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span><br />
[URI code of the percentage character is "%25"]<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%'''</span><br />
["lazy" notation, omitting the "25". Actually, this is NOT correct, not URI compliant (RFC 2396), hence such an URI<br />
should not be generated. But it is proposed that the wallet app that has to decode the URI is implemented to understand<br />
this "lazy" syntax in the "tip" field anyhow, as safeguard to avoid errors in case that the merchant app generates such<br />
a "lazy" URI]<br />
<br />
Ex. 3) The pre-set tip value is 0.08508 BTC, and the "notes" field in the client app is pre-occupied with the name of the restaurant:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25'''</span>&message=Charly%27s%20Bar<br />
<br />
Explanation:<br />
* The new parameter has no "req-" prefix, i.e. if an old bitcoin client app does not know it, it can safely ignore it.<br />
* Otherwise, the customer's bitcoin client will not open the normal but an enhanced send dialog where the customer can specify a tip that will be added to the bill to be paid. In examples 2 and 3 above the tip shall be pre-configured with the amount specified in the URI, so the customer can most conveniently just accept it by a simple tap, if the client app is well-written.<br />
<br />
The details are of course dependent on the client app implementation, a best practice-example is demonstrated in the following images.<br />
<br />
Standard send dialog (no tips):<br />
<br />
[[File:bitcoin-app-tipOFF_BIP_0021.png|border]]<br />
<br />
<br />
Advanced send dialog for giving tips:<br />
<br />
[[File:bitcoin-app-tipON_BIP_0021.png|border]]<br />
<br />
Discussion: It has been argued that the described improvement of the user experience for the scenario "make payment with a tip" can be achieved by sole improvement of the wallet app, without any protocol change.<br />
<br />
But this is only partly true. Certainly enhancement of the wallet app to provide an advanced "send" dialog for easy tipping is crucial. However, with the legacy BIP 0021 the wallet app cannot know whether it shall display the standard send dialog (no tip) or the advanced send dialog (with tip option) to the user. So the user has to select this manually. With the optional "tip" parameter in the URI, the wallet app can readily display the appropriate send dialog without extra user interaction, thereby providing ultimate user experience.<br />
<br />
== Further enhancement for paying tips in restaurant/bar: "tip address" ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 9 Sept 2013)<br />
<br />
Further enhancement: Sending billing amount and tip to separate addresses:<br />
<br />
(Note: This feature is typically invisible in the GUI of the customer's wallet app)<br />
<br />
bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparams ]<br />
bitcoinaddress = base58 *base58<br />
bitcoinparams = *bitcoinparam<br />
bitcoinparam = amountparam | labelparam | messageparam | <span style="color:#0000FF">'''tipparam |'''</span> <span style="color:#E20074">'''tipaddrparam |'''</span> otherparam | reqparam<br />
amountparam = "amount=" *digit [ "." *digit ]<br />
labelparam = "label=" *pchar<br />
messageparam = "message=" *pchar<br />
<span style="color:#0000FF">'''tipparam = "tip=" [ *digit [ "." *digit ] [ "%" [ "25" ] ] ]'''</span><br />
<span style="color:#E20074">'''tipaddrparam = "tipaddr=" bitcoinaddress'''</span><br />
otherparam = pchar *pchar "=" *pchar<br />
reqparam = "req-" pchar *pchar "=" *pchar<br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25</span><span style="color:#E20074">&tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
The "tipaddr" parameter specifies that if the wallet app sends a tip in addition to the "amount", it shall '''''preferably''''' send it to the specifed "tip address". However, this is not mandatory (because it is an optional parameter w/o "req-"), so if the wallet app sends amount and tip to the main address, the merchant shall still be able to figure this out.<br />
<br />
If the merchant cannot handle tips sent to the same address as the billing amount, he shall instead make use of this parameter:<br />
<br />
<span style="color:#a20024">'''reqtipaddrparam = "req-tipaddr=" bitcoinaddress'''</span><br />
<br />
Example:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567</nowiki><span style="color:#0000FF">'''&tip=15%25&</span><span style="color:#a20024">&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2'''</span><br />
<br />
In this case, the wallet app is guaranteed to send the tip to the separate address, or will otherwise reject the complete URI. Upon rejection, the waiter knows that the customer has a non-compliant wallet app and can start a second try showing the URI without any tip parameters (or with "tip=0"). The tip can then be paid in a separate transaction (or classically by cash).<br />
<br />
== Short parameter tags yielding shorter URIs for QR codes ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 10 Sept 2013)<br />
<br />
Another proposal: Allow short forms for the parameter tags, to shorten the URIs.<br />
<br />
This is not important for URIs when used in links on web pages, but it can become relevant when generating QR codes. The longer the URI, the more difficult it will be to scan and decode the QR code by a smartphone due to smaller QR code block size or lower error protection level.<br />
<br />
Hence a simple table of equivalent ALIASES is proposed, to shorten the URI:<br />
<br />
'''Parameter Tag Alias'''<br />
amount= a=<br />
label= l=<br />
message= m=<br />
tip= t=<br />
tipaddr= ta=<br />
req- -<br />
req-tipaddr= -ta=<br />
req-aal= -aal=<br />
<br />
Hence, for example the following URIs are fully equivalent:<br />
<br />
155 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&req-tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
129 characters:<br />
<nowiki>bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?a=.567&t=15%25&-ta=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&m=Thank%20You&l=Charly%27s%20Bar</nowiki><br />
<br />
== Critical Improvement of BIP 0021 for "req-" param ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
One aspect of current BIP 0021 is critical:<br />
<br />
It says that wallets that do not know one or several "req-" keys in the URI should reject (i.e. not process) the complete URI, to avoid doing anything in the wrong way.<br />
<br />
However, very old wallet apps may have not even implemented this rule and may still process the "known part" of the URI, thereby causing an unwanted result.<br />
<br />
The solution to the problem is to specify BIP 0021 in a way that, in case that at least one "req-" key is used, some other details of the URI must be modified too, such that it becomes "incompatible" and "undecodable" by older apps.<br />
<br />
The concrete proposal here is to append "R-" directly after "bitcoin:". Then a string with a "req-" parameter would look like this:<br />
<nowiki>bitcoin:</nowiki>'''R-'''<nowiki>175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&tip=15%25&</nowiki>'''req-'''<nowiki>tipaddr=1waiter7b38klseWrTZm5sE8PrrupPB2Q2&message=Thank%20You&label=Charly%27s%20Bar</nowiki><br />
<br />
<br />
The BFN Syntax then looks as follows:<br />
bitcoinurn = "bitcoin:" '''[ "R-" ]''' bitcoinaddress [ "?" bitcoinparams ]<br />
where "R-" is mandatory as soon as at least one "reqparam" is used.<br />
<br />
== Paying to Multiple Outputs ==<br />
([[User:Michael_S|Michael_S]] ([[User talk:Michael_S|talk]]) 12 Sept 2013)<br />
<br />
Another Enhancement relates to the "Humble Bundle" scenario: Paying one transaction with multiple outputs, specifying a dedicated amount for each output address.<br />
<br />
This scenario allows to specify additional pairs of addresses and amounts. Optionally, also further labels can be specified. We call the new parameter "'''req-aal'''" for '''a'''ddress-'''a'''mount-'''l'''abel, and we specify it as a '''req'''uired parameter because procesing an incomplete URI would result in sending only a partial amount.<br />
<br />
bitcoinparam = amountparam | labelparam | '''reqaalparam |''' messageparam | tipparam | tipaddrparam | otherparam | reqparam<br />
reqaalparam = "req-aal=" bitcoinaddress ":" *digit [ "." *digit ] [ ":" *pchar]<br />
<br />
Example:<br />
<nowiki>bitcoin:R-175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=0.567&label=book&req-aal=1tZdShH7b38klseWrTZm5sE8PrtZPwqdK:0.123:game&message=Thank%20You</nowiki><br />
<br />
<br />
<br />
== Feed partially signed transactions for wallet to sign ==<br />
<br />
`bitcoin:ANYaddress?presig=`<br />
<br />
Example `bitcoin:ANYaddress?presig=45505446ff0002000000000101beee3e40b018f740df8a88ddb411862abf5a634................1231e61c33b4d6992fb61871a2ec711e7b5793c69632b22ea342804110000050054aedf370900`</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Cubits&diff=66244Cubits2019-03-03T20:04:53Z<p>Transisto: </p>
<hr />
<div>'''<big>Cubits announced termination of their exchange and filled for bannkrupcy in a press release on December 11, 2018 <ref> https://www.facebook.com/CubitsHQ/posts/1480335922100663?__tn__=-R</ref><br />
</big>'''<br />
<br />
{infobox company|name=Cubits|image=[[File:Cubits_Logo_square.png|200px]]<br />
|industry=[[:Category:Payment Processors | Payment Processor]], [[eWallet]]<br />
|foundation=2014<br />
|founder=[[Tim Rehder]], [[Julian Mautner]], [[Andreas Lehrbaum]]<br />
|employees=50+ <br />
|location= London, United Kingdom<br />
|twitter=CubitsHQ<br />
|facebook=CubitsHQ<br />
|<br />
|website=[https://cubits.com/ cubits.com]<br />
}}<br />
'''Cubits''' was a multi-purpose Bitcoin platform for buying, exchanging, storing, and accepting Bitcoin. Cubits was founded in 2014 by Tim Rehder, Julian Mautner and Andreas Lehrbaum and launched after a year in development, in January 2015 <ref> http://bitcoinscientist.com/cubits-web-app-launch-aims-accelerate-bitcoin-buying/#sthash.AYcBwi0o.dpbs</ref>. Since its launch, Cubits has been one of the fastest-growing Bitcoin marketplaces in Europe.<br />
Cubits was a UK Registered company and was registered as a Telecommunications Digital & IT Payment Service provider in accordance with UK Money Laundering Regulations. <ref>http://tyba.com/company/cubits/about/ </ref><br />
<br />
<br />
<br />
===Service Description===<br />
Cubits was offering European Bitcoin payment processing services with a secure, user-friendly platform for buying, exchanging, storing, and accepting Bitcoin. Customers are able to buy and sell Bitcoins in 17 different currencies through major payment providers.<br />
===Cubits Wallet===<br />
The Cubits wallet was a web wallet which allows Cubits users to buy, sell and monitor their Bitcoins.<ref>[https://cubits.com]</ref> Users could instantly purchase or sell Bitcoin with Mastercard and Visa or payment providers OKPAY, SOFORT and OBT, and also have the option to connect their Cubits Wallet to their bank account to increase the ease and speed of buy/sell activities. <br />
Cubits 2FA and multisignature technology to ensure that customer's Bitcoins are always secure. Any Bitcoins stored within a Cubits Wallet are placed in deep cold storage, meaning that in the rare event of an online attack users' Bitcoins are never at risk.<br />
<br />
===Features===<br />
*Easy-to-use interface<br />
* Visa and Mastercard supported<br />
*Support for 17 currencies <ref> [http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership] </ref><br />
*Seamless Wallet and Payment Modules <ref> http://www.icetotallygaming.com/news/cubits-goes-ice-totally-gaming-2015-and-announces-partnership-softswiss</ref><br />
*Instant BTC transactions<br />
*Buy/Sell up to 150EUR with only SMS verification<br />
*2FA and Multisignature Security <ref>http://www.slideshare.net/Cubits_BTC/cubits-wp-paymentprocessorv3</ref><br />
*All customer Bitcoins kept in deep cold storage <ref>http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/</ref><br />
*New addresses for individual transactions <ref>http://bitcoinchaser.com/cubits-bitcoin-payment-system-making-strides</ref><br />
<br />
<br />
==External Links==<br />
* [https://cubits.com Cubits.com] website<br />
* [http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/ Cubits Launch Aims to Accelerate Bitcoin Buying in Europe] website<br />
[http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership]<br />
[[Category:EWallets]]<br />
[[Category:Wallets]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Cubits&diff=66243Cubits2019-03-03T20:04:36Z<p>Transisto: </p>
<hr />
<div>'''<big>Cubits announced termination of their exchange and filled for bannkrupcy in a press release on December 11, 2018 <ref> https://www.facebook.com/CubitsHQ/posts/1480335922100663?__tn__=-R</ref><br />
</big>'''{infobox company|name=Cubits|image=[[File:Cubits_Logo_square.png|200px]]<br />
|industry=[[:Category:Payment Processors | Payment Processor]], [[eWallet]]<br />
|foundation=2014<br />
|founder=[[Tim Rehder]], [[Julian Mautner]], [[Andreas Lehrbaum]]<br />
|employees=50+ <br />
|location= London, United Kingdom<br />
|twitter=CubitsHQ<br />
|facebook=CubitsHQ<br />
|<br />
|website=[https://cubits.com/ cubits.com]<br />
}}<br />
'''Cubits''' was a multi-purpose Bitcoin platform for buying, exchanging, storing, and accepting Bitcoin. Cubits was founded in 2014 by Tim Rehder, Julian Mautner and Andreas Lehrbaum and launched after a year in development, in January 2015 <ref> http://bitcoinscientist.com/cubits-web-app-launch-aims-accelerate-bitcoin-buying/#sthash.AYcBwi0o.dpbs</ref>. Since its launch, Cubits has been one of the fastest-growing Bitcoin marketplaces in Europe.<br />
Cubits was a UK Registered company and was registered as a Telecommunications Digital & IT Payment Service provider in accordance with UK Money Laundering Regulations. <ref>http://tyba.com/company/cubits/about/ </ref><br />
<br />
<br />
<br />
===Service Description===<br />
Cubits was offering European Bitcoin payment processing services with a secure, user-friendly platform for buying, exchanging, storing, and accepting Bitcoin. Customers are able to buy and sell Bitcoins in 17 different currencies through major payment providers.<br />
===Cubits Wallet===<br />
The Cubits wallet was a web wallet which allows Cubits users to buy, sell and monitor their Bitcoins.<ref>[https://cubits.com]</ref> Users could instantly purchase or sell Bitcoin with Mastercard and Visa or payment providers OKPAY, SOFORT and OBT, and also have the option to connect their Cubits Wallet to their bank account to increase the ease and speed of buy/sell activities. <br />
Cubits 2FA and multisignature technology to ensure that customer's Bitcoins are always secure. Any Bitcoins stored within a Cubits Wallet are placed in deep cold storage, meaning that in the rare event of an online attack users' Bitcoins are never at risk.<br />
<br />
===Features===<br />
*Easy-to-use interface<br />
* Visa and Mastercard supported<br />
*Support for 17 currencies <ref> [http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership] </ref><br />
*Seamless Wallet and Payment Modules <ref> http://www.icetotallygaming.com/news/cubits-goes-ice-totally-gaming-2015-and-announces-partnership-softswiss</ref><br />
*Instant BTC transactions<br />
*Buy/Sell up to 150EUR with only SMS verification<br />
*2FA and Multisignature Security <ref>http://www.slideshare.net/Cubits_BTC/cubits-wp-paymentprocessorv3</ref><br />
*All customer Bitcoins kept in deep cold storage <ref>http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/</ref><br />
*New addresses for individual transactions <ref>http://bitcoinchaser.com/cubits-bitcoin-payment-system-making-strides</ref><br />
<br />
<br />
==External Links==<br />
* [https://cubits.com Cubits.com] website<br />
* [http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/ Cubits Launch Aims to Accelerate Bitcoin Buying in Europe] website<br />
[http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership]<br />
[[Category:EWallets]]<br />
[[Category:Wallets]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Cubits&diff=66242Cubits2019-03-03T20:03:58Z<p>Transisto: changed tenses</p>
<hr />
<div><big>Cubits announced termination of their exchange and filled for bannkrupcy in a press release on December 11, 2018 <ref> https://www.facebook.com/CubitsHQ/posts/1480335922100663?__tn__=-R</ref><br />
</big><br />
{{infobox company|name=Cubits|image=[[File:Cubits_Logo_square.png|200px]]<br />
|industry=[[:Category:Payment Processors | Payment Processor]], [[eWallet]]<br />
|foundation=2014<br />
|founder=[[Tim Rehder]], [[Julian Mautner]], [[Andreas Lehrbaum]]<br />
|employees=50+ <br />
|location= London, United Kingdom<br />
|twitter=CubitsHQ<br />
|facebook=CubitsHQ<br />
|<br />
|website=[https://cubits.com/ cubits.com]<br />
}}<br />
'''Cubits''' was a multi-purpose Bitcoin platform for buying, exchanging, storing, and accepting Bitcoin. Cubits was founded in 2014 by Tim Rehder, Julian Mautner and Andreas Lehrbaum and launched after a year in development, in January 2015 <ref> http://bitcoinscientist.com/cubits-web-app-launch-aims-accelerate-bitcoin-buying/#sthash.AYcBwi0o.dpbs</ref>. Since its launch, Cubits has been one of the fastest-growing Bitcoin marketplaces in Europe.<br />
Cubits was a UK Registered company and was registered as a Telecommunications Digital & IT Payment Service provider in accordance with UK Money Laundering Regulations. <ref>http://tyba.com/company/cubits/about/ </ref><br />
<br />
<br />
<br />
===Service Description===<br />
Cubits was offering European Bitcoin payment processing services with a secure, user-friendly platform for buying, exchanging, storing, and accepting Bitcoin. Customers are able to buy and sell Bitcoins in 17 different currencies through major payment providers.<br />
===Cubits Wallet===<br />
The Cubits wallet was a web wallet which allows Cubits users to buy, sell and monitor their Bitcoins.<ref>[https://cubits.com]</ref> Users could instantly purchase or sell Bitcoin with Mastercard and Visa or payment providers OKPAY, SOFORT and OBT, and also have the option to connect their Cubits Wallet to their bank account to increase the ease and speed of buy/sell activities. <br />
Cubits 2FA and multisignature technology to ensure that customer's Bitcoins are always secure. Any Bitcoins stored within a Cubits Wallet are placed in deep cold storage, meaning that in the rare event of an online attack users' Bitcoins are never at risk.<br />
<br />
===Features===<br />
*Easy-to-use interface<br />
* Visa and Mastercard supported<br />
*Support for 17 currencies <ref> [http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership] </ref><br />
*Seamless Wallet and Payment Modules <ref> http://www.icetotallygaming.com/news/cubits-goes-ice-totally-gaming-2015-and-announces-partnership-softswiss</ref><br />
*Instant BTC transactions<br />
*Buy/Sell up to 150EUR with only SMS verification<br />
*2FA and Multisignature Security <ref>http://www.slideshare.net/Cubits_BTC/cubits-wp-paymentprocessorv3</ref><br />
*All customer Bitcoins kept in deep cold storage <ref>http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/</ref><br />
*New addresses for individual transactions <ref>http://bitcoinchaser.com/cubits-bitcoin-payment-system-making-strides</ref><br />
<br />
<br />
==External Links==<br />
* [https://cubits.com Cubits.com] website<br />
* [http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/ Cubits Launch Aims to Accelerate Bitcoin Buying in Europe] website<br />
[http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership]<br />
[[Category:EWallets]]<br />
[[Category:Wallets]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Cubits&diff=66241Cubits2019-03-03T20:02:24Z<p>Transisto: </p>
<hr />
<div><big>Cubits announced termination of their exchange and filled for bannkrupcy in a press release on December 11, 2018 <ref> https://www.facebook.com/CubitsHQ/posts/1480335922100663?__tn__=-R</ref><br />
</big><br />
{{infobox company|name=Cubits|image=[[File:Cubits_Logo_square.png|200px]]<br />
|industry=[[:Category:Payment Processors | Payment Processor]], [[eWallet]]<br />
|foundation=2014<br />
|founder=[[Tim Rehder]], [[Julian Mautner]], [[Andreas Lehrbaum]]<br />
|employees=50+ <br />
|location= London, United Kingdom<br />
|twitter=CubitsHQ<br />
|facebook=CubitsHQ<br />
|<br />
|website=[https://cubits.com/ cubits.com]<br />
}}<br />
'''Cubits''' was a multi-purpose Bitcoin platform for buying, exchanging, storing, and accepting Bitcoin. Cubits was founded in 2014 by Tim Rehder, Julian Mautner and Andreas Lehrbaum and launched after a year in development, in January 2015 <ref> http://bitcoinscientist.com/cubits-web-app-launch-aims-accelerate-bitcoin-buying/#sthash.AYcBwi0o.dpbs</ref>. Since its launch, Cubits has been one of the fastest-growing Bitcoin marketplaces in Europe.<br />
Cubits is a UK Registered company and is registered as a Telecommunications Digital & IT Payment Service provider in accordance with UK Money Laundering Regulations. <ref>http://tyba.com/company/cubits/about/ </ref><br />
<br />
<br />
<br />
===Service Description===<br />
Cubits offers one of the premier European Bitcoin payment processing services with a secure, user-friendly platform for buying, exchanging, storing, and accepting Bitcoin. Customers are able to buy and sell Bitcoins in 17 different currencies through major payment providers.<br />
===Cubits Wallet===<br />
The Cubits wallet is a web wallet which allows Cubits users to buy, sell and monitor their Bitcoins.<ref>[https://cubits.com]</ref> Users can instantly purchase or sell Bitcoin with Mastercard and Visa or payment providers OKPAY, SOFORT and OBT, and also have the option to connect their Cubits Wallet to their bank account to increase the ease and speed of buy/sell activities. <br />
Cubits 2FA and multisignature technology to ensure that customer's Bitcoins are always secure. Any Bitcoins stored within a Cubits Wallet are placed in deep cold storage, meaning that in the rare event of an online attack users' Bitcoins are never at risk.<br />
<br />
===Features===<br />
*Easy-to-use interface<br />
* Visa and Mastercard supported<br />
*Support for 17 currencies <ref> [http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership] </ref><br />
*Seamless Wallet and Payment Modules <ref> http://www.icetotallygaming.com/news/cubits-goes-ice-totally-gaming-2015-and-announces-partnership-softswiss</ref><br />
*Instant BTC transactions<br />
*Buy/Sell up to 150EUR with only SMS verification<br />
*2FA and Multisignature Security <ref>http://www.slideshare.net/Cubits_BTC/cubits-wp-paymentprocessorv3</ref><br />
*All customer Bitcoins kept in deep cold storage <ref>http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/</ref><br />
*New addresses for individual transactions <ref>http://bitcoinchaser.com/cubits-bitcoin-payment-system-making-strides</ref><br />
<br />
<br />
==External Links==<br />
* [https://cubits.com Cubits.com] website<br />
* [http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/ Cubits Launch Aims to Accelerate Bitcoin Buying in Europe] website<br />
[http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership]<br />
[[Category:EWallets]]<br />
[[Category:Wallets]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Cubits&diff=66240Cubits2019-03-03T20:01:59Z<p>Transisto: dead exchange</p>
<hr />
<div>Cubits announced termination of their exchange and filled for bannkrupcy in a press release on December 11, 2018 <ref> https://www.facebook.com/CubitsHQ/posts/1480335922100663?__tn__=-R</ref><br />
<br />
{{infobox company|name=Cubits|image=[[File:Cubits_Logo_square.png|200px]]<br />
|industry=[[:Category:Payment Processors | Payment Processor]], [[eWallet]]<br />
|foundation=2014<br />
|founder=[[Tim Rehder]], [[Julian Mautner]], [[Andreas Lehrbaum]]<br />
|employees=50+ <br />
|location= London, United Kingdom<br />
|twitter=CubitsHQ<br />
|facebook=CubitsHQ<br />
|<br />
|website=[https://cubits.com/ cubits.com]<br />
}}<br />
'''Cubits''' was a multi-purpose Bitcoin platform for buying, exchanging, storing, and accepting Bitcoin. Cubits was founded in 2014 by Tim Rehder, Julian Mautner and Andreas Lehrbaum and launched after a year in development, in January 2015 <ref> http://bitcoinscientist.com/cubits-web-app-launch-aims-accelerate-bitcoin-buying/#sthash.AYcBwi0o.dpbs</ref>. Since its launch, Cubits has been one of the fastest-growing Bitcoin marketplaces in Europe.<br />
Cubits is a UK Registered company and is registered as a Telecommunications Digital & IT Payment Service provider in accordance with UK Money Laundering Regulations. <ref>http://tyba.com/company/cubits/about/ </ref><br />
<br />
<br />
<br />
===Service Description===<br />
Cubits offers one of the premier European Bitcoin payment processing services with a secure, user-friendly platform for buying, exchanging, storing, and accepting Bitcoin. Customers are able to buy and sell Bitcoins in 17 different currencies through major payment providers.<br />
===Cubits Wallet===<br />
The Cubits wallet is a web wallet which allows Cubits users to buy, sell and monitor their Bitcoins.<ref>[https://cubits.com]</ref> Users can instantly purchase or sell Bitcoin with Mastercard and Visa or payment providers OKPAY, SOFORT and OBT, and also have the option to connect their Cubits Wallet to their bank account to increase the ease and speed of buy/sell activities. <br />
Cubits 2FA and multisignature technology to ensure that customer's Bitcoins are always secure. Any Bitcoins stored within a Cubits Wallet are placed in deep cold storage, meaning that in the rare event of an online attack users' Bitcoins are never at risk.<br />
<br />
===Features===<br />
*Easy-to-use interface<br />
* Visa and Mastercard supported<br />
*Support for 17 currencies <ref> [http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership] </ref><br />
*Seamless Wallet and Payment Modules <ref> http://www.icetotallygaming.com/news/cubits-goes-ice-totally-gaming-2015-and-announces-partnership-softswiss</ref><br />
*Instant BTC transactions<br />
*Buy/Sell up to 150EUR with only SMS verification<br />
*2FA and Multisignature Security <ref>http://www.slideshare.net/Cubits_BTC/cubits-wp-paymentprocessorv3</ref><br />
*All customer Bitcoins kept in deep cold storage <ref>http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/</ref><br />
*New addresses for individual transactions <ref>http://bitcoinchaser.com/cubits-bitcoin-payment-system-making-strides</ref><br />
<br />
<br />
==External Links==<br />
* [https://cubits.com Cubits.com] website<br />
* [http://www.coindesk.com/cubits-app-launch-aims-accelerate-bitcoin-buying-europe/ Cubits Launch Aims to Accelerate Bitcoin Buying in Europe] website<br />
[http://www.igamingbusiness.com/news/softswiss-and-cubits-bitcoin-payments-partnership]<br />
[[Category:EWallets]]<br />
[[Category:Wallets]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Coinkite&diff=66239Coinkite2019-03-03T19:57:28Z<p>Transisto: </p>
<hr />
<div>==Coinkite==<br />
<br />
<br />
<br />
Coinkite<ref> (12/11/2013). [http://www.thestar.com/news/gta/2013/11/12/bitcoin_entrepreneurs_want_to_put_virtual_coins_in_your_wallet.html "Bitcoin entrepreneurs want to put virtual coins in your wallet".] ''[[Toronto Star]]''.</ref><ref> (11/11/2013). [http://bitcoinmagazine.com/7449/exploring-the-bitcoin-alliance-of-canada-part-i/ "Bitcoin in Canada, Part I: Introducing the Bitcoin Alliance of Canada".] ''[[Bitcoin Magazine]]''.</ref><ref>nvK (10/11/2013). [https://bitcointalk.org/index.php?topic=309431.0 "(ANN) Coinkite.com (Bitcoin Wallet+Debit Card+POS Terminals)accepting invites re".] ''[[bitcointalk.org]]''.</ref><ref>KYT DOTSON (22/10/2013). [http://siliconangle.com/blog/2013/09/25/bitcoin-weekly-2013-september-25-lucky-gambler-makes-11k-btc-coinsetter-to-launch-soon-coinkite-brings-pos-solution/ "Bitcoin Weekly 2013 September 25: Lucky Gambler Makes 11k BTC, Coinsetter to Launch Soon, Coinkite Brings POS Solution".] ''[[Silicon Angle]]''.</ref><ref> (5/11/2013). [https://en.bitcoin.it/wiki/Coinkite "Coinkite".] ''[[Bitcoin Wiki]]''.</ref><ref> (5/11/2013). [https://www.coinforum.ca/discussion/461/accepting-invite-requests-for-coinkite-com "Accepting invite requests for Coinkite.com".] ''[[coinforum.ca]]''.</ref><ref> (1/11/2013). [http://www.thebitpages.com/merchants/1076 "Coinkite".] ''[[The Bit Pages]]''.</ref><ref> (2013). [http://www.linkedin.com/company/coinkite "Company: Coinkite".] ''[[LinkedIN]]''.</ref> offers a number of [[bitcoin]] services, including hardware wallet such as Coldcard and Opendime.<br />
<br />
<br />
Coikite closed it's Online wallet service on March 28th, 2016 <ref>[https://coinkite.com/faq]</ref><br />
<br />
<br />
==Discontinued wallet features== <br />
* Powerful, easy to use web wallet. Receive and send bitcoin amounts from a web interface. Two factor authentication, memorable image (to resist phishing attempts) and many other security features are in place. Users are free of the burden of securing their own computer.<br />
<br />
* [https://coinkite.com/faq/multisig Multi-Signature and shared wallets] with up to M-of-15 and options for any/all keys to be generated offline (Co-Sign Pages and Bitcoin Multisig API)<br />
<br />
* Developers Platform, [https://coinkite.com/developers Bitkit Bitcoin API] provides simple and powerful REST integrations for adding bitcoin functions into your business / application.<br />
<br />
* Payment Processing, customizable [https://coinkite.com/faq/pay Pay/Buy/Donate buttons] to integrate in your website or shopping cart. Works over Tor.<br />
<br />
* Point-of-sale payment terminal. Coinkite sells a hardware device, complete with QR scanner and receipt printer that can be used to perform bitcoin transactions without a computer and in a retail setting.<br />
<br />
* "Debit" Card. Coinkite offers all it's members a plastic card which can be used at the payment terminals, but is also useful anywhere as it has a bitcoin address on the back. Bitcoin sent to that address are linked to the user's Coinkite balance.<br />
<br />
==Discontinued Wallet Services==<br />
<br />
* multiple sub-accounts for grouping funds (ie. "Savings", "Chequing")<br />
<br />
* all transactions occur in the public blockchain, and there is no "internal bookkeeping" of funds.<br />
<br />
* monthly, yearly and pay as you go membership plans are offered.<br />
<br />
* detailed transaction logging, real-time on-screen alerts as funds as received<br />
<br />
* multiple [[cryptocurrenies]]: bitcoin, litecoin, testnet coins are offered with equal features<br />
<br />
====Services Links====<br />
<br />
* [https://coinkite.com/faq/money Online wallets]<br />
<br />
* [https://coinkite.com/faq/terminal Merchant Point-of-Sale terminals]<br />
<br />
* [https://coinkite.com/faq/terminal Bitcoin debit cards]<br />
<br />
==Unique [[BIP]] 32 Feature==<br />
<br />
Coinkite is internally based on BIP 32 [[Hierarchical Deterministic]] (HD) wallets. Each new member receives a "welcome email" which contains the "xpubkey" (extended public key) for their deposits, and an *encrypted* copy of the corresponding xprivkey. The xpubkey can be used by the account owner to see all public keys associated with their account (both past and future). Combined with the "audit" feature, the user can fetch a list of all UTXO (unspent transaction outputs) associated with their account and verify the public key's subpath from the given xpubkey. Similarly, they can check the UTXO is correctly stored on the blockchain.<br />
<br />
<br />
Coinkite has stated that in the event of the closure or other failure of the business, they will publicize the symmetric key protecting the xprivkey values that have been distributed to members. With that key, each user could recover their funds by re-generating the private keys for each UTXO. <br />
<br />
<br />
The founders of Coinkite understood the inherent risk of trusting a third party with the private keys for your bitcoins, and this application of BIP 32 helps to address these concerns should the business disappear. The company calls this system "full reserve" since the users are in a position to verify that their funds are not being used for any other purpose than safe-keeping while on deposit at Coinkite.<br />
<br />
==Debit Card==<br />
<br />
For a small fee (and included in some membership plans), Coinkite users may receive a physical card. This eases use of their Coinkite account at the POS terminal and the QR code on the rear is useful for making deposits.<br />
<br />
==POS Terminal==<br />
<br />
Coinkite sells a hardware device which can perform a number of transactions. It connects via GPRS (cell) or Wifi to Coinkite backend servers which perform the blockchain operations. It does not directly connect to the P2P network.<br />
<br />
Users can log into their Coinkite account at the machine, using either their Coinkite card (and a 4-6 digit PIN, plus optionally a 2FA token) or use a one-time QR code from the Coinkite website. Once connected to their account, they can perform many types of transactions:<br />
<br />
* print out their current balances<br />
<br />
* scan a QR and pay it using their balance<br />
<br />
* withdraw funds to cash (requires the retail to become the counter-party)<br />
<br />
* deposit cash (buying coins from the retailer)<br />
<br />
* make a printed invoice (ie. a unique bitcoin address for payment of a specific amount)<br />
<br />
* verify a payment has been received (by scanning any receipt printed by a Coinkite terminal)<br />
<br />
The POS terminal is also useful to enable the bitcoin-based retail business. Cashiers (authorized users) can print a receipt with QR code that maybe presented to customers as a bill in bitcoin to be paid. Once paid, using any bitcoin wallet of choice, the payment can be easily verified at the terminal by scanning it's QR code. The number of confirmations for the incoming funds is displayed and appropriate warnings are shown for zero confirmation transactions. It is up to the retailer to define their policy on number of required confirmations and presumably the size of the transaction will be a deciding factor.<br />
<br />
Other "non account holder" transactions that are possible:<br />
<br />
* print current exchange rates (Bitcoin vs. fiat) to a receipt<br />
<br />
* deposit cash into bitcoin (ie. retailer is selling bitcoins)<br />
<br />
* coins are delivered to a URL or private key.<br />
<br />
* scan bitcoin QR to pay (retailer is selling bitcoins, paid directly to settle bitcoin debt)<br />
<br />
* scan to verify transaction (prints amount received, and confirmation status for Coinkite transactions)<br />
<br />
The POS terminal supports Bitcoin for all operations. Coins can be delivered as a paper wallet, directly into a Coinkite account (must be pre-existing) or into web voucher (PIN code and short URL).<br />
<br />
==External Links==<br />
<br />
* [https://www.coinkite.com Coinkite Home page]<br />
<br />
* [https://www.coinkite.com/faq FAQ page]<br />
<br />
* [https://coinkite.com/promo/wiki Sign-up]<br />
<br />
* [http://expresscoin.com/wallets/bitcoin/coinkite How to Setup a Coinkite Bitcoin Wallet]<br />
<br />
==References==<br />
<references /><br />
<br />
==Images==<br />
[[File:Coinkite_interfaces.png|300 px|alt=Coinkite interfaces|Coinkite interfaces]]<br />
[[File:Bitcoin-pos-terminal.png|300 px|alt=Bitcoin POs Terminal|Coinkite terminal]]<br />
[[File:Coinkite_logo.png|300 px|alt=Coinkite logo|Coinkite logo]]<br />
[[File:Http://i.imgur.com/AnrNck0.png|300 px|Coinkite's Bitcoin Payment Button]]<br />
<br />
[[Category:Debit Cards]]<br />
[[Category:Wallets]]<br />
[[Category:EWallets]]<br />
[[Category:HybridEWallets]]<br />
[[Category:Mixing_Services]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]<br />
[[Category:Hardware Terminals]]<br />
[[Category:Cryptobanks]]<br />
[[Category:POS]]<br />
[[Category:Bitcoin payment systems]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Coinkite&diff=66238Coinkite2019-03-03T19:57:08Z<p>Transisto: </p>
<hr />
<div>==Coinkite==<br />
<br />
<br />
<br />
Coinkite<ref> (12/11/2013). [http://www.thestar.com/news/gta/2013/11/12/bitcoin_entrepreneurs_want_to_put_virtual_coins_in_your_wallet.html "Bitcoin entrepreneurs want to put virtual coins in your wallet".] ''[[Toronto Star]]''.</ref><ref> (11/11/2013). [http://bitcoinmagazine.com/7449/exploring-the-bitcoin-alliance-of-canada-part-i/ "Bitcoin in Canada, Part I: Introducing the Bitcoin Alliance of Canada".] ''[[Bitcoin Magazine]]''.</ref><ref>nvK (10/11/2013). [https://bitcointalk.org/index.php?topic=309431.0 "(ANN) Coinkite.com (Bitcoin Wallet+Debit Card+POS Terminals)accepting invites re".] ''[[bitcointalk.org]]''.</ref><ref>KYT DOTSON (22/10/2013). [http://siliconangle.com/blog/2013/09/25/bitcoin-weekly-2013-september-25-lucky-gambler-makes-11k-btc-coinsetter-to-launch-soon-coinkite-brings-pos-solution/ "Bitcoin Weekly 2013 September 25: Lucky Gambler Makes 11k BTC, Coinsetter to Launch Soon, Coinkite Brings POS Solution".] ''[[Silicon Angle]]''.</ref><ref> (5/11/2013). [https://en.bitcoin.it/wiki/Coinkite "Coinkite".] ''[[Bitcoin Wiki]]''.</ref><ref> (5/11/2013). [https://www.coinforum.ca/discussion/461/accepting-invite-requests-for-coinkite-com "Accepting invite requests for Coinkite.com".] ''[[coinforum.ca]]''.</ref><ref> (1/11/2013). [http://www.thebitpages.com/merchants/1076 "Coinkite".] ''[[The Bit Pages]]''.</ref><ref> (2013). [http://www.linkedin.com/company/coinkite "Company: Coinkite".] ''[[LinkedIN]]''.</ref> offers a number of [[bitcoin]] services, including hardware wallet such as Coldcard and Opendime.<br />
<br />
Coikite had closed it's Online wallet service on March 28th, 2016 <ref>[https://coinkite.com/faq]</ref><br />
<br />
<br />
==Discontinued wallet features== <br />
* Powerful, easy to use web wallet. Receive and send bitcoin amounts from a web interface. Two factor authentication, memorable image (to resist phishing attempts) and many other security features are in place. Users are free of the burden of securing their own computer.<br />
<br />
* [https://coinkite.com/faq/multisig Multi-Signature and shared wallets] with up to M-of-15 and options for any/all keys to be generated offline (Co-Sign Pages and Bitcoin Multisig API)<br />
<br />
* Developers Platform, [https://coinkite.com/developers Bitkit Bitcoin API] provides simple and powerful REST integrations for adding bitcoin functions into your business / application.<br />
<br />
* Payment Processing, customizable [https://coinkite.com/faq/pay Pay/Buy/Donate buttons] to integrate in your website or shopping cart. Works over Tor.<br />
<br />
* Point-of-sale payment terminal. Coinkite sells a hardware device, complete with QR scanner and receipt printer that can be used to perform bitcoin transactions without a computer and in a retail setting.<br />
<br />
* "Debit" Card. Coinkite offers all it's members a plastic card which can be used at the payment terminals, but is also useful anywhere as it has a bitcoin address on the back. Bitcoin sent to that address are linked to the user's Coinkite balance.<br />
<br />
==Discontinued Wallet Services==<br />
<br />
* multiple sub-accounts for grouping funds (ie. "Savings", "Chequing")<br />
<br />
* all transactions occur in the public blockchain, and there is no "internal bookkeeping" of funds.<br />
<br />
* monthly, yearly and pay as you go membership plans are offered.<br />
<br />
* detailed transaction logging, real-time on-screen alerts as funds as received<br />
<br />
* multiple [[cryptocurrenies]]: bitcoin, litecoin, testnet coins are offered with equal features<br />
<br />
====Services Links====<br />
<br />
* [https://coinkite.com/faq/money Online wallets]<br />
<br />
* [https://coinkite.com/faq/terminal Merchant Point-of-Sale terminals]<br />
<br />
* [https://coinkite.com/faq/terminal Bitcoin debit cards]<br />
<br />
==Unique [[BIP]] 32 Feature==<br />
<br />
Coinkite is internally based on BIP 32 [[Hierarchical Deterministic]] (HD) wallets. Each new member receives a "welcome email" which contains the "xpubkey" (extended public key) for their deposits, and an *encrypted* copy of the corresponding xprivkey. The xpubkey can be used by the account owner to see all public keys associated with their account (both past and future). Combined with the "audit" feature, the user can fetch a list of all UTXO (unspent transaction outputs) associated with their account and verify the public key's subpath from the given xpubkey. Similarly, they can check the UTXO is correctly stored on the blockchain.<br />
<br />
<br />
Coinkite has stated that in the event of the closure or other failure of the business, they will publicize the symmetric key protecting the xprivkey values that have been distributed to members. With that key, each user could recover their funds by re-generating the private keys for each UTXO. <br />
<br />
<br />
The founders of Coinkite understood the inherent risk of trusting a third party with the private keys for your bitcoins, and this application of BIP 32 helps to address these concerns should the business disappear. The company calls this system "full reserve" since the users are in a position to verify that their funds are not being used for any other purpose than safe-keeping while on deposit at Coinkite.<br />
<br />
==Debit Card==<br />
<br />
For a small fee (and included in some membership plans), Coinkite users may receive a physical card. This eases use of their Coinkite account at the POS terminal and the QR code on the rear is useful for making deposits.<br />
<br />
==POS Terminal==<br />
<br />
Coinkite sells a hardware device which can perform a number of transactions. It connects via GPRS (cell) or Wifi to Coinkite backend servers which perform the blockchain operations. It does not directly connect to the P2P network.<br />
<br />
Users can log into their Coinkite account at the machine, using either their Coinkite card (and a 4-6 digit PIN, plus optionally a 2FA token) or use a one-time QR code from the Coinkite website. Once connected to their account, they can perform many types of transactions:<br />
<br />
* print out their current balances<br />
<br />
* scan a QR and pay it using their balance<br />
<br />
* withdraw funds to cash (requires the retail to become the counter-party)<br />
<br />
* deposit cash (buying coins from the retailer)<br />
<br />
* make a printed invoice (ie. a unique bitcoin address for payment of a specific amount)<br />
<br />
* verify a payment has been received (by scanning any receipt printed by a Coinkite terminal)<br />
<br />
The POS terminal is also useful to enable the bitcoin-based retail business. Cashiers (authorized users) can print a receipt with QR code that maybe presented to customers as a bill in bitcoin to be paid. Once paid, using any bitcoin wallet of choice, the payment can be easily verified at the terminal by scanning it's QR code. The number of confirmations for the incoming funds is displayed and appropriate warnings are shown for zero confirmation transactions. It is up to the retailer to define their policy on number of required confirmations and presumably the size of the transaction will be a deciding factor.<br />
<br />
Other "non account holder" transactions that are possible:<br />
<br />
* print current exchange rates (Bitcoin vs. fiat) to a receipt<br />
<br />
* deposit cash into bitcoin (ie. retailer is selling bitcoins)<br />
<br />
* coins are delivered to a URL or private key.<br />
<br />
* scan bitcoin QR to pay (retailer is selling bitcoins, paid directly to settle bitcoin debt)<br />
<br />
* scan to verify transaction (prints amount received, and confirmation status for Coinkite transactions)<br />
<br />
The POS terminal supports Bitcoin for all operations. Coins can be delivered as a paper wallet, directly into a Coinkite account (must be pre-existing) or into web voucher (PIN code and short URL).<br />
<br />
==External Links==<br />
<br />
* [https://www.coinkite.com Coinkite Home page]<br />
<br />
* [https://www.coinkite.com/faq FAQ page]<br />
<br />
* [https://coinkite.com/promo/wiki Sign-up]<br />
<br />
* [http://expresscoin.com/wallets/bitcoin/coinkite How to Setup a Coinkite Bitcoin Wallet]<br />
<br />
==References==<br />
<references /><br />
<br />
==Images==<br />
[[File:Coinkite_interfaces.png|300 px|alt=Coinkite interfaces|Coinkite interfaces]]<br />
[[File:Bitcoin-pos-terminal.png|300 px|alt=Bitcoin POs Terminal|Coinkite terminal]]<br />
[[File:Coinkite_logo.png|300 px|alt=Coinkite logo|Coinkite logo]]<br />
[[File:Http://i.imgur.com/AnrNck0.png|300 px|Coinkite's Bitcoin Payment Button]]<br />
<br />
[[Category:Debit Cards]]<br />
[[Category:Wallets]]<br />
[[Category:EWallets]]<br />
[[Category:HybridEWallets]]<br />
[[Category:Mixing_Services]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]<br />
[[Category:Hardware Terminals]]<br />
[[Category:Cryptobanks]]<br />
[[Category:POS]]<br />
[[Category:Bitcoin payment systems]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Coinkite&diff=66237Coinkite2019-03-03T19:56:40Z<p>Transisto: very outdated</p>
<hr />
<div>==Coinkite==<br />
<br />
<br />
<br />
Coinkite<ref> (12/11/2013). [http://www.thestar.com/news/gta/2013/11/12/bitcoin_entrepreneurs_want_to_put_virtual_coins_in_your_wallet.html "Bitcoin entrepreneurs want to put virtual coins in your wallet".] ''[[Toronto Star]]''.</ref><ref> (11/11/2013). [http://bitcoinmagazine.com/7449/exploring-the-bitcoin-alliance-of-canada-part-i/ "Bitcoin in Canada, Part I: Introducing the Bitcoin Alliance of Canada".] ''[[Bitcoin Magazine]]''.</ref><ref>nvK (10/11/2013). [https://bitcointalk.org/index.php?topic=309431.0 "(ANN) Coinkite.com (Bitcoin Wallet+Debit Card+POS Terminals)accepting invites re".] ''[[bitcointalk.org]]''.</ref><ref>KYT DOTSON (22/10/2013). [http://siliconangle.com/blog/2013/09/25/bitcoin-weekly-2013-september-25-lucky-gambler-makes-11k-btc-coinsetter-to-launch-soon-coinkite-brings-pos-solution/ "Bitcoin Weekly 2013 September 25: Lucky Gambler Makes 11k BTC, Coinsetter to Launch Soon, Coinkite Brings POS Solution".] ''[[Silicon Angle]]''.</ref><ref> (5/11/2013). [https://en.bitcoin.it/wiki/Coinkite "Coinkite".] ''[[Bitcoin Wiki]]''.</ref><ref> (5/11/2013). [https://www.coinforum.ca/discussion/461/accepting-invite-requests-for-coinkite-com "Accepting invite requests for Coinkite.com".] ''[[coinforum.ca]]''.</ref><ref> (1/11/2013). [http://www.thebitpages.com/merchants/1076 "Coinkite".] ''[[The Bit Pages]]''.</ref><ref> (2013). [http://www.linkedin.com/company/coinkite "Company: Coinkite".] ''[[LinkedIN]]''.</ref> offers a number of [[bitcoin]] services, including hardware wallet such as Coldcard and Opendime.<br />
<br />
Coikite had closed it's Online wallet service on March 28th, 2016 <br />
<ref>[https://coinkite.com/faq]<br />
<br />
<br />
==Discontinued wallet features== <br />
* Powerful, easy to use web wallet. Receive and send bitcoin amounts from a web interface. Two factor authentication, memorable image (to resist phishing attempts) and many other security features are in place. Users are free of the burden of securing their own computer.<br />
<br />
* [https://coinkite.com/faq/multisig Multi-Signature and shared wallets] with up to M-of-15 and options for any/all keys to be generated offline (Co-Sign Pages and Bitcoin Multisig API)<br />
<br />
* Developers Platform, [https://coinkite.com/developers Bitkit Bitcoin API] provides simple and powerful REST integrations for adding bitcoin functions into your business / application.<br />
<br />
* Payment Processing, customizable [https://coinkite.com/faq/pay Pay/Buy/Donate buttons] to integrate in your website or shopping cart. Works over Tor.<br />
<br />
* Point-of-sale payment terminal. Coinkite sells a hardware device, complete with QR scanner and receipt printer that can be used to perform bitcoin transactions without a computer and in a retail setting.<br />
<br />
* "Debit" Card. Coinkite offers all it's members a plastic card which can be used at the payment terminals, but is also useful anywhere as it has a bitcoin address on the back. Bitcoin sent to that address are linked to the user's Coinkite balance.<br />
<br />
==Discontinued Wallet Services==<br />
<br />
* multiple sub-accounts for grouping funds (ie. "Savings", "Chequing")<br />
<br />
* all transactions occur in the public blockchain, and there is no "internal bookkeeping" of funds.<br />
<br />
* monthly, yearly and pay as you go membership plans are offered.<br />
<br />
* detailed transaction logging, real-time on-screen alerts as funds as received<br />
<br />
* multiple [[cryptocurrenies]]: bitcoin, litecoin, testnet coins are offered with equal features<br />
<br />
====Services Links====<br />
<br />
* [https://coinkite.com/faq/money Online wallets]<br />
<br />
* [https://coinkite.com/faq/terminal Merchant Point-of-Sale terminals]<br />
<br />
* [https://coinkite.com/faq/terminal Bitcoin debit cards]<br />
<br />
==Unique [[BIP]] 32 Feature==<br />
<br />
Coinkite is internally based on BIP 32 [[Hierarchical Deterministic]] (HD) wallets. Each new member receives a "welcome email" which contains the "xpubkey" (extended public key) for their deposits, and an *encrypted* copy of the corresponding xprivkey. The xpubkey can be used by the account owner to see all public keys associated with their account (both past and future). Combined with the "audit" feature, the user can fetch a list of all UTXO (unspent transaction outputs) associated with their account and verify the public key's subpath from the given xpubkey. Similarly, they can check the UTXO is correctly stored on the blockchain.<br />
<br />
<br />
Coinkite has stated that in the event of the closure or other failure of the business, they will publicize the symmetric key protecting the xprivkey values that have been distributed to members. With that key, each user could recover their funds by re-generating the private keys for each UTXO. <br />
<br />
<br />
The founders of Coinkite understood the inherent risk of trusting a third party with the private keys for your bitcoins, and this application of BIP 32 helps to address these concerns should the business disappear. The company calls this system "full reserve" since the users are in a position to verify that their funds are not being used for any other purpose than safe-keeping while on deposit at Coinkite.<br />
<br />
==Debit Card==<br />
<br />
For a small fee (and included in some membership plans), Coinkite users may receive a physical card. This eases use of their Coinkite account at the POS terminal and the QR code on the rear is useful for making deposits.<br />
<br />
==POS Terminal==<br />
<br />
Coinkite sells a hardware device which can perform a number of transactions. It connects via GPRS (cell) or Wifi to Coinkite backend servers which perform the blockchain operations. It does not directly connect to the P2P network.<br />
<br />
Users can log into their Coinkite account at the machine, using either their Coinkite card (and a 4-6 digit PIN, plus optionally a 2FA token) or use a one-time QR code from the Coinkite website. Once connected to their account, they can perform many types of transactions:<br />
<br />
* print out their current balances<br />
<br />
* scan a QR and pay it using their balance<br />
<br />
* withdraw funds to cash (requires the retail to become the counter-party)<br />
<br />
* deposit cash (buying coins from the retailer)<br />
<br />
* make a printed invoice (ie. a unique bitcoin address for payment of a specific amount)<br />
<br />
* verify a payment has been received (by scanning any receipt printed by a Coinkite terminal)<br />
<br />
The POS terminal is also useful to enable the bitcoin-based retail business. Cashiers (authorized users) can print a receipt with QR code that maybe presented to customers as a bill in bitcoin to be paid. Once paid, using any bitcoin wallet of choice, the payment can be easily verified at the terminal by scanning it's QR code. The number of confirmations for the incoming funds is displayed and appropriate warnings are shown for zero confirmation transactions. It is up to the retailer to define their policy on number of required confirmations and presumably the size of the transaction will be a deciding factor.<br />
<br />
Other "non account holder" transactions that are possible:<br />
<br />
* print current exchange rates (Bitcoin vs. fiat) to a receipt<br />
<br />
* deposit cash into bitcoin (ie. retailer is selling bitcoins)<br />
<br />
* coins are delivered to a URL or private key.<br />
<br />
* scan bitcoin QR to pay (retailer is selling bitcoins, paid directly to settle bitcoin debt)<br />
<br />
* scan to verify transaction (prints amount received, and confirmation status for Coinkite transactions)<br />
<br />
The POS terminal supports Bitcoin for all operations. Coins can be delivered as a paper wallet, directly into a Coinkite account (must be pre-existing) or into web voucher (PIN code and short URL).<br />
<br />
==External Links==<br />
<br />
* [https://www.coinkite.com Coinkite Home page]<br />
<br />
* [https://www.coinkite.com/faq FAQ page]<br />
<br />
* [https://coinkite.com/promo/wiki Sign-up]<br />
<br />
* [http://expresscoin.com/wallets/bitcoin/coinkite How to Setup a Coinkite Bitcoin Wallet]<br />
<br />
==References==<br />
<references /><br />
<br />
==Images==<br />
[[File:Coinkite_interfaces.png|300 px|alt=Coinkite interfaces|Coinkite interfaces]]<br />
[[File:Bitcoin-pos-terminal.png|300 px|alt=Bitcoin POs Terminal|Coinkite terminal]]<br />
[[File:Coinkite_logo.png|300 px|alt=Coinkite logo|Coinkite logo]]<br />
[[File:Http://i.imgur.com/AnrNck0.png|300 px|Coinkite's Bitcoin Payment Button]]<br />
<br />
[[Category:Debit Cards]]<br />
[[Category:Wallets]]<br />
[[Category:EWallets]]<br />
[[Category:HybridEWallets]]<br />
[[Category:Mixing_Services]]<br />
[[Category:Exchanges]]<br />
[[Category:Shopping Cart Interfaces]]<br />
[[Category:Services]]<br />
[[Category:Frontends]]<br />
[[Category:Clients]]<br />
[[Category:Mobile]]<br />
[[Category:Hardware Terminals]]<br />
[[Category:Cryptobanks]]<br />
[[Category:POS]]<br />
[[Category:Bitcoin payment systems]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Wasabi_Wallet&diff=66236Wasabi Wallet2019-03-03T19:41:48Z<p>Transisto: Created page with "Wasabi Wallet is a wallet that implements CoinJoin. It is open source and written in C#. The package includes Tor and all traffic goes through it, so IP addresses are well hid..."</p>
<hr />
<div>Wasabi Wallet is a wallet that implements CoinJoin. It is open source and written in C#. The package includes Tor and all traffic goes through it, so IP addresses are well hidden. It is very easy to install and use. The wallet includes all standard privacy tech like a Deterministic wallet and warnings against address reuse, as well as a nice interface for choosing which UTXOs to spend which can help with coin control. The wallet uses Client-side block filtering to obtain its own transaction history in a private way.<br />
<br />
CoinJoins happen between users without any liquidity provider middlemen. The coinjoins happen at fixed times when a coinjoin round happens, which is approximately once every hour and a half. These figures are correct as of 2018.<br />
<br />
User's wallets connect to a centralized server which coordinates the CoinJoin. The wallet uses chaumian blind signatures (which is very similar to the cryptography used in blinded bearer certificates) so that this server or anyone else does not learn the true linkage between transaction inputs and outputs. The server is run by the zkSnacks company which has developed Wasabi Wallet, the company makes its income by taking a small fee (of 0.03% per participant as of 2018) from each coinjoin transaction.</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Bech32_adoption&diff=65998Bech32 adoption2018-12-30T01:33:07Z<p>Transisto: </p>
<hr />
<div>[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. This page tracks the adoption of [[Bech32]].<br />
<br />
Ideally wallets and services would first support ''sending to'' bech32 addresses. After almost everything can send to, then people may be willing to adopt bech32 widely for receiving.<br />
<br />
The amount of bech32 addresses on the blockchain is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| Bitcoin Core || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Bitcoin Knots || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Electrum || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Armory || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| JoinMarket || {{Yes}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{Yes}} || {{Planned}} ||<br />
|-<br />
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864<br />
|-<br />
| Samourai Wallet || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]<br />
|-<br />
| BTC.com || {{Yes}} || {{No}} ||<br />
|-<br />
| Casa || {{Yes}} || {{No}} ||<br />
|-<br />
| Mycelium || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Bitcoin Wallet for Android || {{No}} || {{No}} ||<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Yes}} ||<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||<br />
|-<br />
| Ledger chrome app || {{No}} || {{No}} ||<br />
|-<br />
| Ledger Live (desktop app) || {{No}} || {{No}} ||<br />
|-<br />
| KeepKey chrome app || {{No}} || {{No}} ||<br />
|-<br />
| BitBox Desktop app || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Trezor + Electrum || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Ledger + Electrum || {{Yes}} || {{Yes}} ||<br />
|-<br />
| BitBox + Electrum || {{Yes}} || {{Yes}} ||<br />
|-<br />
| KeepKey + Electrum || {{Yes}} || {{Acceptable|PR Merged}} ||<br />
|-<br />
| Archos + Electrum || {{Yes}} || {{Yes}} ||<br />
|-<br />
| Coldcard + Electrum || {{Yes}} || {{Yes}} ||<br />
|}<br />
<br />
=== Web Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| Coinapult || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Coin.Space || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| BitGo || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| blockchain.info web wallet || {{Yes}} || {{No}} || https://twitter.com/provoost/status/1037802325874761728<br />
|-<br />
| HolyTransaction || {{Yes}} || {{No}} ||<br />
|-<br />
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12<br />
|-<br />
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated<br />
|-<br />
| BitBargain.co.uk || {{Yes}} || {{No}} ||<br />
|-<br />
| Bitcoin.de || {{Yes}} || {{No}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/<br />
|-<br />
| Bitfinex || {{No}} || {{No}} ||<br />
|-<br />
| BitMEX || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128<br />
|-<br />
| Bitstamp || {{No}} || {{No}} ||<br />
|-<br />
| Bitwage || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Bisq || {{No}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139 https://bisq.community/t/bech32-address-support/6521<br />
|-<br />
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992<br />
|-<br />
| CoinFalcon || {{Yes}} || {{No}} ||<br />
|-<br />
| Coinfloor || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Flyp.me || {{Yes}} || {{No}} ||<br />
|-<br />
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/<br />
|-<br />
| Gemini || {{No}} || {{No}} ||<br />
|-<br />
| Genesis || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| HitBTC || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{Yes}} || {{No}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56<br />
|-<br />
| Itbit || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Kraken || {{Yes}} || {{No}} || https://twitter.com/krakenfx/status/1060306827848470528<br />
|-<br />
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com<br />
|-<br />
| Localbitcoins.com || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{Evaluating|??}} || {{No}} ||<br />
|-<br />
| Poloniex.com || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/a3jhcf/you_can_now_withdraw_from_poloniex_to_bech32/<br />
|-<br />
| Walltime || {{Yes}} || {{Yes}} || https://walltime.info<br />
|}<br />
<br />
=== Bitcoin ATM Models ===<br />
<br />
Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| GenesisCoin || {{No}} || {{No}} ||<br />
|-<br />
| General Bytes || {{No}} || {{No}} ||<br />
|-<br />
| Lamassu Douro || {{No}} || {{No}} ||<br />
|}<br />
<br />
=== Blockchain Explorers ===<br />
<br />
For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.<br />
<br />
Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.<br />
<br />
See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Display !! Index !! Notes<br />
|-<br />
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/<br />
|-<br />
| Bitupper Explorer || {{Yes}} || {{Yes}} || https://bitupper.com/en/explorer/bitcoin<br />
|-<br />
| blockchain.info || {{Yes}} || {{No}} ||<br />
|-<br />
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/<br />
|-<br />
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc<br />
|-<br />
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co<br />
|-<br />
| blockstream.info || {{Yes}} || {{Yes}} || https://blockstream.info/<br />
|-<br />
| chaindex || {{Yes}} || {{Yes}} || https://chaindex.com/blockchain/<br />
|-<br />
| Insight || {{No}} || {{No}} || Open source explorer, instances are https://insight.bitpay.com/ and https://chain.localbitcoins.com/<br />
|-<br />
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/<br />
|-<br />
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin<br />
|}<br />
<br />
=== Payment Processors ===<br />
<br />
<!-- Payment processors in alphabetical order please --><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Invoice addresses !! Withdrawal addresses !! Notes<br />
|-<br />
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} ||<br />
|}<br />
<br />
=== Other Services ===<br />
<br />
Casinos, marketplaces, etc that let users withdraw money<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Withdrawals !! Notes<br />
|-<br />
| 1Broker || {{Yes}} || <br />
|-<br />
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]<br />
|-<br />
| YOLOdice || {{Yes}} || A popular dice site https://yolodice.com<br />
|}<br />
<br />
=== References ===<br />
<br />
[[Category:Software]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Target&diff=17573Target2011-10-01T05:26:58Z<p>Transisto: </p>
<hr />
<div>The '''target''' is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 [[hash]] of a [[block]]'s header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more [[difficulty|difficult]] it is to generate a block.<br />
<br />
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again. <br />
<br />
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks -- which should take two weeks if this goal is kept perfectly --, every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.<br />
<br />
=== What is the target now? === <br />
* [http://blockexplorer.com/q/hextarget Current target]<br />
* [http://blockexplorer.com/q/getdifficulty Current difficulty], as output by Bitcoin's getDifficulty<br />
* [http://blockexplorer.com/q/probability Current probability of winning a block per attempt]<br />
<br />
=== When does the target change next? ===<br />
<br />
* [http://blockexplorer.com/q/nextretarget Next retarget]<br />
<br />
=== What has the target been in the past? ===<br />
<br />
* [http://blockexplorer.com/q/nethash Difficulty history, (at column 5)]<br />
* [http://www.bitcointalk.org/index.php?topic=2345.msg31405#msg31405 Re: difficulty over time data?]<br />
* [http://bitcoin.sipa.be/ Bitcoin network graphs] <br />
<br />
=== What is the maximum target? ===<br />
0x00000000ffff0000000000000000000000000000000000000000000000000000<br />
<br />
Since a lower target makes Bitcoin generation more difficult, the maximum target is the ''lowest'' possible [[difficulty]].<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Transistohttps://tests.bitcoin.it/w/index.php?title=Wallet&diff=16473Wallet2011-09-12T02:38:50Z<p>Transisto: </p>
<hr />
<div>A Bitcoin '''wallet''' contains<ref>[https://bitcointalk.org/index.php?topic=4448.0 Wallet import/export: bitkeys format]</ref>:<br />
<br />
* keypairs for each of your [[address|addresses]]<br />
* transactions done from/to your addresses<br />
* user preferences <br />
* default key<br />
* reserve keys<br />
* [[Accounts_explained|accounts]]<br />
* a version number<br />
* [[Key pool]]<br />
* Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.<br />
<br />
The data file for the wallet is wallet.dat and is located in the Bitcoin [[data directory]].<br />
<br />
It is intended that a wallet be used on only one installation of Bitcoin at a time. Attempting to clone a wallet for use on multiple computers will result in "weird behavior"<ref>[http://forum.bitcoin.org/index.php?topic=5324.msg77896#msg77896 Multiple instance of bitcoin with the same wallet]</ref>.<br />
<br />
==See Also==<br />
<br />
* [[Securing your wallet]]<br />
* [[EWallet]]<br />
<br />
==References==<br />
<references /></div>Transistohttps://tests.bitcoin.it/w/index.php?title=Target&diff=7236Target2011-04-13T16:01:06Z<p>Transisto: /* What has the target been in the past? */</p>
<hr />
<div>The '''target''' is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 [[hash]] of a [[block]]'s header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more [[difficulty|difficult]] it is to generate a block.<br />
<br />
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again. <br />
<br />
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks -- which should take two weeks if this goal is kept perfectly --, every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.<br />
<br />
=== What is the target now? === <br />
* [http://blockexplorer.com/q/hextarget Current target]<br />
* [http://blockexplorer.com/q/getdifficulty Current difficulty], as output by Bitcoin's getDifficulty<br />
* [http://blockexplorer.com/q/probability Current probability of winning a block per attempt]<br />
<br />
=== When does the target change next? ===<br />
<br />
* [http://blockexplorer.com/q/nextretarget Next retarget]<br />
<br />
=== What has the target been in the past? ===<br />
<br />
* [http://blockexplorer.com/q/nethash Difficulty history, (at row 5)]<br />
* [http://www.bitcoin.org/smf/index.php?topic=2345.msg31405#msg31405 Re: difficulty over time data?]<br />
<br />
=== What is the maximum target? ===<br />
0x00000000ffff0000000000000000000000000000000000000000000000000000<br />
<br />
Since a lower target makes Bitcoin generation more difficult, the maximum target is the ''lowest'' possible [[difficulty]].<br />
<br />
{{fromold|target}}<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Transisto