Pages:
Author

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

full member
Activity: 322
Merit: 151
They're tactical
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Wink

Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two.


Anyway with js the best you can have is illusion of non spaghetti code, because it's not like js really support object polymorphism, or anything.

The node.js packaging can give the impression of design pattern, but it's mostly intentional.

Can always have definition of module/interface hierarchy for js ui app, but to me it just look like decoration.

It's has to understand the node-> module->method pattern but that's all. Node are the http layer, module can be abstracted with a js class with rpc calls, but anything more evolved is not possible in js.

As far as i know for js, all classes and functions are the same type, so it's hard to have good design pattern.

The application can just rely on naming convention and assume the type from there, it's the best you can do with js.

Which is how you end up using variable name as if it was the type name of a static class, but it's just variable naming convention there is no real "type class". The name correspond to an instance of unique class defined with the inline synthax, but it's not the the type name of a static class, it has no intrinsic meaning for the js engine. ( big difference for design pattern ^^).

With enough semantic confusion it can look like design pattern, but the js engine cant do any real type checking of anything.

JS programmers are used to this, even if I find this disturbing can give it the merit that it works and the synthax is intuitive for OO programmers, but in reality it's still very weak .

It's very hard to have true multi layered pattern with js.

You can only have one true layer of abstraction.

If a js class method is used as call back and has to use different class depending on returned data type, hard to make in sort the second class is fully aware of the calling context, you can only be sure of the type at one level, because of lack of true explicit typing, even giving the instance of the caller class cant give it's type to the callee, the method can only assume the "this" type from the naming convention of the caller code. The synthax is cute & all but it's very easy to mess up with multi layered code. In the end it can only be close to spaghetti :p

The design pattern has to be pretty flat or it will always end up messy with js.

To me all class/modules need to be on the same level using the static class like variable naming convention of js. Each module interface  is implemented as inline class instance with a specific global name, and modules call are made throught call to this object methods, callback being mostly hard coded into the object definition for a specific UI. Most of the time it's simpler to let application initiliaze the object-module instance with the parameters it can customize for it needs, and let the js object handle the call back internally.

The js application need to have these module / class definition, and a node to connect to who host these modules, and then it can distribute the request on these node for the different interactions with the UI, using call to the named objects methods .

But it's not hard to see how a better language can be thought of Smiley
full member
Activity: 322
Merit: 151
They're tactical
@ladixDev, let's stop talking and instead produce some specifications.

The specification needs the part on script language, the part on blockchain protocol, and application api, both for blockchain and non blockchain functions.
sr. member
Activity: 336
Merit: 265
@ladixDev, let's stop talking and instead produce some specifications.
full member
Activity: 322
Merit: 151
They're tactical
You appear to be doing premature optimization, which as you know is an incorrect methodology in software design.

No no, i  dont try to specially optimize for the moment, just keep performance enough for use. But for multimédia and interactive application, it need to be kept minimum optimized. The threshold of minimum useability require good code for interactive multi media app, I want to integrate vectorial computing and 3d too. And I already have gone through cycle of developpement for different part of the framework, even still not really in optimization phase.
full member
Activity: 322
Merit: 151
They're tactical
sr. member
Activity: 336
Merit: 265
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Wink

Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two.

That is just correct software design.

Let's dig into the API specifics on our new forum.

Data formats should have specifications.

As we dig into specifications, then we will understand each other.

The node module hierarchy is not visible from ui/app side, so it mean in theory the UI can plug at any level of the node api, down to the binary data level to high level functions in other modules. The only simple way to force the app api to a particular level is to only expose the module at highest level (that no other modules depend on ), but the application can have to go down to protocol level, to make block explorer for example, not sure it's good to force the abstraction layer too high, specially if different blockchain need to be handled by the application.

It is not going to help you to marry your design to a blockchain design when you are trying to interface with a "blockchain" which doesn't have blocks.

And you want scaling don't you.

You appear to be doing premature optimization, which as you know is an incorrect software design methodology.
full member
Activity: 322
Merit: 151
They're tactical
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Wink

Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two.

That is just correct software design.

Let's dig into the API specifics on our new forum.

Data formats should have specifications.

As we dig into specifications, then we will understand each other.

The node module hierarchy is not visible from ui/app side, so it mean in theory the UI can plug at any level of the node api, down to the binary data level to high level functions in other modules. Internally there is a dependency hierachy ( visual studio seem to struggle a bit with multithread compilation Shocked), a way to force the app api to a particular level is to only expose the module at highest level (that no other modules depend on ), but the application can have to go down to protocol level, to make block explorer for example, not sure it's good to force the abstraction layer too high, specially if different blockchain need to be handled by the application. And the ui/application doesnt necessarily have to know all the node modules hierarchy and the different level of the api, it can just pick the api from any module interface, depending on how it helps the application to do what it has to do.
sr. member
Activity: 336
Merit: 265
Quote from: anonymous
Quote from: anonymous
...risks you losing competitive edge to a project which does have a team and funding. I hope to see you succeed will keep an eye out. Thanks for your time.

It is a risk which is why I will not open source the code until the user adoption has reached minimum critical mass.

Ahh.. thats tough.. bitbay did that but its worthless because noone can audit the work.. it doesnt catch on because you have to trust the developer that its bug free.. for me id look at unit tests thats the first thing i look at to see quality of work..

That is a very good point. Unit tests (that anyone can run) can convince the market that the blockchain is solid.
sr. member
Activity: 336
Merit: 265
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Wink

Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two.

That is just correct software design.

Let's dig into the API specifics on our new forum.

Data formats should have specifications.

As we dig into specifications, then we will understand each other.
sr. member
Activity: 336
Merit: 265
That is why we can kick ass versus Bitcoin in terms of onboarding, because we can offer dozens of apps which interest users in different ways and then the buzz will spread that all these apps are based on the BitNet: a new form of Internet that even powers mobile apps. We're building a new high-level, decentralized protocol for the Internet.

Hollywool-over-their-eyes (aka Hollywhores) is making a movie about us, but note the projector slide in the background is an Ethereum roadmap; which exemplifies that the whales behind ETH are very well connected with the mafia media aka USG.MIT.

The DAO attacker is a Bitcoin $billionaire and he (and @r0ach) claim that Ethereum is backed by an R3 consortium of banksters who also have connections with the USA govt DEEP STATE and the DEEP STATE's academic institutions such as MIT, Cornell, etc..

My stance on this is that it appears to be true that Ethereum's backers are able to pull strings at the United Nations, and mass media. I am not invested in Ethereum long-term. I don't believe in it as a long-term viable project. I invested as a diversification, in case that corrupt group that backs Ethereum is able to succeed.

I believe TPTB in our world planted Bitcoin as Nash Ideal Money virus to help bring about their NWO with a world central bank. I think they also helped created Ethereum through one of the factions of their network of control, for several reasons:

1. To provide a playground for the fools so they can separate them from their money.
2. To stress test challenges to Bitcoin.
3. To stress test other sub-blockchains or networks that could be master controlled by settlement to the Bitcoin chain in the future.

My view is that both Bitcoin and Ethereum are corrupt shit. And I intend to challenge those. But until I do, I am diversified currently with some holdings of both BTC and ETH (in addition to some minor holdings of a couple other very speculative altcoins).

That doesn't necessarily mean that Vitalik or Gmaxwell are corrupt. I really don't know those guys well. Those devs aren't the whales who are controlling those blockchains.

Conjecture on what lies ahead:

I don't know what happens now. Perhaps fireworks. MPeX promised to wreck havoc if ever miners attempt to create 20 MB blocks. I don't know if he still thinks he can keep that threat.

If you have any evidence that MP is anything but a bloviating paper tiger, I'd be interested to see it.

MP tends to pop up from time to time, promising to annihilate anyone who does X. Then X occurs, and no ill effects are unleashed upon the perpetrator of X.

So which is the lie? Is the claim if heartlessness and irregard for 'lesser humans' a lie? Or is the claim of power a lie?

He was the $150 million DAO hacker. He is the central public spokesman of the The Most Serene Republic (TMSR). He had or has a million+ bitcoins ($1+ billion) and he sold 250,000 of them after Aug 2016. He claims he ended Hillary Clinton's election on July 16, 2016 when a hack reveal she intended to attack the TMSR. These and more James Bond intrigue are documented upthread.

Is MP the foul-mouthed, sperm whale, Socrates version of 007?  Undecided



Quote from: anonymous
I don't believe that. Usually the simplest explanation is also corect. Now, i believe that these institutions / corporations may try to influence EF to steer the project to fit their own needs, but that's all.

That's also a possibility, but ICOs are very easy to manipulate, you just buy your token from yourself with borrowed BTC (then pay back the BTC to the lender) so you own most the tokens at $0 cost.

Quote from: anonymous
The same about bitcoin, yes a power war is the likely scenario. But you're probably overestimating them. It is not likely for any of these sides to risk their wealth to win this war, aka to go into a fork war and dump & buy the other chain. Too risky. The common thing that links everyone in this space is arguably greed. Nobody will risk wealth out of principles.

That is @dinofelis' stance and I have been leaning towards it lately as I have stated publicly.
full member
Activity: 322
Merit: 151
They're tactical
Most of the blockchain protocol is about transaction Smiley the UI doesnt have to know about the block emission, but lot of the blockchain protocol is about messages to advertize new block and transaction. The UI has to understand about the transaction format which is part of the blockchain protocol, as well potentially of the bitcore engine opcodes to be complete. But the UI doesnt have to know the opcodes to serialize the tx to an hash and sign it, but at least parse the input & output and the addresses involved.

Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Wink

With default behavior and Event handling for generic node of a particular blockchain with only coins related functions, to emulate the functioning of classic full nodes without application modules, and new functions added to the api via modules and/or scripts.
sr. member
Activity: 336
Merit: 265
If the app has to make transaction, it has to manipulate at least addresses, and to be secure, at least also private key and transaction hash. If the app trust the node producing the tx hashes to sign, otherwise it need a way to display the tx , and compute it's hash in the UI. The tx itself can be built in the node based on its local wallet infos, and send the tx hashes to the UI to sign.

I know all these things. We'll do the correct protocol design, and we don't need to conflate layers.

Of course for standard data formats such as transaction signing and value transfer data, the application and blockchain share the same understanding of those.
full member
Activity: 322
Merit: 151
They're tactical
If the app has to make transaction, it has to manipulate at least addresses, and to be secure, at least also private key and transaction hash. If the app trust the node producing the tx hashes to sign, otherwise it need a way to display the tx , and compute it's hash in the UI. The tx itself can be built in the node based on its local wallet infos, and send the tx hash to the UI to sign.

But it seem hard to keep the system secure keeping the blockchain protocol out of the application layer, or it need a middle layer to manage some from of accounting that can be checked by all nodes on the network. And the app sign transaction using this format, and some middle layer turn it to a blockchain tx.
sr. member
Activity: 336
Merit: 265
If it need to send a transaction, it's hard to avoid the blockchain layer Smiley Especially if they have to be signed in the browser, which is important for security. And keeping private data private. Aka private key never have to leave the UI in clear form.


But in the idea Yes it's script to program this sort of application logic.

But I think with a bit of intelligence most of the complexity of smart contract can be avoided with simple code with a good scripting engine to handle this kind of problematics.

Afaics all that can be done with separation-of-concerns layers interfacing through a standard protocol.

Any way, we'll spec out the protocol and API and then we'll know if there are any issues.

So your main question was whether I can provide you a blockchain API which can meet your needs and soon enough. That is a very good question and I don't have a definitive answer yet on the timing. But I need to be able to give you an ETA asap because you have to do planning also.

But I don't think you need to worry about which programming language I use for the blockchain code. Well I guess you can worry from the standpoint that you need to trust that it is robust. But you will interact through a protocol layer that is language agnostic.

We need to get into specifics asap. Let me get the forum up.
full member
Activity: 322
Merit: 151
They're tactical
Ok, stop stroking your micropenis and get back to work. We could use a new toy to speculate on.

You want to speculate on this ? ?  Shocked Shocked
hero member
Activity: 532
Merit: 500
Ok, stop stroking your micropenis and get back to work. We could use a new toy to speculate on.
full member
Activity: 322
Merit: 151
They're tactical
You need callback events from state changes on the blockchain to the music server? Thus you need smart contracts?

The music server need to be able to check chain state, either it's by monitoring Event or polling the state from a node when it needs it

I guess you can call this a smart contract, but the way it's done it's more like ready only function in the music server, it doesnt have to sign anything or emit new blocks. Just check the access and earn a reward. The reward is signed by content owner from another node when the stream is verfied by the player app.

For the moment as i said the design is still partially centralized.

Well it doesn't need the full power of a scripting language if we have a standardized protocol for setting a callback event on blockchain state transitions. We'd rather not conflate the payment transaction with the event callback.

In fact, the nodes which provide callback services are orthogonal to the main blockchain protocol and can be offered by the free market. It isn't my job.

Ideally The blockchain state transition are also related to the delivery of the content, and there is a séquence of events involved between different nodes in triangle between music producer (content owner sign reward to distribution, fix distribution condition), distribution  ( content server, check distribution condition, send content, get reward from producer), and customer ( html5 app sign tx to content owner, get the content from distributer).

Customer clicks button. App sends transaction to the blockchain for payment and sets an asynchronous callback event for confirmation of the transaction with a callback service provider node. Callback code releases download to the customer and sends a transaction to the blockchain for updating the downloaded count.

Its all standard APIs. No need to conflate the blockchain and the application layers.

If it need to send a transaction, it's hard to avoid the blockchain layer Smiley Especially if they have to be signed in the browser, which is important for security. And keeping private data private. Aka private key never have to leave the UI in clear form.


But in the idea Yes it's script to program this sort of application logic.

But I think with a bit of intelligence most of the complexity of smart contract can be avoided with simple code with a good scripting engine to handle this kind of problematics.
sr. member
Activity: 336
Merit: 265
You need callback events from state changes on the blockchain to the music server? Thus you need smart contracts?

The music server need to be able to check chain state, either it's by monitoring Event or polling the state from a node when it needs it

I guess you can call this a smart contract, but the way it's done it's more like ready only function in the music server, it doesnt have to sign anything or emit new blocks. Just check the access and earn a reward. The reward is signed by content owner from another node when the stream is verfied by the player app.

For the moment as i said the design is still partially centralized.

Well it doesn't need the full power of a scripting language if we have a standardized protocol for setting a callback event on blockchain state transitions. We'd rather not conflate the payment transaction with the event callback.

In fact, the nodes which provide callback services are orthogonal to the main blockchain protocol and can be offered by the free market. It isn't my job.

Ideally The blockchain state transition are also related to the delivery of the content, and there is a séquence of events involved between different nodes in triangle between music producer (content owner sign reward to distribution, fix distribution condition), distribution  ( content server, check distribution condition, send content, get reward from producer), and customer ( html5 app sign tx to content owner, get the content from distributer).

Customer clicks button. App sends transaction to the blockchain for payment and sets an asynchronous callback event for confirmation of the transaction with a callback service provider node. Callback code releases download to the customer and sends a transaction to the blockchain for updating the downloaded count.

Its all standard APIs. No need to conflate the blockchain and the application layers.
sr. member
Activity: 336
Merit: 265

I rather fancy that term as a compliment to describe my walls of text. Please freel free to employ that colloquialism liberally throughout the forum when the uppitytunity strikes.
full member
Activity: 322
Merit: 151
They're tactical
You need callback events from state changes on the blockchain to the music server? Thus you need smart contracts?

The music server need to be able to check chain state, either it's by monitoring Event or polling the state from a node when it needs it

I guess you can call this a smart contract, but the way it's done it's more like ready only function in the music server, it doesnt have to sign anything or emit new blocks. Just check the access and earn a reward. The reward is signed by content owner from another node when the stream is verfied by the player app.

For the moment as i said the design is still partially centralized.

Well it doesn't need the full power of a scripting language if we have a standardized protocol for setting a callback event on blockchain state transitions. We'd rather not conflate the payment transaction with the event callback.

In fact, the nodes which provide callback services are orthogonal to the main blockchain protocol and can be offered by the free market. It isn't my job.

Ideally The blockchain state transition are also related to the delivery of the content, and there is a séquence of events involved between different nodes in triangle between music producer (content owner sign reward to distribution, fix distribution condition), distribution  ( content server, check distribution condition, send content, get reward from producer), and customer ( html5 app sign tx to content owner, get the content from distributer).

But the music server in the idea he is still the bitch of the system, he has no decision in the blockchain, it just has to check the client is ok with the content owner and deliver the content for probably cheap reward. It doesnt need to hold private keys or anything, specially if it store crypted files that can be de crypted by the html5 app from interaction with content owner.

But any case it has to work with a triangle.
Pages:
Jump to: