Topic: Do you think "iamnotback" really has the" Bitcoin killer"? - page 22. (Read 79971 times)

Nebula

Let's do it! I just think maybe "we" will choose other apps as a priority instead of the music app. But I am also okay with doing a music app first too. I love music and would surely use the app myself! We'll brainstorm about it soon...

I will be very enthused about apps I will myself use, because I will have many ideas of how to innovate them. My million user successes in commercial software were the ones I created because I wanted to use them (and saw the market was lacking the specific features/capabilities that I wanted). For a music app, I want it to be my music player and also keep track of all my music so I never have to hassle with backing up my music, transcoding formats, etc... And I don't want it to tie me into any walled gardens, no adware, no bullshit, etc..

Yeah we'll be "cheating" also but copying for example the way others are already cheating:

http://www.listentoyoutube.com/ (get my idea yet?)

Have you ever noticed you can overlay and obscure the SoundCloud HTML player buttons? Instant library of songs without the 10,000 plays per day app limit. I have some (clever or out-of-the-box thinking?) ideas we can discuss.

Remember our apps need a social component. There needs to be sharing (likes), commenting, etc..

But the more important point is how you the app creator will get paid. And how much money you will be able to earn creating apps.

All you need to do is make apps that people will like to tell their Facebook friends to use.

I think from there, you can start to deduce what I have in mind, but I hold off on the details while I try to finish up getting the preliminaries of the scalable, decentralized blockchain for OpenShare into code. Then we will start to talk in earnest about collaborating, launching, and making a lot of money while shocking this community with our STICKY, VERIFIED adoption rate (into the millions I expect).

I am excited because now I see that real capable app developers are contacting me. So I only need to convince you that my blockchain technology and onboarding strategy is viable, then we can go change the world.

I am on the 2 drug treatment now. Let's hope my energy is ready roll now. I need go finish up on the proposed changes for the (optional proposed app) programming language and see if it realistic for me to write the transpiler in a matter of weeks. I am going to try to go wrap that up now after doing my forum communication now. Are you interested to help on the transpiler? Should I start a Github project for that? Which name is best Async, Copute, Lucid, or Next (Nxt)?

All app programmers please keep in touch. I want to make you wealthy. Let's have fun also.

I'll make an official thread and Slack once I get through the preliminaries and am confident that my production (in code!) is back up to normal.

Hahaha, when I was reading your first paragraph, Sun Tzu came to mind exactly as you wrote it 

Yes, this is with block rewards constant.  Tail emission.  But in the case of rewards proportional to block length (fees), you have to multiply A's revenues with the fact that his blocks bring in more money.  He has a lower percentage of blocks on the chain, but these blocks bring him more rewards as they are bigger.

So if his big blocks bring him 20% more income per block, this is neutral.

However, the thing to keep in mind is to get an orphan rate of 0.2 by network propagation, it means that on average your blocks take 0.2 of the block period to get to the others.  0.2 of 10 minutes is 2 minutes.  If you have good links, in order for them to take 2 minutes, they must be mindbogglingly HUGE.
If it takes 2 minutes to pump a block to another miner with whom you are connected with a 10 Gb/s link, we are talking about 100 GB blocks or something.

As I said earlier, this kind of argument only starts to play a role when the network is already dead.  Because if a significant fraction of the block time (10 minutes in bitcoin) is what it takes for miners amongst themselves to propagate blocks and get them orphaned, no "normal node user" can ever obtain the block chain up to date, because normal users have a worse network connection to the miners (source of block chain) than miners amongst themselves.  Especially if network quality is impacting seriously on their revenues, miners will have the best possible links between them: mutually advantageous (and much less costly than the mining itself: a 10 Gb/s link to Joe MiningPool is less expensive than your mining gear).

If you really want a solution to this problem, then "block length" is not the right parameter, but block income is:

one should cap the "block reward + fee", to, say, 20 btc.  As such, miners can make all the blocks they want, long, short, but their TOTAL INCOME (reward + fees) is capped to 20 btc FOREVER (part of the protocol).   A block with a total reward larger than 20 btc is simply invalid.  

If you do that, you get consensus convergence: blocks will grow until the mem pool is empty, or until fees sum to 20 btc.
If fees sum to close to 20 btc, then users can lower their fees.  There is however a dangerous lock out spiral: if fees reach 20 btc, then there will be transactions that are excluded, and users could increase their fees in order to hope to get their transaction in.  But then, blocks would become even smaller !  The right action would be that all users stop putting large fees ; which they will, eventually.  So users should start LOWERING their fees from the moment that the block rewards start to approach 20 btc.

Byteball could be the killer of BTC. The end of BTC's dominant position.

Maybe I can appear strong for people to think im weak 

Some have less subtle approach

https://youtu.be/URybdpu_NhI

Not sure who is winning, everyone is cheating anyway :p

Absolutely not. I just like to win. You are playing a strategy to lose by attempting to be strong where you are weak. I am playing to win by appearing to be weak where I am actually very strong. As I said, I have not explained my idea in detail for that yet. But I told you that we should integrate into the status quo and appear to be weak, while in reality we are building an indie market within it.

The Art of War by Sun Tzu

“Appear weak when you are strong, and strong when you are weak.”
“The supreme art of war is to subdue the enemy without fighting.”

But...

Michael Jackson said Sony kills the music.


The popular musician agreed to be in the music industry's system.


They are kidnapped as Kids in the getho and brainwashed by lawyer, it's not exactly the same  

But yeah I guess it's not completly good synergy for the moment, but the fruit might just need a little kick to fall down too even if some people seem to think they are entitled to the tree.



they will fight back with every dirty trick they can muster




Chicken :p

Music is problematic, because if a song even has an element of another song it (such as a similar riff), the music industry can use their lawyers to force you to sell out to them. Decentralized paradigm it is more difficult for them, but they could scare the artists by making a few examples.

I think it would be better to not require artists to do anything. My idea is a clever integration.

It will never work the way you are thinking. Disrupting and stealing the popular musicians is war against the music industry and they will fight back with every dirty trick they can muster. They promoted them and created their popularity. That is in effect stealing their IP. The popular musician agreed to be in the music industry's system.

There isn't going to be any revolution like an overt protest and overturning of the music industry, because the artists are a captive audience of the industry in large part. It is a specialized industry with specialized needs. The best to hope for is developing indie niches within a broader scope of participation with the existing status quo in order to obtain the necessary economies-of-scale and side-step the hen-egg dilemma.

We can talk more detail on this later. It is premature now for me to state my specific idea.

I doubt music content is best priority. The synergies are weaker than other things we could prioritize, because there are so many hurdles, a fractured market, and there is not so much innovation that can be done (unlike for example software where there is unbounded innovation TBD).

Your design is not secure in terms of all nodes (users' chains) seeing a consistent ordering, because the set of possibilities is unbounded and you can't disprove a negative in an unbounded universe. It is covered in my whitepaper. Raiblocks already invented what you did, and they tried to arrive at consensus with voting but @monsterer and I explained why that was flawed.

We have a good contact within independent music producer, but I dont have the feeling they are very fond of internet, and have used & abused by many system already, they dont have high amount of trust on Internet to sell music. But the conditions are also no that good for many of them, so I guess it can be tempting

There was the ODRL thing that was interesting, regarding the problematic of digital right, if a thing like this can be integrated as blockchain object, that could be convincing with labels & music producer


https://www.w3.org/community/odrl/

 The ODRL Policy Language provides a flexible and interoperable information model to support transparent and innovative use of digital assets in the publishing, distribution and consumption of content, applications, and services across all sectors and communities. The ODRL Policy model is targeted to support the business models of open, educational, government, and commercial communities through Profiles that enhance the model to align to their requirements whilst providing a common semantic layer for interoperability.


Need to find the good mocking Jay to start the revolution or with anonymous blockchain for them to cheat their producer with a vo coder

Maybe some would jump, like daft punk, or some other who understand technology and have good lawyer for internet right

I think Kim dot kom was on this too, and then he got arrested  

15 years ago we were going to see big producer to speak about internet music distribution, suddently their face turned like they are sit on a cactus. It looked very painful.  I think they d rather deal with terrorists than with internet hackers

Excellent, so you've completed a lot of the work I was going to need to do if I prioritized a music content app or feature. We should talk about this in the near future.

Did you see the debate I had with @Gmaxwell about ogg streaming index?

Yes we definitely have a problem with the musicians being beholden to the rent seekers and that musicians can barely earn anything. I have a new idea which I think might work, but I am wary if music content should be the first priority. I am happy to know someone has some experience in this area. We should definitely talk about this soon.

You make a good point about them not appreciating the technology. And always the hen-and-egg problem on economies-of-scale. I think even less users can make music, as compared to for example blogging or sharing content. So music content relies on attracting the artists, and as you say they are significantly a captive audience of the rent seekers. So that might be one of the most difficult sectors to disrupt. I originally wanted to go after that market and as I said, I have a unique idea, but I am thinking lately and reinforced by your feedback, that it is not the lowest hanging fruit for us.

I believe what I want to do is genuinely new, as new as PoS was to PoW.


One of key fundamentals is that any requirements for synchrony make it very complicated to realize a robust design.

So actually the care put into the design can make a huge difference in how difficult it is to implement it in reality.


K.I.S.S.

I am one of top fixers of bugs historically when I worked for others.

Bugs finding and fixing do slow everything down. And blockchains must not have irrevocable errors. I agree it is a major challenge.

DPoS was able to simplify matters significantly by making the witness set permissioned (instead of unbounded as is the case for PoW miners).


I've never looked at the Bitcoin code and I never intend to (well heck I might look, in fact I just did for example glance at merkle.cpp).

I'd lose more time messing with that fragile C++ codebase, than I would writing from scratch. Perhaps there are some aspects I could extract from the code base, if I find it helps. But as for working from the code base as whole and trying to modify it, no chance I will follow that strategy.


I do agree with getting the most rudimentary functionality working before trying to add more features.


Yes of course. Don't bite off more than you can chew.


Not just a few changes. No code has yet been borrowed from any other altcoin project, other than perhaps cryptographic and networking libraries. We'll see going forward though...

3  - 4 years? Yes if you are trying to write bitcoin-qt node. But I'll find a way to cut corners so that only rudimentary capabilities are achieved quickly and incremental improvements can be added ongoing.

@alkan I think you explained it well in another way.

---

I think, that I now understand the issue. Let me put it into my own words and see if we are on the same page...

In equation (3) the miner’s expected revenue gets discounted by the chance that his block is orphaned (1 - p_orphan). That is, the rewards are only counted for the blocks that make it into the blockchain. So, if a miner for example produces 10 blocks per day with an orphan rate of 0.2, he will get the rewarded for a total of 8 blocks.

However, this perspective turns out as incorrect as block production rate will ultimately depend on the block difficulty which is automatically adjusted according to orphan rate and hash rate of all the miners.

What actually matters for a miner's block production is thus not how many of his (produced) blocks make it into the chain, but how many of the blocks in the chain are produced by him (production share). This is not the same thing! The mining rewards (fees+block rewards) must be multiplied by the miner's production share since the total block production (per time unit) remains constant due to automatic difficulty adjustement.

Let's make a simple example with only 3 miners A, B and C who all have the same hash power 1/3 and the same orphan rate 0.01. The miners don't engage in any form of selfish mining strategies. It's easy to see that under these conditions every miner will build 1/3 of the blocks in the chain, as everybody has the exact same chances.

Now, let's assume that A starts building bigger blocks so that his orphan rate increases to 0.2, while B und C retain their orphan rates of 0.01. To determine the fraction of the blocks (in the chain) built by the respective miners, we can calculate:

A: (0.8*1/3) / (0.8*1/3 + 0.99*1/3 + 0.99*1/3) = 0.288
B and C: (0.99*1/3) / (0.8*1/3 + 0.99*1/3 + 0.99*1/3) = 0.356

And we see that B and C can now build more blocks of the chain than their relative hash rates.
According Peter R's equation (3), their success rate would be 0.99*1/3= 0.33, which is incorrect.

Mining is a relativistic game!

Topic title / Question ?
Answer = NO.

We know this because he has not made it yet.
Although he was quoted saying it would be released in early 2017.

I don't think many of you have seen half his topics by his army of accounts here.
Many of them in the political section..
I think he's fucking nuts.

He favors a lot of conspiracy type theories but does not see them as such.
Take Bitcoin for example, he claims it was made buy a shadowy govt NWO styled group with an agenda.
Which is a key reason why he claims to be making the "Bitcoin Killer"
To over throw these evil dictators destroying us etc.
..using an ICO i predicted he planned on making all along in secret. 

Oh and Boost in BTC core ? really ? yeah that is pretty gay hahahha  

This btc value raise doesn't mean anything, the outcome is still as uncertain as it was when it was below 1000$. It might be a mini pump to make people believe ( especially some btc holders ) things are okay now.
Also this confirms what i told @iamnotback ( about a potential pump & dump war between BU and core after split, etc eth style ), roger ver said he would dump coins on core chain. Obviously after that he will try to pump it in a flippening attempt, something similar to what chandler and shilbert tried with ETC.
https://www.reddit.com/r/Bitcoin/comments/60n50d/roger_ver_confirms_in_case_of_a_split_i_will_sell/

I will get into wall of text mode to give a better picture lol

The thing is originally my background is i got into programming browser component in the start of the 2000, with components based on ATL and NPAPI/XPCOM, with code that had to be portable over two browser interface, which include also the events related to the system windowing, the component model XPCOM/COM with their own interface definition language, and the system to link the IDL interface to javascript binding.

Also related to the idea there is direct show, and it's when i started to understand how microsoft were totally genius with this system, because it allow people to develop new codec and filters, to be integrated into standard filtergraph and being used in any application. Result, microsoft they just do the skeleton for plugin system, and all application based on it can use all the codec and filters programmed for it.

And same goes with activeX style programing, to extend browser functionality.

The catch ? Well it needs completely hardcore type definition to fit with COM, IDL, dll, registry based, with the whole interface to define and instantiate those complex object.

I got my brain totaly smoking on this one for a few year in the 2000's, with this whole mess of defining complex component to be instantiate by blind application, with massive surtyping and all this.

But the real trigger is when i started to program with AS3, flex builder, and android sdk, i started to really see all this component based pattern everywhere, based on XML data definition like flex with eclipse, WSDL kind of programming with flex, it completely made the trigger to me.

I post this to explain the background, and it fit with the github discussion of iamnotback on it, it's completly the problematics my brain have been crunching in the past years, and it's completely in the center of the problematic with distributed application where some component or module can be run on top of the block chain by node that are blind to it's data type.

From there , there is two main path to get to real distributed application, there is the way how i explained a bit before, with some block being marked as being pure data block, replacing the merklle root by the hash of the data, and a system to mark those block like why not with a path system '/application/myapp/mydata' in the block data, and then some option to tell the client which path he want to download, and the other he just need to keep the block header to keep the chain coherent.

After for the data itself, the thing i have in mind and turning around for a while, is to have those block also being able to contain structured data, that are related to module, why not with some kind of OLE like thing based on data type and component implementing interface to deal with them, and then you could have something like a coinbase like input to mark the type of the data, and eventually the parent block for hierarchized data, and then the members of the object as outputs of the transaction.

Like this it would allow to define tree graph like thing on the block chain, with data hierarchy, and runtime defined object, that can be loaded in json like runtime type based on the transaction.

Each member of the object can be changed with a transaction based on the output that define this member.

And then having components module loaded by the node to implement the interface either via rpc or direct http request outputing html5 data, or xml/xslt.

The general idea is this, but there are maybe still caveat, but i'm polishing the plan in my mind

Add to this a little pinch of darpa browser experience science, and it's effectively the eth killer

I doubt you appreciate the significance of what I wrote. So let's explain it in an economic model context:


Diversification is done to lessen gains and also lessen risks of loss. BTC is up 5% and ETH is down 7% (hardly a "crash"), so it worked exactly as planned thus far. I still have some BTC. I still expect ETH to outperform. I'm not a day trader. One day of volatility doesn't matter to me. Even if ETH declines back to $28 - $31, I can't conclude that I will lose in the end. Below that range, I would consider I made a huge mistake.

I also predicted BTC to rise, and called the bottom exactly at $990s in real-time. So once again, my record speaks for itself. I diversified just in case of an outside chance of that BU does something crazy (such as 51% attack BTC).

You are batting for speculative gains between coins (whereas I am just trying to stay level with the average rise of the crypto ecosystem in general) and you are watching your speculations daily like a hawk. I have no time for that sort of activity with my tokens.

Well personally, I looked into bitcore code, and it's far from being ideal to me. For plenty of reason, it's monolithic, not necessarily extremely well architectured, heavy memory foot print etc.

I already have 80% of working block chain client with my framework, in 100% C with zero deps & using 30mo of ram.

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