Other Observations
VirtaCoin addresses are similar to Bitcoin addresses and can be used to send and receive
Bitcoins as well, though it is to be noted that bitcoin blockchain is enitrely different and
needs to be in reach of the wallet software in order to use such feature. One can also send
VirtaCoins to a Bitcoin address and Bitcoins to a VirtaCoin address, if they have both of
the two blockchains stored in their PC. A single VirtaCoin or Bitcoin address can as well be
used to separately manage balances of both cryptocurrencies. VirtaCoin is the first and only
scrypt-based coin to do all this. Here is an example of a VirtaCoin address:
1PZiaTusAqZtiyfxUSUUUnzZSXzfAzTE1Y
It can be seen that the address also starts with a "1", just like most Bitcoin addresses.
VirtaCoins can be sent to Bitcoin addresses that begin with a "3" such those provided by
BitGo and GreenAddress and generated by CryptoLife's Universal Address Generator.
"3" Bitcoin addresses are mostly used in multi-signature wallets and can be used to send
Bitcoins to VirtaCoin addresses as well. You will need to know the private key of your
VirtaCoin or Bitcoin address to be able to view and manage the opposite balance of the
wallet that originally created the address, meaning for a VirtaCoin address created with
VirtaCoin Core you'll need the private key in order to see any bitcoins sent to that
VirtaCoin address in a Bitcoin wallet. Exchanges and some online wallet providers don't
normally provide you with the private keys of your VirtaCoin or Bitcoin address so its
best to use addresses created from wallets that you have total control of, such as desktop or
mobile wallets. Desktop wallets such as VirtaCoin Core, MultiBit and others available at
https://bitcoin.org/en/choose-your-wallet can be used to export the private keys to a file
on your computer. Mobile apps such as Bitcoin Paper Wallet and the online Bitcoin
Wallet Generator at BitAddress.org can generate addresses with private keys.
To use VirtaCoin address as a Bitcoin address in a Bitcoin wallet simply import the
private key of your VirtaCoin address into the wallet. The popular Blockchain Wallet
works very well with your VirtaCoin address and so does MasterCoin's Omniwallet.
With both these wallet you can import your private key with ease and manage any bitcoins
sent to your address. When you import only your private key your correct
VirtaCoin/Bitcoin address (public key) will be revealed in your list of addresses. Once
you have received or sent bitcoins you should be able to view any transaction done with
your VirtaCoin address as well as your BTC balance on the Bitcoin Network using block
explorers such as Blockchain, CoinPrism or Blockr.
At the moment there isn't a way of directly viewing and managing the VirtaCoins sent to a
"3" bitcoin address. However if you generate a "3" Bitcoin address using CryptoLife and
then import the private keys into a Blockchain Wallet it will reveal a "1" Bitcoin address.
That "1" Bitcoin address is associated with the "3" Bitcoin address you generated with
CrytoLife, meaning they have the same private key and "Hash 160" identifier and can now
be used as a VirtaCoin address. The "Hash 160" identifier is shown in Blockchain's Block
Explorer whenever you try searching it for an address. If you search for your "3" address
and you click on the "Hash 160" link you'll see the same "1" address that you first saw
when importing the private key. To use your Bitcoin address as a VirtaCoin address you can
import the private key of your Bitcoin address into the VirtaCoin Core wallet. Please
remember to backup your wallet before importing another address into VirtaCoin Core.
Conclusion
Upon validation of our design in the Market, we expect proof-of-work designs to become
a potentially more competitive form of peer-to-peer crypto-currency due to the more
evenly de-centralised distribution resisting 51% vulnerability, also 1000 times more number
of coins than bitcoin can ever generate assumes more availabilty for investment and more
secure wealth management offering for investors (21 million max. vs 21 billion max.)
thereby achieving lower inflation/lower transaction fees at comparable network security
levels.
https://www.virtacoin.online/vtapaper.pdf
Topic: How to build a virtual blockchain on top of a Bitcoin blockchain (Read 615 times)
November 23, 2020, 04:45:23 AM
Basically you're describing off-chain/side-chain protocol. There are many implementation such as Liquid Network, RSK and Omni Layer.
November 22, 2020, 03:58:02 PM
Have you heard of sidechains?
November 22, 2020, 08:46:21 AM
We probably agree that all public DLTs need an incentive to verify transactions, and now I mean all transactions (even smart contracts that don't convert cryptocurrencies). So is there or can there be a public DLT that has no native token of its own to provide this incentive? I might ask even better: is it theoretically possible to have a DLT for smart contracts (such as Ethereum) and pay for transaction verification not with gas, but with a token from a completely different DLT? Like Bitcoin?
This approach sounds interesting. Did you perform any tests on it?
I always considered it to be a good thing to have the verification incentive and the ledger defined by the same protocol because it will then be simpler to verify and analyze the whole process. On the other hand I would consider it to be possibly very insightful for the theoretical analysis of both self-contained and externally-incentivized ledgers if someone had a working and robust example of the latter approach running.
We probably agree that all public DLTs need an incentive to verify transactions, and now I mean all transactions (even smart contracts that don't convert cryptocurrencies). So is there or can there be a public DLT that has no native token of its own to provide this incentive? I might ask even better: is it theoretically possible to have a DLT for smart contracts (such as Ethereum) and pay for transaction verification not with gas, but with a token from a completely different DLT? Like Bitcoin?
The reason for this would be quite simple: a new token would not have to be introduced, which would have to build trust from the very beginning (as with the ICO). I realize that transaction verifiers will always have to have an incentive to authenticate.
A cryptonetwork without a token, say X, could do some above-standard over Bitcoin, but we wouldn't want to make an X-coin to serve as a reward for verifiers, because then the project of cryptonetwork X would have to be big enough for the exchanges to notice. would introduce the X-coin / Bitcoin exchange pair. So we have a hypothetical DLT named X. Therefore, we introduce that some hypothetical transaction verifier on X be paid in Bitcoins.
Let's look at it specifically. I am "A". "A" sends a transaction to X's ledger to "B" in the form of a smart contract that Bitcoin does not understand. In order for a transaction to be written to the ledger, it must be verified. But the verifier does not want any X-coin, because he would have a problem with its exchangeability at the beginning of the operation. So what happens?
Let's make X an extension of Bitcoin. The very original idea was that X’s miner would be paid for in an already established token. This is a fundamentally different scenario than we see today, when new miners do not get too involved in a new project because they carry a relatively high risk. Suddenly they will knock so they can verify for the new X.
Because X has a protocol that Bitcoin does not understand, you need to have new authenticators (I thought so, but it's not true, read on). They will be motivated by paying for an already established cryptocurrency. This means that the new DLT network named X will benefit from the established trust in Bitcoin. Using cryptographic logic gates (such as those used in the construction of the Lightning Network), two DLTs can be combined (as we have seen, for example, in Atomic Exchanges).
A small number of verifiers for X, but a large one for Bitcoin, would not be a problem at all. I can imagine miners selling themselves to any DLT if they are paid out in Bitcoin. But I would still mind that I had to have two miners: a miner who would process the payout in Bitcoins to another miner on X. That sounds inefficient. But let's put that aside for now.
The introduction of new DLTs in the normal way is in principle similar to forking - a disproportionately unfavorable introduction of completely new DLTs. I understand the principle of the market, the tokens of only those DLTs that make sense will be retained, on the other hand, I do not think that this results in meaningless and continuous creation of more and more tokens.
The difference between X and forking or the classic introduction of the new DLT is abysmal: forking makes incompatible miners and shrinks the network. The introduction of a completely new DLT is again extremely risky. Therefore, here is a solution in the form of X. Recall that the reason for all this is the fact that Bitcoin cannot do some advanced operations because it does not have them logged. Because of this, the verifier does not know when to come into contact with an advanced transaction what to do and whether everyone else understands the same.
In practice, everything would be roughly done by the sender of the transaction paying the verifier X in Bitcoins, so the Bitcoin transaction will obviously contain some all-encompassing ID. A bitcoin transaction is completed only if the verifier for X publishes a new transaction in X's DLT, otherwise it could happen to verify it and get Bitcoins, but it will no longer appear on the blockchain (which is captured in the classic model, because I can not deny to a blockchain transaction and get a mining reward).
If we start to examine the added value of the verifier for X, we will simplify the whole thing. The X authenticator function can be performed by the X user himself and the transaction initiator
.
Central to this is evidence that the transaction ID in X appears on the Bitcoin blockchain. The initiator pays for this - he does not pay for the fact that he can pay, but he pays for it to solve the problem of complete disclosure or the problem of Byzantine generals, if you will. So, for example, I take a transaction for X and incorporate its ID into a Bitcoin transaction. The consensus will then be that if the shading Bitcoin transaction is in the Bitcoin blockchain before any conflicting one, then it is right. Cryptonetwork X then does not have to have its own native token. The conflict within X would be resolved according to the protocol.
Cryptonetwork thus only serves as a platform for public encryption keys aliases. Bitcoin's protocol will solve most potential problems, because it's actually enough to follow the Bitcoin blockchain where we integrated our X. If someone has a faulty transaction, it will be accepted in Bitcoin, but X users will ignore it. Of course, splits can occur in this virtual blockchain too.
The beauty is that even if you are the only user of your protocol, it will not compromise the security of your transaction at all. Imagine having the entire production process interwoven with smart contracts, electronic authentication and private key control (even if it would be damn expensive). Naturally, machines in the production process will also be able to create transactions because they have their own wallet. Machine-to-machine communication with the benefits of DLT would be implemented so that your machines understand your protocol. Sometime in the future, Bitcoin would function as a gigantic platform, where you pay for the amount of information included in the transaction (which is already partly true now).
Transactions X would no longer operate with the currency. The only API would be to interpret the Bitcoin blockchain into the X protocol language. Bitcoin would have only two functions - to put something into a public distributed database and reward the one who did it. No other things besides the P2PKH script would theoretically be needed.
If the new X were to manage ownership of the assets, I would still be able to do without a native token. This is because the asset (similar to the example above) will be interpreted by the Bitcoin blockchain and can track its own history of owners entered in the form of an account pair private-public key alias address.
With X you can make a corporate DLT (more than one blockchain), a completely private DLT or a fully permissionless DLT. All superstructure complexity is recorded in protocol X. Protocol X must be robust. Note that elementary objects (addresses) do not have to interact directly at all, as they interact virtually with each other.
So in the end, we went from complexity to total simplicity. It is possible that I overlooked something completely fundamental and it is completely useless, but not at all. Or something like that has been working for a long time. Please let me know. Thank you.
The reason for this would be quite simple: a new token would not have to be introduced, which would have to build trust from the very beginning (as with the ICO). I realize that transaction verifiers will always have to have an incentive to authenticate.
A cryptonetwork without a token, say X, could do some above-standard over Bitcoin, but we wouldn't want to make an X-coin to serve as a reward for verifiers, because then the project of cryptonetwork X would have to be big enough for the exchanges to notice. would introduce the X-coin / Bitcoin exchange pair. So we have a hypothetical DLT named X. Therefore, we introduce that some hypothetical transaction verifier on X be paid in Bitcoins.
Let's look at it specifically. I am "A". "A" sends a transaction to X's ledger to "B" in the form of a smart contract that Bitcoin does not understand. In order for a transaction to be written to the ledger, it must be verified. But the verifier does not want any X-coin, because he would have a problem with its exchangeability at the beginning of the operation. So what happens?
Let's make X an extension of Bitcoin. The very original idea was that X’s miner would be paid for in an already established token. This is a fundamentally different scenario than we see today, when new miners do not get too involved in a new project because they carry a relatively high risk. Suddenly they will knock so they can verify for the new X.
Because X has a protocol that Bitcoin does not understand, you need to have new authenticators (I thought so, but it's not true, read on). They will be motivated by paying for an already established cryptocurrency. This means that the new DLT network named X will benefit from the established trust in Bitcoin. Using cryptographic logic gates (such as those used in the construction of the Lightning Network), two DLTs can be combined (as we have seen, for example, in Atomic Exchanges).
A small number of verifiers for X, but a large one for Bitcoin, would not be a problem at all. I can imagine miners selling themselves to any DLT if they are paid out in Bitcoin. But I would still mind that I had to have two miners: a miner who would process the payout in Bitcoins to another miner on X. That sounds inefficient. But let's put that aside for now.
The introduction of new DLTs in the normal way is in principle similar to forking - a disproportionately unfavorable introduction of completely new DLTs. I understand the principle of the market, the tokens of only those DLTs that make sense will be retained, on the other hand, I do not think that this results in meaningless and continuous creation of more and more tokens.
The difference between X and forking or the classic introduction of the new DLT is abysmal: forking makes incompatible miners and shrinks the network. The introduction of a completely new DLT is again extremely risky. Therefore, here is a solution in the form of X. Recall that the reason for all this is the fact that Bitcoin cannot do some advanced operations because it does not have them logged. Because of this, the verifier does not know when to come into contact with an advanced transaction what to do and whether everyone else understands the same.
In practice, everything would be roughly done by the sender of the transaction paying the verifier X in Bitcoins, so the Bitcoin transaction will obviously contain some all-encompassing ID. A bitcoin transaction is completed only if the verifier for X publishes a new transaction in X's DLT, otherwise it could happen to verify it and get Bitcoins, but it will no longer appear on the blockchain (which is captured in the classic model, because I can not deny to a blockchain transaction and get a mining reward).
If we start to examine the added value of the verifier for X, we will simplify the whole thing. The X authenticator function can be performed by the X user himself and the transaction initiator
.Central to this is evidence that the transaction ID in X appears on the Bitcoin blockchain. The initiator pays for this - he does not pay for the fact that he can pay, but he pays for it to solve the problem of complete disclosure or the problem of Byzantine generals, if you will. So, for example, I take a transaction for X and incorporate its ID into a Bitcoin transaction. The consensus will then be that if the shading Bitcoin transaction is in the Bitcoin blockchain before any conflicting one, then it is right. Cryptonetwork X then does not have to have its own native token. The conflict within X would be resolved according to the protocol.
Cryptonetwork thus only serves as a platform for public encryption keys aliases. Bitcoin's protocol will solve most potential problems, because it's actually enough to follow the Bitcoin blockchain where we integrated our X. If someone has a faulty transaction, it will be accepted in Bitcoin, but X users will ignore it. Of course, splits can occur in this virtual blockchain too.
The beauty is that even if you are the only user of your protocol, it will not compromise the security of your transaction at all. Imagine having the entire production process interwoven with smart contracts, electronic authentication and private key control (even if it would be damn expensive). Naturally, machines in the production process will also be able to create transactions because they have their own wallet. Machine-to-machine communication with the benefits of DLT would be implemented so that your machines understand your protocol. Sometime in the future, Bitcoin would function as a gigantic platform, where you pay for the amount of information included in the transaction (which is already partly true now).
Transactions X would no longer operate with the currency. The only API would be to interpret the Bitcoin blockchain into the X protocol language. Bitcoin would have only two functions - to put something into a public distributed database and reward the one who did it. No other things besides the P2PKH script would theoretically be needed.
If the new X were to manage ownership of the assets, I would still be able to do without a native token. This is because the asset (similar to the example above) will be interpreted by the Bitcoin blockchain and can track its own history of owners entered in the form of an account pair private-public key alias address.
With X you can make a corporate DLT (more than one blockchain), a completely private DLT or a fully permissionless DLT. All superstructure complexity is recorded in protocol X. Protocol X must be robust. Note that elementary objects (addresses) do not have to interact directly at all, as they interact virtually with each other.
So in the end, we went from complexity to total simplicity. It is possible that I overlooked something completely fundamental and it is completely useless, but not at all. Or something like that has been working for a long time. Please let me know. Thank you.
Jump to: