I had the pleasure of listening in to the afternoon session wrap-up live. If you feel like listening in on the 95 minutes of goodness, then please, I urge you to click here – my source. If this is your lunch or coffee break and you need to get back to work soon, then here’s a 5 minute play by play:
Involving Academia:
There is an education gap between developers and educators. The resources are there on bitcointalk, but they’re often buried under spam posts or other noise. Educators need to have a collaborative effort for their own research, like a shared resource problem lab, was even given as an example. Those were powerful viewpoints – we do have existing systems such as bitcoin.org which has a developers reference, and even an autogenerated sources
Trustless UX and Crypto Human Interaction:
Trustlessness in terms of users like vulnerability and dependency. Do users care about trustlessness and security and if they don’t they should perhaps consider otherwise. Also, another question, should there be a tradeoff for ease of time and convenience (transactions going through faster) if there is a compromise of privacy or perhaps slightly with security?
Also was also mentioned that there is an incentive to centralize an application if users become complacent on the service (because of your dedicated servers providing a strong user experience or community), so much so that VC funding and capital has been persuaded towards such solutions (another reason I could imagine is that there is clearer accountability in a centralized business model – as opposed to a peer 2 peer network).
Other Highlights:
- “the reward will go into the fees over time as demand is placed”
- there is a mining gap to where as you hold hardware there is a gap to where fees???
- Having academic incentives or bounties for best-paper awards are definitely a good thing and should increase for more research within bitcoin to flourish in academia!
Concerns of Mining Centralization not Unfounded:
Switching gears, another presenter brought up concerns regarding a Voted on ruleset (allowing miners to select Blocksize is one idea that comes to mind) asserting that allowing for decision making within a smaller minority of influencers is very dangerous.
Selective rule enforcement:
- 1..2….3 steps away from imposing rules that benefit them for their.
- Should bitcoin be considered a threat to bitcoin’s future or is it that bitcoin has just failed? Everything should be considered a threat.
- simulation and testing techniques – what data should be collected from the network? What transaction is communicated beyond op-codes, the transaction hashes and the hash-encoded outputs?
-
Its hard to model bitcoin because at the protocol level it is not yet modular. Proof of stake are even more complex and because of those issues its very difficult to give an adequate
-
Keeping things civil between miners and developers. Dealing with immediate alerts. Who is allowed to send messages directly to mining operators and what kind of mechanisms and how should these messages look? Do miners use the current bitcoin messaging system today? Do miners have this infrastructure utilized?
-
How do we improve the communications between developers and ecosystem operators such as mining operators or exchanges?
-
The block size is a contentious debate … we can solve other actual problems and add new features the protocol and should focus our efforts on that instead of focusing energies on false urgencies.
Bitcoin Testing Configurations and Analysis:
Questions that came up that have not yet been well researched (hint, hint, Join in!):
- How do people configure their nodes?
- There are concerns with tests, but it’s possible to overcome those.
- Maybe snapshot and topology – not instantly in realtime (that could be exploited) maybe once every 4-6 months … that would be incredibly useful to researchers. Maybe a repo for the testing and research data?
- A bitcoin measurement body like a research group???
Scalability and hosted infrastructure:
Judging by the sponsor list, they had a large turnout of the wallet and hosting companies available (the sponsors) This group unanimously agrees to hardfork bitcoin to increase the block size. Its not about changing the block size, its about showing the world that bitcoin knows how to govern itself. The Stress tests cause confusion for fees. Most infrastructure end-points run custom non-core bitcoin software and tools to implement the protocol.
There was a lot of concern of the cost and support to wallet companies themselves in the spam/stress test when transactions don’t go through.
Two possible Pathway to adopt better cryptography into BTC:
For the protocol level improvements discussed below, most stuff can be soft-forked. Where can we improve scaling: looking at digital signature validation, Another idea: Suppose we could replace ECDSA with EC-Schnorr – it’s the same but the math behind it doesn’t involve division. It’s also possible to generate native multi-signature capabilities (currently a p2sh client or service is required to do multisignature transactions) where the 1 of 1 signature looks to be the same size as something huge like 10 of 10 or even 5 of 10 signature.
Compact verifiable computing (SNARKS) – could eliminate all blockchain data and just provide proof that they are correct – they would need to be lamport signatures would have be faster to produce lamport work if we had ‘magic’ crypto, it would suddenly be perhaps a good idea again.
Further reading:
Usenix << Eclipse Attacks on Bitcoin’s Peer 2 peer network
Shannon Hartley theorem << Computational approach to handle limiting decay from information propagation???
Mobile process calculus << python calculus – analysis of concurrent process like bitcoin and ++ would be greatly desired for Cryptocurrency long term.
