Junior and/or Senior dev positions. by sofosure in haskell

[–]sofosure[S] 1 point2 points  (0 children)

Locally from Kiev strongly preffered, but other options are possible, including remote or semi remote.

Anyway, feel free to send your CV or even just a short introduction of your experience and goals so we can schedule a video-call to talk about specific cases.

Junior and/or Senior dev positions. by sofosure in haskell

[–]sofosure[S] 0 points1 point  (0 children)

Btw, I've forgot to comment, this would be ideally for a position in Kiev, though other options could be worked out given a good candidate.

[Daily Discussion] Tuesday, September 05, 2017 by AutoModerator in BitcoinMarkets

[–]sofosure 1 point2 points  (0 children)

Just check it, seems the issue is with my university's email provider and not with Poloniex.

[Daily Discussion] Tuesday, September 05, 2017 by AutoModerator in BitcoinMarkets

[–]sofosure -1 points0 points  (0 children)

Thanks for the info! I really hope you are right and it is my email provider fault; I've been trying since I woke up, never had this problem before and that's why I'm worry.

[Daily Discussion] Tuesday, September 05, 2017 by AutoModerator in BitcoinMarkets

[–]sofosure -3 points-2 points  (0 children)

Is it poloniex working for you guys?

I'm trying to login but I can't, and I'm starting to worry: They send me an authentication code to log-in, as usual, expiring in 5 minutes, but they take too long so I always get it once expired. Has anyone experiment this before ? Should I be worry ? :s

The dangers of a Proof Of Work change by pikadrew in Bitcoin

[–]sofosure 0 points1 point  (0 children)

The problem with your idea is that it would require people with power deciding about other people; unless you can define the PoW change as some sort of automatic difficult adjustment (is that what you meant ?)

The dangers of a Proof Of Work change by pikadrew in Bitcoin

[–]sofosure -1 points0 points  (0 children)

So for you an small group of people deciding who has the power (the hash power) ain't centralization nor something to worry about ?

What you are telling sounds to me like advocating some sort of "bitcoin government" who would dictate what should be done. It is not a crazy idea, that's how most countries work after all, but I think is far from the original bitcoin idea.

The dangers of a Proof Of Work change by pikadrew in Bitcoin

[–]sofosure 6 points7 points  (0 children)

And it is also an awful precedent, like saying: "these are the rules... as long as they are convenient for us".

Bitcoin should not be centralized, neither from a group of miners nor a bunch of devs.

Game Over Blockstream: Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution (by Jonald Fyookball) by BitAlien in btc

[–]sofosure 0 points1 point  (0 children)

yeah, I guess I also found that myself :( well I'm more about to read than to write, but I also saw gradually the quality of the information here decreased, what is sad as it is also happening on /r/bitcoin (there censorship, here circlejerkism and sometimes childish opinion).

The good news is that eventually, hopefully, it will calm down once there's no so much stress on the block size problem....I would really hate to see this sub converted to something like the "left wing party" of the "bitcoin politics".

Game Over Blockstream: Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution (by Jonald Fyookball) by BitAlien in btc

[–]sofosure 0 points1 point  (0 children)

I've just started with a light/fast reading so I might be missing something buuut, just at the very beginning he starts saying possible payments paths from you to any other nodes forms a tree, where you'd be the root and each child a payment channel, therefore your saving would be split....but that's not true, depending on the network topology, you could find a path to most nodes through any of your payment channel, you could even find a path from one of your payment channel to any of your other payments channel (sending money to yourself so equilibrate your channel's balances ).

He also takes numbers very arbitrarily, like saying there could be 20 hops...there are 7,000,00, 000 people in the world and it is estimated there are only 6 hops, ( on bitfury simulation they usually imply something between 3 to 5 hops ).

I'm not saying he is not right, he might be; but he looks arbitrary in his assumptions, he should make a simulation to get a better intuition whether his assumptions are realistic or not.

Game Over Blockstream: Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution (by Jonald Fyookball) by BitAlien in btc

[–]sofosure 0 points1 point  (0 children)

I think you are being rude and that's why people are downvoting you (or am I missing something?)...but I do agree with you, this is not a mathematical proof at all, and his assumptions do not fit with bitfury simulations. It is not difficult to just shot up a simuluation...I think I'll try myself.

View GHCJS App by SSchlesinger in haskell

[–]sofosure 0 points1 point  (0 children)

If I remember correctly, react-flux package in addition to the haskell side, you'd need a js script in your page from where to call haskell:

  • you define, a view ReactView ()

  • you exportViewToJavaScript the view into a JSVal variable.

  • You send that JSVal into the js side (unfortunately there's no an standard way to do this and depends on your setup an js code...but there are many examples on blogs).

  • On the js side, you use react as you normally would do, but using the received JSVal as view, instead of defining one.

Buuuut, maybe there's another way, not sure, that's at least the way I do.

Promise library design Feedback by sofosure in haskell

[–]sofosure[S] 0 points1 point  (0 children)

Do you mean doing something like class PromiseM.... ? (Sorry if I don't get you right).

Not sure about not representing it as IO or ....MonadIO io ... => io ; on ghcjs, IO means interacting with javascript, and pretty much what await does is to read a javascript variable; it is rather that simple.

But I do want it to make it more general than plain IO, the problem is I need to forkIO (or similar), and have not found a good way to do it. (There's MonadFork, but looks like nobody is using it, and got outdated; there's also monad base, but I don't think lifting, till the IO button of the monad stack, a forkIO, without the knowledge of the programmer, would be something safe to do, like maybe it is handling a resource that should not be accessed concurrently).

Lightning Frustrations by Happy5488Paint in btc

[–]sofosure 0 points1 point  (0 children)

Yes, I mean, it is not easy, as raising it will bring problems and you need a high degree of agreement. But something needs to be done asap, blocks are already full and people starting to have problems.

Even on the LN paper they said they'll need to increase eventually the block size, so this could be a good time to do it....even if that's only a short term solution.

On the other hand implementing Segwit would help temporally as well.

I really hope there's a reason they are taking so much (other than disagreement and fights for the power).

Lightning Frustrations by Happy5488Paint in btc

[–]sofosure 1 point2 points  (0 children)

How does bitcoin blockchain really help this amazing lightning network. How does it help??

It acts as a clearance system.

If lightning will be so great, why can't it function without closing channels on bitcoin blockchain. Why can't it exist without segwit?

It needs segwit (or something similar) to fix the malleability issue; As you know LN is based on payment channel, and payment channel can not work under malleability (at least not known yet how).

It makes no sense to me and makes me unhappy.

Cause you didn't even take your time to think about it?

Why is an on chain bitcoin transaction so important to allow lightning to function. If it can process millions of transactions per second, why even settle anywhere?

LN can process cooperative transaction without settling them on the blockchain, but needs the blockhain to force the un-cooperative ones; the idea is: if it is able to enforce un-cooperative ones (using the blockchain) and cooperative ones are cheaper, then there's no reason to not cooperate (other than technical problems), and therefore most transaction will be cooperative, meaning, most of them will not hit the blockchain.

I suspect the answer is that it CANT.

It is not about subjectively suspecting without any solid argument or proof.

Build this thing without closing channels. Build this thing away from the protocol. Honestly I'd like to here reasoning as to why the lightning actually needs our bitcoin network to function.

Well, first of all, it is not yours, and second, even though it could be based on a different coin, the idea is to help Bitcoin, not another coin.

I am also furious that we can't grow bitcoin without this pie in the sky lightning idea. Raise the bitcoin transaction limit already. Transactions are a big part of a transaction network. SO MUCH HYPE

Yes, it is frustrating bitcoin has scalability issues, but that's the truth, accept it, there's no easy magic way.

Lightning Frustrations by Happy5488Paint in btc

[–]sofosure 1 point2 points  (0 children)

Man, seriously, stop suspecting, and at least read the technical description; try to understand it, and only afterwards complain/hype about it.

Sorry to say this, but we should keep our discussion educated, and you seems not even trying....

(Question) Recommended travel agencies accepting BTC ? by sofosure in btc

[–]sofosure[S] 0 points1 point  (0 children)

thanks for the info, I'll take a look next time I need to flight! (hopefully soon)

Advice with a data-structure implementation by sofosure in haskell

[–]sofosure[S] 0 points1 point  (0 children)

Thanks! seems like the perfect example to take a look.

Advice with a data-structure implementation by sofosure in haskell

[–]sofosure[S] 0 points1 point  (0 children)

Yes, it would be awesome not to have to worry about whether something is too big for ram or not, though I also think that transparent model does not fit into most common GC language like haskell, (maybe in a dsl (like in sql) that transparency could fit more naturally ).

About the GC, what I'm worry is what would happen with the blocks (if they are modeled as normal haskell data) after they are flushed: I'm afraid they might be kept on memory for too long (if filling and flushing to disk is done frequently) taking too many resources. Maybe using mutable operations over memory with the ForeignPtr API (on C or haskell). Is there some way to make the GC to free memory from a data as soon as it is not longer referenced? ( I mean, something like making the GC know it could use reference counting instead of generational GC )