BitShares Forum
Main => General Discussion => Topic started by: wackou on December 14, 2014, 01:05:18 pm
-
I was talking with Fuzz recently and he mentioned his desire to publish a slate of delegates, however he doesn't have a delegate himself to do that and asked me whether I could help him figure it out. Preferably, this should be possible to integrate into the mumble chatroom so people could just click on a link there. After giving it a little bit of thought, I came up with those potential solutions:
- the dev team enhances the current bts:// url scheme to allow multiple delegates at once
At the moment, one can create a link bts://<delegate-name>/approve, which will open the GUI wallet and approve the delegate whose name is in the link. That only works for one delegate at a time, though, but probably it would be very easy to extend this to something like bts://approve-slate/delegate1&delegate2&delegate3&delegate4
PROS:
- easy, barely no setup required
- no delegate required either
CONS:
- approves all the delegate at the time of clicking, but doesn't change approval if Fuzz updates his slate later
- Fuzz gets a delegate, only to publish a slate (ie: doesn't try to get elected)
This would be the more "standard" way of doing it
PROS:
- uses standard delegate slate publishing methods
- he can update his slate, and people that have him approved will vote for the updated slate
CONS:
- people need to use "vote as recommended" (not the default option)
- people need to have him approved in their wallets, which means there's a risk that he ends up becoming an active delegate
- This message from Toast:
https://bitsharestalk.org/index.php?topic=12020.msg158784#msg158784
But I'm not sure I really understand what this entails (this probably sounds like the best solution in the long-term, though)
Any other ideas/thoughts about what would be the best way to do this?
I believe that this would go a long way towards solving voter apathy, and surely there are some low-hanging fruits that can be picked to ensure that it is as easy as possible for people wanting to publish a slate to do so, and for shareholders that trust a community figure to just "follow" their votes.
-
a third option would be to cooperate with a delegate whoch does not want to have/investigate slates ... and publish a slate in cooperation ..
Say cass doesnt have the time to evaluate delegates and publish a slate .. he can cooperate (openly) with fuzz and publish the slate for fuzz ... fuzz can the advertise the use of cass's slate that is mainzained by fuzz ..
Pro:
- cass wins votes
- fuzz has a slate
Cons:
- what if the cooperation breaks?
- involves trust
- slate can only be updates by cass .. unless he is ok with compromising his privkey .. which he shouldnt be ..
-
a third option would be to cooperate with a delegate whoch does not want to have/investigate slates ... and publish a slate in cooperation ..
Say cass doesnt have the time to evaluate delegates and publish a slate .. he can cooperate (openly) with fuzz and publish the slate for fuzz ... fuzz can the advertise the use of cass's slate that is mainzained by fuzz ..
Pro:
- cass wins votes
- fuzz has a slate
Cons:
- what if the cooperation breaks?
- involves trust
- slate can only be updates by cass .. unless he is ok with compromising his privkey .. which he shouldnt be ..
I support this.
And is there a way to check details of slate? (i.e. who support who)
-
And is there a way to check details of slate? (i.e. who support who)
"publish slates" is a certain kind of transaction which contains ALL delegates in the slate. See for example txid: db5cee34a2a36010dde86a58971ab73583270485
From that set of delegates, a slateID is produced deterministically (hash of set of delegates .. of some kind - BM mentioned that in a hangout)
and that slate id is then published with your delegate (public field). See for example:
blockchain_get_account delegate.xeroc
BTW, I published a standalone script to publish slates: https://github.com/xeroc/delegate-slate
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
I asked @svk some time ago if it was possible to index those transactions and show them separately .. My guess is that he eventually will be able to implement it .. if not and he released the source code for the front and backend .. someone else can push an update to that!
-
Delegates slates by category might be useful.. those within certain bands of statistics and delivery - whatever is truly useful for the network stability should be the priority. I wonder some slates might get political otherwise.. some delegates campaigning on agendas like marketing is all very well but a delegate has one core function and those who do that best should dominate.
Also, off topic but I note that buying assets removes the alert that I'm not using all my voting power from that address.. which was a surprise. I wonder that holders of BTS-assets have as much invested in seeing the network stable, as any other holders of BTS.
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
I asked @svk some time ago if it was possible to index those transactions and show them separately .. My guess is that he eventually will be able to implement it .. if not and he released the source code for the front and backend .. someone else can push an update to that!
I think delegate slate updates don't have a unique transaction type, any voting transaction includes a slate basically. But I'll check your transaction to see if there's a way to identify it uniquely.
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
I asked @svk some time ago if it was possible to index those transactions and show them separately .. My guess is that he eventually will be able to implement it .. if not and he released the source code for the front and backend .. someone else can push an update to that!
I think delegate slate updates don't have a unique transaction type, any voting transaction includes a slate basically. But I'll check your transaction to see if there's a way to identify it uniquely.
I was talking about the transactions that PUBLISH a slate .. not those that vote for them
take a look at db5cee34a2a36010dde86a58971ab73583270485
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
I asked @svk some time ago if it was possible to index those transactions and show them separately .. My guess is that he eventually will be able to implement it .. if not and he released the source code for the front and backend .. someone else can push an update to that!
I think delegate slate updates don't have a unique transaction type, any voting transaction includes a slate basically. But I'll check your transaction to see if there's a way to identify it uniquely.
I was talking about the transactions that PUBLISH a slate .. not those that vote for them
take a look at db5cee34a2a36010dde86a58971ab73583270485
I may just never have encountered one so I'll check your transaction for sure. What's the transaction type called?
-
Thanks for reply. I think if people are able to see the details of slate easily (on GUI, especially), it would provide more transparency.
I asked @svk some time ago if it was possible to index those transactions and show them separately .. My guess is that he eventually will be able to implement it .. if not and he released the source code for the front and backend .. someone else can push an update to that!
I think delegate slate updates don't have a unique transaction type, any voting transaction includes a slate basically. But I'll check your transaction to see if there's a way to identify it uniquely.
I was talking about the transactions that PUBLISH a slate .. not those that vote for them
take a look at db5cee34a2a36010dde86a58971ab73583270485
I may just never have encountered one so I'll check your transaction for sure. What's the transaction type called?
[
"db5cee34a2a36010dde86a58971ab73583270485",{
"trx": {
"expiration": "2014-12-02T20:10:47",
"delegate_slate_id": null,
"operations": [{
"type": "define_delegate_slate_op_type",
"data": {
"slate": {
"supported_delegates": [
266,
317,
335,
371,
875,
1193,
4458,
4914,
[.....]
-
[
"db5cee34a2a36010dde86a58971ab73583270485",{
"trx": {
"expiration": "2014-12-02T20:10:47",
"delegate_slate_id": null,
"operations": [{
"type": "define_delegate_slate_op_type",
"data": {
"slate": {
"supported_delegates": [
266,
317,
335,
371,
875,
1193,
4458,
4914,
[.....]
I'm looking into adding support for slates but it's surprisingly complicated. While yours is fairly straightforward, I currently would classify that transaction as an account update since that is what happens on the second operation of that transaction. However the "define_delegate_slate_op_type" is included quite often and I'm not really sure it's always the case of someone actually updating their slate. When you use the publish_slate command, does it immediately broadcast a transaction or does it get tacked on to the next transaction you make?
Here's an example of a slightly more complicated transaction from block #1097825:
"515eed9a038e04e24641669108ecfbb1ad070c31",
{
"trx" : {
"expiration" : "2014-11-25T02:32:22",
"delegate_slate_id" : null,
"operations" : [
{
"type" : "define_delegate_slate_op_type",
"data" : {
"slate" : {
"supported_delegates" : [
1,
6,
10,
59,
66,
266,
306,
334,
337,
338,
371,
795,
1193,
2151,
2156,
2158,
3324,
3649,
5464,
5570,
5589,
5722,
6006,
6212,
6582,
6939,
8679,
9810,
9811,
9870,
9871,
9878,
9879,
9880,
9882,
10082,
10155,
10171,
10173,
10174,
10206,
10207,
10213,
10214,
10243,
10287,
10288,
10323,
10425,
10510,
11028,
12313,
12314,
12316,
14020,
14758,
21537,
21539,
22353,
30739,
30919
]
}
}
},
{
"type" : "deposit_op_type",
"data" : {
"amount" : 38558728581,
"condition" : {
"asset_id" : 0,
"slate_id" : 3.158111506591852e+18,
"type" : "withdraw_signature_type",
"data" : {
"owner" : "BTS2FstgYG33DGa1WySZKUnL8r5rqTrfR9ts",
"memo" : {
"one_time_key" : "BTS5ZNTRbhprCCAnorSq65MGSmYN43xb3pSHXSMk1LaGn453DPADP",
"encrypted_memo_data" : "a7b76f8e863fdb02032482757907b1ed467994e886a527b75d6854a10730ff32a0a4219fa964fbee58f6968ce1d2846801357abb0c1af0459b93c4b4d62a0bce"
}
}
}
}
},
{
"type" : "define_delegate_slate_op_type",
"data" : {
"slate" : {
"supported_delegates" : [
1,
6,
10,
59,
66,
266,
306,
307,
317,
334,
335,
337,
338,
371,
795,
875,
1193,
2151,
2156,
2158,
3324,
3649,
4458,
4914,
5464,
5570,
5589,
5722,
6006,
6212,
6582,
6939,
8679,
9810,
9811,
9870,
9871,
9872,
9878,
9879,
9880,
9882,
9954,
10082,
10155,
10171,
10173,
10174,
10206,
10207,
10213,
10214,
10243,
10287,
10288,
10306,
10323,
10425,
10493,
10510,
11028,
11083,
11099,
12313,
12314,
12316,
13721,
14020,
14758,
16658,
21130,
21537,
21539,
21706,
22353,
23569,
23728,
30739,
30919
]
}
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSBHXs4ECfmUQTH7tKufTXAMpvB3UMD8987",
"amount" : 32887363825,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSDMTbpf2Ym1d41vZYjx4PDoVWD62Vc6b2T",
"amount" : 1250374756,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSDn8dJoeX7DS3eQe4kia1Dee1C9fhrtmHy",
"amount" : 1203985000,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSFvedctmXoLXZR92443VsPoMcDEq4mGC2M",
"amount" : 1526035000,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSGVFM5Eybt3Th1DVkndbZV1hUnkyspQUwT",
"amount" : 1549985000,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSLaiCf1q2xqsrnBtf6CMkfL7UnWB6SVLXF",
"amount" : 65000000,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSMJBRPBoGTtwvB39cdJBXtFVC8kq6RmxwM",
"amount" : 10000000,
"claim_input_data" : ""
}
},
{
"type" : "withdraw_op_type",
"data" : {
"balance_id" : "BTSP63x6Pc5drid61wd7wKLMh3Hz7RvjGus3",
"amount" : 66000000,
"claim_input_data" : ""
}
}
]
That transaction actually includes TWO define_delegate_slate_op_type operations, one with 61 delegates the other with 79 delegates. There are also 8 withdraw_op_type operations, none of which withdraw to an account like they normally do but to 8 different public keys. The delegate account is identified nowhere, which I find strange, so there's no way for me to tell who actually published this slate. Basically, it's complicated.. Looking through the transactions I see a lot of transactions like this, so unless someone can explain how this all works I'm not sure I can properly add slates at the moment..
This is I guess a slate published by a non-delegate, guess I'll just ignore those for now. I would still like to know why there are two slate operations in there though.
-
oh .. what a mess ...
paging @toast @bytemaster
-
The define_delegate_slate op is used to create internal slate records that voting depends on.
Publishing a public slate to your account is different, and just uses the update_account op to update your account's "public_data".
We've realized there is currently no good way to look at an account's published slate and actually figure out who it approves; it's now on the TODO list: https://github.com/BitShares/bitshares/issues/1216
-
The define_delegate_slate op is used to create internal slate records that voting depends on.
Publishing a public slate to your account is different, and just uses the update_account op to update your account's "public_data".
We've realized there is currently no good way to look at an account's published slate and actually figure out who it approves; it's now on the TODO list: https://github.com/BitShares/bitshares/issues/1216
OK, that's actually my original interpretation of how define_delegate_slate was being used, thanks for clarifying that!
-
I think what happens is this:
Everytime you vote for a combination of delegates that hasn't been voted for before, a new delegate slate is published. Subsequent transactions voting for the same delegate combination can then reference the resulting slate_id instead of including the whole list everytime. That's just the way voting works.
The tx contains several withdraws probably because someone wanted to vote with all their stake, which was distributed across several balance ids.
I'd also speculate that someone has published a delegate slate while simultaneously voting for a different combination of delegates, that's why there are two slates in the tx. But that's really just a wild guess.
Edit: just saw Vikram's answer.