Topic: Do you think "iamnotback" really has the" Bitcoin killer"? - page 20. (Read 79971 times)
Deflationary crypto-currency will correspond with a change from debt-based, industrial age to investment-based, knowledge age.
Although reputation can be gamed
Not a WoT. I posit that we can build a (more automated form of a) WoT into OpenShare by default.
, it should still work well for smaller establishments. It would be interesting to find the threshold where a larger business could bury its negative reputation.
A WoT is not gameable by larger establishments either.
If it's easy enough to replicate Airbnb or Uber using OpenShare, the meta-app concept should arise naturally. What about for more specialized markets or something like medical information?
The list of ideas is endless. Blockchains are not just for payments.
MP's point was that the actual service ends up being not as reliable as one might hope, because providers are flaky. China's Airbnb clone employs professionals who go counsel the providers on how to not be flaky.
My thought would be to have a reputation model so that flakiness is weeded out via competition.
Perhaps we can improve Airbnb. And many, many, many other big things perhaps we can disrupt with OpenShare.
My thought would be to have a reputation model so that flakiness is weeded out via competition.
Perhaps we can improve Airbnb. And many, many, many other big things perhaps we can disrupt with OpenShare.
I was under the impression Airbnb had been moving toward some form of quality control as well.
Although reputation can be gamed, it should still work well for smaller establishments. It would be interesting to find the threshold where a larger business could bury its negative reputation.
If it's easy enough to replicate Airbnb or Uber using OpenShare, the meta-app concept should arise naturally. What about for more specialized markets or something like medical information?
Open sourcing analysis is always a superior result, when the participants are smart.
Airbnb is simply a market maker. It provided a common layer for the supply to provide service, and a focal point for demand to discover the supply. The main keys were marketing and simplicity.
Good ol' Mircea, the rude jerk who happens to be correct.
Is MP correct?
For me Airbnb was a way for me to see what sort of pad I might find in different areas of the world without traveling. So although I wasn't a buyer (yet), I was a site visitor. Perhaps Airbnb could have extracted some economic value from my travel lust in other ways.
MP sees only the reservation business (which he claims Airbnb makes worse), and I see the travel lust business. Airbnb is selling not only reservations, but more pictorial and personalized/diversified travel lust experience. MP says he had more personalized travel experiences before Airbnb existed, but most people didn't.
Why do we pay more for Hersey's milk chocolate bar (than a cloned-quality generic one)? Its the wrapper and the slightly curved shape (mmm I can taste that in my mind). Selling a meme is not just selling the service that is physically settled.
He may be correct that the actual service sucks and is not viable long-term due to unprofessionalism of the rental providers. But what I might do (if it is economic) is rather turn Airbnb into a travel lust business for getting access to localized information. So I would sell information and not just reservations. Once we convert it to a blockchain app, we don't need to charge commissions (not with the funding model I have in mind) and we don't need exclusivity that is one of complaints against the Airbnb service (i.e. you can only contact through the service).
MP's point was that the actual service ends up being not as reliable as one might hope, because providers are flaky. China's Airbnb clone employs professionals who go on location to counsel the providers on how to not be flaky.
My thought would be to have a reputation model so that flakiness is weeded out via competition.
Perhaps we can improve Airbnb. And many, many, many other big things perhaps we can disrupt with OpenShare.
Good point. Thanks. Yeah there is a competition for our available cognition. It isn't that we are dumb, but nobody has infinite cognitive bandwidth and physical time. We are literally forced to use our mobile phones to type/swipe because we need to get things done while on the move. Thus mobile apps have to be designed to be ergonomic in a mobile setting with the smaller UI. My mobile phone goes 0% batt lately because I never leave my desk (i.e. I forget my phone exists).
Curious what readers think of this?
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
Airbnb is simply a market maker. It provided a common layer for the supply to provide service, and a focal point for demand to discover the supply. The main keys were marketing and simplicity.
Good ol' Mircea, the rude jerk who happens to be correct.
Is MP correct?
For me Airbnb was a way for me to see what sort of pad I might find in different areas of the world without traveling. So although I wasn't a buyer (yet), I was a site visitor. Perhaps Airbnb could have extracted some economic value from my travel lust in other ways.
MP sees only the reservation business (which he claims Airbnb makes worse), and I see the travel lust business. Airbnb is selling not only reservations, but more pictorial and personalized/diversified travel lust experience. MP says he had more personalized travel experiences before Airbnb existed, but most people didn't.
Why do we pay more for Hersey's milk chocolate bar (than a cloned-quality generic one)? Its the wrapper and the slightly curved shape (mmm I can taste that in my mind). Selling a meme is not just selling the service that is physically settled.
He may be correct that the actual service sucks and is not viable long-term due to unprofessionalism of the rental providers. But what I might do (if it is economic) is rather turn Airbnb into a travel lust business for getting access to localized information. So I would sell information and not just reservations. Once we convert it to a blockchain app, we don't need to charge commissions (not with the funding model I have in mind) and we don't need exclusivity that is one of complaints against the Airbnb service (i.e. you can only contact through the service).
Convenience is now valued above all else until safety becomes a concern, and that's only a temporary interruption. Airbnb exemplifies the type of convenience in demand.
MP's point was that the actual service ends up being not as reliable as one might hope, because providers are flaky. China's Airbnb clone employs professionals who go on location to counsel the providers on how to not be flaky.
My thought would be to have a reputation model so that flakiness is weeded out via competition.
Perhaps we can improve Airbnb. And many, many, many other big things perhaps we can disrupt with OpenShare.
Anything requiring more than one layer of abstraction incurs more cognitive load than most are capable of or willing to put forth, mostly due to financial and time constraints.
Good point. Thanks. Yeah there is a competition for our available cognition. It isn't that we are dumb, but nobody has infinite cognitive bandwidth and physical time. We are literally forced to use our mobile phones to type/swipe because we need to get things done while on the move. Thus mobile apps have to be designed to be ergonomic in a mobile setting with the smaller UI. My mobile phone goes 0% batt lately because I never leave my desk (i.e. I forget my phone exists).
Curious what readers think of this?
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
Airbnb is simply a market maker. It provided a common layer for the supply to provide service, and a focal point for demand to discover the supply. The main keys were marketing and simplicity.
Good ol' Mircea, the rude jerk who happens to be correct. Convenience is now valued above all else until safety becomes a concern, and that's only a temporary interruption. Airbnb exemplifies the type of convenience in demand. Anything requiring more than one layer of abstraction incurs more cognitive load than most are capable of or willing to put forth, mostly due to financial and time constraints.
Will destroying Bitcoin by fixing it make us insanely wealthy?
@IadixDev, I appreciate very much your and other app devs' interest. App devs should be able to use which ever programming languages and frameworks they prefer. If you have some preexisting code which can be readily integrated, there is a golden rule of software development to never entirely rewrite existing source code from a blank slate. Perhaps a music app can be popular and earn money in OpenShare's funding model, even without requiring the content providers to signup. Need to be clever as I pointed out upthread. Personally I love music so I would use it if it is done well. No need to repeat here the debate about some of the tradeoffs of C. In addition to all that recent discussion at the Zenscript Github issues tracker, @keean and I had been discussing Rust in 2016. W.r.t. to those technical insights/choices/preferences, I think over time programmers migrate to what is proven to work best. So we'll find that out as we iterate.
I think this OpenShare project should have its own slack or forum. Slack is better for interactive discussions, but I don't want to be on interactive discussions all day else I won't get much coding done. Forums are better for permanent records of information. So I suppose what we need is a forum and a slack which I visit on a schedule, perhaps 2 - 3X a week. I think that would be sufficient for now and we don't need an official discussion thread on BCT yet because we have still too much coding work to do.
@IadixDev, I appreciate very much your and other app devs' interest. App devs should be able to use which ever programming languages and frameworks they prefer. If you have some preexisting code which can be readily integrated, there is a golden rule of software development to never entirely rewrite existing source code from a blank slate. Perhaps a music app can be popular and earn money in OpenShare's funding model, even without requiring the content providers to signup. Need to be clever as I pointed out upthread. Personally I love music so I would use it if it is done well. No need to repeat here the debate about some of the tradeoffs of C. In addition to all that recent discussion at the Zenscript Github issues tracker, @keean and I had been discussing Rust in 2016. W.r.t. to those technical insights/choices/preferences, I think over time programmers migrate to what is proven to work best. So we'll find that out as we iterate.
I think this OpenShare project should have its own slack or forum. Slack is better for interactive discussions, but I don't want to be on interactive discussions all day else I won't get much coding done. Forums are better for permanent records of information. So I suppose what we need is a forum and a slack which I visit on a schedule, perhaps 2 - 3X a week. I think that would be sufficient for now and we don't need an official discussion thread on BCT yet because we have still too much coding work to do.
Did you check a bit the code on the git ?
https://github.com/iadix/purenode
Wrote a few article on the website too on those topics of memory management in C , and binary compatibility, but it's not complete yet.
http://iadix.com/ico/blogs/en
I think i found a good way to deal with the C downside with internal allocator with reference counting, and dynamic tree graph, I think most issue of C with memory & stdio glitches are in check.
Normally there is not a single call to malloc or the stdlib at all, it use only kernel level functions , and internal allocator with free zone stack, and reference count, supposed to be quite fast.
It's completely GC like, except memory is made available once reference count reach zero, with intel lock atomic instructions for reference inc/dec, instead of being garbage collected periodically. All variable that have no reference are freed once the ref count reach zero.
https://github.com/iadix/purenode/blob/master/libcon/base/mem_base.c#L1138
It dereference recursively all children , and free them when ref count is decreased to zero , but otherwise it's the same than than GC with manual handling of local variable scope.
The only Goody of cpp would be custom operators and automatic destructor/reference dec for stack variables when they get out of scope. With C the scope of stack/local variable need to be managed manually with manual ref dec when the reference get out of scope.
The system with the tree layer source is not on the public git, there is only the binary module and the import defïnition, but I can give access to the git with the full source, or publish them, but id rather avoid prematurely
And it already get rid of native C runtime, to have compiler/system independant binary modules. With dynamic tree graph with runtime data type definition, secure log system, and handling of http/json/rpc based on module export.
And normally it completely cop with C downside with pointer ownership, with no memory leak, dynamic list of dynamic type with reference counting etc. All like GC languages. And with the system , even list/array can be typed, eg to differentiate between a list of block hash and a list of tx hashes, based on json interpreter with optional explicit typing.
Byteball has a design feature we should copy:
Oh I didn't know that the interest rate was going to remain 10% increase to existing hodlers for each round. I thought the terms became less favorable on each future round, because it isn't summarized on the homepage and that is the pattern I observed thus far on quick perusal.
So in that case you claim, then yes 1.119 = 6X growth.
So then in that case it is true that ultimately Tony will only have 1% of the issued supply at that future time (although it is not clear about the other 1% and how it can be given away to wallet signups without it being gamed). However that presumes this his 10,000 GB do not receive the 10% interest compounding. Can you confirm if that is the case or not?
If rounds are being done every 3 - 4 months as appears to be the case so far, then it will be roughly 4 - 6 years until Tony's stake has decreased from 7% to 1%.
A stock split doesn't increase the value of investors' holdings.
The major real economic effect of the compounding stock split is to incentivize investors to buy & hold earlier so they can maximize their stake relative to those who buy later, due to the power of compounding.
That is actually quite a powerful effect. That is a clever feature to add to a coin. I think I will copy it.
P.S. this is why I get involved asking about things that seem abnormal or exceptional. Because sometimes it means it is something important that I need to know for my own work.
Edit: also I need to do what I promised. Tony my apology is extended to you. May I suggest you make the specifics of everything more clear on your homepage.
Ah that defeats the compelling advantage of having such an interest incentive.
Does this explain why the chart is dumping like the Chocolate Hills of Bohol on a monthly period?
They should have designed it such that if the coins trade in that month, then they don't participate in the interest rewards that month. To discourage short-term trading which would decrease the monthly volatility and to reduce selling pressure and increase buying pressure.
...
If you invest 10 GBytes (~0.45 BTC) you have after 19 rounds 10GB*(1+10/100)^19 = 61.15 GBytes.
Oh I didn't know that the interest rate was going to remain 10% increase to existing hodlers for each round. I thought the terms became less favorable on each future round, because it isn't summarized on the homepage and that is the pattern I observed thus far on quick perusal.
So in that case you claim, then yes 1.119 = 6X growth.
So then in that case it is true that ultimately Tony will only have 1% of the issued supply at that future time (although it is not clear about the other 1% and how it can be given away to wallet signups without it being gamed). However that presumes this his 10,000 GB do not receive the 10% interest compounding. Can you confirm if that is the case or not?
If rounds are being done every 3 - 4 months as appears to be the case so far, then it will be roughly 4 - 6 years until Tony's stake has decreased from 7% to 1%.
A stock split doesn't increase the value of investors' holdings.
The major real economic effect of the compounding stock split is to incentivize investors to buy & hold earlier so they can maximize their stake relative to those who buy later, due to the power of compounding.
That is actually quite a powerful effect. That is a clever feature to add to a coin. I think I will copy it.
P.S. this is why I get involved asking about things that seem abnormal or exceptional. Because sometimes it means it is something important that I need to know for my own work.
Edit: also I need to do what I promised. Tony my apology is extended to you. May I suggest you make the specifics of everything more clear on your homepage.
"Few minutes" won't work as you require few hours for BTC transfer to be confirmed within block chain.
You could buy and transfer one day before the snapshot and sell one day later after the distribution ends.
This will work.
You could buy and transfer one day before the snapshot and sell one day later after the distribution ends.
This will work.
Ah that defeats the compelling advantage of having such an interest incentive.
Does this explain why the chart is dumping like the Chocolate Hills of Bohol on a monthly period?
They should have designed it such that if the coins trade in that month, then they don't participate in the interest rewards that month. To discourage short-term trading which would decrease the monthly volatility and to reduce selling pressure and increase buying pressure.
...
Will destroying Bitcoin by fixing it make us insanely wealthy?
@IadixDev, I appreciate very much your and other app devs' interest. App devs should be able to use which ever programming languages and frameworks they prefer. If you have some preexisting code which can be readily integrated, there is a golden rule of software development to never entirely rewrite existing source code from a blank slate. Perhaps a music app can be popular and earn money in OpenShare's funding model, even without requiring the content providers to signup. Need to be clever as I pointed out upthread. Personally I love music so I would use it if it is done well. No need to repeat here the debate about some of the tradeoffs of C. In addition to all that recent discussion at the Zenscript Github issues tracker, @keean and I had been discussing Rust in 2016. W.r.t. to those technical insights/choices/preferences, I think over time programmers migrate to what is proven to work best. So we'll find that out as we iterate.
I think this OpenShare project should have its own slack or forum. Slack is better for interactive discussions, but I don't want to be on interactive discussions all day else I won't get much coding done. Forums are better for permanent records of information. So I suppose what we need is a forum and a slack which I visit on a schedule, perhaps 2 - 3X a week. I think that would be sufficient for now and we don't need an official discussion thread on BCT yet because we have still too much coding work to do.
@IadixDev, I appreciate very much your and other app devs' interest. App devs should be able to use which ever programming languages and frameworks they prefer. If you have some preexisting code which can be readily integrated, there is a golden rule of software development to never entirely rewrite existing source code from a blank slate. Perhaps a music app can be popular and earn money in OpenShare's funding model, even without requiring the content providers to signup. Need to be clever as I pointed out upthread. Personally I love music so I would use it if it is done well. No need to repeat here the debate about some of the tradeoffs of C. In addition to all that recent discussion at the Zenscript Github issues tracker, @keean and I had been discussing Rust in 2016. W.r.t. to those technical insights/choices/preferences, I think over time programmers migrate to what is proven to work best. So we'll find that out as we iterate.
I think this OpenShare project should have its own slack or forum. Slack is better for interactive discussions, but I don't want to be on interactive discussions all day else I won't get much coding done. Forums are better for permanent records of information. So I suppose what we need is a forum and a slack which I visit on a schedule, perhaps 2 - 3X a week. I think that would be sufficient for now and we don't need an official discussion thread on BCT yet because we have still too much coding work to do.
Any way, that is why a strongly typed language that transpiles to JavaScript is something I am considering. C can also be compiled to JavaScript with Emscripten (as I think you've alluded to above).
Server-side we probably want C/C++ code, but perhaps Node.js is okay for the proof-of-concept stage. Remember we are trying to get to market asap. Then there will be funds to throw into development to refine everything.
Let's talk this out on a slack soon.
I already can develop app quickly with the C framework
Already have html5 player & ogg p2p streamer, it can get to the market quickly, quicker than starting from scratch with node.jsI can have a prototype running in the week, no shit. And it works on android browser. The 3d, crypto, and audio stream.
And the idea is there is almost zero double code between the "server"/node side in C, and the app side in html5/js. Because each part have different purpose.
And the goal of using C is having binary machine code, with sse, system calls, opengl/opencl, and direct full kernel api for sockets and i/o, transpiling this to js is not very useful. And I already have working system of cross platform binary module, with the http/json/rpc server, that bind module export as http/json/rpc interface, with the source and binaries on the git. It already works, it's already developped, and can already be used to make html5 application with html5/js with rpc calls to the node modules.
It just miss some kind of high level définition for interfaces and modules and application code to have something really clean that can generate html5 UI and define applications components , with Event handling the json like data type, inter modules interface etc
Maybe sometime it can make sense to have double code as fall back for when javascript engine in the browser is not enough.
Curious what readers think of this?
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
http://trilema.com/2012/lets-have-fun-with-paul-graham/
http://trilema.com/2014/the-mobile-revolution-or-what-consumers-have-come-to-expect/
Minted rewards from voting is not in my plans. There is nothing stopping apps from having voting if they want (such as upvoting comments a la Reddit). But it will not be tied to any token rewarded by the blockchain protocol. There will however be an advantage for voting as compared to Reddit and StackExchange voting.
Steem made several major errors in design, marketing, and launch/distribution. The original will not be the best.
I think it is based on Graphene, so the same DPoS consensus for the blockchain. I haven't looked in much more detail beyond that. I read they were offer rewards via voting, which IMO was one of the major blunders of Steem.
I heard Dan Larimer is working on improving Graphene and launching a new thing. So Ark and Steem will be using an inferior technology.
Why do we need a Steem clone?
The original is always best.
The original is always best.
Steem made several major errors in design, marketing, and launch/distribution. The original will not be the best.
@iamnotback I didnt know Ark.io was similar to steem? I read all their website recently (ARK's) and it just sounded like they where making another Etherum to me, but maybe I got it all wrong.
I think it is based on Graphene, so the same DPoS consensus for the blockchain. I haven't looked in much more detail beyond that. I read they were offer rewards via voting, which IMO was one of the major blunders of Steem.
I heard Dan Larimer is working on improving Graphene and launching a new thing. So Ark and Steem will be using an inferior technology.
Re: Why Bitcoin won’t hardfork like Ethereum
As if the market will have any other choice. That was a nice lie.
Now that Bitcoin is at least 51% mined from China, prepare for future regulations to be enforced on all transactions. The reference to Taiwan a subliminal warning to Westerners of their future ass kicking humiliation.
The BU mining cartel admitted it can and will 51% attack when required to.
I warned you all last year. And you all said I was spreading FUD.
When you guys are serious about decapitating the centralized power of the miners, come talk to me.
Some people spread rumors around, saying that the mining industry will control Bitcoin if BU wins. This is obviously a fallacy, no one can fight against the market unless he possess more money than the market.
As if the market will have any other choice. That was a nice lie.
Now that Bitcoin is at least 51% mined from China, prepare for future regulations to be enforced on all transactions. The reference to Taiwan a subliminal warning to Westerners of their future ass kicking humiliation.
The BU mining cartel admitted it can and will 51% attack when required to.
I warned you all last year. And you all said I was spreading FUD.
When you guys are serious about decapitating the centralized power of the miners, come talk to me.
Expand on this, I wasn't a big fan of his distribution model either, having large ICOs hold the lions share, makes no sense.
See my prior reply to 7thKingdom. They can't use the distribution to fund app devs, content producers, and power users in order to drive the ecosystem.
But he still has 85%+ yet to be distributed ...
Okay that is a wildcard. I've heard this mentioned but never verified it. What is his commitment on that 85%?
When I was in Byteball's official thread last year to discuss, I thought he had committed to keep only a small premine and distribute all the tokens to BTC holders. What changed?
Edit: it is right there on the website:
Quote from: https://byteball.org/
Fair initial distribution
98% of all bytes and blackbytes will be distributed to current Bitcoin holders who bother to prove their Bitcoin balances during at least one of distribution rounds. No investment is required, you need just to link your Bitcoin and Byteball addresses by making a small BTC payment or by signing a message with your Bitcoin address. Then the number of bytes and blackbytes you receive in each round will be proportional to the balance of your Bitcoin address in the snapshot block of that round.
In the first round, over 70,000 BTC was linked, and we distributed 10% of all bytes and blackbytes according to linked Bitcoin balances in the first Bitcoin block timestamped Dec 25, 2016 (Christmas block). In the second and third rounds, we distributed another 3.7%, over 120,000 BTC was linked.
In the 4th round, which is scheduled for the full moon of April (April 11, 2017 at 06:08 UTC), we'll distribute 62.5 MB for each 1 BTC of linked balance and 0.1 new byte for each 1 byte you already hold. To participate, install the wallet and chat with the Transition Bot that will help you link your Bitcoin and Byteball addresses. Track linking progress at transition.byteball.org.
98% of all bytes and blackbytes will be distributed to current Bitcoin holders who bother to prove their Bitcoin balances during at least one of distribution rounds. No investment is required, you need just to link your Bitcoin and Byteball addresses by making a small BTC payment or by signing a message with your Bitcoin address. Then the number of bytes and blackbytes you receive in each round will be proportional to the balance of your Bitcoin address in the snapshot block of that round.
In the first round, over 70,000 BTC was linked, and we distributed 10% of all bytes and blackbytes according to linked Bitcoin balances in the first Bitcoin block timestamped Dec 25, 2016 (Christmas block). In the second and third rounds, we distributed another 3.7%, over 120,000 BTC was linked.
In the 4th round, which is scheduled for the full moon of April (April 11, 2017 at 06:08 UTC), we'll distribute 62.5 MB for each 1 BTC of linked balance and 0.1 new byte for each 1 byte you already hold. To participate, install the wallet and chat with the Transition Bot that will help you link your Bitcoin and Byteball addresses. Track linking progress at transition.byteball.org.
So there is another dilution of Byteball coming next month. But the current issued supply of 137,000 GB (out of 1,000,000 GB total supply that can be issued) is equivalent (at 4th round offer) to 2 million linked BTC that registered previously (in prior rounds at more favorable terms). So there would need to be serious interest from a large portion of BTC hodlers but they are only awarding $4 of Byteball (at current exchange price) for each 1 BTC linked. So I doubt many BTC hodlers will even bother to waste their time. So apparently the remainder of the supply is never going to get issued unless Tony breaks his commitment on how it should be issued.
The first round of Byteball was awarding 1 GB for each 0.7 BTC. The 4th round is only awarding 0.0625 GB for each 1 BTC. So apparently the distribution is nearly completed.
So the developer/creator of Byteball (named Tony) was very sneaky. He said his premine for himself was only 2%, but in effect it will be more than 10% (currently 14.6%) because less than 20% of the total planned supply will ever be issued.
Edit: "1%" (which is really 6 - 7%) will be given to up to 100m user wallet installs, at 100KB each, so roughly $0.0067 per wallet install at current exchange rate:
https://bitcointalksearch.org/topic/m.18309534
What is not clear is whether the 1% referred to is only of issue supply or of maximum planned supply, as I explained in more detail at the above link.
Note I don't think $0.0067 per wallet install (even if the price increases by 10X or even 100X) is going to incentivize any users to install wallets.
Byteball could be the killer of BTC. The end of BTC's dominant position.
4. Afaics, his distribution model totally ruined any chance for a funding model to onboard the app developers, content providers, and users. This is really the killer mistake.
Expand on this, I wasn't a big fan of his distribution model either, having large ICOs hold the lions share, makes no sense. Do these other coins plan building on top of BB?
But he still has 85%+ yet to be distributed ...
For the language, I have mostly the low level part on the git, with the module system, the dynamic tree with reference pointer, http/rpc server, and most C runtime, and the vector lib for the raytracing. Then the modules method can be called from a js application with http/json/rpc.
For the high level part to make application, i dont have much theory I would go for something very basics who can call module function and handle Event with json like data type, and in the spirit akin to BASIC with simple one line statement easy to evaluate, charm is really the kind of things im looking to have good OOP encapsulation in module with an interface.
Js as far as i know is weak for defining good object sur typing and interface, but if I understand well, your idea is to have a source language with good sur typing and interface définition, and transpiling to js to have équivalent code.
But for me i would still rather stick to a kernel in pure C, that can expose module interface to js/html5 app, and having the node/server side in C rather than node.js. Much better for performance, memory use, and portability. The only thing it really miss now is a good html templating system to generate html5/js page based on input data. For this im not sure if the best is to have browser side generated html like angular js, or something that can generate preformated html from the node, or using xslt which can be done by both server & browser. Or something entierely different to define UI and Event handling and rpc call in html5/js.
That would do in sort to have part of application in C modules with the framework, and part of application on js/html5 who can call those modules. But having another source language to transpile this part of the app with the UI and modules interface, why not.
But all the part with binary data crypto & transcoding in js
For the high level part to make application, i dont have much theory
I would go for something very basics who can call module function and handle Event with json like data type, and in the spirit akin to BASIC with simple one line statement easy to evaluate, charm is really the kind of things im looking to have good OOP encapsulation in module with an interface.Js as far as i know is weak for defining good object sur typing and interface, but if I understand well, your idea is to have a source language with good sur typing and interface définition, and transpiling to js to have équivalent code.
But for me i would still rather stick to a kernel in pure C, that can expose module interface to js/html5 app, and having the node/server side in C rather than node.js. Much better for performance, memory use, and portability. The only thing it really miss now is a good html templating system to generate html5/js page based on input data. For this im not sure if the best is to have browser side generated html like angular js, or something that can generate preformated html from the node, or using xslt which can be done by both server & browser. Or something entierely different to define UI and Event handling and rpc call in html5/js.
That would do in sort to have part of application in C modules with the framework, and part of application on js/html5 who can call those modules. But having another source language to transpile this part of the app with the UI and modules interface, why not.
But all the part with binary data crypto & transcoding in js
We will have to dig into the details in an interactive slack soon. I am thinking apps should be mostly client-side code and they should run both in the browser and as installed app on mobile. App devs could use any languages and frameworks they want. I would like to try to over time standardize a platform so the app dev only has to maintain one body of code and it runs every where. We'll even eventually have our own superapp which acts as an app installer and an app store (all decentralized, no censorship/fees possible).
But I need to work with some app devs to see what works well and how we can stage it. Might have to take it in incremental steps and our first goal is to get to launch asap.
Any way, that is why a strongly typed language that transpiles to JavaScript is something I am considering. C can also be compiled to JavaScript with Emscripten (as I think you've alluded to above).
Server-side we probably want C/C++ code, but perhaps Node.js is okay for the proof-of-concept stage. Remember we are trying to get to market asap. Then there will be funds to throw into development to refine everything.
Let's talk this out on a slack soon.
If we consider *really small* fees, then for an extra included transaction, that extra delay on the network will mean an extra probability of the block being orphaned, putting in jeopardy the whole income. This even happens with small blocks.
Yes, that's probably the way Peter R's model was intended to work (though it not even works out in theory).
Furthermore, as long as you have a block reward that is significantly higher than the total fees per block, even a small increase of the orpahing risk might deter a miner from including every transaction.
Yes, this will simply result in cutting off the very lowest fees of the fee distribution, which will remain for ever in the mem pool.
I don't think that this has much to do with "optimal size" ; it only means that one doesn't include the cheapest transactions below a given fee threshold, because their extra transmission time penalises the whole income while not contributing enough to it.
I don't think that this has much to do with "optimal size" ; it only means that one doesn't include the cheapest transactions below a given fee threshold, because their extra transmission time penalises the whole income while not contributing enough to it.
I think that's the whole point of it. If the model worked as intended, the market would agree on a minimal fee for a transaction to get included in a block. It's not about finding the "optimal size" but the optimal price.
That said, a market doesn't need to come to "equilibrium". An erratically chaotic market dynamics can be fun too
It would be indeed fun to see the majority of nodes switching to Bitcoin Unlimited...
I agree with Shelby that music may not be the best place to start. There is too much entrenched establishment thinking in that domain by both consumers and especially content creators (although it has gotten much better in recent years). Artists are still locked into old ways and I don't believe it will be the easiest market to "attack" first.
Yes, the indie market does offer some inroads, and in time I believe that will be the place to dig in and make our mark, but I don't believe it is the best place to start in the grand scheme of things. I would tend to think a market to focus on first would be one that already has its roots in upending the tradition media/content distribution status quo. The primary ones that come to mind are podcasting/vlogging (and to a lesser extent blogging). These industries are built on the idea of creators getting their content directly in the hands of users with minimal middle man interaction. And the content creators are always looking for new and better ways to monetize their offerings.
Unlike the music industry, where there are a plethora of preconceived ideas and biases holding people back, the podcast/vlog sphere has very little of that. They want innovative distribution ideas, that is why they came into existence in the first place. They want easier/better ways to spread their "art".
Yes, the indie market does offer some inroads, and in time I believe that will be the place to dig in and make our mark, but I don't believe it is the best place to start in the grand scheme of things. I would tend to think a market to focus on first would be one that already has its roots in upending the tradition media/content distribution status quo. The primary ones that come to mind are podcasting/vlogging (and to a lesser extent blogging). These industries are built on the idea of creators getting their content directly in the hands of users with minimal middle man interaction. And the content creators are always looking for new and better ways to monetize their offerings.
Unlike the music industry, where there are a plethora of preconceived ideas and biases holding people back, the podcast/vlog sphere has very little of that. They want innovative distribution ideas, that is why they came into existence in the first place. They want easier/better ways to spread their "art".
Interesting idea.
With my plan, app creators are in charge of their own destiny. So they decide which marketing sectors they want to develop for. But we can brainstorm now so hopefully we have some well thought out apps to launch with, so that the synergy is good for all of us.
If we contrast with Ethereum's model, Ethereum is ostensibly making it very confusing for speculators, because now they have to choose between dozens (or soon 100s) of ICO tokens. Which ones do they invest in? The cognitive load is too high. It ends up diluting speculator focus, and then as you see Byteball gets all the votes (even though I've already explained that Byteball has some serious flaws).
Although Ethereum is getting a lot of experimentation now and we will be behind initially, possibly we can overtake them because for example, the MobileGo smart contract will be taking 10% fees on all game transactions (e.g. game purchases). In OpenShare, the game app would keep all of its revenues on sales plus it would gain additional massive revenues from my planned onboarding monetization model (something similar to Steem's but not based on voting). Tangentially also other crucial differences such as Ethereum's consensus algorithm doesn't appear to scale decentralized (and I don't think Casper will either nor do I believe it is sound, nor do I think Raiden will be the complete solution in all cases, but the devil is in the details on all of that).
All debasement of OpenShare is going towards onboarding, not to an ICO.
You app developers are in effect being issued the money supply in exchange for your onboarding performance, in addition to any other monetization you want to add to your app (e.g. ad funded, in game upgrades, etc). The OpenShare token will sub-second confirmations as well you can post data to the blockchain with sub-second confirmations and practically no limit on TPS or bandwidth.
But I want to emphasize that focusing on the power users and evangelist users first is the most effective. They earn more and bring more users into the onboarding process. The other users want to emulate them and be as great and prosperous as the power users are.
Every transaction will require burning a small transaction fee and so your users get some tokens so they can use the system (and then they get some tokens from using the system, so they can continue using it). The money supply is perpetually deflationary with an unbounded divisibility of the money supply (although it is initially inflationary due to all the onboarding but this onboarding is extremely valuable and will pay us back in terms of a huge marketcap).
Tokens that are rewarded will be non-fungibly locked up for period of time in order to encourage users to use their tokens and not dump then to whales. This will also keep the float small, so that the price is always going up.
Speculators are going to have to fight each other to get into this early. The longer they wait, the higher the price goes. Well at least that is the plan, given the small float relative to the marketcap. But we don't want the Zcash experience where float is too small at the start and then price continually declines as the float increases. But this can be dealt with by selling tokens to raise more funds for development as needed. Maybe even provide advances (against future revenues) to some app devs who need funding upfront.
Note we will not have the crazy dilution of the original Steem design. This will be a very small rate of dilution compared to the impact on the marketcap and price that it should cause. Well that is the theory any way. Remember blockchains and their tokens are just a computer game right.
Quote from: http://trilema.com/2013/valiant-prince-mp-explores-the-mother-of-all-echo-chambers-a-saga-of-our-times/
I'm not particularly interested in liquidating, it's a computer game after all.
Note I have been purposely just a little bit vague and elusive, because I am not ready to have copycat projects of my design just yet.
I believe the largest hurdle to overcome in this market is the idea that consumers have always gotten these things "for free" and there may be some resistance to now paying for them. But the whole idea of a micropayment social media platform is that the consumers wouldn't even really feel the brunt of paying anyway since the transactions would be so small. So I don't think this will be as difficult to overcome as it initially appears.
Consumers are going to be paying with tokens they received for free. And you will also monetize your app from onboarding having nothing to do with whether the consumer spends or not. So you have two ways to monetize. As for teeny-tiny microtransactions, I don't know if that is a good model. I doubt it. The system design will be able to do, but I think you'll be better off with the onboarding monetization perhaps coupled with some monetary transactions for upgraded features or higher quality versions of content downloads (e.g. 256-bit MP3 song upgrades from 128-bit freeware) or what have you. One advantage is the instant transactions so if the user wants an in game upgrade (i.e. to buy a more powerful gun), they can get it instantly and not have to wait. I suggest readers study up on gamification monetization strategies if they aren't already aware of the Farmville model and what has come since that.
Now I hope you start to see why you should be working on an app for OpenShare so you are one of the lucky apps at launch time. That is the best way to get tokens when they are low priced.
Speculators find some devs and hire then to make apps. That is the way you invest in this early. Else you can buy coins on the open market as they trickle out from the onboarding.
What you think guys? Interesting?
So two names that immediately come to mind are... Flow and Fluid
Flow is already taken:
https://flowtype.org/
Fluid is somewhat interesting.
In case anybody was wondering how I plan to improve decentralized consensus, here is a helicopter view summary:
If only that could be done. I have many ideas to *improve* but I'm almost sure that all of it corrupts eventually. This is why no single tech should be dominant for a long time, no uniformity. Nothing should have a long life time, nothing should have a broad importance and acceptance.
Open source. Open source. The Inverse Commons. I keep telling how to do it.
Miners can do what they are doing because it is not illegal in the protocol. Make it illegal then open source the enforcement of the objective law that makes it so. Byzantine fault detection instead of Byzantine agreement.
That is my solution. Now figure out the details.
However, I also can't conclude with 100% certainty that there isn't some mode by which centralized control is still attainable.
We actually have to fix the technology of decentralized consensus. Satoshi's work is not yet complete.
If only that could be done. I have many ideas to *improve* but I'm almost sure that all of it corrupts eventually. This is why no single tech should be dominant for a long time, no uniformity. Nothing should have a long life time, nothing should have a broad importance and acceptance.
Open source. Open source. The Inverse Commons. I keep telling how to do it.
Miners can do what they are doing because it is not illegal in the protocol. Make it illegal then open source the enforcement of the objective law that makes it so. Byzantine fault detection instead of Byzantine agreement.
That is my solution. Now figure out the details.
However, I also can't conclude with 100% certainty that there isn't some mode by which centralized control is still attainable.
We have a slack channel https://iadix.herokuapp.com/ http://iadix.slack.com
I guess we are going to need to move our discussion off of BCT since the mod apparently can't comprehend the importance of the following post which he deleted without my permission!
The mod can't seem to understand that by highlighting the parts I wanted to emphasize, I can make my reply more concise. Programmers understand that I am communicating a lot of information with the +1 and the yellow highlighting.
The mod needs to stop deleting that which he doesn't understand.
Perhaps it is because of that @mindtrust user upthread who complained that my posts are walls of text and too many posts. Well then don't read the damn thread, since the thread was starting to talk about my project dufus. And I have a lot to say because of that fact.
+1
The mod can't seem to understand that by highlighting the parts I wanted to emphasize, I can make my reply more concise. Programmers understand that I am communicating a lot of information with the +1 and the yellow highlighting.
The mod needs to stop deleting that which he doesn't understand.
Perhaps it is because of that @mindtrust user upthread who complained that my posts are walls of text and too many posts. Well then don't read the damn thread, since the thread was starting to talk about my project dufus. And I have a lot to say because of that fact.
The good thing about bitcoin client is it's very well tested , mature etc, but still not that easy to quickly add new feature or encapsulate into a bigger application.
And im perfectly in tune with iamnotback on the need of programming paradigm switch, and im already on this for 2/3 years
So going back into multithread boost c++ like bitcore with the super high coupling everywhere, with all hard coded config, I would rather not
And im perfectly in tune with iamnotback on the need of programming paradigm switch, and im already on this for 2/3 years
So going back into multithread boost c++ like bitcore with the super high coupling everywhere, with all hard coded config, I would rather not
+1
Jump to: