 Show Posts
|
|
Pages: [1] 2 »
|
|
So how does this differ to something like the SAFE Network, the project that MaidSafe are working on? It looks like you're trying to attempt to solve some of the same problems that those guys are but you're placing all your eggs in the blockchain tech basket? Is that right?
|
|
|
|
I personally don't think it's a good idea (and I'm pro bitcoin, very bullish about its future).
Say for example you get paid 3000 USD a month, what if the say before payday bitcoins value is 230 dollars then 5 minutes after your wages go in the value of bitcoin crashes 50 dollars because of some bearwhale dumping.
I'd advise people 'for now' that people get paid in their national currency & set aside a certain amount each month to buy bitcoin.
I can only advise though, go ahead on the path you choose.
I hear what you're saying and agree in many ways. But I guess what I'm suggesting is that if you're already putting aside a certain amount of money each month from your salary and then having to go out and buy bitcoin, why not just automatically buy and cut out a couple of intermediary steps. Like I say, not for everyone, but for those who buy regularly, I can see it being useful. It just removes a bit of that friction which could then encourage someone to then spend that bitcoin instead of holding onto it as you're removed in some way from the time/effort of going to an exchange etc - maybe that reduces the emotional attachment/hodling mentality in some cases as well. |
|
|
|
Thanks for this - unfortunately both of them are US-focused (in terms of employer integration) from what I can make out  But at the current situation with the price dropping and all, will the employers even agree to get paid in Bitcoin? Just a thought  I agree but from speaking to folk, there's a few who buy small amounts regularly for whom it might make sense just to automatically receive a small % of salary in bitcoin to avoid the hassle of buying it directly themselves each week (unless the cost was ridiculous). Be great if someone popped up with a plug-n-play solution for employers in the UK. |
|
|
|
|
I'm struggling to find a way of taking a solution to an employer that will let them automagically pay Bitcoin directly to an employee who requests it as part of salary.
Minimum fuss so that it's straight forward for an employer who just doesn't want any hassle - i.e. they'll do it, but only if it's really easy and doesn't cause them any extra work when they run the payroll for the rest of the staff.
Any suggestions? The only solutions I've found tend to be US/$-centric.
Cheers
|
|
|
|
|
Hi all - I've had some interest from a pension company that are pretty new to the world of crypto/Bitcoin/blockchain (in the sense that I'm expecting most people to not know anything about it but there's an opportunity to talk about the subject to a fairly large number of people. I can't disclose the country or company but does anyone out there have any great ideas/concepts to introduce them to?
I'm thinking around document verification and obviously smart contract payments further down the line. But are there any immediate applications that jump to mind for this type of business at this stage? How would you approach this kind of opportunity?
Thanks guys
|
|
|
|
|
Thanks all for your comments - a few useful links there. Looks like the process itself is pretty straightforward it's just the same old story about trying to convert BTC to GBP after the sale that presents a few problems (here in the UK at least).
Re the question about giving customers a receipt from the sale - I could be entirely wide of the mark here but I suspect that we're still at the stage in the cycle where if someone wants to pay using Bitcoin, they'll be sufficiently up to speed that they can check the blockchain themselves for proof! ;-)
|
|
|
|
Hi guys, I've had a request from a coffee shop this week to help them to accept Bitcoin in the UK. Good news. Does anyone have any tips? Please note this is the UK (not US, etc) - i.e. I'm pretty sure that you couldn't simply use Bitpay / Coinbase and get sterling into the merchant's bank account at the end of each day because of the current banking restrictions in this country. So there's two questions:- 1. If the merchant's in no rush for sterling: I'd just suggest getting a tablet and using Bitpay's Bitcoin Checkout app ( https://play.google.com/store/apps/details?id=com.bitpay.checkout). Seems like a really straightforward interface. Mind you, it's not clear to me how they could *easily* transfer these bitcoins (it's unlikely to be significant sums) into sterling at a future date - although this is likely to be less of an issue initially as these businesses have bought into the overall concept. 2. If the merchant does want sterling however: is there any way of setting this up automatically in the UK? There seem to be real issues around this. Thanks a lot for your help guys.  |
|
|
|
We have to wait a little bit to have them but it is coming and being implemented.
There are proposed extensions to the bitcoin protocol to address some of these questions. See this [OP_CHECKLOCKTIMEVERIFY][1] for example. It is available on viacoin. Eventually, the idea is that sidechains will be better suited for these scenarios leaving the blockchain with 'normal' transactions. [1]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawikiGreat, thanks guys. I've spent some time digging into OP_CHECKLOCKTIMEVERIFY now. It can sometimes be hard to separate the potential from the reality. Don't want to put people off by promising a bright new future with all this added functionality if the reality is that it won't be available until many years have passed  |
|
|
|
It's always entertaining watching newbies that don't know what they are talking about trying to explain what they incorrectly assume to other newbies. odolvlobo is correct. To a certain extent it depends on the wallet software you are using. There are a few important points to be aware of though: You can encounter complications if you spend bitcoins that have not yet confirmed. A transaction uses the hash of the transaction that created the output that you are spending to identify that output. It's possible for the hash of an unconfirmed transaction to change before it becomes confirmed (This is often called "transaction malleability"). If that happens, then the second transaction will no longer be valid, and you'll need to re-send it. In the example given, if your friend is right there with you, most wallet software will allow you to create a single transaction that has two outputs. The single transaction can send 0.5 BTC to the coffee shop and 0.5 BTC to your friend, and you'll have no change to worry about at all. I wonder if there could be an issue with the second transaction (to my friend) possibly being confirmed more quickly for some reason (better connectivity, coffee shop suffering bad connectivity etc) that then means that the second transaction (chronologically) would be picked up before the first - meaning that the coffee shop has to wait even longer to see their money.
The second transaction isn't valid in a block (can't be confirmed) until the first transaction is in a block. Therefore, it isn't possible for the second transaction to be confirmed before the first. They can both be confirmed in the same block (at the same time), or the first transaction can be confirmed and your friend can end up waiting for a later block for his transaction to confirm. Am sorry , am still learning but i tried my best to answer him Thank you for clarifying it a bit more for me too Brilliant, thanks for that very clear explanation. I think I *may* now have understood transaction malleability for the first time as well which is a bonus! I haven't carried out many transactions - and definitely never tried simultaneous transactions - so I had no idea that that sort of functionality was availability in some wallets. Thanks everyone for your input on this. It's can be hard to find definitive answers some times so everyone's help is really appreciated. If people get it wrong, all well and good - then more of us get to learn the right answers |
|
|
|
Question: can I spend that 0.5 bitcoin that's mine (but returned to me via a new change address) before the next block is confirmed (i.e. within 10 minutes)? Or do I have to wait until my coffee purchase is confirmed before I can pay my friend?
Thanks!
As far as I know, yes you can spend it although it's not yet confirmed. But the new transaction (to your friend) won't be confirmed until the previous transaction (coffee) get confirmed. Interesting, thanks. I wonder if there could be an issue with the second transaction (to my friend) possibly being confirmed more quickly for some reason (better connectivity, coffee shop suffering bad connectivity etc) that then means that the second transaction (chronologically) would be picked up before the first - meaning that the coffee shop has to wait even longer to see their money. |
|
|
|
Could someone clear up a question for me please?
I have 1 Bitcoin. I go into a coffee shop with a friend. I buy a coffee for 0.5 bitcoin (yeah, it's expensive) and then whilst waiting for the coffee to be ready, use my mobile wallet to pay my friend the 0.5 bitcoin that I owe him.
Ignore transaction fees for a minute. As I understand it, that 1 Bitcoin (assuming it's a complete bitcoin, not made up of many smaller units) is used in the the first transaction for the coffee - so 0.5 bitcoin is sent to the coffee shop address whilst 0.5 bitcoin will be returned to my (new) change address.
Question: can I spend that 0.5 bitcoin that's mine (but returned to me via a new change address) before the next block is confirmed (i.e. within 10 minutes)? Or do I have to wait until my coffee purchase is confirmed before I can pay my friend?
Thanks!
First of all You say , use my mobile wallet to pay my friend the 0.5 bitcoin that I owe him.then whilst 0.5 bitcoin will be returned to my (new) change address.
When you paid to your friend why would it return to your new address And if you mean return to your friend's address then yes you can use the bitcoin again without waiting for confirmation(as i know cos i do it all the time) The money that gets returned to me is the change from the coffee shop purchase (i.e. I have to send a full 1BTC so I get 0.5 BTC change back from the coffee shop). Do I have to wait for that 0.5 BTC to be returned as change and confirmed before I use it? I think from what you're saying that yes, I could. So does that mean that the change money is returned immediately and it doesn't depend on waiting for the transaction to be included in the next block? I guess that's possible if my wallet software automatically creates a new change address that contains 0.5BTC regardless of whether my coffee shop 0.5 BTC transaction is confirmed - i.e. even if the transaction doesn't go through, I've still ended up splitting up that 1BTC in my wallet? |
|
|
|
|
Could someone clear up a question for me please?
I have 1 Bitcoin. I go into a coffee shop with a friend. I buy a coffee for 0.5 bitcoin (yeah, it's expensive) and then whilst waiting for the coffee to be ready, use my mobile wallet to pay my friend the 0.5 bitcoin that I owe him.
Ignore transaction fees for a minute. As I understand it, that 1 Bitcoin (assuming it's a complete bitcoin, not made up of many smaller units) is used in the the first transaction for the coffee - so 0.5 bitcoin is sent to the coffee shop address whilst 0.5 bitcoin will be returned to my (new) change address.
Question: can I spend that 0.5 bitcoin that's mine (but returned to me via a new change address) before the next block is confirmed (i.e. within 10 minutes)? Or do I have to wait until my coffee purchase is confirmed before I can pay my friend?
Thanks!
|
|
|
|
In terms of the time-lock, I was thinking of money within a transaction that's not released until a specific event occurs which is recorded (somewhere) online - i.e. not simply lets wait until block X for the transaction to be valid. I guess the specific block would work if it was a trust fund that only paid out when your descendants reached say 21 years old (as you can calculate the rough block at this stage) but that feels like a blunt solution in some ways.
I don't see why you would really need something like this. This still requires that the recipient keep a private key safely stored for 21 years. A sender could store a paper wallet with a law firm, to be given to the recipient in 21 years. More likely, the funds would be invested in a low-risk investment for 21 years, instead of being stored under a mattress. I'm trying to think about a situation where (1) the conditions to accessing the money are embedded at the time that the transaction takes place and (2) it doesn't require a 3rd party in the future to execute (i.e. trusting a law firm to not lose/give you access to your paper wallet). It might be that a multi-sig solution is more appropriate here - perhaps with another family member and some kind of escrow agent who steps in if there's an argument with the family member (or he/she loses the private key). I'm interested in thinking of use cases where we can replace standard legal contracts (e.g. a legacy under a will) with transactions that have built-in conditions when they are created so that they pay out automatically to the right people in the future. |
|
|
|
|
In terms of the geo-restricted transactions part, what I'm wondering is whether it's possible a currency that can only be used within one area such as maybe a town - for example, to replace/power a local currency such as the Brixton Pound [http://news.bbc.co.uk/1/hi/magazine/8245276.stm]. This helps to keep the wealth circulating within an area that might be deprived economically. It seems as if this could be more of a solution for a local token that is built on top of Counterparty/using Coloured Coins etc perhaps rather than using standard bitcoins I guess. It goes against the fundamentally global-by-default nature of Bitcoin but I can see a value to getting a project like this off the time.
In terms of the time-lock, I was thinking of money within a transaction that's not released until a specific event occurs which is recorded (somewhere) online - i.e. not simply lets wait until block X for the transaction to be valid. I guess the specific block would work if it was a trust fund that only paid out when your descendants reached say 21 years old (as you can calculate the rough block at this stage) but that feels like a blunt solution in some ways.
|
|
|
|
I hear people speaking about the potential of Bitcoin - for example, being able to carry out transactions that are in some way geo-restricted or time-locked so that the recipient will only receive his/her money when an oracle checks some form of online record (eg. showing someone has died or reached a certain age).
But it's not clear to me how long it might actually take for us to implement these things in the real world. As far as I can make out, these things are all possible in theory - but is it possible to implement them yet? Or are we going to have to wait for years until this sort of functionality is available?
I'm asking this question partly to assess whether or not it's worth developing a business on the assumption that this sort of functionality is, or will be imminently, available - or whether it's simply far too far off in the future to even consider at this point in time.
Time locked is pretty simple and you can already do it: https://en.bitcoin.it/wiki/NLockTimeAll this talking about oracles deciding stuff, I am not so sure about that, since it is really hard to find a reliable oracle Thanks for the link re time lock. My instinct is that whilst oracles (reading the register of births, deaths etc) might be more complicated, restricting transactions according to GPS co-ordinates should be much simpler given the existing technology around mobile/location. But maybe that's an unfair assumption? |
|
|
|
|
I hear people speaking about the potential of Bitcoin - for example, being able to carry out transactions that are in some way geo-restricted or time-locked so that the recipient will only receive his/her money when an oracle checks some form of online record (eg. showing someone has died or reached a certain age).
But it's not clear to me how long it might actually take for us to implement these things in the real world. As far as I can make out, these things are all possible in theory - but is it possible to implement them yet? Or are we going to have to wait for years until this sort of functionality is available?
I'm asking this question partly to assess whether or not it's worth developing a business on the assumption that this sort of functionality is, or will be imminently, available - or whether it's simply far too far off in the future to even consider at this point in time.
|
|
|
|
I like to explain it as a system of receipts.
Each receipt represents a transaction (naturally). And we stack the receipts one on top of another. We take those stacks (after 10 min of stacking) and place them in a box (a block). Over time, those boxes are stacked on top of each other to form the blockchain.
We can program "accountants" to go in and verify the transactions and do all sorts of cool stuff to look at the data.
You can get as detailed as you want by writing what exactly goes into a transaction on the receipts.
Maybe if we're exchanging lego, the person who puts their newly acquired lego into the shoebox receives a receipt at the same time which contains the number of lego pieces deposited plus a random reference. A copy of the same receipt is also given to everyone who is acting as a miner. If the student then wants to spend that lego/bitcoin in the future, they have to go round each of the 'miners', display the random reference on the receipt; the miner checks it out and, if so, lets them unseal the shoebox with the knife. Hmmm, this is getting a bit more complicated now....  |
|
|
|
you need something that you can build
you could use LEGO for building the chain, use blocks of different colors and have the miners build them and check every time if the chain/blocks are alike every time someone adds a transaction Definitely like the lego idea, thanks. It could be easier to start off that way. Each student could get a square block made up of varying numbers of lego pieces to represent 1 BTC - which is then clearly divisible, to an extent, into its constituent parts. There's a point that can be discussed around the fact that bitcoins then aren't perfectly fungible (i.e. when you move (or spend) them you're spending some specific bitcoins). Maybe the lego could then get put into the shoeboxes. |
|
|
|
At a Minneapolis bitcoin meet up, the organizers did a manual implementation of a ledger where people were given a few dollar bills (everyone's balance known by all), called out their transactions (Bob gives Sally $2), exchanged dollar bills, and everyone recorded the transaction. The organizers then took the dollar bills away and the exercise continued.
This doesn't address the proof of work concept very well, but it shows the value of the ledger.
Good idea, I guess in particular that brings across the fact if everyone holds the same records, it's impossible to unilaterally alter the ledger fraudulently. I'm keen to get the whole experience as 'touchy feely' as possible. Ideally, the simpler it is, the more potential there is to start rolling this method out into younger age groups as well which could yield an even more valuable longer term result when it comes to adoption. |
|
|
|
light some fiat on fire Then we risk getting into that whole 'proof of burn' debate....think I might leave that until lecture 2 |
|
|
|
|
