Accounting and technical challenges of Bitcoin payments
 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.20 EUR-0.279 $ -0.174 £ -0.244 CHF |
| Mandatory registration: | Yes
|
| 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: | View |
| Announce globally: | no |
demonstration of a payment in the bitcoin network (5 min). accounting challenges (5 min).
security risks (15 min).
the proposed date is just a placeholder! the date, time and duration are variables and will probably change.
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)
project proposal: accepting bitcoin payments in level2 self service bar simple page dispensing bitcoin addresses (analogue to the cup on the shelf for accepting cash) open questions: who should know the keys? current space custom gives access to the coin cup to all. bitcoin is different, once the private keys leak anyone who knows them can use the disponible coins without being physically present in the hackerspace. this makes tracing the unauthorized spending by corellating time and visitors in space impossible. also in case of deterministic wallets the knowledge of the seed will allow also future bitcoin income to be at risk of theft. how to solve the exchange rate volatility problem?
