o no ...
here we go with the 'classic' trend ...
sheesh! ...
#crysx
Not sure you noticed, but a few pages back I announced an SPR fork, SpreadClassic.
New ANN being prepared as we type.
Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 87. (Read 790417 times)
November 16, 2016, 04:54:06 AM
o no ...
here we go with the 'classic' trend ...
sheesh! ...
#crysx
Not sure you noticed, but a few pages back I announced an SPR fork, SpreadClassic.
New ANN being prepared as we type.
November 16, 2016, 04:42:04 AM
o no ...
here we go with the 'classic' trend ...
sheesh! ...
#crysx
Not sure you noticed, but a few pages back I announced an SPR fork, SpreadClassic.
New ANN being prepared as we type.
November 16, 2016, 04:41:03 AM
A while back, we were discussing the mechanisms for consensus in regards to determining how much Service Nodes would be paid from the coinbase. I know that having an arbitrary taxing of the mining reward that goes to Service Nodes is ridiculous and would annoy much of the mining community.
The solution as it stands, and as I remember it, is that the miners will vote with a signature with every block that they mine, which will produce an average payment that SNs will receive. For those who were not here for this discussion, consider this example:
Two miners are mining Spreadcoin and each have equal mining capabilities resulting in 50 percent of the block being received by both miners. If both voted for zero percent of the mining reward then Service Nodes would receive zero reward for their services (in the early stages this will be the decentralized block explorer). If one miner voted for 0 percent and the other for 100 percent, 50 percent of the block reward would be sent off to SN operators. So each miner would receive half of each block.
While I disagree with the arbitrary taxing of the coinbase, I am still sort of concerned about the solution that I'm assuming is / will be worked on in the future. My main issue with it, which I brought up originally, was that a miner (a rogue miner) could come in and have no care for Spreadcoin's future and set all of his mining blocks to zero thereby resulting in a much lower, and perhaps unsustainable reward schedule for SNs.
Georgem's counter to this, I believe was that it would encourage SN operators to buy mining equipment and mine themselves thereby getting a vote. Or regular Spreadcoin miners, like our main guy Sirazimuth with his huge amount of hash power, could rebel against the rogue miner and set their votes to 100 percent rewards to counter the rogue's 0 percent votes.
I would like to propose a different solution to the above on the premise that miners are inherently greedy and do not have NEARLY as much of a stake in a coin that they mine as those who have invested money to buy the coin. This is clearly the case, as miners have "liquidity" and can bring their mining equipment to new coins should one cease to be profitable. Those who have invested in a coin can not just switch their coins to another coin so easily and thus have far more incentive to ensure that the coin is a success.
My proposal, should it be feasible, is that in order for miners to have a vote they must prove that they have some stake in Spreadcoin's success. A collateral of sorts in order to ensure that they are in fact a community member and not some mercenary coming in to extract wealth from the community. A collateral ensures that they have a stake in the success of Spreadcoin, and thus have the incentive to vote in a meaningful way. A way which has Spreadcoin's best interest at heart. Of course other people would be able to mine the coin, but only those with X amount of Spreadcoin would be able to vote on the reward that goes towards the overlay network.
I am not sure if this is possible through coding. If it is, I think that it solves the problems with 1) assigning an arbitrary amount of coinbase reward to be taxed from miners and 2) the issue of rogue miners having 0 stake in the success of Spreadcoin and thus no incentive to make any vote aside from the one that most immediately benefits them.
tl;dr In order for miners to vote on rewards that go to Service Nodes they must have a stake (in the form of collateral) in Spreadcoin's future so as not to vote in ways which may be detrimental to Spreadcoin for sake of their immediate profits.
The solution as it stands, and as I remember it, is that the miners will vote with a signature with every block that they mine, which will produce an average payment that SNs will receive. For those who were not here for this discussion, consider this example:
Two miners are mining Spreadcoin and each have equal mining capabilities resulting in 50 percent of the block being received by both miners. If both voted for zero percent of the mining reward then Service Nodes would receive zero reward for their services (in the early stages this will be the decentralized block explorer). If one miner voted for 0 percent and the other for 100 percent, 50 percent of the block reward would be sent off to SN operators. So each miner would receive half of each block.
While I disagree with the arbitrary taxing of the coinbase, I am still sort of concerned about the solution that I'm assuming is / will be worked on in the future. My main issue with it, which I brought up originally, was that a miner (a rogue miner) could come in and have no care for Spreadcoin's future and set all of his mining blocks to zero thereby resulting in a much lower, and perhaps unsustainable reward schedule for SNs.
Georgem's counter to this, I believe was that it would encourage SN operators to buy mining equipment and mine themselves thereby getting a vote. Or regular Spreadcoin miners, like our main guy Sirazimuth with his huge amount of hash power, could rebel against the rogue miner and set their votes to 100 percent rewards to counter the rogue's 0 percent votes.
I would like to propose a different solution to the above on the premise that miners are inherently greedy and do not have NEARLY as much of a stake in a coin that they mine as those who have invested money to buy the coin. This is clearly the case, as miners have "liquidity" and can bring their mining equipment to new coins should one cease to be profitable. Those who have invested in a coin can not just switch their coins to another coin so easily and thus have far more incentive to ensure that the coin is a success.
My proposal, should it be feasible, is that in order for miners to have a vote they must prove that they have some stake in Spreadcoin's success. A collateral of sorts in order to ensure that they are in fact a community member and not some mercenary coming in to extract wealth from the community. A collateral ensures that they have a stake in the success of Spreadcoin, and thus have the incentive to vote in a meaningful way. A way which has Spreadcoin's best interest at heart. Of course other people would be able to mine the coin, but only those with X amount of Spreadcoin would be able to vote on the reward that goes towards the overlay network.
I am not sure if this is possible through coding. If it is, I think that it solves the problems with 1) assigning an arbitrary amount of coinbase reward to be taxed from miners and 2) the issue of rogue miners having 0 stake in the success of Spreadcoin and thus no incentive to make any vote aside from the one that most immediately benefits them.
tl;dr In order for miners to vote on rewards that go to Service Nodes they must have a stake (in the form of collateral) in Spreadcoin's future so as not to vote in ways which may be detrimental to Spreadcoin for sake of their immediate profits.
Interesting
I don't think it changes anything for miners if its optional. They will only participate if they can make enough money to pay costs and show a profit. They won't lock themselves in so easily as servicenodes, even for the right to vote.
There should be a way to lock miners in through some sort of hybrid collateral and Pow/PoS arrangement, more from a decentralisation point of view. There is an interesting proposals for a way to merge proof of work, with proof of stake and proof of activity
https://eprint.iacr.org/2014/452.pdf
If you can tie collateral to servicenodes to mining, then you have a way to increase decentralisation as buying lots of equipment is not enough, you also have to buy lots of SPR.
November 16, 2016, 04:35:38 AM
o no ...
here we go with the 'classic' trend ...
sheesh! ...
#crysx
November 16, 2016, 02:49:18 AM
when will the decentralized blockexplorer come? 
November 16, 2016, 01:37:47 AM
A while back, we were discussing the mechanisms for consensus in regards to determining how much Service Nodes would be paid from the coinbase. I know that having an arbitrary taxing of the mining reward that goes to Service Nodes is ridiculous and would annoy much of the mining community.
The solution as it stands, and as I remember it, is that the miners will vote with a signature with every block that they mine, which will produce an average payment that SNs will receive. For those who were not here for this discussion, consider this example:
Two miners are mining Spreadcoin and each have equal mining capabilities resulting in 50 percent of the block being received by both miners. If both voted for zero percent of the mining reward then Service Nodes would receive zero reward for their services (in the early stages this will be the decentralized block explorer). If one miner voted for 0 percent and the other for 100 percent, 50 percent of the block reward would be sent off to SN operators. So each miner would receive half of each block.
While I disagree with the arbitrary taxing of the coinbase, I am still sort of concerned about the solution that I'm assuming is / will be worked on in the future. My main issue with it, which I brought up originally, was that a miner (a rogue miner) could come in and have no care for Spreadcoin's future and set all of his mining blocks to zero thereby resulting in a much lower, and perhaps unsustainable reward schedule for SNs.
Georgem's counter to this, I believe was that it would encourage SN operators to buy mining equipment and mine themselves thereby getting a vote. Or regular Spreadcoin miners, like our main guy Sirazimuth with his huge amount of hash power, could rebel against the rogue miner and set their votes to 100 percent rewards to counter the rogue's 0 percent votes.
I would like to propose a different solution to the above on the premise that miners are inherently greedy and do not have NEARLY as much of a stake in a coin that they mine as those who have invested money to buy the coin. This is clearly the case, as miners have "liquidity" and can bring their mining equipment to new coins should one cease to be profitable. Those who have invested in a coin can not just switch their coins to another coin so easily and thus have far more incentive to ensure that the coin is a success.
My proposal, should it be feasible, is that in order for miners to have a vote they must prove that they have some stake in Spreadcoin's success. A collateral of sorts in order to ensure that they are in fact a community member and not some mercenary coming in to extract wealth from the community. A collateral ensures that they have a stake in the success of Spreadcoin, and thus have the incentive to vote in a meaningful way. A way which has Spreadcoin's best interest at heart. Of course other people would be able to mine the coin, but only those with X amount of Spreadcoin would be able to vote on the reward that goes towards the overlay network.
I am not sure if this is possible through coding. If it is, I think that it solves the problems with 1) assigning an arbitrary amount of coinbase reward to be taxed from miners and 2) the issue of rogue miners having 0 stake in the success of Spreadcoin and thus no incentive to make any vote aside from the one that most immediately benefits them.
tl;dr In order for miners to vote on rewards that go to Service Nodes they must have a stake (in the form of collateral) in Spreadcoin's future so as not to vote in ways which may be detrimental to Spreadcoin for sake of their immediate profits.
The solution as it stands, and as I remember it, is that the miners will vote with a signature with every block that they mine, which will produce an average payment that SNs will receive. For those who were not here for this discussion, consider this example:
Two miners are mining Spreadcoin and each have equal mining capabilities resulting in 50 percent of the block being received by both miners. If both voted for zero percent of the mining reward then Service Nodes would receive zero reward for their services (in the early stages this will be the decentralized block explorer). If one miner voted for 0 percent and the other for 100 percent, 50 percent of the block reward would be sent off to SN operators. So each miner would receive half of each block.
While I disagree with the arbitrary taxing of the coinbase, I am still sort of concerned about the solution that I'm assuming is / will be worked on in the future. My main issue with it, which I brought up originally, was that a miner (a rogue miner) could come in and have no care for Spreadcoin's future and set all of his mining blocks to zero thereby resulting in a much lower, and perhaps unsustainable reward schedule for SNs.
Georgem's counter to this, I believe was that it would encourage SN operators to buy mining equipment and mine themselves thereby getting a vote. Or regular Spreadcoin miners, like our main guy Sirazimuth with his huge amount of hash power, could rebel against the rogue miner and set their votes to 100 percent rewards to counter the rogue's 0 percent votes.
I would like to propose a different solution to the above on the premise that miners are inherently greedy and do not have NEARLY as much of a stake in a coin that they mine as those who have invested money to buy the coin. This is clearly the case, as miners have "liquidity" and can bring their mining equipment to new coins should one cease to be profitable. Those who have invested in a coin can not just switch their coins to another coin so easily and thus have far more incentive to ensure that the coin is a success.
My proposal, should it be feasible, is that in order for miners to have a vote they must prove that they have some stake in Spreadcoin's success. A collateral of sorts in order to ensure that they are in fact a community member and not some mercenary coming in to extract wealth from the community. A collateral ensures that they have a stake in the success of Spreadcoin, and thus have the incentive to vote in a meaningful way. A way which has Spreadcoin's best interest at heart. Of course other people would be able to mine the coin, but only those with X amount of Spreadcoin would be able to vote on the reward that goes towards the overlay network.
I am not sure if this is possible through coding. If it is, I think that it solves the problems with 1) assigning an arbitrary amount of coinbase reward to be taxed from miners and 2) the issue of rogue miners having 0 stake in the success of Spreadcoin and thus no incentive to make any vote aside from the one that most immediately benefits them.
tl;dr In order for miners to vote on rewards that go to Service Nodes they must have a stake (in the form of collateral) in Spreadcoin's future so as not to vote in ways which may be detrimental to Spreadcoin for sake of their immediate profits.
November 14, 2016, 05:08:35 AM
Sorry for your loss georgem, long live to DPR ! 
November 13, 2016, 06:29:57 PM
Does DPR have much growing to do since he's so young or is he basically fully developed now? Looking forward to more pictures of him 
Actually from what I've heard and read (and seen with mr. spread), most of their growth/maturity happens within the first 3 months.
But the curious thing is that after that they still keep growing forever, although only slowly.
So a 2 year old djungarian dwarf hamster (Phodopus sungorus) will be up to 30-40% larger than what he was after 3 months.
This picture of DPR is from yesterday:
He has this unique character trait that he bends his head sideways when looking at us humans. Like saying: "What the f*uck is this..."
DPR looks very cool. i like that little guy.
i actually used to keep a pair of laboratory white rats as a pets back in my youth.
They were super friendly and loved being handled and their favorite food was slugs!
Theyd go forking bonkers over them!! On rainy days id find slugs in my garden feasting on my errr....well i wont go there lol.
Anyway, these rats would sit up on hind legs holding the sqirming slimy slug with their front claws/legs
and munch em like a kid in 7th heaven licking on an ice cream cone.
wish i had a video, it would be priceless...
anyway............ GO SPREADCOIN
November 13, 2016, 08:57:13 AM
While you kick yourself for not investing in Trumpcoin, more Wikileaks of the DSDN Whitepaper:
(needs a bit of editing for typos)
Just waiting to clarify a few things about Spreadwallet (did I say that before already? Head it getting a bit like Java, lots of memory leaks)
Some //dev trolling
(needs a bit of editing for typos)
Just waiting to clarify a few things about Spreadwallet (did I say that before already? Head it getting a bit like Java, lots of memory leaks)
Some //dev trolling
Dis gon b gud
November 12, 2016, 12:37:53 PM
Maybe DPR is giving the what the fuck face because people are dumping even at these prices lol.
In other non-hamster related news (aka boring news) the explorer at chainz doesn't look like it's working. Webpage returns "Syntax Error: Invalid const type "TCoinOption" expected "TCoinStatus" [line: 2271, column: 7, file: ChainzDB]"
Edit: It's back up!
In other non-hamster related news (aka boring news) the explorer at chainz doesn't look like it's working. Webpage returns "Syntax Error: Invalid const type "TCoinOption" expected "TCoinStatus" [line: 2271, column: 7, file: ChainzDB]"
Edit: It's back up!
Cool.
I love it when devs forget to disable error reporting and broadcast to the whole wide world where exactly an error happened, what DB they use, etc....
November 11, 2016, 06:04:22 PM
Maybe DPR is giving the what the fuck face because people are dumping even at these prices lol.
In other non-hamster related news (aka boring news) the explorer at chainz doesn't look like it's working. Webpage returns "Syntax Error: Invalid const type "TCoinOption" expected "TCoinStatus" [line: 2271, column: 7, file: ChainzDB]"
Edit: It's back up!
In other non-hamster related news (aka boring news) the explorer at chainz doesn't look like it's working. Webpage returns "Syntax Error: Invalid const type "TCoinOption" expected "TCoinStatus" [line: 2271, column: 7, file: ChainzDB]"
Edit: It's back up!
November 11, 2016, 05:11:16 AM
Does DPR have much growing to do since he's so young or is he basically fully developed now? Looking forward to more pictures of him
Actually from what I've heard and read (and seen with mr. spread), most of their growth/maturity happens within the first 3 months.
But the curious thing is that after that they still keep growing forever, although only slowly.
So a 2 year old djungarian dwarf hamster (Phodopus sungorus) will be up to 30-40% larger than what he was after 3 months.
This picture of DPR is from yesterday:
He has this unique character trait that he bends his head sideways when looking at us humans. Like saying: "What the f*uck is this..."
November 11, 2016, 01:40:13 AM
Thank you very much.
In hamsteryears, it's like Mr. Spread died 65 years old. Not too old, but also not too young. I had hoped he would have lived another 6-12 months...
DPR's weight is now 35 g. Now that I have a bigger "data set" of dwarf hamsters, it looks like Mr. Spread was a veritable Bud Spencer among dwarf hamsters. Pretty big and heavy with his 65g (on average).
I think this is my favorite photo of all. His rotundness makes him extra endearing.
Does DPR have much growing to do since he's so young or is he basically fully developed now? Looking forward to more pictures of him
November 10, 2016, 11:43:31 AM
That is some sad news. He was quite the character and I will certainly miss his 'presence'. You gave the warning that he might not have much time a while ago, but I didn't think it would be this soon! I guess my micro-nation will be dedicating the first few service node payments to a memorial for Mr. Spread - maybe I can put it onto the blockchain.
Congrats again on the new member(s) of the family. May Dread Pirate Roberts (and the other newest member) live a long and healthy life! The real question is how much does he weigh? lol!
Also, speaking of donations.
Thank you very much.
In hamsteryears, it's like Mr. Spread died 65 years old. Not too old, but also not too young. I had hoped he would have lived another 6-12 months...
DPR's weight is now 35 g. Now that I have a bigger "data set" of dwarf hamsters, it looks like Mr. Spread was a veritable Bud Spencer among dwarf hamsters. Pretty big and heavy with his 65g (on average).
Here are some of the best shots of him:
And pictures like this are my favorite:
He used to hang out at the plexiglas door gap, sniffing and looking.... "there is something going on out there!"
BTW, I have tons of video and foto material, I will create a compilation and use much of it in the podcast, where appropriate.
It's very MEME worthy material.
November 10, 2016, 10:50:57 AM
That is some sad news. He was quite the character and I will certainly miss his 'presence'. You gave the warning that he might not have much time a while ago, but I didn't think it would be this soon! I guess my micro-nation will be dedicating the first few service node payments to a memorial for Mr. Spread - maybe I can put it onto the blockchain.
Congrats again on the new member(s) of the family. May Dread Pirate Roberts (and the other newest member) live a long and healthy life! The real question is how much does he weigh? lol!
Also, speaking of donations.
November 10, 2016, 10:27:44 AM
As soon as I have more time I will answer your questions in more detail.
For now, just as a foretaste:
2 weeks ago you asked:
A bitcoin node doesn't talk with the bitcoin blockchain, only with other bitcoin nodes.
The bitcoin blockchain doesn't even "really exist" in a static form since it's in a constant state of flux in the top few most recent blocks. (multiple blockchains exist at the same time, until "it's been decided" who the orphan blocks are, but this process repeats ad infinitum since new blocks keep coming in all the time as the height increases)
I don't think that the average confirmation time has much to do with the fee, with the only exception when you send a zero-fee transaction and are then at the total mercy of a miner to STILL put you on the blockchain even though you didn't incentivize him to do so. That's probably a little bit different for coins who hit their max block size all the time. But even then, it will remain unpredictable how long it takes your transaction to be confirmed. Paying a higher fee is NOT a guarantee that your transaction will be confirmed earlier. It only creates an incentive. Incentives are not the same thing as guarantees.
And therefor I don't think you can use that for any reliable system of "node scores". Too many parameters and uncertainties.
For now, just as a foretaste:
2 weeks ago you asked:
Georgem
If a Bitcoin node broadcasts a message to the Bitcoin Blockchain, is it reasonable to expect that the average confirmation time for all transactions within a given fee range is how long that individual broadcast message should take, give or take say +12hrs?
If a Bitcoin node broadcasts a message to the Bitcoin Blockchain, is it reasonable to expect that the average confirmation time for all transactions within a given fee range is how long that individual broadcast message should take, give or take say +12hrs?
A bitcoin node doesn't talk with the bitcoin blockchain, only with other bitcoin nodes.
The bitcoin blockchain doesn't even "really exist" in a static form since it's in a constant state of flux in the top few most recent blocks. (multiple blockchains exist at the same time, until "it's been decided" who the orphan blocks are, but this process repeats ad infinitum since new blocks keep coming in all the time as the height increases)
I don't think that the average confirmation time has much to do with the fee, with the only exception when you send a zero-fee transaction and are then at the total mercy of a miner to STILL put you on the blockchain even though you didn't incentivize him to do so. That's probably a little bit different for coins who hit their max block size all the time. But even then, it will remain unpredictable how long it takes your transaction to be confirmed. Paying a higher fee is NOT a guarantee that your transaction will be confirmed earlier. It only creates an incentive. Incentives are not the same thing as guarantees.
And therefor I don't think you can use that for any reliable system of "node scores". Too many parameters and uncertainties.
Ok, I agree with that. I was looking for a way to get maximum proofs done in shortest time period. Bitcoin block validation times is a problem with that. But it needs to happen for many different reasons.
Ideally, if there are 2, 000 or 6,000 service nodes, it would be great to have them verified as holding x-blockchain once if not many times each day.
We can discuss atomic swaps another time as a route to generating proofs of nodes. I'm happy that we are walking in the right direction with it. Atomic swaps is smart contracts with LockTime. If I can transact $1 or $10bn using atomic swaps, which it was designed to do, it's got potential for what we need.
November 10, 2016, 09:58:10 AM
As soon as I have more time I will answer your questions in more detail.
For now, just as a foretaste:
2 weeks ago you asked:
A bitcoin node doesn't talk with the bitcoin blockchain, only with other bitcoin nodes.
The bitcoin blockchain doesn't even "really exist" in a static form since it's in a constant state of flux in the top few most recent blocks. (multiple blockchains exist at the same time, until "it's been decided" who the orphan blocks are, but this process repeats ad infinitum since new blocks keep coming in all the time as the height increases)
I don't think that the average confirmation time has much to do with the fee, with the only exception when you send a zero-fee transaction and are then at the total mercy of a miner to STILL put you on the blockchain even though you didn't incentivize him to do so. That's probably a little bit different for coins who hit their max block size all the time. But even then, it will remain unpredictable how long it takes your transaction to be confirmed. Paying a higher fee is NOT a guarantee that your transaction will be confirmed earlier. It only creates an incentive. Incentives are not the same thing as guarantees.
And therefor I don't think you can use that for any reliable system of "node scores". Too many parameters and uncertainties.
For now, just as a foretaste:
2 weeks ago you asked:
Georgem
If a Bitcoin node broadcasts a message to the Bitcoin Blockchain, is it reasonable to expect that the average confirmation time for all transactions within a given fee range is how long that individual broadcast message should take, give or take say +12hrs?
If a Bitcoin node broadcasts a message to the Bitcoin Blockchain, is it reasonable to expect that the average confirmation time for all transactions within a given fee range is how long that individual broadcast message should take, give or take say +12hrs?
A bitcoin node doesn't talk with the bitcoin blockchain, only with other bitcoin nodes.
The bitcoin blockchain doesn't even "really exist" in a static form since it's in a constant state of flux in the top few most recent blocks. (multiple blockchains exist at the same time, until "it's been decided" who the orphan blocks are, but this process repeats ad infinitum since new blocks keep coming in all the time as the height increases)
I don't think that the average confirmation time has much to do with the fee, with the only exception when you send a zero-fee transaction and are then at the total mercy of a miner to STILL put you on the blockchain even though you didn't incentivize him to do so. That's probably a little bit different for coins who hit their max block size all the time. But even then, it will remain unpredictable how long it takes your transaction to be confirmed. Paying a higher fee is NOT a guarantee that your transaction will be confirmed earlier. It only creates an incentive. Incentives are not the same thing as guarantees.
And therefor I don't think you can use that for any reliable system of "node scores". Too many parameters and uncertainties.
November 10, 2016, 09:54:49 AM
I'm afraid it's not as simple as that, since we want to make it work as part of a large decentralized and permissionless system.
It looks like we are going to have some sort of smart contracts that will be handled by servicenodes and that's what will allow things like "decentralized exchange" to come into existence. (Among other such contracts).
But if you think that a spreadwallet alone is enough to make this work you are mistaken. People will abuse the shit out of it.
Will have more tangible insights once I start my podcast.
It looks like we are going to have some sort of smart contracts that will be handled by servicenodes and that's what will allow things like "decentralized exchange" to come into existence. (Among other such contracts).
But if you think that a spreadwallet alone is enough to make this work you are mistaken. People will abuse the shit out of it.
Will have more tangible insights once I start my podcast.
Atomic swaps was invented to avoid centralized exchanges. So it is a way to improve decentralisation.
I don't see any reason why this won't work if Spreadwallet can host two daemons. The minimum requirement for atomic swaps is a user must have access to both daemons. To make this work, we have to automate the process. No manual intervention. Servicenodes need to kick-off atomic swaps of information.
A variant of atomic swaps with smart contracts is just a variant of atomic swaps. So I'm sure there is more than one way to get the same outcome.
November 10, 2016, 09:43:29 AM
I'm afraid it's not as simple as that, since we want to make it work as part of a large decentralized and permissionless system.
It looks like we are going to have some sort of smart contracts that will be handled by servicenodes and that's what will allow things like "decentralized exchange" to come into existence. (Among other such contracts).
But if you think that a spreadwallet alone is enough to make this work you are mistaken. People will abuse the shit out of it.
Will have more tangible insights once I start my podcast.
It looks like we are going to have some sort of smart contracts that will be handled by servicenodes and that's what will allow things like "decentralized exchange" to come into existence. (Among other such contracts).
But if you think that a spreadwallet alone is enough to make this work you are mistaken. People will abuse the shit out of it.
Will have more tangible insights once I start my podcast.
November 10, 2016, 09:07:59 AM
Where Spreadwallet is in charge of two daemons.
There is already a process to swap coins between two chains, so the trick here will be to automate the process as part of Proof of X's chains node. We just need to replace swapping coins (or we might keep it) with swapping instructions to do stuff, like broadcast a message to the Bitcoin network:
Public keys must be serialized using strict SEC format:
Compressed keys are mandatory.
When included in transactions, hash_type must be set to 1.
Signatures must be serialized using strict DER format.
Request Message
Each message shall have the following format.
Result Message
The server shall reply to Request methods with a response message.
Give error message, if request fails
Trade Request
This method is used to initiate the protocol.
The response for the method has a subset of the trade information.
If it goes through and accepted, Houston, we have the start of the proof.
A trade-id is generated for each transaction (| means concatenation).
The third party's public key is modified to give
This method is used to exchange public keys between the parties. Each party has to provide 5 public keys and the long trader must provide hash_x. The slow trader should set hash_x to Null.
The server responds with 5 public keys and hash_x.
This method is for the parties to exchange signatures.
Segwit should help with any signature malleability issues to help prevent malware fucking up the process.
If I were in a bar and I had just drank 10 pints of beer, I'd be saying 'I love you Tier Nolan' right about now.
There is already a process to swap coins between two chains, so the trick here will be to automate the process as part of Proof of X's chains node. We just need to replace swapping coins (or we might keep it) with swapping instructions to do stuff, like broadcast a message to the Bitcoin network:
Public keys must be serialized using strict SEC format:
Code:
byte(0x02) byte_array(32): Compressed even key
byte(0x03) byte_array(32): Compressed odd key
byte(0x03) byte_array(32): Compressed odd key
Compressed keys are mandatory.
When included in transactions, hash_type must be set to 1.
Signatures must be serialized using strict DER format.
Code:
byte(0x30) byte(total_length) byte(0x02) byte(len(R)) byte_array(len(R)) byte(len(s)) byte_array(len(s)
Request Message
Each message shall have the following format.
Code:
{"id":1, "method": "method.name", "params": [param1, param2]}
Result Message
The server shall reply to Request methods with a response message.
Code:
{"id": 1, "result": result, "error: Null}
Give error message, if request fails
Trade Request
This method is used to initiate the protocol.
Code:
{"id":1, "method": "trade.request", [version, long_deposit, [third_parties], k_client,
sell_magic_value, sell_coin_amount, sell_coin_fee,
sell_locktime,
buy_magic_value, buy_coin_amount, buy_coin_fee,
buy_locktime]}
sell_magic_value, sell_coin_amount, sell_coin_fee,
sell_locktime,
buy_magic_value, buy_coin_amount, buy_coin_fee,
buy_locktime]}
Code:
// wtf?
version: Integer version of the handshake (should be set to 1)
slow_trader (boolean): True if the server is the slow trader, false otherwise
third_party (list of string): Hex encoding of acceptable 3rd parties' public key (or Null for no 3rd party)
k_client (string): A random hex encoded byte array (32 bytes)
sell_coin_magic_value (string): Hex encoding of the network magic value for the coin being sold
sell_coin_amount (number): An integer count of the number of coins being sold (in the smallest units)
sell_locktime (number): The int locktime for the client's refund transaction
buy_coin_magic_value (string): Hex encoding of the network magic value for the coin being bought
buy_coin_amount (number): An integer count of the number of coins being bought (in the smallest units)
buy_locktime (number): The int locktime for the server's refund transaction
version: Integer version of the handshake (should be set to 1)
slow_trader (boolean): True if the server is the slow trader, false otherwise
third_party (list of string): Hex encoding of acceptable 3rd parties' public key (or Null for no 3rd party)
k_client (string): A random hex encoded byte array (32 bytes)
sell_coin_magic_value (string): Hex encoding of the network magic value for the coin being sold
sell_coin_amount (number): An integer count of the number of coins being sold (in the smallest units)
sell_locktime (number): The int locktime for the client's refund transaction
buy_coin_magic_value (string): Hex encoding of the network magic value for the coin being bought
buy_coin_amount (number): An integer count of the number of coins being bought (in the smallest units)
buy_locktime (number): The int locktime for the server's refund transaction
The response for the method has a subset of the trade information.
Code:
{"id":1, "result": [version, slow_trader, [third_parties], k_server,
sell_coin_amount, sell_coin_fee, sell_locktime,
buy_coin_amount, buy_coin_fee, buy_locktime]
"error": Null}
sell_coin_amount, sell_coin_fee, sell_locktime,
buy_coin_amount, buy_coin_fee, buy_locktime]
"error": Null}
If it goes through and accepted, Houston, we have the start of the proof.
A trade-id is generated for each transaction (| means concatenation).
Code:
tr_id = SHA-256(k_client | k_server)
The third party's public key is modified to give
Code:
third_party_key_modified = tr-id * third_party_key
This method is used to exchange public keys between the parties. Each party has to provide 5 public keys and the long trader must provide hash_x. The slow trader should set hash_x to Null.
Code:
{"id": 1, "method":"keys.request", "params": [tr_id, key1, key2, ... key5, hash_x]}
The server responds with 5 public keys and hash_x.
Code:
{"id": 1, "result": [key1, key2, ... key5, hash_x], "error": Null}
This method is for the parties to exchange signatures.
Code:
//server_payout_signature: This is the signature for the server's payout transaction (input A)
server_refund_signature: This is the signature for the server's timelocked refund transactions
server_third_party_signature: This is the signature for the server's transaction to direct the output to a third party
{"id": 1, "method": "exchange.signatures", "params": [tr_id, server_payout_signature, server_refund_signature, server_third_party_signature]
//response
{"id": 1, "result": [client_payout_signature, client_refund_signature, client_third_party_signature], "error": Null}
//client_payout_signature: This is the signature for the client's payout transaction (input A)
client_refund_signature: This is the signature for the client's timelocked refund transactions
client_third_party_signature: This is the signature for the client's transaction to direct the output to a third party
server_refund_signature: This is the signature for the server's timelocked refund transactions
server_third_party_signature: This is the signature for the server's transaction to direct the output to a third party
{"id": 1, "method": "exchange.signatures", "params": [tr_id, server_payout_signature, server_refund_signature, server_third_party_signature]
//response
{"id": 1, "result": [client_payout_signature, client_refund_signature, client_third_party_signature], "error": Null}
//client_payout_signature: This is the signature for the client's payout transaction (input A)
client_refund_signature: This is the signature for the client's timelocked refund transactions
client_third_party_signature: This is the signature for the client's transaction to direct the output to a third party
Segwit should help with any signature malleability issues to help prevent malware fucking up the process.
If I were in a bar and I had just drank 10 pints of beer, I'd be saying 'I love you Tier Nolan' right about now.
Jump to: