On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.
He can? Transaction A has LockTime, so even if transaction B sending the coins back is released, the sender can't use them. One thing this system lacks is strong untraceability. I didn't find a way that offers anonymity while not entrusting the bank with any money, so untraceable transactions still need to trust the bank a bit. But at least this scheme allows relatively low trust together with few on-chain transactions.
For untraceability you could use a different method (or combination) with a different set of tradeoffs, such as oblivious mixing transactions, Open Transactions, etc. |
|
|
|
OK, great, but is that supported by official bitcoin client?
I don't think so, but the only thing you can do about that is writing the code to support it. It is supported by Multibit and maybe some other clients though. |
|
|
|
|
Replies as in that thread are symptomatic of people who hear about Bitcoin mining before they hear about Bitcoin.
If you tell someone "hey, there's this thing called Bitcoin mining, it's some crazy system where it's valuable because it costs electricity, you can make money!" of course you'll get a strong negative reaction.
But if you say "Bitcoin is the world's first decentralized digital currency. It [Enter your favorite part of the long list of advantages Bitcoin has here]. Bitcoins are valuable because of their usefulness in commerce. Oh, and there's a thing called mining which makes the whole system work. Care to join in and be paid for your contribution?", you might not get any reaction at all, but if they make it through the first part, the reaction should be much more positive.
|
|
|
|
Is this ... to try and make people rich?
Bitcoin was created to allow people to more efficiently exchange goods and services they are capable of supplying for goods and services they value, thus increasing the effective wealth of everyone in the world (on average). So in a way, yes. I was told this by several people and not to trust anyone.
Trust me on this, don't trust anyone. Especially people telling you not to trust anyone. |
|
|
|
Hey, you know what would be kinda cool?
If instead of taking you to the front page of a post, when you clicked watch or unwatch, it took you to the watchlist.
Just a thought.
I disagree. What it should do is keep you in the current thread and page, and if not, the first page as it does now. |
|
|
|
Coupon payment summary for June 2012 (total 0.01934658 BTC per bond):
Do you mine solo, or do you use a pool ? Inaba is in charge of these decisions. I don't believe he's mining solo. Of course this has no effect on the coupons paid. |
|
|
|
This system has a flaw lol.
Merchant: fuck you, you are not getting your 8 BTC. Sign & Take 2 BTC or 0.
I'm not sure what you are talking about, but did you actually read how the system works? The receiver can't confiscate funds he wasn't specifically paid, he could die and the sender still receives the tied up funds at the end of the term. You might be confusing this with an escrow transaction, where this could be an issue. |
|
|
|
You are aware, but the OP isn't, it seems  Read the screenshot, or even the last line of the OP and you'll see for yourself, you don't have to trust me. You do know this thread is over a year old, right? "Ignore users" probably didn't exist back then. I am using it, But do you want me to simply stop using the "show new replies" feature then?
Really, What would be the point of it..
You can migrate all the "show new replies" posts over to your watchlist, and then enable auto-watch in your preferences, then it works the same way. +1, the watchlist does all that "new replies" does, and more. JackRabiit's complaint is no longer an issue. Only thing is I don't think there's an obvious link to the migration page, but there is in the thread about the watchlist. |
|
|
|
Coupon payment summary for June 2012 (total 0.01934658 BTC per bond): Block number Timestamp Timestamp (Unix) Elapsed time Difficulty Block reward Coupon Bonds Total Status
186815 Jun 29 2012 21:39:24 1341005964 203520 1726566.55919 50 0.0013722521 20000 27.4450420 Paid
186479 Jun 27 2012 13:07:24 1340802444 190252 1726566.55919 50 0.0012827914 20000 25.6558280 Paid
186143 Jun 25 2012 08:16:32 1340612192 192041 1726566.55919 50 0.0012948539 20000 25.8970780 Paid
185807 Jun 23 2012 02:55:51 1340420151 211481 1726566.55919 50 0.0014259299 15000 21.3889485 Paid
185471 Jun 20 2012 16:11:10 1340208670 182860 1583177.84744 50 0.0013446187 15000 20.1692805 Paid
185135 Jun 18 2012 13:23:30 1340025810 177791 1583177.84744 50 0.0013073450 15000 19.6101750 Paid
184799 Jun 16 2012 12:00:19 1339848019 184346 1583177.84744 50 0.0013555457 15000 20.3331855 Paid
184463 Jun 14 2012 08:47:53 1339663673 191909 1583177.84744 50 0.0014111585 15000 21.1673775 Paid
184127 Jun 12 2012 03:29:24 1339471764 189299 1583177.84744 50 0.0013919664 15000 20.8794960 Paid
183791 Jun 09 2012 22:54:25 1339282465 183801 1583177.84744 50 0.0013515381 15000 20.2730715 Paid
183455 Jun 07 2012 19:51:04 1339098664 197893 1591074.96185 50 0.0014479379 15000 21.7190685 Paid
183119 Jun 05 2012 12:52:51 1338900771 197285 1591074.96185 50 0.0014434893 10000 14.4348930 Paid
182783 Jun 03 2012 06:04:46 1338703486 183962 1591074.96185 50 0.0013460079 10000 13.4600790 Paid
182447 Jun 01 2012 02:58:44 1338519524 214732 1591074.96185 50 0.0015711450 10000 15.7114500 Paid
|
|
|
|
|
I would certainly be interested in reinstating this, but I'm just too busy at this particular point in time, and anyway I wanted to design the model more than I wanted to be publicly associated with these affairs. If someone else wants to offer his own bonds after this model I don't mind. If there's demand (which I'm not really sure) maybe I'll do this too.
One thing that could make the bond more attractive is, instead of taking a fee and keeping the raised funds as reserve for bids, keep only a partial on-call reserve, invest the rest in some safe program, and offer the bonds at exactly face value.
|
|
|
|
5. When I upgrade the client say from version 0.62beta to 0.63 is there a risk of corrupting or losing the wallet?
There shouldn't be a problem, but the risk is there. It's always a good idea to back up your wallet, both regularly and specifically before upgrading the client. I believe they're currently accepting US based businesses only. From their website:
...
Besides that, I will be processing initially very small volume of coins so I will have no need to have them converted instantly to fiat, so no need for a payment processor for me now.
You don't have to convert to USD with Bit-Pay, you can simply let them handle the BTC payments for you and have them worry about checking that the coins were sent. They also have all sorts of apps, buttons and forms. Their fee for BTC payments is about 1%, and I think it's not limited to any country. |
|
|
|
|
Ok, now I'm confused. You don't need a replacement for every new version of transaction 2; but you do need a replacement for the first version. Alice won't sign transaction 1 before she is sure she can get the money back in the end; this happens after Bob signs the first version of transaction 2. But after that Bob needs the power to replace this first version with the version that pays him; for that he needs replacement.
|
|
|
|
You should rely on Mike Hearn's proposal. As far as I know it's the one that already partially implemented.
To me it looks identical to hashcoin's, what am I missing? Looks identical to me, except that it's intended to pay for a wifi hotspot access, not just anything. Question, can Lock_Time be extended with newer revisions? If it can, then there is no reason that this process cannot extend much longer than the initial lock_time, allowing the user to extend the agreement from the original period (be it a day or a month) out for as long as the counterparty would allow. Somehow, though, I suspect that extending a lock_time is prohibited for some technical reason that I don't understand. The first transaction isn't replaced, it just has lock_time. The second transaction doesn't have lock_time; the first version starts at seq 0 and then all new versions of it are final. The versions of the 2nd transaction don't replace each other, rather they are kept private and only one of them (at the choice of the receiver, who will choose the one paying him the most) can be broadcast to replace the first version. |
|
|
|
You should rely on Mike Hearn's proposal. As far as I know it's the one that already partially implemented.
To me it looks identical to hashcoin's, what am I missing? |
|
|
|
This is all fine, but if a customer is willing to trust the processor with a small deposit, then he doesn't need any funds tied up into the channels. Once again, I think that this idea is sound, but is more likely to be used at the macro level.
Without a channel, he loses the ability to make instant payments which are larger than the deposit. Wait, what? Are you saying that the user would be able to make instant payments in excess of the funds he has tied up into the channel? No, I'm saying that the funds he has tied up in the channel can be much more than what he would have in a deposit, since he doesn't need to trust the processor with it. Funds in the deposit are also tied up and require a transaction to replenish, so they only make sense if:
1. The customer pays unpredictably, so he doesn't want to "waste" a channel which he ends up not using - he'd rather send a deposit and use it if and when he needs.
Which covers the use case of 99% of all Paypal members, which was my point. As I said Bitcoin is not a replacement for just PayPal. Actually the average person's expenses are fairly predictable - they're equal to his income minus the amount he's saving. Many of the specific payments are also known in advance, bills, groceries etc. |
|
|
|
I think it would work, but I can't see how the payment processor makes any money. As you said, his own funds are tied up in multiple connections; so all that money has to be rented somehow, and that doesn't even cover the costs of running the service itself.
The operational costs are very low. The time value of money will have to be paid by the customer, but it shouldn't be prohibitive. If the interest rate is 0.5% per month, that's more or less the cost of using this scheme (better than Bit-Pay's 1% or PayPal's 3%+), and you get instant payments which can be arbitrarily small. And if you make it shorter than 1 month it is proportionally less - with 6 days it's 0.1%. And, if a customer both sends and receives payment, and is willing to trust the processor with a small amount, he can cancel out most payments and thus not need a large channel, decreasing the cost per transaction. This is all fine, but if a customer is willing to trust the processor with a small deposit, then he doesn't need any funds tied up into the channels. Once again, I think that this idea is sound, but is more likely to be used at the macro level. Without a channel, he loses the ability to make instant payments which are larger than the deposit. Funds in the deposit are also tied up and require a transaction to replenish, so they only make sense if: 1. The customer pays unpredictably, so he doesn't want to "waste" a channel which he ends up not using - he'd rather send a deposit and use it if and when he needs. 2. The customer receives and sends payment frequently, and he wants the deposit to act as a buffer to cancel out adjacent sends and receives. In this scenario even a deposit much less than the volume can absorb most of it, decreasing the channel requirement. Either one of just a channel or just a deposit is fine for some use cases, but their combination is much more powerful and flexible. What are the friction points for this channel arrangement and how might that affect it's adoption at the micro level?
The friction is the need to broadcast 2 transactions per channel, and tying up the amount of the channel for its duration (the tradeoff is - longer channels need more funds to tie up, but require less transactions per time unit). This means that this system has a cost, which depends on the time value of money and the use pattern. |
|
|
|
The resource requirements will be lower if we keep most transactions off the chain.
This is a circular argument, the reason people started using bitcoin bank in the first place was because of the resource requirements. Not circular argument, positive feedback loop. People using Bitcoin banks will make the blockchain lighter, which in turn will make it easier to make competitive and efficient banks. An analogy to explain the distinction: Why, quantitatively, does Bitcoin have (edit: fundamental) value? Because you can buy stuff with it. Why can you buy stuff with it? Because it has value. Is this a circular argument? No, it's a positive feedback loop with two equilibria - one where the value is 0, and one where the value is proportional to the commerce Bitcoin enables. Luckily, we have managed to bootstrap ourselves away from the 0 equilibrium. |
|
|
|
Can you explain in a bit more detail what exactly a channel is ?
(as that is where the magic seems to happen)
The explanation is at the linked thread. I'm building up on hashcoin's work, not redoing it. I added another link in the OP. |
|
|
|
Exchanges have a problem because they deal with traditional money which isn't a cryptocurrency.
So are you saying bitcoin will never be view by the authorities as real money? because I think its probably just a matter of transaction volume. No, I said it's not a cryptocurrency and thus you technically can't do with it what you can do with a cryptocurrency. What makes Bitcoin decentralized is that there are many nodes and miners, with a low barrier of entry to becoming one. The situation is almost as good if there are multiple payment processors which have a low barrier of entry and trust requirement.
The growing resource requirements are a barrier to entry, as are the regulations that will be imposed on payment processors. The resource requirements will be lower if we keep most transactions off the chain. And payment processors of the kind I'm considering can't really be regulated any more than miners and network nodes, if they choose not to be. |
|
|
|
|
Show Posts
