Added better spacing

All Core Devs Meetings/Meeting 12.md

@@ -27,22 +27,40 @@ Full conversation happens 12:27-29:17.
 
 ## 4. [EIP 161](https://github.com/ethereum/EIPs/issues/161) Clarification and Proposal to update the YP to say that built-in accounts (pre-compiles) are never empty and update implementations based on that. [Yoichi]
 Yoichi: Yellow paper metropolis updates look fine, but Spurious Dragon changes have been reverted and are unclear. Yoichi visited Gavin's office which provided a better picture of how the Yellow Paper should be amended to update it to the latest. Yoichi will continue to work on it. Gavin and Yoichi are going to meet more frequently to help get the Yellow Paper updated. Yoichi has concerns on the copyright of the Yellow Paper and will work with Gavin on that.
+
 Arkadiy: EIP 161 allows to delete empty accounts, but it does not specify a 
 EIP-161 defines an empty account as "has no code and zero nonce and zero balance." By this definition precompiled contracts are never empty because they do have native code. Parity and go-ethereum afaict still would treat built-in account as basic and potentially empty. This is not an issue for the current mainnet, as all the built-ins have some balance, but may become an issue for Metropolis and private networks. Should we update the YP to say that built-in accounts are never empty and update implementations according to that?
+
 Yoichi: Wrt to the Yellow Paper: The Spurious Dragon pull request specified that the pre-compiles could be empty, but we can easily change that to say pre-compiles cannot be empty. There would need to be an in-client mechanism to distinguish empty user accounts and empty pre-compiles.
+
 Arkadiy: The de-facto standard appears to be that the pre-compiles can be empty, so we can just keep that standard. Just want a confirmation from others.
+
 Pawel: That was the case before the Spurious Dragon HF. I don't see any reason for a change.
-Peter: At some point, there was a bug in both parity/go clients that caused a mini-fork. The issue was that geth did not delete pre-compiles because it had a rule that pre-compiles could not be deleted, but parity did not have that rule. I agree with Arkadiy that this is a weird corner case and we need to specify this to prevent things like this to happen again.
+
+Peter: At some point, there was a bug in both parity/go clients that caused a mini-fork. The issue was that geth did not delete pre-compiles because it had a rule that pre-compiles could not be deleted, but parity did not have that rule. I agree with 
+
+Arkadiy that this is a weird corner case and we need to specify this to prevent things like this to happen again.
+
 Yoichi: YP currently has an exception for pre-compiles that even when an OOG call happens they are touched and the state is created.
+
 Martin: How can this be a problem on private networks?
+
 Yoichi: This is only a problem if they create private networks with homestead rules. People can start networks with pre-Spurious Dragon rules with empty accounts. That is the only case.
+
 Vitalik: Imo over time we should deprecate features for people making private networks for people with pre-Spurious Dragon rules.
+
 Martin: Should it be assumed that hard forks are dependent on each other?
+
 Peter: There have been discussions on this and the potential for people to be able to jump around various soft forks to implement certain features from different forks, but this could cause major complications and unforeseen dependencies between hard forks.
+
 Christian: Yeah, cpp-ethereum is designed with the assumption of strictly ascending hard forks.
+
 Hudson: This seems to not require an EIP, because this was dealt with during a previous HF. So everyone seems in agreement that it is not worth it to have backwards compatibility that is independent of incremental HFs to avoid overcomplications.
+
 Arkidy: I agree, but the YP needs to be updated to clarify that.
+
 Peter: Yeah I agree we don't need to support that.
+
 Yoichi: I will clarify this point in my Spurious Dragon PR.
 
 ## 5. Metropolis Update
@@ -54,10 +72,15 @@ Christain prefers EIP 5 be replaced with EIP 211 RETURNDATACOPY and RETURNDATASI
 
 [Back to Metropolis]
 Hudson: Vitalik, you mentioned that the price increase has affected the timing of when block times are adjusted due to the difficulty bomb.
+
 Vitalik: Yes.
+
 Vitalik ran calculations based on statistics on the blockchain during the meeting.
+
 End of June: Blocktime will be around 19.5s
+
 End of August: around 28.5s.
+
 Vitalik: Imo it would be great to get it out before the end of June, but a hard deadline would be end of August. Recommendation: End of June as a normal case target and end of Aug. as worst case deadline. The conditions that normal users will have live through for either case continue to get better and better which is dependent by price. Blockchain difficulty is a lagging moving average of the price. Imo probably is < 10% that difficulty will ever go down again, will almost certainly be above 200.
 
 Vitalik elaborates more on this in 56:30 on the call.
@@ -68,8 +91,11 @@ Vitalik: Practical thing to do is to keep our heads down and try to complete thi
 Martin: I want to mention that anyone implementing Metropolis changes and other EIPs need to submit their test cases to tackle weird edge cases. The things learned when implementing these changes will benefit all clients and prevent consensus issues.
 
 There is currently not a formal process to submit these test cases. Informal process is to talk to Martin or Dimitry about submitting the test cases.
+
 Peter: One of the issues for devs is that it is complicated and messy to create tests that no one bothers. Long term solution suggestion: tool that allows a simple way to create tests. A way to more automatically create test cases.
+
 Martin: I complete agree. For now, it is valuable for devs to write up descriptions and submit their test cases to send to Dimitry or others.
+
 Hudson: I will talk to Dimitry about a cleaner process in the future and formalizing a way to submit test cases.
 
 ## Attendance