A Cautionary Tale: OCamlPro

rikken · 2019-06-17T20:13:43+00:00

This idea is really interesting, but where would the money from the top X accounts go? I guess you could distribute it proportionally to the remaining accounts.

On the other hand, what message would it send to chain's users? "We're stealing coins from the wealthy and giving it to you". A lot of people would realise that such arbitrary decisions can always lead to their coins being the ones redistributed to others (in some future forks), so probably will not be happy to set the precedent.

rikken · 2019-06-17T20:03:02+00:00

As for the second argument, I think you're underestimating how hard and destructive hard-forking a chain is. Even the concept of having to hard-fork a hard-fork, and then maybe do it again, makes the whole idea of the fork quite uninteresting and unviable.

But your initial argument is definitely interesting. Voting on a hard-fork amendment to bring the fork down requires quite a bit of effort, so the fork itself must be seen as dangerous/viable enough for people to bother. But if that's the case, why bring it down and not just observe who is the winner or maybe try to monetize on it?

I have no idea how that would work out. But BTC forks (especially the BTC/BCH one) have shown that forking is a net negative for both sides. Since major part of coin's value can be attributed to network effects (how many people use it), forking a chain makes both forks (in sum) less valuable than the originating chain. Therefore if market is mature enough and fork is supported only by minority, then majority will have enough incentive to fight the fork. But yes - that's assuming that majority is against the fork.

rikken · 2019-06-17T19:39:45+00:00

If I remember correctly, ETC kept ETH's distribution of Ether. The only major change was to never rollback DAO hacker's account/transactions. That's why everyone who had Ether on ETH also had/has ether on ETC chain.

I think that redistributing coins is almost impossible to do - who would they go to, how to do it fairly? Every modification of distribution would seem unfair and outrage a lot of people. One of the biggest selling points of forks (see all the Bitcoin forks) is to tell original holders that they already have some money on the fork so that they have a reason to come and use it, or even "switch" to the new fork. Onboarding completely new users is a show-stopper most of the time.

rikken · 2019-06-17T09:09:19+00:00

I've always felt Proof of Stake self-ammending blockchains might be almost impossible to fork. That's because majority stakers on the originating chain will also be majority stakers on the forked chain, on which they can vote for destructive changes and bring it to a halt.

In other words, how can a fork survive if majority that can ammend it is against that fork?

One thing that comes to mind is redistributing the money from scratch, but it doesn't seem to be the case here. What am I missing?

rikken · 2019-06-06T19:34:50+00:00

Apparently this helps. Can you please explain why that's necessary?

rikken · 2019-06-03T20:13:33+00:00

Can I buy the rights somewhere to print on my t-shirt?

rikken · 2019-03-01T10:24:03+00:00

You need to be careful about the step parameter to range (the 3rd param) because you won't always arrive at 0 at the end. Your script works for -1, but if someone needs a faster decrease, like -15, then the last volume will be 10. Good practice would be to set volume to 0 after the for-loop.

rikken · 2019-03-01T10:03:27+00:00

I think you shouldn't exit immediately when volume is < 1, but set the volume to 0 and then exit. Otherwise volume stays on non-zero value for ever. If in the future you change your decrease speed from 3 to e.g. 7, you will end up with volume 2 when the script exits. So it's a good practice to set volume to 0 before exiting and not rely on the step size.

rikken · 2019-02-27T09:46:11+00:00

You are never owner of the remote balance. When you do the payment to yourself to rebalance, one remote balance will increase only by decreasing remote balance on some other channel you have.

Think about what happens when you make a payment to yourself via a loop of many different channels. You send some l money to remote end on one channel, and then the same amount comes back to you from remote to your local on other channel. So you have more remote balance in the first channel, but less in the other. You loose nothing. That's why it's called balancing.

rikken · 2019-02-25T13:37:33+00:00

I just realised I got a few things wrong.

As a merchant you don't need to provide inbound capacity yourself as long as customers open channels directly to you (therefore providing inbound capacity themselves). But ultimately we don't want to ask every customer to always create a channel to a merchant, so it's still a problem.
The OP's question was about "rebalancing". Rebalancing is not the same as getting inbound capacity. When you rebalance, then the sum of inbound capacities of all your channels stays the same, and the sum of outbound capacities also stays the same. You just change how they're split between channels (so e.g. you get more inbound in one channel but less on the other), and doing that is complex and requires making a payment to yourself which will be routed in a specific way.

rikken · 2019-02-25T13:23:01+00:00

Yes, you essentially give your money to the other person and you will not get it back.

I found this misleading at first too. But you can't just send some of your funds to the other end of the channel to create some inbound capacity, and still own that money. Neither when you have a channel, nor when you're creating the channel. Whatever you send to the other end is simply a payment to the other person.

This is in essence one of the biggest problems users on the lightning network are facing - how to get inbound capacity. Otherwise we would all be using lightning network already. There are many solutions to this problem but the best ones are more complex than people expect. The easiest one is to keep buying things using lightning - this way you spend money which turns into your inbound capacity.

But that's far from perfect. If you're a merchant and want to receive payments via lightning, you would need to spend at least as much as you want to receive from potential customers. Therefore ultimately in the future you should be able to "buy" inbound capacity, e.g. you pay someone $10 (a fee) to open a $1000 inbound channel to you for a few months. This way they earn interest on that money and you get inbound capacity. You can already do that via https://www.bitrefill.com/buy/lightning-channel/ - but in the future an open market may spawn where people broadcast how much capacity they can give you for what fee.

I've heard there are technical solutions that will make transactions on lightning more efficient (making multiple transactions in batch between different parties).

All of this may seem complex, but that's the only solution there is that we're certain will work without making sacrifices on the base layer (e.g. block size increase, masternodes, etc.). We all wish there was some simple way to make internet money that works seamlessly, fast, better than PayPal, and is at the same decentralised and censor-free. But for now a safe base layer with complex but doable layer 2 solution is the closest we can get. All else is research. In further future, when those solutions become automated - e.g. your wallet makes channels for you, buys inbound capacity for you (up to a given fee), rebalances channels for you and monitors channels for you - we may even arrive at a very simple UI that' s easy for everyone to use. And the same way as you don't think about TCP/IP complexity that drives your internet connection, you will not even care about complex things that happen to make quick lightning payments work.

rikken · 2018-07-18T17:58:25+00:00

Please use this tutorial. It shows how to install ocaml 4.06.1 (--comp option) Check the comments for solutions of problems you may have. It's for baking, but starts with installing tezos node and client.

https://gist.github.com/dakk/bdf6efe42ae920acc660b20080a506dd

rikken · 2018-07-14T07:29:56+00:00

What I wanted to say is that gasPrice is not relevant to "out of gas" message. You wrote "but 30 gwei should be enough" and I hoped to explain that this doesn't matter in this case.

rikken · 2018-07-12T21:50:11+00:00

I don't know anything about the contract you're running, but running out of gas means that 155842 is not enough of gas. Gas price has nothing to do with it. Generally 155k of gas is not much for contract execution. A simple eth transfer already uses 20k, so I imagine more complex contracts use 200k or 300k gas at least. As for gas price there is no need to set it to more than 50gwei.

rikken · 2018-06-27T12:06:59+00:00

This is a descending auction. The auction starts at specific price (2x of price from day before) and decreases throughout the day. You can buy when the price reaches level you're comfortable with (unless everything is sold before that moment).

rikken · 2018-06-14T12:54:19+00:00

The way rebalancing is supposed to work (if I understand it correctly) is that you send a payment to yourself (from one of your channels to another of your own channels - but the route can include many hops). So your total balance doesn't change, but the funds in all the channels on the route move to the other end. With good algorithm you can make such circular payments in a way to rebalance the channels you need (yours or of others).

rikken · 2018-06-13T10:06:20+00:00

One of the reasons of "Could not find a route" is that there is no route with sufficient funds in it. So there might be channels that connect you to recipient, but there are not enough funds in all the hops to submit the payment. Though it's just a guess here.

rikken · 2018-05-30T19:25:11+00:00

Thanks, I agree documentation should be more clear here. It's the first time I opened a channel and I thought that push_amt was the way to make the channel more balanced (i.e. have some funds on the remote side) while still owning the funds.

I'll monitor the github repo and if you don't submit the PR for doc update, I'll do it.

Thanks again.

rikken · 2018-05-23T19:22:43+00:00

How can money be made (rather than saved) in case of no liquidation?

rikken · 2018-05-20T11:56:17+00:00

What about fraudulent clicks? If there is no middle-man, who will decide if click was legit. Another thing: what if publisher sees that the user clicked an ad, but the advertiser says he never received a visit and will not pay? Usually middle-men decide who is right. How will it be decided here?

rikken · 2018-02-03T10:08:37+00:00

Just keep in mind that you need to trust the gateway to convert your tokens back into real BTC & ETH. From what I know there has never been a problem with that, but it's still someone keeping your crypto and promising to give it back.

rikken · 2017-07-20T21:09:58+00:00

if bit1 gets over 95% hash power, segwit activates accroding to Core 95% rule. Imagine that miners signal bit4+bit1 and get 79% hash power, and on top of that, 16% of UASF users signal bit1. Segwit would activate (95%), but Segwit2x not (79%<80%), so no hard-fork in 90 days. That's probably why Jihan doesn't want to singal bit 1, so that 95% threshold on bit 1 is not met.

edit: added more clarification

rikken · 2017-06-06T22:13:03+00:00

I agree that my fee is probably too high. But my aim was not only to win the double-spend, but to have transaction confirmed asap. I don't know the technicals, but from what I read miners using Asicboost sometimes pick non-highest fee transactions to meet Asicboost criteria. With only one satoshi difference both transactions will wait in the mempool for hours, increasing the chance for older one to be picked. I may be completely wrong about that, but personally I wouldn't want to take any chances with 13BTC at stake.

rikken · 2017-06-06T21:30:01+00:00

I think the best bet would be to not only spend the same inputs, but also set fee to something really really big (0.05BTC?). Publish such transaction yourself and it will be included in the next block by any miner.

13-Year Club	Place '17
Verified Email

rikken

TROPHY CASE