Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: [FYI] JoyStream  (Read 603 times)

Offline testz

[FYI] JoyStream
« on: June 17, 2015, 06:31:29 PM »

http://www.joystream.co

Quote
The brilliant insight of the BitTorrent system was to mobilize the idle upstream bandwidth of peers which had a mutual interest in acquiring the same content through barter tit-for-tat exchange. However, the problem of how to incentivize bandwidth contribution from peers which had no need for downloading, e.g. because they had completed the download - or because they had no interest, was a serious problem for the quality of the experience. People tried to work around this by organizing into private communities which imposed strict rules for minimial levels of bandwidth contribution, however access to and continued membership with such communities always remained too elusive and complicated for a lot of people. JoyStream attempts to solve this problem, with an open peer-to-peer solution in line with BitTorrent itself, by using the new money of the Internet, BitCoin.

Quote
JoyStream is at present made up of a small team of one
looking to talk to interested customers, developers and investors.

Offline Pheonike

Re: [FYI] JoyStream
« Reply #1 on: June 17, 2015, 06:52:43 PM »

I PM's him on Reddit about Bitshares. Have not heard back yet. Problem is his model is primarily going to be microtransactions, the thing we are not catering to in 2.0.

Offline rgcrypto

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
Re: [FYI] JoyStream
« Reply #2 on: June 17, 2015, 07:33:13 PM »
signed up!

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: [FYI] JoyStream
« Reply #3 on: June 17, 2015, 08:07:30 PM »
Cool.

Problem is his model is primarily going to be microtransactions, the thing we are not catering to in 2.0.

Well, his application requires payment channels between a specific sender and receiver. You aren't going to pay Bitcoin fees on each tiny chunk of data. You only need to pay a fee once to set up the payment channel and then another fee to close it and settle the payment. Still, Bitcoin fees are considerably less than the default fee we would be targetting for typical transactions on BitShares 2.0. But there is no reason more creative fee models couldn't be used for other transactions to make micropayments like this reasonable.

First, I think we should absolutely have a min fee, max fee, and percentage fee for transfer operations. For example, transferring X BitUSD from one account to another could charge 0.001*X as a fee converted into BTS through the fee pool, but with a lower bound of $0.005 worth of BTS and an upper bound of $0.50 worth of BTS (if there was no fee pool or set fee exchange rate, the system could default to some fixed value like the upper bound). Blinded or stealth transfers will have to assume the worst case, therefore it makes no economic sense to charge less than the upper bound (which is also why the upper bound is so low, because otherwise stealth transfers would be unreasonably expensive for regular payments).

Second, setting up a micropayment channel would take a very small fixed fee (just to compensate the network for processing the transaction and prevent spam). But for the settlement transaction on the micropayment channel to be valid, it would require an appropriate fee to be paid depending on the amount of the balance going to the recipient (using same formula as regular transfer discussed above).

Here is an example. Alice sets up a micropayment channel from Alice to Bob and initially allocates it with 10 BitUSD. The micropayment channel expires at midnight of that day (3 hours in the future) and is set up to require a 30 minute refutation period. Setting up the channel cost Alice only $0.005 worth of BTS. If no one provides a valid settlement transaction on the micropayment channel before midnight, then the first valid settlement transaction on the micropayment channel added after midnight gets immediately applied. Otherwise, when either Alice or Bob submit a valid settlement transaction on the micropayment channel before midnight, the blockchain waits for 30 minutes (or until expiration time, whichever is sooner) before applying that settlement transaction unless the other party (Bob or Alice, respectively) submits a valid settlement transaction that is more recent (based on sequence number in the signed transaction) than the previously submitted one (in which case that settlement transaction is applied immediately). Each party only gets to submit a valid settlement transaction on the micropayment channel once (and they can even be free assuming they are standard ones that are small in size). Part of being a valid settlement transaction is to account for the fees that need to be paid which depend on the amount of the balance that is allocated to the receiver (in this case Bob). So, if Bob submits the valid (signed by both Alice and Bob) settlement transaction that pays Bob 4.30 BitUSD, it must pay a fee of at least 0.0043 BitUSD converted into BTS and the remainder of 5.6957 BitUSD goes back to Alice. In this case, the total fees paid by Alice are $0.0093 worth of assets for a net transfer of $4.30 worth of assets to Bob. There would still be an upper bound on the percentage fee, so if the micropayment channel was set up with a much larger balance and at the end the settlement sent more than 500 BitUSD to Bob, the fee paid would be limited to $0.50 worth of BitUSD converted into BTS via the fee pool (for a total fee payment of $0.55 worth of assets by Alice).

So we can totally make micropayment channels economically feasible on the BitShares blockchain. In fact the BitShares blockchain is so much better for this torrenting application because you are not going to want to wait 10 minutes to get confirmation that the micropayment channel is set up before sending the data (but with 1 second blocks on the other hand...). It's only problematic when you want to send a lot of small transfers to many different people (that you haven't already set up channels with a priori) where the amounts sent are so small that the minimum fee we are willing to accept ($0.005 in my examples above) is not quite low enough.
« Last Edit: June 17, 2015, 08:09:40 PM by arhag »

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1120
  • VIRAL
    • View Profile
    • Dating & Relationship Advice For Smart Women
  • BTS: methodx
Re: [FYI] JoyStream
« Reply #4 on: June 17, 2015, 10:29:35 PM »
You guys will also be interested in project maelstrom.

It's a browser based on Chromium, made by BitTorrent Inc and is basically a way to make websites into torrents. Popular websites load fast and are completely decentralized. So for example, sites like The Pirate Bay could remain active even if they lose access to every domain. And as long as you're using the Maelstrom browser, they're just as easy to access as any regular website.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: [FYI] JoyStream
« Reply #5 on: June 17, 2015, 10:41:07 PM »
You guys will also be interested in project maelstrom.

It's a browser based on Chromium, made by BitTorrent Inc and is basically a way to make websites into torrents. Popular websites load fast and are completely decentralized. So for example, sites like The Pirate Bay could remain active even if they lose access to every domain. And as long as you're using the Maelstrom browser, they're just as easy to access as any regular website.

Very strange.

I assume they are only useful for static content. I can't see how dynamic websites could possibly work. But I guess most things nowadays are moving to single-page web apps that communicate with the server using JSON over a REST API. So this could allow you to just use your web servers for the API and leave all other content to the decentralized network (which ideally is properly motivated through micropayments).

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1120
  • VIRAL
    • View Profile
    • Dating & Relationship Advice For Smart Women
  • BTS: methodx
Re: [FYI] JoyStream
« Reply #6 on: June 17, 2015, 10:53:41 PM »
You guys will also be interested in project maelstrom.

It's a browser based on Chromium, made by BitTorrent Inc and is basically a way to make websites into torrents. Popular websites load fast and are completely decentralized. So for example, sites like The Pirate Bay could remain active even if they lose access to every domain. And as long as you're using the Maelstrom browser, they're just as easy to access as any regular website.

Very strange.

I assume they are only useful for static content. I can't see how dynamic websites could possibly work. But I guess most things nowadays are moving to single-page web apps that communicate with the server using JSON over a REST API. So this could allow you to just use your web servers for the API and leave all other content to the decentralized network (which ideally is properly motivated through micropayments).

Yeah exactly. I think this is a fantastic first step toward a more decentralized web and if it can further be incentivised by micropayments, even better. I see Maelstrom as being much more practical than something like Maidsafe, which has been under development for over 7 years.

Offline CLains

  • Hero Member
  • *****
  • Posts: 2576
    • View Profile
  • BTS: clains
Re: [FYI] JoyStream
« Reply #7 on: June 17, 2015, 10:59:54 PM »

I PM's him on Reddit about Bitshares. Have not heard back yet. Problem is his model is primarily going to be microtransactions, the thing we are not catering to in 2.0.

Yeah it's unfortunate if BitShares prices micro-transactions too high. I've been in talks with Bedeho Mender who's behind this project and he was positive about potentially using BitShares in the future, but for now he wants to focus on a MVP and get feedback from the Bitcoin community (wise choice judging from the Reddit!). I sent BM a PM concerning this project a few weeks ago as well, but I have not heard anything back from him regarding this.

We should definitely consider how BitShares could be useful for JoyStream, as he's open to suggestions at this stage.


Offline VoR0220

Re: [FYI] JoyStream
« Reply #9 on: June 19, 2015, 03:35:57 PM »
Totally had this same idea....I need to get in contact with him.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline VoR0220

Re: [FYI] JoyStream
« Reply #10 on: June 20, 2015, 01:42:18 AM »
He seems a little more interested in creating a sidechain rather than creating a new cryptocurrency. Either way...I'm very interested in this project....I'm absolutely offering up my services to help it. It's hard enough finding likeminded people in this world.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: [FYI] JoyStream
« Reply #11 on: June 20, 2015, 02:29:23 AM »
What is really necessary though is micropayment middlemen. The set up and settlement costs for micropayment channels between the two parties exchanging money for services is going to be too costly on BitShares or Bitcoin for many micropayment applications. It is best to have a free market for micropayment middlemen where there are hopefully not too many choices splitting up buyers and sellers but also still a highly competitive market to drop profit margins to near zero thus saving costs.

Buyers and sellers could join one or more popular middlemen by setting up a micropayment channel with them that is intended to expire in a day. Buyers would have to pre-allocate some balance in the channel for each middleman that they suspect is large enough to get them through the days worth of micropayments they expect to make. For each connected seller, the middleman would need to pre-allocate some initial balance in each channel. This means the middleman needs a large amount of capital to meet the daily micropayment needs of all the sellers it wants to be able to service (it could have less but then it requires frequently settling and reopening the micropayment channels of buyers to get the funds to then fill up the balances of the seller's micropayment channels, which all adds up in fees). The middleman needs to collect enough revenue by taking a cut in the micropayments delivered in order to justify the opportunity cost of not investing all of that capital (as well as the less significant operational cost of running the servers). The middleman might require the seller to put up an equal amount of the initial balance in a separate fund as part of the channel which they fully get back when the channel is settled as a way to prevent distributed attacks by competitors trying to get the middleman to tie up large amounts of capital (since the attacker would also need to tie up equally large amounts of capital, which is costly).

These micropayment middlemen wouldn't care what the micropayment are being used for (torrenting, tips, bandwidth, etc.). As long as a buyer and seller are already on the same micropayment middleman and the balances on their existing channels are sufficient, they can deliver the micropayment via the middleman for a percentage fee rather than a fixed fee. If there are a few good middlemen, the likelihood of buyer and seller already being on the same middleman is high. Furthermore if there are many equally good options for buyers/sellers, buyers and sellers can filter each other based on the middlemen they are on to avoid needing to set up a micropayment channel with a new middleman and thus further save costs. If done right, this might mean that the fixed costs that buyers and sellers need to pay is on the order of a few cents per day to meet all of their daily micropayment needs with various different parties (this would of course not include the percentage fee they would need to pay on the total value transferred via micropayments).

Of course a lot of the above complications for middlemen could be avoided if buyers and sellers can just trust the middleman with the money they are owed (no more than a day's worth of payments need to be trusted) and the sellers are okay with waiting one day until they can get their payments. If the middlemen already have a strong reputation, trusting them may not be too much to ask for. In that case, the buyers need to just replenish their balance once a day and sellers can withdraw their balance each day (but delayed by one day). If buyers don't want to trust the middleman with even a day's worth of balance, they can set up the micropayment channels instead, but the sellers don't have that option. Again, the fixed costs would just be a few cents per day for buyer and seller. The percentage fees would also be lower since the middleman would not have to tie up a large amount of their own collateral.

Offline VoR0220

Re: [FYI] JoyStream
« Reply #12 on: June 20, 2015, 04:22:22 AM »
As always, an excellent analysis arhag. It's starting to make me wonder. Do you think it at all possible that we could implement these micropayment middle men in BTS?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads


 

Google+