Do you think "iamnotback" really has the" Bitcoin killer"?

[iamnotback]

Re: What cryptocurrency is solving the scaling problem?

your beloved "domains, and dapps" will come to Bitcoin in summer 2017 via Rootstock.

Sidechains are insolubly insecure and can never work. @ArticMine and I debated it a month ago.

How likely is it that Bitcoin will be overtaken in the event of a contentious hard fork? I think this is an example of things to come. Bitcoin will be attacked through its mining, the network, legally, and every other possible way. If you don't think Bitcoin is going to be attacked, you've misunderstood what this is about. You don't go and poke a $20 trillion industry and go, "Hey, we're going to disrupt you!" You can't just wait for it to roll over. This is offensive to a lot of governments, rich institutions, and a lot of people who don't want to see Bitcoin succeed. If a fork happens, we get to learn what happens when a fork attack occurs. Anyone who thinks a fork will be unopposed is quickly going to discover that this will be a battle on all fronts. Inevitably the two sides are going to attack each other on the network, with denial-of-service attacks, with hash rate; they're going to attack each other publicly, privately, anonymously and not. Every bug in the software will get poked and poked again, so they better fix them well. The battle becomes "who has the best software development team? How quickly can they maintain that code and keep uptime?" That race is only 7 blocks wide. I don't think the people who are threatening to do a hard fork have thought clearly about the implications. This will allow Bitcoin to test all the attack vectors (nodes, relays, hashing, replay transactions, etc). And the result will be a Bitcoin that's battle-hardened, because it will have survived a fork attack and we will better understand what happens under such highly contentious conditions. It's very important to not mistake smooth sailing for good sailors. If any altcoin somehow overtakes bitcoin and gets to this scale, they will have to deal with the same scaling and governance controversies. Many of them will end up centralised or with failures in architecture. These are the rites of passage; you first have to grow up to face them. How many of the other blockchains are preparing for this? Not many, because they aren't paying attention. This is a fantastic experiment but it's not easy. This is a game with $20 billion at stake.

Bitcoin is already centralized by exchanges, they're the ones steering the market

That is an important point.

Re: What cryptocurrency is solving the scaling problem?

I've always wondered this about certain coins. For example, I pretty much never see congestion on DOGE, LTC, and ETH/ETC. Is it a function of being underused, or have they actually solved the traffic issue?

Most of those coins never leave the exchanges.

In other words, they have no adoption use case at all. They can be destroyed overnight by an attack on exchanges (by an inside attack, hacker, or regulatory crackdown such as from the SEC for those which sold ICOs).

[1715644911]

1715644911

[iamnotback]

@ladixDev, we seem to have a misunderstanding about separation-of-concerns.

Unless you need smart contracting, the blockchain's only function is to order (cryptographic hashes of) events unambiguously, i.e. with a consensus as to the ordering.

Bitcoin has a rudimentary scripting system for multisig and other things that can be done with the opcodes.

Are you claiming you need to run smart contracts on the blockchain? What specific need for smart contracts do you have in a music app?

As for servers for the music content, aren't they orthogonal to the blockchain?

Which scripting features do you need on the blockchain for your music app?

It's not necessarily for smart contract, but script language to program the blockchain node itself, the block validation logic, Event handling of network message, blockchain request, tx signatures, and the distributed applications itself, mostly the UI with html5 / js template, with a js modules for in browser crypto, and some module call via http/rpc/json to do the heavy work related to blockchain request or heavy computation.

Afaics, the UI has nothing to do with the blockchain layer.

You need callback events from state changes on the blockchain to the music server? Thus you need smart contracts?

Server for music content are not completely independent from blockchain, they need to check permission access to the media , and also involved with reward for content storing/distribution.

That program running on the music servers is orthogonal to the blockchain running on blockchain nodes. You access the blockchain via standardized blockchain protocol/API to access the state on the blockchain. From the blockchain's perspective, the permission state is just an agnostic blob of data. Your application parses that blob of data as it wishes to.

You can publish your data formats if you want other apps to interopt with your blockchain state. (Or some apps might reverse engineer them)

The only time we need scripting (or smart contracts) is when your use case requires the blockchain to check some invariants on state transitions. Do you have any such requirements?

[IadixDev]

Afaics, the UI has nothing to do with the blockchain layer.

It does because the UI has to manipulate addresses, and sign transaction, and check balances etc

[IadixDev]

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.

[iamnotback]

Afaics, the UI has nothing to do with the blockchain layer.

It does because the UI has to manipulate addresses, and sign transaction, and check balances etc

But that is done through a protocol/API. The UI is a separation-of-concerns. Specifically we don't need to conflate UI logic and data formats with the blockchain layer. The blockchain is agnostic. You just interface with the blockchain through a standard protocol.

[IadixDev]

Afaics, the UI has nothing to do with the blockchain layer.

It does because the UI has to manipulate addresses, and sign transaction, and check balances etc

But that is done through a protocol/API. The UI is a separation-of-concerns. Specifically we don't need to conflate UI logic and data formats with the blockchain layer. The blockchain is agnostic. You just interface with the blockchain through a standard protocol.

So it needs some form of accounting and higher level définition of transaction based on the accounting layer or something like this to completely abstract it away from the blockchain layer.

[the_weegie]

I have the name:

Shelbux (BUX)

You're welcome 

[iamnotback]

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 even my primary job.

[iamnotback]

I have the name:

Shelbux (BUX)

You're welcome  

Shelbollocks.

[the_weegie]

I have the name:

Shelbux (BUX)

You're welcome  

Shelbollocks.

Touché 

[IadixDev]

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.

[iamnotback]

I have the name:

Shelbux (BUX)

You're welcome  

Shelbollocks.

Touché 

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.

[iamnotback]

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.

[IadixDev]

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 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.

[mining1]

Ok, stop stroking your micropenis and get back to work. We could use a new toy to speculate on.

[IadixDev]

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 ? ? 

[iamnotback]

If it need to send a transaction, it's hard to avoid the blockchain layer 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.

[IadixDev]

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.

[iamnotback]

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.

[IadixDev]

Most of the blockchain protocol is about transaction 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

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.