Accounting and technical challenges of Bitcoin payments
m |
|||
| Line 24: | Line 24: | ||
|keywords= | |keywords= | ||
}} | }} | ||
| + | disclaimers: the workshop does not endorse the use of digital crypto currencies. as "digital currency" in context of this workshop it is always meant Bitcoin, not to be confused with real money as issued by banks (p.ex. dollars, Euro) nor private, regional or community money like LETS, WIR, Chiemgauer, etc. | ||
| + | |||
| + | disclaimers: the workshop does not endorse the use of digital crypto currencies. as "digital currency" in context of this workshop it is always meant Bitcoin, not to be confused with real money as issued by banks (p.ex. dollars, Euro) nor private, regional or community money like LETS, WIR, Chiemgauer, etc. | ||
| + | |||
| + | objective: bitcoin crash course, frequently given warnings | ||
| + | |||
| + | history: all previous attempts to create digital money failed (pre 2009, are not longer operational, see e-gold, hashcash) | ||
| + | present: since 2009 there is bitcoin (2011 first fork/alt.coin and since then there are hundreds of other digital crypto currencies) | ||
| + | |||
| + | demo: show a bitcoin address, show that it currently has no input; transfer bitcoins to that address, show that it now has valid input that could be spend from that address. show private key of that address | ||
| + | |||
| + | accounting: how? why? at which exchange rate? what date? how to account for spending or capital gains and losses? you can not refuse bitcoin payments. | ||
| + | focusing on accounting technicalities and not business decissions (who should bear the risk of exchange rate change after a payment? should incomming payments be automatically converted into euros at the time of payment? who should have knowledge of the private keys? implementation?) | ||
| + | |||
| + | security: keep the keys secret (who knows the keys can spend the coins), keep the keys safe (if lost, you can't spend the coins), make sure you pay to the right address (payments are not reversible, if paid to wrong address the coins are spent/gone). most common incidents involve unauthorized spending (theft), data loss (hw failure, disk formats & reinstalls), payment to wrong addresses or duplicate payments, software errors (bugs causing payments to invalid addresses). | ||
| + | possible solutions: deterministic wallets (from one seed can restore all addresses), payments to scripts (m of n scritps for payments), hardware wallets (store private keys away from general purpose computers and perform signing inside themselves, never revealing keys to computers that could be compromised) | ||
Revision as of 20:15, 28 February 2015
 Accounting and technical challenges of Bitcoin payments
accounting and security challenges of Bitcoin payments
| |
|---|---|
| |
| Type of Event: | Workshop |
| From: | 2015/06/30 19:15 |
| Till: | 2015/06/30 19:45 |
| Recurring: | no |
| Organizer: | syn2cat |
| Cost: | 0 EUR0 $ 0 £ 0 CHF |
| Mandatory registration: |
|
| Attendees: | Log-in to RSVP |
| Contact Person(s): | Martin (mail) |
| Keywords: | |
| Location | |
| Where: | Level2 (87, route de Thionville, Luxembourg, Luxembourg) |
| Map: |
Loading map...
|
| Tools | |
| QrCode: | 
|
| Add to your calendar: | Download … further results |
| Alternate picture: | None |
| Announce globally: | no |
demonstration of a payment in the bitcoin network (5 min). accounting challenges (5 min).
security risks (15 min).
disclaimers: the workshop does not endorse the use of digital crypto currencies. as "digital currency" in context of this workshop it is always meant Bitcoin, not to be confused with real money as issued by banks (p.ex. dollars, Euro) nor private, regional or community money like LETS, WIR, Chiemgauer, etc.
disclaimers: the workshop does not endorse the use of digital crypto currencies. as "digital currency" in context of this workshop it is always meant Bitcoin, not to be confused with real money as issued by banks (p.ex. dollars, Euro) nor private, regional or community money like LETS, WIR, Chiemgauer, etc.
objective: bitcoin crash course, frequently given warnings
history: all previous attempts to create digital money failed (pre 2009, are not longer operational, see e-gold, hashcash) present: since 2009 there is bitcoin (2011 first fork/alt.coin and since then there are hundreds of other digital crypto currencies)
demo: show a bitcoin address, show that it currently has no input; transfer bitcoins to that address, show that it now has valid input that could be spend from that address. show private key of that address
accounting: how? why? at which exchange rate? what date? how to account for spending or capital gains and losses? you can not refuse bitcoin payments. focusing on accounting technicalities and not business decissions (who should bear the risk of exchange rate change after a payment? should incomming payments be automatically converted into euros at the time of payment? who should have knowledge of the private keys? implementation?)
security: keep the keys secret (who knows the keys can spend the coins), keep the keys safe (if lost, you can't spend the coins), make sure you pay to the right address (payments are not reversible, if paid to wrong address the coins are spent/gone). most common incidents involve unauthorized spending (theft), data loss (hw failure, disk formats & reinstalls), payment to wrong addresses or duplicate payments, software errors (bugs causing payments to invalid addresses). possible solutions: deterministic wallets (from one seed can restore all addresses), payments to scripts (m of n scritps for payments), hardware wallets (store private keys away from general purpose computers and perform signing inside themselves, never revealing keys to computers that could be compromised)
