I am hearing this term " Segregated Witness" a lot lately. What is it ?
Good question
Since their buzzwords work so well, maybe we could copy them for our DPOS rebranding:
Segregated Proof of Stake
Discriminate and Proof of Segregation
/sorry crap joke
@bitacer,
@bytemaster @speedy Andreas Antonopoulos describes that on DailyDecrypt with Amanda: https://youtu.be/kSq-58ElBzk?t=1m48s
BTW ... those that haven't got it yet ..
BitShares does this ALREADY!
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#assign-ids-rather-than-using-uuids
In particular, I am talking about extracting the "signature proof" from the "transaction details".
Quote from: xeroc on February 08, 2016, 11:30:19 AM
BTW ... those that haven't got it yet ..
BitShares does this ALREADY!
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#assign-ids-rather-than-using-uuids
In particular, I am talking about extracting the "signature proof" from the "transaction details".
So in BitShares signatures are separated from the transaction data structure?
Quote from: bitacer on February 08, 2016, 11:38:42 AM
Quote from: xeroc on February 08, 2016, 11:30:19 AM
BTW ... those that haven't got it yet ..
BitShares does this ALREADY!
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#assign-ids-rather-than-using-uuids
In particular, I am talking about extracting the "signature proof" from the "transaction details".
So in BitShares signatures are separated from the transaction data structure?
yes ..
essentially you have a "blob" (json data) that is signed by your account's authority.
Once your signature is validated (which can be done independent of any other blockchain data),
you 'blob' is authorized.
after that its content is verified against the blockchain's data (e.g. to prevent doublespending etc.)
I highly recommend to read through this section:
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#technology-lessons
Andreas knows all this , I remember once he talked down about how BitShares is only good for crowd-funding . Yes Andreas, that too.
Quote from: speedy on February 07, 2016, 06:28:48 PM
Since their buzzwords work so well, maybe we could copy them for our DPOS rebranding:
Segregated Proof of Stake
Discriminate and Proof of Segregation
/sorry crap joke
Let them open the road with their buzzwords, keep moving..
(http://thechronicleherald.ca/sites/default/files/imagecache/ch_article_main_image/articles/B97169609Z.120130411210519000GMG2N70S.11.jpg)
Quote from: xeroc on February 08, 2016, 11:30:19 AM
BTW ... those that haven't got it yet ..
BitShares does this ALREADY!
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#assign-ids-rather-than-using-uuids
In particular, I am talking about extracting the "signature proof" from the "transaction details".
Our ID allocation system is different than what he is talking about. This is more to do with how we detect duplicate transactions.
The idea that we could borrow from this is to discard signatures from the transaction history allowing us to remove them from the blocks. We never look at signatures while reindexing, so that are not necessary once we get past the "last irreversible block".
Quote from: xeroc on February 08, 2016, 11:42:01 AM
Quote from: bitacer on February 08, 2016, 11:38:42 AM
Quote from: xeroc on February 08, 2016, 11:30:19 AM
BTW ... those that haven't got it yet ..
BitShares does this ALREADY!
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#assign-ids-rather-than-using-uuids
In particular, I am talking about extracting the "signature proof" from the "transaction details".
So in BitShares signatures are separated from the transaction data structure?
yes ..
essentially you have a "blob" (json data) that is signed by your account's authority.
Once your signature is validated (which can be done independent of any other blockchain data),
you 'blob' is authorized.
after that its content is verified against the blockchain's data (e.g. to prevent doublespending etc.)
I highly recommend to read through this section:
https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#technology-lessons
If one is technically inclined (as in developer type technical), this blog post is a great read. Ahh well a year+ of lessons learned the very hard way ... this should have made front page of ycombinator etc IMO.
Quote from: gamey on February 09, 2016, 05:34:07 AM
If one is technically inclined (as in developer type technical), this blog post is a great read. Ahh well a year+ of lessons learned the very hard way ... this should have made front page of ycombinator etc IMO.
Apart from this, which was a big mistake IMO:
QuoteAssign IDs rather than using UUIDs
This meant there was no way to hold onto a reference of a sent transaction until it hit the blockchain, which caused all kinds of problems.
Quote from: monsterer on February 09, 2016, 03:06:30 PM
QuoteAssign IDs rather than using UUIDs
This meant there was no way to hold onto a reference of a sent transaction until it hit the blockchain, which caused all kinds of problems.
Not really .. with the hash of the transaction you can identify every transaction .. thing is .. we didn't have an index in the database for those hashes, but AFAIK, we do now ..
Quote from: monsterer on February 09, 2016, 03:06:30 PM
Quote from: gamey on February 09, 2016, 05:34:07 AM
If one is technically inclined (as in developer type technical), this blog post is a great read. Ahh well a year+ of lessons learned the very hard way ... this should have made front page of ycombinator etc IMO.
Apart from this, which was a big mistake IMO:
QuoteAssign IDs rather than using UUIDs
This meant there was no way to hold onto a reference of a sent transaction until it hit the blockchain, which caused all kinds of problems.
Well I did say "great read" not Best Practices Guide. I had some issues with it too, but by and large it is rare to find a blog post that has so many hard learned lessons.
I could pick on the post a bit too, but I don't come around here to be exclusively negative. chuckles!
What would be really really great is if BM could go into all the personal lessons he learned when running a company. Who to hire, who to fire, and the whys and whens. There is exactly 0% chance of that happening, but that is the only subject that would interest me more than this.
Quote from: gamey on February 09, 2016, 03:21:05 PM
Well I did say "great read" not Best Practices Guide. I had some issues with it too, but by and large it is rare to find a blog post that has so many hard learned lessons.
Agreed. The majority of it is actually quite insightful.
edit: I am guilty of being too negative sometimes. In my defence I have a cold, lol :)