ryan
/
handshake
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated faq

pull/1/head
handshake-web 2020-02-02 04:34:50 +00:00
parent 35642ec18b
commit 9f737dfbb8
2 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
faq/index.html
View File

@ -130,13 +130,13 @@
<h3>Does this promote carbon emissions?
<span><footer class='footer-caret-down' src='/img/footer/down-caret.svg' alt='Toggle expanded answer on mobile'/></span>
<span class='hide'><footer class='footer-caret-up' src='/img/footer/up-caret.svg' alt='Toggle expanded answer on mobile'/></span></h3>
<span><p>Handshake uses proof-of-work mining, as it is currently the most reliable way to do compact light client proofs. Proof of work uses computational power, a lot of it. However, the overwhelming majority of this computational power is produced using renewables, currently wind and hydro. The reason proof-of-work is currently primarily renewables is that the competitive cost has driven down to places with <i>excess</i> energy, which are remote hydro and wind farms. While there are no guarantees this will persist, the percentage which uses renewables is increasing. In the future, it is possible to have it be a contributor to subsidizing off-grid solar power. As the grid becomes less viable due to local generation, it is possible that miners securing the network can provide an additional revenue stream. This isn't certain, but a theory is that if mining is secured by solar, the network security would be much higher, as that would mean that it requires significant investment in physical infrastructure to attack. This benefits people with off-grid solar panels, as their electricity is otherwise worthless after their batteries are fully charged. While it is uncertain if this will prove to be the case and alternatives should be ready, currently the overwhelming majority of proof of work mining uses renewables is increasing.</p></span>
<span><p>Handshake uses proof-of-work mining, as it is currently the most reliable way to do compact light client proofs. Proof of work uses computational power, a lot of it. However, the overwhelming majority of this computational power is produced using renewables, currently wind and hydro. The reason proof-of-work is currently primarily renewables is that the competitive cost has driven down to places with <i>excess</i> energy, which are remote hydro and wind farms. While there are no guarantees this will persist, the percentage which uses renewables is increasing. In the future, it is possible to have it be a contributor to subsidizing off-grid solar power. As the grid becomes less viable due to local generation, it is possible that miners securing the network can provide an additional revenue stream. This isn't certain, but a theory is that if mining is secured by solar, the network security would be much higher, as that would mean that it requires significant investment in physical infrastructure to attack. This benefits people with off-grid solar panels, as their electricity is otherwise worthless after their batteries are fully charged. While it is uncertain if this will prove to be the case and alternatives should be ready, currently the overwhelming majority of proof of work mining using renewables is increasing.</p></span>
</div>
<div class="question">
<h3>When is the first handshake?
<span><footer class='footer-caret-down' src='/img/footer/down-caret.svg' alt='Toggle expanded answer on mobile'/></span>
<span class='hide'><footer class='footer-caret-up' src='/img/footer/up-caret.svg' alt='Toggle expanded answer on mobile'/></span></h3>
<span><p>On the 615817th Bitcoin block height, the BTC blockhash will be committed into the Handshake genesis block. While it can be immediately mined, the genesis block is only locked in after six confirmations. After the first six confirmations of valid Bitcoin blocks with the genesis block will not change even with a deep reorg. The code is available for download starting on February 1, 2020. Transactions will enabled after two weeks worth of blocks.
<span><p>On the 615817th Bitcoin block height, the BTC blockhash will be committed into the Handshake genesis block. While it can be immediately mined, the genesis block is only locked in after six confirmations. After the first six confirmations of valid Bitcoin blocks, the genesis block will not change, even with a deep reorg. The code is available for download starting on February 1, 2020. Transactions will enabled after two weeks worth of blocks.
</p></span>
</div>

18
files/handshake.txt
View File

@ -2103,8 +2103,8 @@ general. Further, no guarantees are provided with coin supply, coin value, or
name value. In the event of a worldwide distribution, it is up to the wider
community to execute this plan.
Project developers involved before the mainnet launch have committed to never
make unilateral advocacy of where the blockchain should go, and any rhetoric
Those making unilateral advocacy of where the blockchain should go under the
auspicies of being an early developer of the chain, and any rhetoric related
should be seen with suspicion. It is up to the community to suggest changes and
any code forks are initiated with community consensus and approval.
@ -2113,16 +2113,16 @@ acknowledging new state updates. It is heavily recommended for service providers
to have long deposit times and their own internal controls and software
verification.
Hard forks are presumed to be possible in this system, for example, with the
proposed hard fork for the global distribution to all of humanity. All hard
forks are only valid upon community consent.
Hard forks are presumed to be possible in this system, there are no guarantees
around mining, economics, etc.
Trademark holders are responsible for munging their own renewals and
registrations, and the project developers do not have the ability to make
registrations, and project developers do not have the ability to make
unilateral changes to the system after the sunrise period. Any changes to the
name ownership requires a hard fork and is contingent upon community approval of
fullnodes and miners. Any changes after the sunrise period should be proposed to
the community as a hardfork.
records requires a hard fork and is contingent upon community approval of
fullnodes and miners. Any changes after the sunrise period may be proposed
to the community as a hardfork, or more likely the updates should be made
(without consensus) in the resolver client-side.
No guarantees are provided for transaction formats past one year. Pre-signed
transactions should not be presumed to be permanently available. Private keys