Vote messages constructed by the voting system are digitally signed by BU Members using their public key.
Members can use a single signature to vote on all open proposals at once.
There are no new member applications in this voting round
Please get involved. Bitcoin Unlimited is a new paradigm where the membership decides on functional development, admission of new members, and operational changes requiring the expenditure of funds.
-----BEGIN BITCOIN SIGNED MESSAGE-----
VOTING IS OPEN FOR BUIPs 168 169 170 171 172 173 174 175 176 177 ON 15 TO 20 OCTOBER 2021
-----BEGIN BITCOIN SIGNATURE-----
15TiujYmnHa33fjEnasBBm1eWcGx9YEXPL
H+QoTAIHhME/VxMWB+FFLHlXIvo+Oof5hSp7FMPsqEHId6pFXk/3STaGG7FzCSLu/+6DnkhGyrRUmqDme9G17Y0=
-----END BITCOIN SIGNED MESSAGE-----
i did install the app and voted , to help test the system. i thought it was a mock vote, but now i see it will be counted (i might not have voted as i did, but let’s move forward).
however, now i am confused about the voting security model. it reduces to being in control of the signing device, correct?
Great to know you would like to help test, @AdrianX
It does rely on an Android App at present. There is a priority to also put the App on F-DROID. @jQrgen can explain more about that.
@79b79aa8
Thanks for testing the first vote on BUIP167 . Actually, we are only tallying the votes from the existing Awemany voting system. So, please vote there as you intend and that will be the decider.
We don’t want to reduce the security model, so, your point about control of the signing device is a concern to me as well. I think there is an argument that the vote organiser should be able to specify that the vote requires signed messages and they can be input into the device, so it does not hold the private key. This is a major functional variation from the existing implementation.
Another BUIP is ready to vote on VotePeer: BUIP168: Add support for Native Introspection CHIP
This time the setting “anonymous” is selected, so the voting is limited to the participant group, but there will not be a historical record of which choice each participant made. This will expire in 18 hours.
The camera is used for QR-Code based authentication.
VotePeer collects anonymous crash logs and performance data. This means that when someone re-opens VotePeer after a Crash, developers can see the stack trace, operating system and the phone model that produced the crash.
Also, if the app is performing badly it will be anonymously reported to a performance dashboard that the VotePeer developers can see. All the reported data is anonymous.
VotePeer is developed in such a way that all the following services can be replaced or removed.
Crash reporting
Always collected
Collects stack traces and relevant application state when an application crashes.
Collects device and OS information to assist with debugging crashes.
Usage-dependent
Collects any custom keys, logs, and free-text user IDs that developers attach to crash reports. Also collects any developer-defined non-fatal events with custom stack traces. (VotePeer developer does not attach user-identifiable information to crash reports)
Collects “breadcrumb” logs if Crashlytics is used together with Google Analytics. These logs identify user actions immediately before a crash along with crash counts (Google analytics is not used by VotePeer).
Performance Monitoring
Always collected
Collects IP addresses to provide geography-based segmentation of performance data. (IP-address is not visible to VotePeer-developer, but is used by the performance monitoring SAAS tool to display “hotspots” on an obscure map)
Collects app performance metrics such as app launch time and network request latency, as well as developer-specified custom traces to measure app performance. (VotePeer developers has not added custom traces)
Collects CPU/memory usage of the application to provide a timeline view of the app’s performance.
Collects device information, OS information, application information to filter the performance data against different segments of devices.
Cloud Firestore (Deprecated, to be removed from VotePeer)
The Firebase user agent is a bundle of information collected from most Firebase SDKs and includes the following: device, OS, app bundle ID, and developer platform. The user agent is never linked to a user or device identifier and is used by the Firebase team to determine platform and version adoption in order to better inform Firebase feature decisions.
Cloud Functions (HTTP-request wrapper and serverless functions service used for prototyping. Interchangeable with node-express)
Always collected
Collects function invocation metadata, including the function name and IP address of the function caller.
Click Here or the following banner is a direct download to for the latest release**
The banner links to a permanent URL for downloading the latest VotePeer-version directly from the VotePeer app GitLab repo.
Personally, I think F-DROID is really cool. Compatibility with VotePeer requires further assessment as every library that is dependent on google-play-services has to be removed.
We would probably also have to review what is required to have android push notifications on F-DROID as I don’t think F-DROID accepts Google Cloud Messaging. Maybe we would have to develop a OpenPush Server
. Actually, we are only tallying the votes from the existing Awemany voting system. So, please vote there as you intend and that will be the decider.
.
