Join Factom Founders Peter Kirby and possibly Paul Snow on Hangouts Wednesday December 10th at 6.30PM (PT) @Seattle Bitcoin Meetup.
You are invited to join us at the Seattle Bitcoin Meetup, if you can't make it you can tune in to the Google Hangouts at the below link.
Live stream starts at 6.30PM (PT).
https://plus.google.com/events/cgotpt5d6g5ad8k0idniuk6eo64?authkey=CIG519ynvf78cA
Topic: [ANN] FACTOM - Introducing Honesty to Record-Keeping - page 469. (Read 2115931 times)
This will be a self policing style system, similar to how the Bitcoin miners self police amongst themselves for the block reward. If a miner decides to award themselves more BTC than the fees that were paid in, then the majority of other miners will reject that block. Factom will have a similar system. The majority will reject a block which has outputs that exceed the number of signed inputs.
As far as that level of detail for constructing proofs of transfers, we haven't gotten to that yet. There is a lineage that can be traced, protected by signatures, so it can't be forged.
The Entry will be associated with an Entry Credit commit payment, which was signed by a key. That key had an Entry Credit balance because of a signed Factoid transaction, which essentially converted Factoid value into Entry Credit value at some exchange rate.
The progression of value can be followed back to where the Factoid's were initially committed. Since signatures and hashes provide cryptographic assurance, then a proof can be constructed. If we are going to record that proof, or have it be an in-memory operation like Bitcoin is yet to be determined.
As far as that level of detail for constructing proofs of transfers, we haven't gotten to that yet. There is a lineage that can be traced, protected by signatures, so it can't be forged.
The Entry will be associated with an Entry Credit commit payment, which was signed by a key. That key had an Entry Credit balance because of a signed Factoid transaction, which essentially converted Factoid value into Entry Credit value at some exchange rate.
The progression of value can be followed back to where the Factoid's were initially committed. Since signatures and hashes provide cryptographic assurance, then a proof can be constructed. If we are going to record that proof, or have it be an in-memory operation like Bitcoin is yet to be determined.
When entry credits are used to create entries, the entry credits are effectively burned, and the Factoids released to the servers.
How exactly are they released? What will the "release" transaction look like on the Factoid chain? What kind of linking will there be to show that the newly released Factoids are associated with burned entry credits?
4: When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers. This is similar to transaction fees paid to Bitcoin miners. Distribution proportionality schemes are also preliminary.
Could you please elaborate on this. Because seems like what you are saying is that every single Entry into Factom will result in a transaction on the Factoid chain. This will surely bloat the Factoid chain very quickly.
When Factoids are converted into Entry Credits, they return to the protocol. The number of Factoids currently in the protocol can be computed. When entry credits are used to create entries, the entry credits are effectively burned, and the Factoids released to the servers.
That is all high level stuff. The actual payment to the servers will occur on a far less frequent basis. We are thinking every four hours. The payment will be their block reward share, plus their share of the Factoids released in the previous four hour period. (So we collect the payments over four hours, then we wait four hours, then we release the payments. So payments would be made every four hours, and at the time they are made, they are four hours old.)
In Bitcoin, block chain rewards are paid out after 100 confirmations, though most pools wait for 120 confirmations. That's 7 to 10 hours.
4: When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers. This is similar to transaction fees paid to Bitcoin miners. Distribution proportionality schemes are also preliminary.
Could you please elaborate on this. Because seems like what you are saying is that every single Entry into Factom will result in a transaction on the Factoid chain. This will surely bloat the Factoid chain very quickly.
@BrianDeery, thanks for breaking things down. I now have a better understanding of how Factom works.
I agree that my thresh.mult. scheme creates an extra incentive for a 51% attack. I'm saying "extra", because with the current design the attacker can short his Factoid position (on the market) and then perform the attack.
Threshold multisig also changes the system dynamics. If the service gets big enough, the majority can misbehave and steal all the stored bitcoin in the system. With the current design, if the majority misbehave, they will end up destroying the value they created in the system. This seems like the biggest problem with a threshold multisig to me.
I agree that my thresh.mult. scheme creates an extra incentive for a 51% attack. I'm saying "extra", because with the current design the attacker can short his Factoid position (on the market) and then perform the attack.
Watch Paul Snow on Hangouts for the latest Factom updates from the Denver Bitcoin Center. Click on the pic. 
http://i.imgur.com/aVkj4fC.png
http://i.imgur.com/aVkj4fC.png
Paul Snow is a star! Thanks for the great explanation of Factom.
How is Factom not everywhere? This is such a great project that is going to change record keeping everywhere. Record keeping that is needed by a trusted source!
To be a Factom Server
...
I hope this helps.
...
I hope this helps.
Thanks for trying but it helped only 20%
Perhaps my Q number 2 was answered indirectly.Maybe I'm not taking enough time to break down my Qs more minutely, maybe you are busy and skim over my Qs without realizing what is being asked.
It's OK though, take your time. I understand that probably much of what I'm asking is not yet set in stone.
Brian did a much better job of answering...
dansmith:
I must admit there is a lot we didn't put in the paper. There isn't a lot on consensus or incentives. 38 pages was stretching it already. Satoshi's was only 9. AlanX is memorializing more of what we are designing in a forthcoming consensus paper. Incentives have yet to be explored formally.
1: Yes, something like that. historical crowd sales map the private key owner in Bitcoin to be the new owner in the funded system. A lot of that heavily relies on having the same elliptic curve as Bitcoin, though. 5 years have passed, so we can build our system using updated crypto, but that would make shortcuts like this harder. It would be nice to get some advantages by using Edwards Curves, etc. We haven't gotten quite to that level of detail yet for that part of the system. Also, we have very limited time to experiment with new things.
2: Yes. The cost of doing business includes paying the BTC transaction fee. For the Federated servers to play in the system, they need to have a small amount of hot wallet BTC to pay transaction fees. Since there is a small (~=16) set of Federated servers who need to hold the BTC for transaction fees, users or non-authoritative full nodes do not need to hold BTC. Every 10 minutes, a deterministic algorithm determines which one of the 16 Federated servers is responsible for anchoring the group's data.
3: There are varying levels of trust that an application can have. Just like Bitcoin, Factom is eventually consistent. Bitcoin gives the irreversibility metric by number of confirmations and by how many of the nodes have the TX in their mempools. Factom will have granularity of certainty too.
certainty level 1: A Federated server has acknowledged receipt of the data.
certainty level 2: The Federated server's peers have not alerted a problem over the Factom P2P network.
certainty level 3: The Anchor (Merkle root of all Factom data over last 10 minutes) with your data in it has a Bitcoin transaction on the Bitcoin network.
certainty level 4: Federated server peers have not created alert transactions in the form of alert BTC transactions.
certainty level 5: The Anchor has 1 Bitcoin confirmation.
certainty level 6: The Anchor is buried under under several Bitcoin blocks, without also seeing some kind of alert or canceling transactions from the Federated server peers. Eventually, Factom will extend beyond a statute of limitations style period to prevent the Federated server majority from canceling an anchor of a misbehaving peer.
Since we use a multistep commit and reveal process, the Federated servers will be accepting payment for Entries which they do not know the contents of. If later, they censor based on the Entry content, it is provable. A user ( or more probably an Audit server) will publicize this censorship. The Audit servers have an incentive to make the community dislike the current Federated servers, so the Audit servers can get enough votes to be promoted up to Federated servers, and get more Factoids. Adam Back advocated for blind commitments similar to what we are doing in Bitcoin earlier. https://bitcointalksearch.org/topic/blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-206303
A lot of this is still preliminary.
4: When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers. This is similar to transaction fees paid to Bitcoin miners. Distribution proportionality schemes are also preliminary.
5: I think this is where a misunderstanding is occurring. The 16 Federated servers cooperate to collectively sign the Directory Block, which has Merkle roots of all the Entry Blocks. They need to agree as a majority to a single directory block. If a server were to pay for Entries to the system itself, it would get back less than 1/16th of the value it put in.
Concerning the threshold multisig:
Factom's reason for existence is to move transactions off of the blockchain. looping half of the process back into BTC again goes against that core rationale, but I can see where you are going with it.
Factom is a dynamic system. With a multisig system, someone has to actually control the private keys. That doesn't afford a really dynamic system.
We have a type of delegated proof of stake. This gives the active users in the system the say in who they want to package transactions. This has some merits. I hear the Ethereum folks are planning on now using some type of POS in their consensus. There are even serious proposals for bringing POS elements into Bitcoin (see Proof of Activity http://www.cs.technion.ac.il/~idddo/PoAslides.pdf).
The POS elements mean that the system authorities (federated servers and audit servers) can change in a short period of time based on the expressed wishes of the users. There are often calls to change what mining pools are patronized by individual miners. this will give a similar ability but enclosed in the Factom system.
If we brought in merge mining to the system, we would rely on miners twofold. we are already using miners for the non-reversibility. with merge mining, they would also be setting policy. This is a secondary business for them, and may not give it the attention someone who made it their sole business.
Bitcoin multisig currently doesn't have a high enough M of N for standard scripts. we are trying to get this project working without the help of miners (other than them not censoring our anchors, etc). current standard transactions give a maximum of 4 of 6, which isn't enough separation of powers for my taste. http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses Going higher would involve cooperation with miners.
But back to the threshold multisig. For the system to be dynamic and in control of the users, there needs to be some coupling between the stored value in the system and a say in who controls the system. in a threshold multisig system, the coupling is permanent once a payment is made. this encourages keeping smaller amounts in multisig as a balance, defeating the purpose of the whole system (moving transactions off the blockchain).
Threshold multisig also changes the system dynamics. If the service gets big enough, the majority can misbehave and steal all the stored bitcoin in the system. With the current design, if the majority misbehave, they will end up destroying the value they created in the system. This seems like the biggest problem with a threshold multisig to me.
Systems build on top of Factom are expecting it to last indefinitely. Factom also gives proof of the negative, which makes switching from one system to another expensive for a distributed system. There is some commentary on this in our AMA thread in Reddit. http://www.reddit.com/r/Bitcoin/comments/2mkyrg/we_are_the_founders_of_factom_see_our_white_paper/ Systems are looking for a canonical source to hold the entirety of their transactions. Setting up competing threshold multisig systems would expand the search space needed to prove a negative. Also a distributed system would need to decide which system to expand its search into. Too wide of a search and spam becomes a problem. Seperating Factom from bitcoin value also makes it portable. Factom can switch the POW system which provides its non-reversibility. If Bitcoin falls to another POW system, Factom can switch to being secured by that system, or a multitude of systems.
I haven't considered all the pros and cons of a system you are imagining. I can imagine a system like it working technically. I can also imagine a purely altruistic system of packaging transactions and securing them with Bitcoin. It boils down to what system correctly aligns incentives of all the parties involved, rather than what is technically possible. On the topic of incentives, I must admit I have a strong incentive to believe the things I have described. Please do consider exploring further the system you are starting down.
I must admit there is a lot we didn't put in the paper. There isn't a lot on consensus or incentives. 38 pages was stretching it already. Satoshi's was only 9. AlanX is memorializing more of what we are designing in a forthcoming consensus paper. Incentives have yet to be explored formally.
1: Yes, something like that. historical crowd sales map the private key owner in Bitcoin to be the new owner in the funded system. A lot of that heavily relies on having the same elliptic curve as Bitcoin, though. 5 years have passed, so we can build our system using updated crypto, but that would make shortcuts like this harder. It would be nice to get some advantages by using Edwards Curves, etc. We haven't gotten quite to that level of detail yet for that part of the system. Also, we have very limited time to experiment with new things.
2: Yes. The cost of doing business includes paying the BTC transaction fee. For the Federated servers to play in the system, they need to have a small amount of hot wallet BTC to pay transaction fees. Since there is a small (~=16) set of Federated servers who need to hold the BTC for transaction fees, users or non-authoritative full nodes do not need to hold BTC. Every 10 minutes, a deterministic algorithm determines which one of the 16 Federated servers is responsible for anchoring the group's data.
3: There are varying levels of trust that an application can have. Just like Bitcoin, Factom is eventually consistent. Bitcoin gives the irreversibility metric by number of confirmations and by how many of the nodes have the TX in their mempools. Factom will have granularity of certainty too.
certainty level 1: A Federated server has acknowledged receipt of the data.
certainty level 2: The Federated server's peers have not alerted a problem over the Factom P2P network.
certainty level 3: The Anchor (Merkle root of all Factom data over last 10 minutes) with your data in it has a Bitcoin transaction on the Bitcoin network.
certainty level 4: Federated server peers have not created alert transactions in the form of alert BTC transactions.
certainty level 5: The Anchor has 1 Bitcoin confirmation.
certainty level 6: The Anchor is buried under under several Bitcoin blocks, without also seeing some kind of alert or canceling transactions from the Federated server peers. Eventually, Factom will extend beyond a statute of limitations style period to prevent the Federated server majority from canceling an anchor of a misbehaving peer.
Since we use a multistep commit and reveal process, the Federated servers will be accepting payment for Entries which they do not know the contents of. If later, they censor based on the Entry content, it is provable. A user ( or more probably an Audit server) will publicize this censorship. The Audit servers have an incentive to make the community dislike the current Federated servers, so the Audit servers can get enough votes to be promoted up to Federated servers, and get more Factoids. Adam Back advocated for blind commitments similar to what we are doing in Bitcoin earlier. https://bitcointalksearch.org/topic/blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-206303
A lot of this is still preliminary.
4: When the Entry Credits are used to pay for Entries, new Factoids will be credited and spread amongst the various participating Federated and Audit servers. This is similar to transaction fees paid to Bitcoin miners. Distribution proportionality schemes are also preliminary.
5: I think this is where a misunderstanding is occurring. The 16 Federated servers cooperate to collectively sign the Directory Block, which has Merkle roots of all the Entry Blocks. They need to agree as a majority to a single directory block. If a server were to pay for Entries to the system itself, it would get back less than 1/16th of the value it put in.
Concerning the threshold multisig:
Factom's reason for existence is to move transactions off of the blockchain. looping half of the process back into BTC again goes against that core rationale, but I can see where you are going with it.
Factom is a dynamic system. With a multisig system, someone has to actually control the private keys. That doesn't afford a really dynamic system.
We have a type of delegated proof of stake. This gives the active users in the system the say in who they want to package transactions. This has some merits. I hear the Ethereum folks are planning on now using some type of POS in their consensus. There are even serious proposals for bringing POS elements into Bitcoin (see Proof of Activity http://www.cs.technion.ac.il/~idddo/PoAslides.pdf).
The POS elements mean that the system authorities (federated servers and audit servers) can change in a short period of time based on the expressed wishes of the users. There are often calls to change what mining pools are patronized by individual miners. this will give a similar ability but enclosed in the Factom system.
If we brought in merge mining to the system, we would rely on miners twofold. we are already using miners for the non-reversibility. with merge mining, they would also be setting policy. This is a secondary business for them, and may not give it the attention someone who made it their sole business.
Bitcoin multisig currently doesn't have a high enough M of N for standard scripts. we are trying to get this project working without the help of miners (other than them not censoring our anchors, etc). current standard transactions give a maximum of 4 of 6, which isn't enough separation of powers for my taste. http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses Going higher would involve cooperation with miners.
But back to the threshold multisig. For the system to be dynamic and in control of the users, there needs to be some coupling between the stored value in the system and a say in who controls the system. in a threshold multisig system, the coupling is permanent once a payment is made. this encourages keeping smaller amounts in multisig as a balance, defeating the purpose of the whole system (moving transactions off the blockchain).
Threshold multisig also changes the system dynamics. If the service gets big enough, the majority can misbehave and steal all the stored bitcoin in the system. With the current design, if the majority misbehave, they will end up destroying the value they created in the system. This seems like the biggest problem with a threshold multisig to me.
Systems build on top of Factom are expecting it to last indefinitely. Factom also gives proof of the negative, which makes switching from one system to another expensive for a distributed system. There is some commentary on this in our AMA thread in Reddit. http://www.reddit.com/r/Bitcoin/comments/2mkyrg/we_are_the_founders_of_factom_see_our_white_paper/ Systems are looking for a canonical source to hold the entirety of their transactions. Setting up competing threshold multisig systems would expand the search space needed to prove a negative. Also a distributed system would need to decide which system to expand its search into. Too wide of a search and spam becomes a problem. Seperating Factom from bitcoin value also makes it portable. Factom can switch the POW system which provides its non-reversibility. If Bitcoin falls to another POW system, Factom can switch to being secured by that system, or a multitude of systems.
I haven't considered all the pros and cons of a system you are imagining. I can imagine a system like it working technically. I can also imagine a purely altruistic system of packaging transactions and securing them with Bitcoin. It boils down to what system correctly aligns incentives of all the parties involved, rather than what is technically possible. On the topic of incentives, I must admit I have a strong incentive to believe the things I have described. Please do consider exploring further the system you are starting down.
To be a Factom Server
...
I hope this helps.
...
I hope this helps.
Thanks for trying but it helped only 20%
Perhaps my Q number 2 was answered indirectly.Maybe I'm not taking enough time to break down my Qs more minutely, maybe you are busy and skim over my Qs without realizing what is being asked.
It's OK though, take your time. I understand that probably much of what I'm asking is not yet set in stone.
I realized that I'll have to more carefully re-read the paper so I could establish some fundamental things before I re-visit my scheme with thresh.sig addresses.
Upon the initial Factoid distribution, you will start with a hand-crafted genesis block acc.to the distribution results?
Is a Factom Server expected to have its own btc in order to create an anchor on the btc blockchain?
Will it be the application's job to make sure that the anchor was placed on the blockchain, and if it was not placed there then rate the Factom Server unfavorably?
What is the process how the Factom Server will convert the Entry Credits back into Factoids?
Since the Entry Credits are paid to the Factom Server which creates the Entry Block, what is preventing a malicious actor who wants to spam the Entry Credits chain from setting up its own Factom Server and continually paying to it?
Upon the initial Factoid distribution, you will start with a hand-crafted genesis block acc.to the distribution results?
Is a Factom Server expected to have its own btc in order to create an anchor on the btc blockchain?
Will it be the application's job to make sure that the anchor was placed on the blockchain, and if it was not placed there then rate the Factom Server unfavorably?
What is the process how the Factom Server will convert the Entry Credits back into Factoids?
Since the Entry Credits are paid to the Factom Server which creates the Entry Block, what is preventing a malicious actor who wants to spam the Entry Credits chain from setting up its own Factom Server and continually paying to it?
To be a Factom Server, you have to have enough user votes to be one of the top n servers, where n is the number of Factom Servers. So people can't just create their own servers. All actions of a server must past muster with the rest of the servers, or a majority will vote you out of the pool. So you cannot misbehave.
Only one of the Factom Servers places the Merkle root into the blockchain, and that server is selected via a deterministic lottery (i.e.one of the hashes) so everyone can validate and verify the anchors.
Users will do validation based on their security levels.
The consensus algorithm isn't well documented, but I am doing that now.
I hope this helps.
A small suggestion to the whitepaper p.30 Dictionary Attack:
you can hash chainID together with salt. This will mitigate the Dictionary Attack.
you can hash chainID together with salt. This will mitigate the Dictionary Attack.
Very true.
A small suggestion to the whitepaper p.30 Dictionary Attack:
you can hash chainID together with salt. This will mitigate the Dictionary Attack.
you can hash chainID together with salt. This will mitigate the Dictionary Attack.
I realized that I'll have to more carefully re-read the paper so I could establish some fundamental things before I re-visit my scheme with thresh.sig addresses.
1. Upon the initial Factoid distribution, you will start with a hand-crafted genesis block acc.to the distribution results?
2. Is a Factom Server expected to have its own btc in order to create an anchor on the btc blockchain?
3. Will it be the application's job to make sure that the anchor was placed on the blockchain, and if it was not placed there then rate the Factom Server unfavorably?
4. What is the process how the Factom Server will convert the Entry Credits back into Factoids?
5. Since the Entry Credits are paid to the Factom Server which creates the Entry Block, what is preventing a malicious actor who wants to spam the Entry Credits chain from setting up its own Factom Server and continually paying to it?
1. Upon the initial Factoid distribution, you will start with a hand-crafted genesis block acc.to the distribution results?
2. Is a Factom Server expected to have its own btc in order to create an anchor on the btc blockchain?
3. Will it be the application's job to make sure that the anchor was placed on the blockchain, and if it was not placed there then rate the Factom Server unfavorably?
4. What is the process how the Factom Server will convert the Entry Credits back into Factoids?
5. Since the Entry Credits are paid to the Factom Server which creates the Entry Block, what is preventing a malicious actor who wants to spam the Entry Credits chain from setting up its own Factom Server and continually paying to it?
Use cases for Factom...this could get interesting!
How Factom Could Have Saved Bank of America $17 Billion in Fines
How Factom Could Have Prevented the $42.2 Billion BP Oil Spill
https://docs.google.com/document/d/1o4WR6U-ajYSczWp5yIhGSXfZCYKmyX-OTInI6ve9i0Q/
How Factom Could Have Saved Bank of America $17 Billion in Fines
How Factom Could Have Prevented the $42.2 Billion BP Oil Spill
https://docs.google.com/document/d/1o4WR6U-ajYSczWp5yIhGSXfZCYKmyX-OTInI6ve9i0Q/
Watch Paul Snow on Hangouts for the latest Factom updates from the Denver Bitcoin Center. Click on the pic.
Thank you for your informative responses.
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
I am not sure I understand, but it seems that the miners would have to actually send the tokens at the end of the day. Are these Factom miners? Because Factom doesn't have miners... But even if they did, the miner would have to actually send the coins?
What we are doing is completely automated.
I have not considered this scheme, but would be happy to if I could understand what problem you are solving here.
Thank you for your informative responses.
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
Interesting but colored coins is not a protocol unlike Mastercoin/Counterparty - and Factom. Afaik Colored coins allows you to identify utxo outputs and 'color' them - I dont see how you would be able to achieve the same as what Factom is proposing.
It seems that your proposal is more cumbersome as it would involve - colored coins, multisig, and miners tracking tokens (something that would require coordination with miners and/or pools)
Factom addresses the bloat issue by hashing transactions offchain on Factom servers, hence the need for its own token.
Join Factom Founders on Hangouts tomorrow December 4th @Denver Bitcoin Center.
You are invited to join us at the Denver Bitcoin Center, if you can't make it you can tune in to the Google Hangouts at the below link.
Live stream starts at 7PM (MT).
https://www.youtube.com/watch?v=G6foiXEHvDA
You are invited to join us at the Denver Bitcoin Center, if you can't make it you can tune in to the Google Hangouts at the below link.
Live stream starts at 7PM (MT).
https://www.youtube.com/watch?v=G6foiXEHvDA
Thank you for your informative responses.
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
@AlanX, you suggested that buying 1000s of entries in Factom with BTC can prevent the bloat&cost problem and I agree.
However, IMHO it would be possible to achieve the same by having colored Factom tokens (colored as in colored coins).
The would-be user of Factom sends his tokens into a m-of-n threshold signature Bitcoin address controlled by the Factom miners (miners' address).
There will be only one miners' address into which ALL users must deposit their Factom tokens. Signatures made by the privkey of the address from which a user funded miners' address will be used to uniquely identify each Factom user.
The miners must themselves keep track of how many tokens have already been spent by each user.
The miners can have a policy of disbursing the already-spent tokens out of the miners' address at the end of each day.
The downsides:
Miners are not immediately rewarded but only at the end of the day.
Miners must keep track of colored tokens' movement on the bitcoin blockchain.
Have you considered this scheme?
Jump to: