Help, My Wallet Won't Sync

The chatlog from #lightning-network discussing recent Lightning DDOS/vulnerability

bitPico [5:49 PM] If any LN testers see their connection slots full it’s us. We will release the attack code when ready. The network needs better protection against DDoS’s. (edited)
Laolu Osuntokun [5:59 PM] ? or report to specific implementations @bitPico? like the early days of bitcoin, don't think many impls have even started to start to cover dos vectors busy working on safety in other aspects
bitPico [6:00 PM] As it stands no implementation can handle connection exhaustion attacks by overflowing the underlying TCP stack.
Laolu Osuntokun [6:00 PM] not sure if any limit inbound connections yet
bitPico [6:02 PM] Doesn’t matter; we use the TCP half-open attack. This occurs at the kernel.
Laolu Osuntokun [6:02 PM] sure you'd still run into fd limits so that's not really impl specific
bitPico [6:02 PM] Yes; we exhaust the FD’s. (edited)
Laolu Osuntokun [6:04 PM] you could do the same for any active bitcoin node today, nodes would need to set up network-level mitigations unless the impls were super low level enough to detect something like that so would really depend on their default kernel settings
Matt Drollette [6:10 PM] echo 1 > /proc/sys/net/ipv4/tcp_syncookies … ?
bitPico [6:14 PM] Our Bitcoin implementation performs round-robin disconnects to induce network churn. This is one of the best methods to prevent most TCP attacks. Churn is needed in decentralized systems. It keeps them robust. Longstanding TCP connections are bad. *ie we disconnect N nodes every T mins.
Laolu Osuntokun [6:18 PM] if it's half open, how are you detecting the TCP connections then @bitPico? well for LN the connections are typically long lived @mdrollette yeh, defenses are at the kernel lvl
bitPico [6:21 PM] Round-robin disconnects free the kernel FD’s. There is also App level half-connect Works like this Syn Ack But don’t sent the Ack The connection is then half-open TCP connect scans work like this. TCP half-open scans are harder to detect.
ɹɑd [6:33 PM] Is there a way to tell lnd to listen on ipv4 instead of ipv6? When I try lnd --listen=0.0.0.0:9735 ..., it is listening on IPv6 TCP *:9735 but I need it to listen on IPv4.
Matt Drollette [6:34 PM] I think if you give it a specific IP instead of 0.0.0.0 it will only bind to that specific interface
ɹɑd [6:34 PM] ok, trying that…
bitPico [6:36 PM] Dual-stack OS will still open IPv6 Windows and Linux are VERY different TCP stacks. The behaviour is different.
ɹɑd [6:38 PM] Nice, that worked. Thanks, @mdrollette
bitPico [7:13 PM] How does LN protect from “dead end packets”? ie* onion wrapped but final destination doesn’t exist. aka routing amplification attack
kekalot [7:14 PM] :trumpet::skull:
bitPico [7:16 PM] We will test it and perform a 100,000 route amplification. We are trying to make our test kit reusable as possible to work out the kinks. (edited)
kekalot [7:16 PM] :trumpet::skull:
bitPico [7:25 PM] Seeing bad OP-SEC on LN; don’t name your node as the type of hardware. Those raspberry pi’s will go down.
kekalot [7:25 PM] :trumpet: :skull:
camelCase [7:26 PM] :joy:
bitPico [7:26 PM] ie* eclair.raspberry.pi
Abhijeet singh [8:05 PM] joined #lightning-network.
bitPico [8:48 PM] https://gist.github.com/anonymous/46f6513625579c5a920fe04b32103a03 Already running some custom attack vectors on LN nodes to see how they standup.
Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to x.x.x.x:9735 for attack vector TCPHO. Sun Mar 18 23:49:08 [INFO] - open_tcp_transports: Preparing TCP connection to We expect to perfect this testsuite by the weekend with some very useable attack vectors Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 success, sending attack payload. Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 failed, message = Connection refused. Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 success, sending attack payload. Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 success, sending attack payload. Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 success, sending attack payload. Sun Mar 18 23:51:19 [INFO] - operator(): TCP connection to x.x.x.x:9735 success, sending attack payload.
:+1: If you notice weird traffic it’s us.
bitPico [9:00 PM] We are most interested in our “route payload amplification” attack vector. This attack onion wraps payloads via hop by hop where the last hop is the first hop creating a self-denial of service where the LN nodes attack themselves after long route traversal. Exploiting the anonymous nature of onion routing allows no defense to the network. Anonymous routing in and of itself creates a situation where the network can get into an endless loop of self DDoS. Once we complete the entire message serialization routines and a deadline timer the TESTBED will run standalone continuously. Prob. only take another day to complete that. We are also making attack vectors as base classes so new ones can be easily created via overrides. *ie plugin-like attack vectors
Russell O'Connor [9:22 PM] https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
bitPico [9:26 PM] Yes; that idea and our attack vector(s) makes the entire network fall apart. We will prove this works. (edited) When nobody trusts nobody the network collapses. Low level attacks requiring no fees are easier however. (edited) There is nothing to prevent spoofing via replay of older packets. Because onion routing requires decryption (CPU Intensive) this can also be used to clog pathways with old payloads via CPU exhaustion. (edited) This is the real reason why ToR is so damn slow; it’s constantly attacked. It has nothing to do with end users actions.
Matt Drollette [9:34 PM] https://github.com/lightningnetwork/lnd/pull/761 GitHub Switch Persistence [ALL]: Forwarding Packages + Sphinx Replay Protection + Circuit Persistence by cfromknecht · Pull Request #761 · lightningnetwork/lnd This PR builds on #629, and integrates the changes with my more recent work on forwarding packages and batch-replay protection provided via pending changes to lightning-onion repo. Save one or two ...
bitPico [9:40 PM] (#)761 doesn’t impact our AV_03 It does however cause nodes to use more CPU and possibly go to disk per the notes. If LN nodes must go to disk this is bad. The slowest code pathways make the best AV’s.
bitPico [9:52 PM] CircuitKey’s are allocated “on the heap”. (edited) Underlying implementation would use malloc/realloc/free. Instead of RAII. This is asking for an overflow into unknown memory segments. We suggest stack only allocation. Memory on the stack is trivial to maintain; it has no holes; it can be mapped straight into the cache; it is attached on a per-thread basis. Memory in the heap is a heap of objects; it is more difficult to maintain; it can have holes.
Laolu Osuntokun [9:59 PM] @bitPico cpu usage is super minimal, this isn't tor so we're not relaying like gigabytes unknown memory segments? golang is a memory safe language stuff goes on the stack, then escape analysis is used to decide what should go on the heap
bitPico [10:00 PM] Heap allocation is more of a concern here. golang is not memory safe; it uses C underneath.
Laolu Osuntokun [10:01 PM] uhh
bitPico [10:01 PM] golang is not written in golang :slightly_smiling_face:
Laolu Osuntokun [10:01 PM] yes it is... https://github.com/golang/go/blob/mastesrc/runtime/map.go GitHub golang/go go - The Go programming language
bitPico [10:02 PM] That’s like saying the C runtime is C and not ASM. The C runtime is ASM.
Laolu Osuntokun [10:02 PM] go is written in go before go 1.4 (maybe 1.5) is was written in c but still, your "attack vector" isn't an implementation level issue, it's a network/kernel level DoS recycling, syn cookies, etc, would be needed not impl level defenses (edited)
bitPico [10:07 PM] We know the answer but what does golang compile to?
Laolu Osuntokun [10:07 PM] also replay htlc's will be rejected native?
bitPico [10:08 PM] ASM
Laolu Osuntokun [10:08 PM] yeh...
bitPico [10:08 PM] So what we said is exactly true.
Laolu Osuntokun [10:08 PM] no?
bitPico [10:08 PM] It’s as vulnerable as we stated.
Laolu Osuntokun [10:08 PM]
the heap is a heap of objects; it is more difficult to maintain; it can have holes
bitPico [10:09 PM] It still allocates through OS heap memory and not onto the stack in your case here. Which means it has holes.
Laolu Osuntokun [10:10 PM] aight, lemmie know when you exploit these issues in the golang runtime here's the code if you wanna study it: https://github.com/golang/go/ GitHub golang/go go - The Go programming language
bitPico [10:11 PM] ASM is ASM. Heap is heap. Heap is bad in this case. Stack is wise. Same applies to C or C++. Avoid the heap at all costs.
Laolu Osuntokun [10:12 PM] aye aye, capt
stark [10:12 PM] replied to a thread: Seeing bad OP-SEC on LN; don’t name your node as the type of hardware. Those raspberry pi’s will go down. don't name your node at all....
bitPico [10:12 PM] https://www.cs.ru.nl/E.Poll/hacking/slides/hic4.pdf
Laolu Osuntokun [10:13 PM] cool, i'll be waiting on those exploits in the go runtime, i'm sure many others will be excited as well
bitPico [10:14 PM] Has nothing to do with go. It uses malloc underneath. Heap always uses malloc; go, c or c++ or java or whatever.
Laolu Osuntokun [10:15 PM] sure, i think many of us know how memory management works
bitPico [10:15 PM] http://security.cs.rpi.edu/courses/binexp-spring2015/lectures/17/10_lecture.pdf Security experts avoid heap allocation. This is common knowledge. Noticed somebody commented about performance of the PR. That is because of the use of heap allocation instead of stack.
Laolu Osuntokun [10:17 PM] no, it's because of the disk I/O
bitPico [10:18 PM] So LN nodes write data to disk in case of crash? As to not lose funds? That’s what the PR says. Anyway golang uses libc; it is not compiled into pure ASM. (edited) Nevertheless we are not focusing on golang; LN in general and TCP/IP stacks.
ɹɑd [10:22 PM] @bitPico write an exploit and get back with us. Until then it just sounds like concern trolling.
bitPico [10:24 PM] Funny, we are exhausting LN TCP/IP Stacks as we type this… It’s no good if we can overtake the TCP stack and run it out of FD’s. We have 100's of connections to LN nodes and it;s automated using our hand built attack toolkit. When we increase this to 1000's then what?
Matt Drollette [10:26 PM] Isn’t that true of any TCP service though? Or are you saying there is something Lightning or lnd specific about your method?
Laolu Osuntokun [10:26 PM] it's true of any TCP service the defenses are on the kernel level
bitPico [10:27 PM] You’d need to have LN code handle millions of connections to mitigate this. We know golang will crash if this happens. But so will C.
Matt Drollette [10:29 PM] I’m beginning to wonder if @bitPico is actually performing a meta-attack on Lightning. A denial-of-service at the developer level with all this subtle trolling
bitPico [10:29 PM] This first problem is LN keeps inbound connections alive. It does not handle and drop them like a webserver. This is the only reason webservers can scale. Apache uses a timeout of 3 seconds in most cases. Currently we are connected to 45 LN nodes with over 22K connections. One variable change on our end and the network will suffer. (edited)
Matt Drollette [10:31 PM] but is that variable on the heap?
bitPico [10:32 PM] On Linux consider forcing it to require 999999 FD’s. AND do not keep-alive connections. The variable is an enum (an integer). Attack aggressiveness
Matt Drollette [10:33 PM] I’m just joking with you :stuck_out_tongue: I look forward to the write-up on the attack
bitPico [10:33 PM] Otherwise our code will keep LN nodes hung in TIME_WAIT. Anyway we are not trolling; we are BTC whales and LN must not fail. Otherwise our investment suffers. The only motivation behind this testing… As it stands LN nodes need L7 LB. Code will run overnight; sleep before we continue. Good job though on LN so far.
bitPico [10:46 PM] uploaded and commented on this image: Screen Shot 2018-03-19 at 1.44.19 AM.png
Fun stats: We’ve sucked 3.3 GB’s of bandwidth per hour from LN nodes. This will continue while we sleep. Every 80 milliseconds there is 44 attacks being performed.
bitPico [10:48 PM] :sleeping:
kekalot [1:35 AM] Seems likely. They were also the one who claimed segwit 2x would continue after it was officially canceled. Matt Drollette I’m beginning to wonder if @bitPico is actually performing a meta-attack on Lightning. A denial-of-service at the developer level with all this subtle trolling Posted in #lightning-network Mar 18th
bitcoinhunter [3:07 AM] So you put down the network @bitPico or just DDosing dev`s time ?
kekalot [3:08 AM] technically youd need multiple people to be doing it to be considered DDoS this is just DoS
Mike Rizzo [7:57 AM] joined #lightning-network.
Alphonse Pace [8:31 AM] bitpico: are you bragging about attacking computer networks on here?
Bear Shark [9:54 AM] That was the funnest 5 minutes of my life. Watching a guy go from bragging about attempting a DoS to deleting the account.
aceat64 [9:56 AM] Reporting an attack vector is fine, releasing PoC code is fine, but actually DoSing a network is a crime, and to just go online and brag about it, wow The only way that could have been worse would be if they didn't use a pseudonym
Bear Shark [9:58 AM] It's fine. He was probably sitting behind 3 tor exits and 10 VPNs (edited)
chek2fire [10:09 AM] i see c-lightning is always at 80% cpu usage
Russell O'Connor [10:12 AM] Did bitPico delete their own account themselves?
kekalot [10:26 AM] @alp?
Alphonse Pace [10:27 AM] I banned. zero tolerance for illegal shit.
chek2fire [10:29 AM] and he says hitler is alive :stuck_out_tongue:
chek2fire [10:43 AM] i dont know why but the new version of lightning-c has a huge cpu usage (edited)
chek2fire [11:06 AM] is there possible not compatibility from lnd to c-lightning? i just connect bitrefil and they say that in their lnd node bitrefill payments works in my c-lightning is not working when i try to do a payment with their ln links i always get this "code" : 205, "message" : "Could not find a route", "data" : { "getroute_tries" : 2, "sendpay_tries" : 1 } }
hkjn [12:00 PM] was that just-banned bitpico the same one as this one? https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-Novembe000689.html
Russell O'Connor [12:02 PM] I believe they claimed to be. It's hard to know for sure I guess.
Matt Drollette [12:03 PM] Lest we forget.
ASM is ASM. Heap is heap. Heap is bad in this case. Stack is wise. Avoid the heap at all costs. - bitPico
Laolu Osuntokun [1:48 PM] lmao
Sent from my Space Ship
pebble [4:52 PM] joined #lightning-network.
camelCase [10:28 PM] could be possible to run two lnd nodes in sync between them? i mean wallet-wise (edited)
Justin Camarena [8:02 AM] Bitrefill getting DDos'd lol that bitpico tho
Brandy Lee Camacho [8:21 AM] joined #lightning-network.
chek2fire [8:53 AM] my c-lightning node has very high cpu usage is always at 80% in the same time bitcoin node is at 15-17%
Gregory Sanders [8:58 AM] @chek2fire could be the gossip silliness that's being worked on, or bitPico :stuck_out_tongue: probably gossip inefficiency
chek2fire [8:59 AM] maybe someone dos my node i dont know
Laolu Osuntokun [11:46 AM] time to learn how to use iptables folks
Sent from my Space Ship (edited)
camelCase [11:50 AM] anyone knows if what i asked above is possible? like running two or more nodes that replicate the wallet so you avoid having your channels offline
gonzobon [11:55 AM] https://twitter.com/alexbosworth/status/976158861722726405 Alex Bosworth ☇@alexbosworth Lightning nodes are getting DDOS'ed, rumor is that someone from the 2x effort known as "BitPico" has taken credit for this. The Lightning services I've deployed have been attacked from the start, with botnets, etc. Deploying in adversarial conditions, decentralization is hard.
Twitter Mar 20th
camelCase [11:56 AM] well... at least we know we wasn't trolling about that lol
v33r [11:58 AM] https://twitter.com/alexbosworth/status/976158861722726405
gonzobon [11:59 AM] beat you to it @v33r_ :stuck_out_tongue:
Tomislav Bradarić [12:23 PM] something something good for bitcoin but really, better to see how sturdy things are now than when lightning starts getting adopted more, like how the last rise in popularity was at the same time as blockchain spam
gonzobon [12:28 PM] andreas put it in context as a good testing opp.
Hiro Protagonist [1:04 PM] I so wanna get my old sysasmin-devops team together to start running lightning nodes under these conditions. Every website is attacked relentlessly by DoS, spoofing, etc. Defences exist but you need skills to figure out what to do.
submitted by bitsko to btc [link] [comments]

Searching for the Unicorn Cryptocurrency

Searching for the Unicorn Cryptocurrency
For someone first starting out as a cryptocurrency investor, finding a trustworthy manual for screening a cryptocurrency’s merits is nonexistent as we are still in the early, Wild West days of the cryptocurrency market. One would need to become deeply familiar with the inner workings of blockchain to be able to perform the bare minimum due diligence.
One might believe, over time, that finding the perfect cryptocurrency may be nothing short of futile. If a cryptocurrency purports infinite scalability, then it is probably either lightweight with limited features or it is highly centralized among a limited number of nodes that perform consensus services especially Proof of Stake or Delegated Proof of Stake. Similarly, a cryptocurrency that purports comprehensive privacy may have technical obstacles to overcome if it aims to expand its applications such as in smart contracts. The bottom line is that it is extremely difficult for a cryptocurrency to have all important features jam-packed into itself.
The cryptocurrency space is stuck in the era of the “dial-up internet” in a manner of speaking. Currently blockchain can’t scale – not without certain tradeoffs – and it hasn’t fully resolved certain intractable issues such as user-unfriendly long addresses and how the blockchain size is forever increasing to name two.
In other words, we haven’t found the ultimate cryptocurrency. That is, we haven’t found the mystical unicorn cryptocurrency that ushers the era of decentralization while eschewing all the limitations of traditional blockchain systems.
“But wait – what about Ethereum once it implements sharding?”
“Wouldn’t IOTA be able to scale infinitely with smart contracts through its Qubic offering?”
“Isn’t Dash capable of having privacy, smart contracts, and instantaneous transactions?”
Those thoughts and comments may come from cryptocurrency investors who have done their research. It is natural for the informed investors to invest in projects that are believed to bring cutting edge technological transformation to blockchain. Sooner or later, the sinking realization will hit that any variation of the current blockchain technology will always likely have certain limitations.
Let us pretend that there indeed exists a unicorn cryptocurrency somewhere that may or may not be here yet. What would it look like, exactly? Let us set the 5 criteria of the unicorn cryptocurrency:
Unicorn Criteria
(1) Perfectly solves the blockchain trilemma:
o Infinite scalability
o Full security
o Full decentralization
(2) Zero or minimal transaction fee
(3) Full privacy
(4) Full smart contract capabilities
(5) Fair distribution and fair governance
For each of the above 5 criteria, there would not be any middle ground. For example, a cryptocurrency with just an in-protocol mixer would not be considered as having full privacy. As another example, an Initial Coin Offering (ICO) may possibly violate criterion (5) since with an ICO the distribution and governance are often heavily favored towards an oligarchy – this in turn would defy the spirit of decentralization that Bitcoin was found on.
There is no cryptocurrency currently that fits the above profile of the unicorn cryptocurrency. Let us examine an arbitrary list of highly hyped cryptocurrencies that meet the above list at least partially. The following list is by no means comprehensive but may be a sufficient sampling of various blockchain implementations:
Bitcoin (BTC)
Bitcoin is the very first and the best known cryptocurrency that started it all. While Bitcoin is generally considered extremely secure, it suffers from mining centralization to a degree. Bitcoin is not anonymous, lacks smart contracts, and most worrisomely, can only do about 7 transactions per seconds (TPS). Bitcoin is not the unicorn notwithstanding all the Bitcoin maximalists.
Ethereum (ETH)
Ethereum is widely considered the gold standard of smart contracts aside from its scalability problem. Sharding as part of Casper’s release is generally considered to be the solution to Ethereum’s scalability problem.
The goal of sharding is to split up validating responsibilities among various groups or shards. Ethereum’s sharding comes down to duplicating the existing blockchain architecture and sharing a token. This does not solve the core issue and simply kicks the can further down the road. After all, full nodes still need to exist one way or another.
Ethereum’s blockchain size problem is also an issue as will be explained more later in this article.
As a result, Ethereum is not the unicorn due to its incomplete approach to scalability and, to a degree, security.
Dash
Dash’s masternodes are widely considered to be centralized due to their high funding requirements, and there are accounts of a pre-mine in the beginning. Dash is not the unicorn due to its questionable decentralization.
Nano
Nano boasts rightfully for its instant, free transactions. But it lacks smart contracts and privacy, and it may be exposed to well orchestrated DDOS attacks. Therefore, it goes without saying that Nano is not the unicorn.
EOS
While EOS claims to execute millions of transactions per seconds, a quick glance reveals centralized parameters with 21 nodes and a questionable governance system. Therefore, EOS fails to achieve the unicorn status.
Monero (XMR)
One of the best known and respected privacy coins, Monero lacks smart contracts and may fall short of infinite scalability due to CryptoNote’s design. The unicorn rank is out of Monero’s reach.
IOTA
IOTA’s scalability is based on the number of transactions the network processes, and so its supposedly infinite scalability would fluctuate and is subject to the whims of the underlying transactions. While IOTA’s scalability approach is innovative and may work in the long term, it should be reminded that the unicorn cryptocurrency has no middle ground. The unicorn cryptocurrency would be expected to scale infinitely on a consistent basis from the beginning.
In addition, IOTA’s Masked Authenticated Messaging (MAM) feature does not bring privacy to the masses in a highly convenient manner. Consequently, the unicorn is not found with IOTA.

PascalCoin as a Candidate for the Unicorn Cryptocurrency
Please allow me to present a candidate for the cryptocurrency unicorn: PascalCoin.
According to the website, PascalCoin claims the following:
“PascalCoin is an instant, zero-fee, infinitely scalable, and decentralized cryptocurrency with advanced privacy and smart contract capabilities. Enabled by the SafeBox technology to become the world’s first blockchain independent of historical operations, PascalCoin possesses unlimited potential.”
The above summary is a mouthful to be sure, but let’s take a deep dive on how PascalCoin innovates with the SafeBox and more. Before we do this, I encourage you to first become acquainted with PascalCoin by watching the following video introduction:
https://www.youtube.com/watch?time_continue=4&v=F25UU-0W9Dk
The rest of this section will be split into 10 parts in order to illustrate most of the notable features of PascalCoin. Naturally, let’s start off with the SafeBox.
Part #1: The SafeBox
Unlike traditional UTXO-based cryptocurrencies in which the blockchain records the specifics of each transaction (address, sender address, amount of funds transferred, etc.), the blockchain in PascalCoin is only used to mutate the SafeBox. The SafeBox is a separate but equivalent cryptographic data structure that snapshots account balances. PascalCoin’s blockchain is comparable to a machine that feeds the most important data – namely, the state of an account – into the SafeBox. Any node can still independently compute and verify the cumulative Proof-of-Work required to construct the SafeBox.
The PascalCoin whitepaper elegantly highlights the unique historical independence that the SafeBox possesses:
“While there are approaches that cryptocurrencies could use such as pruning, warp-sync, "finality checkpoints", UTXO-snapshotting, etc, there is a fundamental difference with PascalCoin. Their new nodes can only prove they are on most-work-chain using the infinite history whereas in PascalCoin, new nodes can prove they are on the most-work chain without the infinite history.”
Some cryptocurrency old-timers might instinctively balk at the idea of full nodes eschewing the entire history for security, but such a reaction would showcase a lack of understanding on what the SafeBox really does.
A concrete example would go a long way to best illustrate what the SafeBox does. Let’s say I input the following operations in my calculator:
5 * 5 – 10 / 2 + 5
It does not take a genius to calculate the answer, 25. Now, the expression “5 \ 5 – 10 / 2 + 5”* would be forever imbued on a traditional blockchain’s history. But the SafeBox begs to differ. It says that the expression “5 \ 5 – 10 / 2 + 5”* should instead be simply “25” so as preserve simplicity, time, and space. In other words, the SafeBox simply preserves the account balance.
But some might still be unsatisfied and claim that if one cannot trace the series of operations (transactions) that lead to the final number (balance) of 25, the blockchain is inherently insecure.
Here are four important security aspects of the SafeBox that some people fail to realize:
(1) SafeBox Follows the Longest Chain of Proof-of-Work
The SafeBox mutates itself per 100 blocks. Each new SafeBox mutation must reference both to the previous SafeBox mutation and the preceding 100 blocks in order to be valid, and the resultant hash of the new mutated SafeBox must then be referenced by each of the new subsequent blocks, and the process repeats itself forever.
The fact that each new SafeBox mutation must reference to the previous SafeBox mutation is comparable to relying on the entire history. This is because the previous SafeBox mutation encapsulates the result of cumulative entire history except for the 100 blocks which is why each new SafeBox mutation requires both the previous SafeBox mutation and the preceding 100 blocks.
So in a sense, there is a single interconnected chain of inflows and outflows, supported by Byzantine Proof-of-Work consensus, instead of the entire history of transactions.
More concretely, the SafeBox follows the path of the longest chain of Proof-of-Work simply by design, and is thus cryptographically equivalent to the entire history even without tracing specific operations in the past. If the chain is rolled back with a 51% attack, only the attacker’s own account(s) in the SafeBox can be manipulated as is explained in the next part.
(2) A 51% Attack on PascalCoin Functions the Same as Others
A 51% attack on PascalCoin would work in a similar way as with other Proof-of-Work cryptocurrencies. An attacker cannot modify a transaction in the past without affecting the current SafeBox hash which is accepted by all honest nodes.
Someone might claim that if you roll back all the current blocks plus the 100 blocks prior to the SafeBox’s mutation, one could create a forged SafeBox with different balances for all accounts. This would be incorrect as one would be able to manipulate only his or her own account(s) in the SafeBox with a 51% attack – just as is the case with other UTXO cryptocurrencies. The SafeBox stores the balances of all accounts which are in turn irreversibly linked only to their respective owners’ private keys.
(3) One Could Preserve the Entire History of the PascalCoin Blockchain
No blockchain data in PascalCoin is ever deleted even in the presence of the SafeBox. Since the SafeBox is cryptographically equivalent to a full node with the entire history as explained above, PascalCoin full nodes are not expected to contain infinite history. But for whatever reason(s) one may have, one could still keep all the PascalCoin blockchain history as well along with the SafeBox as an option even though it would be redundant.
Without storing the entire history of the PascalCoin blockchain, you can still trace the specific operations of the 100 blocks prior to when the SafeBox absorbs and reflects the net result (a single balance for each account) from those 100 blocks. But if you’re interested in tracing operations over a longer period in the past – as redundant as that may be – you’d have the option to do so by storing the entire history of the PascalCoin blockchain.
(4) The SafeBox is Equivalent to the Entire Blockchain History
Some skeptics may ask this question: “What if the SafeBox is forever lost? How would you be able to verify your accounts?” Asking this question is tantamount to asking to what would happen to Bitcoin if all of its entire history was erased. The result would be chaos, of course, but the SafeBox is still in line with the general security model of a traditional blockchain with respect to black swans.
Now that we know the security of the SafeBox is not compromised, what are the implications of this new blockchain paradigm? A colorful illustration as follows still wouldn’t do justice to the subtle revolution that the SafeBox ushers. The automobiles we see on the street are the cookie-and-butter representation of traditional blockchain systems. The SafeBox, on the other hand, supercharges those traditional cars to become the Transformers from Michael Bay’s films.
The SafeBox is an entirely different blockchain architecture that is impressive in its simplicity and ingenuity. The SafeBox’s design is only the opening act for PascalCoin’s vast nuclear arsenal. If the above was all that PascalCoin offers, it still wouldn’t come close to achieving the unicorn status but luckily, we have just scratched the surface. Please keep on reading on if you want to learn how PascalCoin is going to shatter the cryptocurrency industry into pieces. Buckle down as this is going to be a long read as we explore further about the SafeBox’s implications.
Part #2: 0-Confirmation Transactions
To begin, 0-confirmation transactions are secure in PascalCoin thanks to the SafeBox.
The following paraphrases an explanation of PascalCoin’s 0-confirmations from the whitepaper:
“Since PascalCoin is not a UTXO-based currency but rather a State-based currency thanks to the SafeBox, the security guarantee of 0-confirmation transactions are much stronger than in UTXO-based currencies. For example, in Bitcoin if a merchant accepts a 0-confirmation transaction for a coffee, the buyer can simply roll that transaction back after receiving the coffee but before the transaction is confirmed in a block. The way the buyer does this is by re-spending those UTXOs to himself in a new transaction (with a higher fee) thus invalidating them for the merchant. In PascalCoin, this is virtually impossible since the buyer's transaction to the merchant is simply a delta-operation to debit/credit a quantity from/to accounts respectively. The buyer is unable to erase or pre-empt this two-sided, debit/credit-based transaction from the network’s pending pool until it either enters a block for confirmation or is discarded with respect to both sender and receiver ends. If the buyer tries to double-spend the coffee funds after receiving the coffee but before they clear, the double-spend transaction will not propagate the network since nodes cannot propagate a double-spending transaction thanks to the debit/credit nature of the transaction. A UTXO-based transaction is initially one-sided before confirmation and therefore is more exposed to one-sided malicious schemes of double spending.”
Phew, that explanation was technical but it had to be done. In summary, PascalCoin possesses the only secure 0-confirmation transactions in the cryptocurrency industry, and it goes without saying that this means PascalCoin is extremely fast. In fact, PascalCoin is capable of 72,000 TPS even prior to any additional extensive optimizations down the road. In other words, PascalCoin is as instant as it gets and gives Nano a run for its money.
Part #3: Zero Fee
Let’s circle back to our discussion of PascalCoin’s 0-confirmation capability. Here’s a little fun magical twist to PascalCoin’s 0-confirmation magic: 0-confirmation transactions are zero-fee. As in you don’t pay a single cent in fee for each 0-confirmation! There is just a tiny downside: if you create a second transaction in a 5-minute block window then you’d need to pay a minimal fee. Imagine using Nano but with a significantly stronger anti-DDOS protection for spam! But there shouldn’t be any complaint as this fee would amount to 0.0001 Pascal or $0.00002 based on the current price of a Pascal at the time of this writing.
So, how come the fee for blazingly fast transactions is nonexistent? This is where the magic of the SafeBox arises in three ways:
(1) PascalCoin possesses the secure 0-confirmation feature as discussed above that enables this speed.
(2) There is no fee bidding competition of transaction priority typical in UTXO cryptocurrencies since, once again, PascalCoin operates on secure 0-confirmations.
(3) There is no fee incentive needed to run full nodes on behalf of the network’s security beyond the consensus rewards.
Part #4: Blockchain Size
Let’s expand more on the third point above, using Ethereum as an example. Since Ethereum’s launch in 2015, its full blockchain size is currently around 2 TB, give or take, but let’s just say its blockchain size is 100 GB for now to avoid offending the Ethereum elitists who insist there are different types of full nodes that are lighter. Whoever runs Ethereum’s full nodes would expect storage fees on top of the typical consensus fees as it takes significant resources to shoulder Ethereum’s full blockchain size and in turn secure the network. What if I told you that PascalCoin’s full blockchain size will never exceed few GBs after thousands of years? That is just what the SafeBox enables PascalCoin to do so. It is estimated that by 2072, PascalCoin’s full nodes will only be 6 GB which is low enough not to warrant any fee incentives for hosting full nodes. Remember, the SafeBox is an ultra-light cryptographic data structure that is cryptographically equivalent to a blockchain with the entire transaction history. In other words, the SafeBox is a compact spreadsheet of all account balances that functions as PascalCoin’s full node!
Not only does the SafeBox’s infinitesimal memory size helps to reduce transaction fees by phasing out any storage fees, but it also paves the way for true decentralization. It would be trivial for every PascalCoin user to opt a full node in the form of a wallet. This is extreme decentralization at its finest since the majority of users of other cryptocurrencies ditch full nodes due to their burdensome sizes. It is naïve to believe that storage costs would reduce enough to the point where hosting full nodes are trivial. Take a look at the following chart outlining the trend of storage cost.

* https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/
As we can see, storage costs continue to decrease but the descent is slowing down as is the norm with technological improvements. In the meantime, blockchain sizes of other cryptocurrencies are increasing linearly or, in the case of smart contract engines like Ethereum, parabolically. Imagine a cryptocurrency smart contract engine like Ethereum garnering worldwide adoption; how do you think Ethereum’s size would look like in the far future based on the following chart?


https://i.redd.it/k57nimdjmo621.png

Ethereum’s future blockchain size is not looking pretty in terms of sustainable security. Sharding is not a fix for this issue since there still needs to be full nodes but that is a different topic for another time.
It is astonishing that the cryptocurrency community as a whole has passively accepted this forever-expanding-blockchain-size problem as an inescapable fate.
PascalCoin is the only cryptocurrency that has fully escaped the death vortex of forever expanding blockchain size. Its blockchain size wouldn’t exceed 10 GB even after many hundreds of years of worldwide adoption. Ethereum’s blockchain size after hundreds of years of worldwide adoption would make fine comedy.
Part #5: Simple, Short, and Ordinal Addresses
Remember how the SafeBox works by snapshotting all account balances? As it turns out, the account address system is almost as cool as the SafeBox itself.
Imagine yourself in this situation: on a very hot and sunny day, you’re wandering down the street across from your house and ran into a lemonade stand – the old-fashioned kind without any QR code or credit card terminal. The kid across you is selling a lemonade cup for 1 Pascal with a poster outlining the payment address as 5471-55. You flip out your phone and click “Send” with 1 Pascal to the address 5471-55; viola, exactly one second later you’re drinking your lemonade without paying a cent for the transaction fee!
The last thing one wants to do is to figure out how to copy/paste to, say, the following address 1BoatSLRHtKNngkdXEeobR76b53LETtpyT on the spot wouldn’t it? Gone are the obnoxiously long addresses that plague all cryptocurrencies. The days of those unreadable addresses will be long gone – it has to be if blockchain is to innovate itself for the general public. EOS has a similar feature for readable addresses but in a very limited manner in comparison, and nicknames attached to addresses in GUIs don’t count since blockchain-wide compatibility wouldn’t hold.
Not only does PascalCoin has the neat feature of having addresses (called PASAs) that amount to up to 6 or 7 digits, but PascalCoin can also incorporate in-protocol address naming as opposed to GUI address nicknames. Suppose I want to order something from Amazon using Pascal; I simply search the word “Amazon” then the corresponding account number shows up. Pretty neat, right?
The astute reader may gather that PascalCoin’s address system makes it necessary to commoditize addresses, and he/she would be correct. Some view this as a weakness; part #10 later in this segment addresses this incorrect perception.
Part #6: Privacy
As if the above wasn’t enough, here’s another secret that PascalCoin has: it is a full-blown privacy coin. It uses two separate foundations to achieve comprehensive anonymity: in-protocol mixer for transfer amounts and zn-SNARKs for private balances. The former has been implemented and the latter is on the roadmap. Both the 0-confirmation transaction and the negligible transaction fee would make PascalCoin the most scalable privacy coin of any other cryptocurrencies pending the zk-SNARKs implementation.
Part #7: Smart Contracts
Next, PascalCoin will take smart contracts to the next level with a layer-2 overlay consensus system that pioneers sidechains and other smart contract implementations.
In formal terms, this layer-2 architecture will facilitate the transfer of data between PASAs which in turn allows clean enveloping of layer-2 protocols inside layer-1 much in the same way that HTTP lives inside TCP.
To summarize:
· The layer-2 consensus method is separate from the layer-1 Proof-of-Work. This layer-2 consensus method is independent and flexible. A sidechain – based on a single encompassing PASA – could apply Proof-of-Stake (POS), Delegated Proof-of-Stake (DPOS), or Directed Acyclic Graph (DAG) as the consensus system of its choice.
· Such a layer-2 smart contract platform can be written in any languages.
· Layer-2 sidechains will also provide very strong anonymity since funds are all pooled and keys are not used to unlock them.
· This layer-2 architecture is ingenious in which the computation is separate from layer-2 consensus, in effect removing any bottleneck.
· Horizontal scaling exists in this paradigm as there is no interdependence between smart contracts and states are not managed by slow sidechains.
· Speed and scalability are fully independent of PascalCoin.
One would be able to run the entire global financial system on PascalCoin’s infinitely scalable smart contract platform and it would still scale infinitely. In fact, this layer-2 architecture would be exponentially faster than Ethereum even after its sharding is implemented.
All this is the main focus of PascalCoin’s upcoming version 5 in 2019. A whitepaper add-on for this major upgrade will be released in early 2019.
Part #8: RandomHash Algorithm
Surely there must be some tradeoffs to PascalCoin’s impressive capabilities, you might be asking yourself. One might bring up the fact that PascalCoin’s layer-1 is based on Proof-of-Work and is thus susceptible to mining centralization. This would be a fallacy as PascalCoin has pioneered the very first true ASIC, GPU, and dual-mining resistant algorithm known as RandomHash that obliterates anything that is not CPU based and gives all the power back to solo miners.
Here is the official description of RandomHash:
“RandomHash is a high-level cryptographic hash algorithm that combines other well-known hash primitives in a highly serial manner. The distinguishing feature is that calculations for a nonce are dependent on partial calculations of other nonces, selected at random. This allows a serial hasher (CPU) to re-use these partial calculations in subsequent mining saving 50% or more of the work-load. Parallel hashers (GPU) cannot benefit from this optimization since the optimal nonce-set cannot be pre-calculated as it is determined on-the-fly. As a result, parallel hashers (GPU) are required to perform the full workload for every nonce. Also, the algorithm results in 10x memory bloat for a parallel implementation. In addition to its serial nature, it is branch-heavy and recursive making in optimal for CPU-only mining.”
One might be understandably skeptical of any Proof-of-Work algorithm that solves ASIC and GPU centralization once for all because there have been countless proposals being thrown around for various algorithms since the dawn of Bitcoin. Is RandomHash truly the ASIC & GPU killer that it claims to be?
Herman Schoenfeld, the inventor behind RandomHash, described his algorithm in the following:
“RandomHash offers endless ASIC-design breaking surface due to its use of recursion, hash algo selection, memory hardness and random number generation.
For example, changing how round hash selection is made and/or random number generator algo and/or checksum algo and/or their sequencing will totally break an ASIC design. Conceptually if you can significantly change the structure of the output assembly whilst keeping the high-level algorithm as invariant as possible, the ASIC design will necessarily require proportional restructuring. This results from the fact that ASIC designs mirror the ASM of the algorithm rather than the algorithm itself.”
Polyminer1 (pseudonym), one of the members of the PascalCoin core team who developed RHMiner (official software for mining RandomHash), claimed as follows:
“The design of RandomHash is, to my experience, a genuine innovation. I’ve been 30 years in the field. I’ve rarely been surprised by anything. RandomHash was one of my rare surprises. It’s elegant, simple, and achieves resistance in all fronts.”
PascalCoin may have been the first party to achieve the race of what could possibly be described as the “God algorithm” for Proof-of-Work cryptocurrencies. Look no further than one of Monero’s core developers since 2015, Howard Chu. In September 2018, Howard declared that he has found a solution, called RandomJS, to permanently keep ASICs off the network without repetitive algorithm changes. This solution actually closely mirrors RandomHash’s algorithm. Discussing about his algorithm, Howard asserted that “RandomJS is coming at the problem from a direction that nobody else is.”
Link to Howard Chu’s article on RandomJS:
https://www.coindesk.com/one-musicians-creative-solution-to-drive-asics-off-monero
Yet when Herman was asked about Howard’s approach, he responded:
“Yes, looks like it may work although using Javascript was a bit much. They should’ve just used an assembly subset and generated random ASM programs. In a way, RandomHash does this with its repeated use of random mem-transforms during expansion phase.”
In the end, PascalCoin may have successfully implemented the most revolutionary Proof-of-Work algorithm, one that eclipses Howard’s burgeoning vision, to date that almost nobody knows about. To learn more about RandomHash, refer to the following resources:
RandomHash whitepaper:
https://www.pascalcoin.org/storage/whitepapers/RandomHash_Whitepaper.pdf
Technical proposal for RandomHash:
https://github.com/PascalCoin/PascalCoin/blob/mastePIP/PIP-0009.md
Someone might claim that PascalCoin still suffers from mining centralization after RandomHash, and this is somewhat misleading as will be explained in part #10.
Part #9: Fair Distribution and Governance
Not only does PascalCoin rest on superior technology, but it also has its roots in the correct philosophy of decentralized distribution and governance. There was no ICO or pre-mine, and the developer fund exists as a percentage of mining rewards as voted by the community. This developer fund is 100% governed by a decentralized autonomous organization – currently facilitated by the PascalCoin Foundation – that will eventually be transformed into an autonomous smart contract platform. Not only is the developer fund voted upon by the community, but PascalCoin’s development roadmap is also voted upon the community via the Protocol Improvement Proposals (PIPs).
This decentralized governance also serves an important benefit as a powerful deterrent to unseemly fork wars that befall many cryptocurrencies.
Part #10: Common Misconceptions of PascalCoin
“The branding is terrible”
PascalCoin is currently working very hard on its image and is preparing for several branding and marketing initiatives in the short term. For example, two of the core developers of the PascalCoin recently interviewed with the Fox Business Network. A YouTube replay of this interview will be heavily promoted.
Some people object to the name PascalCoin. First, it’s worth noting that PascalCoin is the name of the project while Pascal is the name of the underlying currency. Secondly, Google and YouTube received excessive criticisms back then in the beginning with their name choices. Look at where those companies are nowadays – surely a somewhat similar situation faces PascalCoin until the name’s familiarity percolates into the public.
“The wallet GUI is terrible”
As the team is run by a small yet extremely dedicated developers, multiple priorities can be challenging to juggle. The lack of funding through an ICO or a pre-mine also makes it challenging to accelerate development. The top priority of the core developers is to continue developing full-time on the groundbreaking technology that PascalCoin offers. In the meantime, an updated and user-friendly wallet GUI has been worked upon for some time and will be released in due time. Rome wasn’t built in one day.
“One would need to purchase a PASA in the first place”
This is a complicated topic since PASAs need to be commoditized by the SafeBox’s design, meaning that PASAs cannot be obtained at no charge to prevent systematic abuse. This raises two seemingly valid concerns:
· As a chicken and egg problem, how would one purchase a PASA using Pascal in the first place if one cannot obtain Pascal without a PASA?
· How would the price of PASAs stay low and affordable in the face of significant demand?
With regards to the chicken and egg problem, there are many ways – some finished and some unfinished – to obtain your first PASA as explained on the “Get Started” page on the PascalCoin website:
https://www.pascalcoin.org/get_started
More importantly, however, is the fact that there are few methods that can get your first PASA for free. The team will also release another method soon in which you could obtain your first PASA for free via a single SMS message. This would probably become by far the simplest and the easiest way to obtain your first PASA for free. There will be more new ways to easily obtain your first PASA for free down the road.
What about ensuring the PASA market at large remains inexpensive and affordable following your first (and probably free) PASA acquisition? This would be achieved in two ways:
· Decentralized governance of the PASA economics per the explanation in the FAQ section on the bottom of the PascalCoin website (https://www.pascalcoin.org/)
· Unlimited and free pseudo-PASAs based on layer-2 in the next version release.
“PascalCoin is still centralized after the release of RandomHash”
Did the implementation of RandomHash from version 4 live up to its promise?
The official goals of RandomHash were as follow:
(1) Implement a GPU & ASIC resistant hash algorithm
(2) Eliminate dual mining
The two goals above were achieved by every possible measure.
Yet a mining pool, Nanopool, was able to regain its hash majority after a significant but a temporary dip.
The official conclusion is that, from a probabilistic viewpoint, solo miners are more profitable than pool miners. However, pool mining is enticing for solo miners who 1) have limited hardware as it ensures a steady income instead of highly profitable but probabilistic income via solo mining, and 2) who prefer convenient software and/or GUI.
What is the next step, then? While the barrier of entry for solo miners has successfully been put down, additional work needs to be done. The PascalCoin team and the community are earnestly investigating additional steps to improve mining decentralization with respect to pool mining specifically to add on top of RandomHash’s successful elimination of GPU, ASIC, and dual-mining dominance.
It is likely that the PascalCoin community will promote the following two initiatives in the near future:
(1) Establish a community-driven, nonprofit mining pool with attractive incentives.
(2) Optimize RHMiner, PascalCoin’s official solo mining software, for performance upgrades.
A single pool dominance is likely short lived once more options emerge for individual CPU miners who want to avoid solo mining for whatever reason(s).
Let us use Bitcoin as an example. Bitcoin mining is dominated by ASICs and mining pools but no single pool is – at the time of this writing – even close on obtaining the hash majority. With CPU solo mining being a feasible option in conjunction with ASIC and GPU mining eradication with RandomHash, the future hash rate distribution of PascalCoin would be far more promising than Bitcoin’s hash rate distribution.
PascalCoin is the Unicorn Cryptocurrency
If you’ve read this far, let’s cut straight to the point: PascalCoin IS the unicorn cryptocurrency.
It is worth noting that PascalCoin is still a young cryptocurrency as it was launched at the end of 2016. This means that many features are still work in progress such as zn-SNARKs, smart contracts, and pool decentralization to name few. However, it appears that all of the unicorn criteria are within PascalCoin’s reach once PascalCoin’s technical roadmap is mostly completed.
Based on this expository on PascalCoin’s technology, there is every reason to believe that PascalCoin is the unicorn cryptocurrency. PascalCoin also solves two fundamental blockchain problems beyond the unicorn criteria that were previously considered unsolvable: blockchain size and simple address system. The SafeBox pushes PascalCoin to the forefront of cryptocurrency zeitgeist since it is a superior solution compared to UTXO, Directed Acyclic Graph (DAG), Block Lattice, Tangle, and any other blockchain innovations.


THE UNICORN

Author: Tyler Swob
submitted by Kosass to CryptoCurrency [link] [comments]

Notes from Ethereum Core Devs Meeting #31 [1/12/18]

The next core dev meeting will be this Friday, January 26, 2018. The agenda and live stream link are located here.

Ethereum Core Devs Meeting 31 Notes

Meeting Date/Time: Friday 01/12/18 at 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Reddit thread

Agenda

  1. Testing Updates.
  2. Yellow paper update.
  3. EWASM update + update on the following related EIPs. a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48 b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174 c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615
  4. Stateless client development.
  5. Add ECADD and ECMUL precompiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].
  6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).
  7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.
  8. Fork release management/Constantinople.
  9. Client updates.
  10. Other non-agenda issues.

Notes

Video starts at [4:36].

[4:56] 1. Testing Updates

No updates.

[5:27] 2. Yellow paper update.

Gavin put the Yellow Paper under the Creative Commons Free Culture License CC-BY-SA. Yoichi and Nick Savers have been making progress handling the Yellow Paper PRs. There is still the somewhat unresolved issue of what should define the "formal standard" of Ethereum and should an update to the Yellow Paper or another specification be required for every new EIP. This can be discussed in more detail in future meetings when there is greater attendance.

[7:43] 3. EWASM update + update on the following related EIPs.

[7:55] General update

Ewasm contributors are currently meeting in person together in Lisbon. EWASM EIPs listed in the subpoints are not up to date and can be disregarded. People should use the github.com/EWASM/design repo. The design has been pretty much speced out in the last year. During the design phase there were 2 implementations done in parallel: Javascript and C++ (which can be integrated in cpp-ethereum and geth). Issues have been faced in building out EWASM including struggling with implementing synchronous code in Javascript/browser. Idea was to move to an asynchronous model. Currently there is not a full decision on using synchronous vs asynchronous, but we are leaning towards synchronous implementation in C++ to run a testnet in cpp-ethereum that can run pure Web Assembly contracts. Metering contract in Web Assembly is on the to-do list and doesn't rely on sync/async decision. Likely will take week to come to a decision on sync vs async. More technical discussion and a funny anecdote involving the asynchronous vs synchronous decision and the affects of the recent Spectre/Meltdown attacks start at [12:07].

[15:08] a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48

Martin Becze will be closing this EIP. It is outdated.

[15:28] b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174

This doesn't have to do with EWASM, it has to do with adding extra opcodes in the current EVM. It is an upgrade to EVM 1.0 which is not needed if we skip straight to EWASM.

[16:47] c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615

Greg has been working with Seed (Gitter tag) who is writing an ELM formalization of the EIP. Greg says that there is no formal social process for deciding things like EVM 1.5 implementation so he is not sure if/when it would be implemented. Greg has been working on cleaning up the proposal for those who want to use it. Greg has some ideas around an EVM 3.0 that pulls everything together with transpilation that he hasn't started working on yet and is not sure if he will.

[20:14] 4. Stateless client development.

Piper left some comments about some development of a stateless client for sharding, but it is very early. Alexey had a blog post describing stateless clients he may re-approach later.

[21:46] 5. Add ECADD and ECMUL pre-compiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].

This topic was brought up months ago with mixed commentary. Christian R. says that ECADD and ECMUL were never intended to be used for general purpose cryptography, but rather it was suppose to be used in conjunction with the pairing pre-compiles for a specific curve that is pairing friendly. Christian says that in the past it has been discussed that there must be a very compelling reason for adding a pre-compile to Ethereum. Silur mentioned that the Monero research team is working on a new ring signature (still unnamed) that can be viewed in the Monero repository. The EWASM team may run some tests to compare native running of the pre-compiles vs EWASM. Adding a new pre-compile would only give a constant speed-up or reduction in cost, but if we achieve the same thing in new virtual machine it will give us a constant speed-up for every conceivable routine and allows for building other schemes like Casper and TrueBit. This is easier with Web Assembly because we can use existing C code. For the moment it looks like focusing energy on adding these proposed pre-compiles would not be worth it compared to just waiting for the next VM (likely EWASM) which will allow far more speed-ups across all computational routines.

[37:00] 6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).

[Note: I tried my best to cover what was discussed here, but I am not an expert in Ethereum transactions. If you find a mistake please point it out to me. Thanks!] Agenda item brought up to get people's opinion on this topic. Currently in Ethereum there are transactions that are stuck in the mempool for a long time because of the way transaction ordering per account is handled. The nonce of a transaction must be greater than the previous mined transactions (or equal if you are trying to replace a transaction). For example you can't process transaction #27 before transaction #26 has been mined. Many of the stuck transactions are dependent on other transactions that pay a much smaller fee, but are not being mined. It seems people inadvertently send an initial transaction with too small of a fee and then more transactions at a higher nonce with a much higher fee that cannot be processed until the first small fee transaction is processed. Alexey wondered if this may pose an attack vector or if we would get a benefit from implementing "child pays for parent" like Bitcoin does. Peter explained even if you define the max amount of gas your transaction could potentially consume, there is no guarantee it will use that much and we won't know until the transaction is processed (the only guarantee is that 21,000 gas will be consumed - a plain ether transfer). The attack vector example would be someone pushing a transaction that truly consumes 3,000,000 gas and attach a transaction fee of 1 wei and then push another TX that claims to consume 3,000,000 gas but with a transaction fee of 1000gwei. From the outside it looks like I can both can be executed for profit from the miner's perspective, but in reality the 2nd transaction will be processed first and the 1st tx will be long running and indirectly punish the miner. Alexey was concerned about the mempool filling up and impact on clients due to the way nonces are handled. Peter clarified that transactions in the mempool in the go ethereum client only maintains the top 4,000 most expensive transactions. If your cheap transaction gets evicted, the expensive transactions you stacked on top of it get evicted as well because they are no longer executable due to the nonce.

[42:21] 7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.

A relay network in general is a group of peers and/or miners who use a peer list to quickly connect to a group of known peers before connecting to (or instead of connecting to) random peers using network discovery. Alexey conjectured that this may create a powerful ring of network players who can share transactions very quickly and hurt the little guys on the outside (hurting the idea of this being a mesh network of peers). Clarifications were made about the issues involving transaction propagation issues with nodes with high transaction throughput such as Infura and Bittrex. Clients suddenly stop pushing transactions or cannot keep up with the blockchain when they are pushing out so many transactions. Hudson will work towards exploring this issue more and connecting the people with the issues with the devs.

[49:45] 8. Fork release management/Constantinople.

Hudson will be working on writing up a starting plan to discuss potential release management issues. BitsBeTripping sent Hudson some good material about project management that he will review and bring to the next meeting. We need to start discussing Constantinople sooner rather than later.

[52:55] 9. Client updates.

10. Other non-agenda items

[1:05:42] Question: Will we see any scaling improvements from Constantinople?

Answer is no because it potentially includes the first steps of the Casper consensus protocol and some account abstraction EIPs, but both of those do not alleviate scaling issues. Sharding would alleviate some of the issues. We are currently mostly bound by database and processing speed due to the database. Short term there are a lot of client improvements that can be accomplished to improve disk I/O, but long term things like sharding will be necessary. The Eth Research site has a lot of interesting threads about sharding including merkle tree formats to be used and ideas around asynchronous accumulators

[1:09:57] Decision process for EIPs?

Needs to be improved. Hudson and others will work on updating EIP #1 and other improvements in Q1. Nick Savers has been added as an EIP editor. Yoichi has been added as an editor. Both are doing a great job.

Attendance

Alex Beregszaszi (EWASM/Solidity/ethereumJS), Alex Van de Sande (Mist/Ethereum Wallet), Alexey Akhunov (Turbo Geth), Ben Edgington (Consensys/Pegasys), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daniel Ellison (Consensys/LLL), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Hugo de la Cruz (ethereumJS/EWASM), Jake Lang (EWASM), Jared Wasinger (ethereumJS/EWASM), Martin Becze (EWASM), Mikhail Kalinin (Harmony), Paweł Bylica (cpp-ethereum/EWASM), Péter Szilágyi (geth), Silur (ethereumJS / EWASM)
submitted by Souptacular to ethereum [link] [comments]

Zcash4win & Zcash4mac MEGATHREAD

This thread is for users to find information that is spread across many threads since zcash4win and zcash4mac are now depreciated.
What happened:
David Mercer the developer who worked on zcash4win and zcash4mac has decided stop allowing downloads of these (which are stuck on old versions) so it doesn't confuse new users since they not up-to-date. David is not part of Zcash Company and his software is open source. The only "Official" Zcash software is the Linux version.
Why
Rather than continue to update the zcash4win and zcash4mac code he has decided to create new wallet/node software from the ground up so it will be a better codebase/GUI and easier to update for the future. The new version will be called "winzec" and available at winzec.com when it is done.
What does this mean for zcash4win and zcash4mac users?
If you are currently running zcash4win or zcash4mac you don't need to do anything. The zcash4win and zcash4mac are just not available to download, they will continue to work until the Hard Fork expected in a few months.
Are the funds I have in zcash4win or zcash4mac lost?
No, remember the way all Blockchains like Zcash and Bitcoin work is that coins are on the Blockchain at all times. Your wallet has the Public and Private keys that allow you to spend from the addresses you control.
Help my wallet won't start!
Since the zcash4win version is version 1.0.12 (and the latest version is 1.0.15) you need to add disabledeprecation=1.0.12 to the configuration file as explained in this thread: https://forum.z.cash/t/required-config-change-for-zcash4win-1-0-12/26632
There is a Video of how to do this Here: https://youtu.be/VT06Nh6TTzw
This will keep the node from auto-depreciation and allow you to still use it until a the new version comes out or the Hard Fork when you will need to switch wallets.
If you do the above steps and it still won't sync you may have to reindex your chain:
Open a Command window and try:
C:\Program Files\zcash4win\app\zcashd.exe -reindex -daemon=0
NOTE: The above line is just an example and will need to be tweaked depending on your computers users/app location/etc..
If you are not familiar with how to run something from a Command line please see this tutorial: https://m.wikihow.com/Run-a-Program-on-Command-Prompt
What if I want to switch wallets?
To switch wallets you first need to determine if you want to use or have funds in a private address.
If you don't have funds in a private address and don't want to use private addresses then you can transfer your funds to many other wallets like Jaxx or a hardware wallet like a Ledger Nano.
I have a list of wallets here: https://www.zcashcommunity.com/wallets/
If you do have funds in a private address and don't want to send them to a transparent address read on:
Step 1 is setting up a new full node. You can install the Zcash Official Linux Client via this guide: https://github.com/zcash/zcash/wiki/1.0-User-Guide
There are several Videos on how install Zcash on Linux here:
https://youtu.be/5ahQZZYcntQ https://youtu.be/9-P7IHC7d-o https://youtu.be/noiPWhPT6sk
I have an very old written step-by-step tutorial about how to set up a VM and install Linux & Zcash here: https://minezcash.com/how-to-mine-zcash-part1/ (just ignore the last "mining steps)
Step 2 Is once you have a new Node running you have two choices: You can generate a new address to send the funds to the new wallet or transfer the wallet.dat file to the new node.
Instructions to get a backup of your wallet from zcash4win are here:
https://youtu.be/JGtpUnHTf2w
You can use that wallet.dat to restore your funds to any full node wallet Linux Windows or Mac.
The best part about running a the official client is that you can update as soon as an update is available directly from the Zcash developers! No more waiting for third party developers to push an update.
While you are here, take a second to backup your wallet.dat file to somewhere safe, preferably offline or on a separate computeUSB so in case of disaster you won't lose everything.
Please feel free to post questions in this thread, new threads on this subject will be closed and re-directed to this thread.
submitted by minezcash to zec [link] [comments]

Transcript of Open Developer Meeting In Discord - 5/10/2019

[Dev-Happy] Blondfrogs05/10/2019
Channel should be open now
Chill05/10/2019
you all rock!
just getting that out of the way :wink:
Tron05/10/2019
Cheers everyone.
theking05/10/2019
Hi fabulous dev team!
Hans_Schmidt05/10/2019
Howdy!
Tron05/10/2019
No specific agenda today.
Questions?
Has everyone seen Zelcore wallet, and Spend app?
theDopeMedic05/10/2019
Any major development status updates that haven't been listed in #news?
Synicide05/10/2019
How was the meetup yesterday? I heard it would be recorded, it is uploaded anywhere yet?
Tron05/10/2019
And Trezor support on Mango Farm assets?
@Synicide Yes it was recorded. The Bitcoin meetup organizer has the video.
I talked about Ravencoin, but mostly about the stuff that was being built on/with/for Ravencoin.
There was about 70% overlap with folks who were at the Ravencoin meetup in March.
Synicide05/10/2019
awesome, looking forward to watching it when it's available
Tron05/10/2019
I'll hit up James and see if he's posting the video.
S1LVA | GetRavencoin.org05/10/2019
@theDopeMedic I'd follow github if youre interested in development status
Synicide05/10/2019
zelcore looks super slick. Been meaning to research its security more with the username/pw being stored on device
Chill05/10/2019
How is the progress on the restricted assets and testnet coming along? A secondary question would be about the approximate fork timeframe.
S1LVA | GetRavencoin.org05/10/2019
Has anyone heard from the community dev (BW) working on Dividends?
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Any word on BW and his progress w dividends?
@S1LVA | GetRavencoin.org LOL
Tron05/10/2019
@S1LVA | GetRavencoin.org Great question. I haven't heard.
Synicide05/10/2019
last meeting BlondFrogs said he would try to connect with BW as he was sick with the flu at the time. Maybe he has an update
S1LVA | GetRavencoin.org05/10/2019
I've tried to get in contact, but with no success.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Got a funny feeling...
Jeroz05/10/2019
Last time we left off with someone mentioning a foundation and Tron saying let’s discuss that next time iirc
kryptoshi05/10/2019
Has anyone taken a look at the merits for this proposal? Thoughts? https://medium.com/systems-nexus/modified-x16r-algorithm-proposal-for-constant-hash-rate-in-short-time-164711dd9044
Medium
Modified X16R algorithm proposal for constant hash rate in short time
Interpretation Lens V. a0.01
Tron05/10/2019
I did see it. Does anyone think this is a problem?
Synicide05/10/2019
It looks interesting... but I'm not sure what it is trying to solve. Looking at netstats, our 1 hour average block time is perfectly 1 minute
S1LVA | GetRavencoin.org05/10/2019
Last I heard from him he expressed how important finishing the code was. I wouldnt jump to conclusions on his absence within the community.
Synicide05/10/2019
x16r by nature will fluctuate, but DGW seems to be doing a good job keeping consistent block times
Tron05/10/2019
Because of relatively broad distribution across the algorithms, the block times are fairly consistent. It is possible, but very, very unlikely to get a sequence that takes up to 4x longer, but that's super rare, and only 4 minutes.
We did some timing analysis of the algorithms early on. A few are 1/2 as long as SHA-256 and some are up to 4x longer. But when you randomly select 16 it usually comes out about even.
Synicide05/10/2019
1hr avg: 1.02min - 24hr avg: 1min
I think we should focus on building, and not trying to fix what isnt necessarily broken
Tron05/10/2019
Agreed.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Agreed
Tron05/10/2019
Is everyone ok with the frequency (every other week) of this discussion?
Jeroz05/10/2019
(Added thumbs down to measure)
Tron05/10/2019
@Jeroz Did you do thumbs-up and thumbs down?
S1LVA | GetRavencoin.org05/10/2019
Seems appropriate. Its not like the devs dont poke around here and chat anyways.
Tron05/10/2019
Anything critical that we should be aware of?
Jeroz05/10/2019
When I need a dev, I poke a dev. When that dev is unavailable. I poke another one :smiley:
Hans_Schmidt05/10/2019
BlondFrogs was testing some github code last month to create a dividends snapshot database of asset holders at a given blockheight. Is that planned for inclusion? That's the only thing needed for dividends.
Jeroz05/10/2019
I hope I didn’t offend any devs
With poking around
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Was thinking voting would be an excellent use case for restricted assets. Local communities, nations, etc... could kyc their residents
radiodub05/10/2019
Is x16r will remain fpga mineable
Tron05/10/2019
@Jeroz We're hard to offend.
Chill05/10/2019
Is the general dev feeling that the next fork should and will include everything needed for the next 6-9 months (barring something completely unforeseen)?
Jeroz05/10/2019
I know :smile:
Tron05/10/2019
@radiodub Nearly impossible to stop FPGAs and still keep GPUs
Jeroz05/10/2019
About that: voting is another hard fork right? Not too soon?
Tron05/10/2019
FPGAs can be reprogrammed as fast. It is silicon (true ASIC) that we can obsolete with a tiny change.
@Jeroz Messaging, voting, Tags, Restricted Assets would require a hard fork (upgrade).
We could do them each individually, but folks get weary of upgrades, so current plan is to roll them together into one.
MrFanelli™05/10/2019
Good idea
Jeroz05/10/2019
Oh voting too?
MrFanelli™05/10/2019
People will like that
Jeroz05/10/2019
I thought that was coming later
Tron05/10/2019
Voting is the one that isn't being worked on now. Tags and Restricted assets have taken precedence.
Jeroz05/10/2019
I know. But you plan on waiting to fork until voting is also done?
That would have my preference tbh
But I can see an issue with too many things at the same time
Tron05/10/2019
If someone wants to step in, we've had one of our devs sidelined and he was working on BlockBook support so more light wallets can connect to Ravencoin. Mostly test cases needed at this point.
S1LVA | GetRavencoin.org05/10/2019
Thats a pretty large upgrade.. Bigger surface for unknowns
Rikki RATTOE Sr. SEC Impresantor05/10/2019
At what point would RVN community consider moving to ASICs because having a Bitcoin level of security would eventually be needed?
MrFanelli™05/10/2019
Never rikki
Tron05/10/2019
@S1LVA | GetRavencoin.org 100% Lots of testing on testnet and bounties.
[Dev-Happy] Blondfrogs05/10/2019
I am here :smiley:
Tron05/10/2019
@Rikki RATTOE Sr. SEC Impresantor There's nothing inherently wrong with ASICs but it tends to centralize to data centers and less opportunity for anyone to just run their gaming rig overnight and collect RVN.
Welcome Blondfrogs
MrFanelli™05/10/2019
Asics are too expensive. If we want normal people to mine, then we cant be an asic network
Rikki RATTOE Sr. SEC Impresantor05/10/2019
@Tron True but what happens when the chain needs a Bitcoin level of protection?
Tron05/10/2019
More GPUs, more FPGAs
MrFanelli™05/10/2019
Nvidia loves ravencoin :stuck_out_tongue:
Chill05/10/2019
ok, so we are pro FPGAs
𝕿𝖍𝖊 𝕯𝖔𝖓 𝕳𝖆𝖗𝖎𝖘𝖙𝖔 CEO ∞05/10/2019
Build it and they will come
Tron05/10/2019
It's all relative. It is cost to attack. If an ASIC isn't available for rent, then only option is rental of non-allocated GPUs
Rikki RATTOE Sr. SEC Impresantor05/10/2019
@Chill Eventually everyone will need FPGAs to be profitable on RVN, at that point I don't see why we just don't make the switch to ASICs
Tron05/10/2019
Also, as much as we don't focus on price, the price does matter because it determines the amount of electricity and hardware will be deployed to get the block reward. Price increase means more security, more mining means more security means higher price.
It's a circle.
Chill05/10/2019
someone tell that to the twitter handler
HailKira05/10/2019
you guys adding seedphrase to desktop wallet?
[Dev-Happy] Blondfrogs05/10/2019
@HailKira We will, just is not a high priority right now.
MrFanelli™05/10/2019
Twitter handle wants rvn ded
Rikki RATTOE Sr. SEC Impresantor05/10/2019
I just don't see much difference between ASIC and FPGA and I'd rather have the added nethash an ASIC will provide once GPUs are virtually kicked off the network
kryptoshi05/10/2019
I'm at 11 GB future proof
Tron05/10/2019
That also limits miners to big money, not gaming rigs.
Synicide05/10/2019
@Rikki RATTOE Sr. SEC Impresantor you have to keep in mind the 'added nethash' is all relative
Rikki RATTOE Sr. SEC Impresantor05/10/2019
FPGAs will limit miners to big $$$ too IMO
Tron05/10/2019
@kryptoshi New algo x16r-12G requires 12GB :frowning:
Seal <:cricat:> Clubber05/10/2019
But sperating smaller gb cards would lead to less adoption if we ever become a mainstream coin.
Adpotion of mining that is
Chill05/10/2019
but we are a mainstream coin
Seal <:cricat:> Clubber05/10/2019
Mains stream as in what eth did
Tron05/10/2019
@Rikki RATTOE Sr. SEC Impresantor I agree. Not a perfect solution.
Steelers05/10/2019
Is this a Dev meeting or Algo meeting :smiley:
Seal <:cricat:> Clubber05/10/2019
But if we ever go mem lane. We should aim for 6 or 8gb.
Tron05/10/2019
Open to other questions.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
@Tron Probably not the time and the place to have this discussion as we stand currently but IMO we're gonna have this conversation for real eventually
Seal <:cricat:> Clubber05/10/2019
Most cards have 6gb now.
kryptoshi05/10/2019
Why 12 gb ? Such a massive jump
Seal <:cricat:> Clubber05/10/2019
^
Would also like to know
Tron05/10/2019
@kryptoshi I was joking. You said you had 11GB card.
Seal <:cricat:> Clubber05/10/2019
Haha
You got em good
I cant imaghine the face he had when he was 1gb short
Lel
Rikki RATTOE Sr. SEC Impresantor05/10/2019
That's what she said
kryptoshi05/10/2019
Hahaha
MrFanelli™05/10/2019
need a 2080ti
Seal <:cricat:> Clubber05/10/2019
How much does the VII have?
16?
[Dev-Happy] Blondfrogs05/10/2019
Any other questions you have for us?
Hans_Schmidt05/10/2019
@[Dev-Happy] Blondfrogs You were testing some github code last month to create a dividends snapshot database of asset holders at a given blockheight. Is that planned for inclusion? That's the only thing needed for dividends.
Chill05/10/2019
a dev might want to contact Crypto Chico for some 'splaining
[Dev-Happy] Blondfrogs05/10/2019
I still haven't contacted the developer that was working on dividends. Was pretty busy with some other stuff. I will contact him this next week, and see where we are at for that.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Chico doesn't do interviews, shame. Tron would be a much needed interview for his community
[Dev-Happy] Blondfrogs05/10/2019
As far as releasing dividends, I can be released at anytime the code is finished and doesn't require any voting or hardfork to occur
kryptoshi05/10/2019
Android asset aware wallet?
Seal <:cricat:> Clubber05/10/2019
Is in beta right
Tron05/10/2019
Testing went well today on Android. Nearing release.
[Dev-Happy] Blondfrogs05/10/2019
as it is a mechanism that is wallet specific
liqdmetal05/10/2019
no protocol level dividends you guys are saying?
[Dev-Happy] Blondfrogs05/10/2019
correct
Tron05/10/2019
DM me if you want to test Android with Asset support. I'll send you the .APK.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
RVN gonna be on tZero wallet? :yum:
liqdmetal05/10/2019
why not? what is the logic on non-protocol dividends
assets + protocol dividends is nirvana
[Dev-Happy] Blondfrogs05/10/2019
dividends is pretty much sending payments to addresses. Right now, you would have to do this manually. The dividends code, will allow this to be done quicker and easier.
No consensus changes are required.
Tron05/10/2019
New Android wallet is BIP44 and original Android wallet is BIP32/BIP39 so the words will not find the funds. You'll need to send them to another wallet, and then send them to new BIP44 derived address.
liqdmetal05/10/2019
we already have payments to addresses
so dividends is not a feature so much as simple wallet script
Hans_Schmidt05/10/2019
@[Dev-Happy] Blondfrogs The dividend code changes look risky'er to me than messaging. Would you consider "tags" branch test-ready?
[Dev-Happy] Blondfrogs05/10/2019
Not yet @Hans_Schmidt
Dividends is easier then you would think if coded correctly. I still haven't seen the code from the community developer. Excited to view it though.
Hans_Schmidt05/10/2019
@[Dev-Happy] Blondfrogs Sorry- I meant restricted, not dividend
kryptoshi05/10/2019
@Tron on the Android wallet, anyone successfully added their own node and got it to sync faster? Always have issues. I have a supped up node and cannot get it to work with the Android wallet...
[Dev-Happy] Blondfrogs05/10/2019
@Hans_Schmidt Oh, that makes more sense. Yes, they are very risky! That is why we are going to create a new bug bounty program for restricted assets testing.
Rikki RATTOE Sr. SEC Impresantor05/10/2019
Once the network does get flooded w FPGAs, should we even consider changing the algo a couple times a year? That would only give bitstream developers added time to hoard their creations for themselves
Kind of like they're already doing with their x16r bitstreams :yum:
kryptoshi05/10/2019
Flooded... lol... like that hardware has mass production scale like gpus...come on dude
MrFanelli™05/10/2019
Bip44 wallet? :smiley:
Rikki RATTOE Sr. SEC Impresantor05/10/2019
@kryptoshi Eventually yes, where there's $$$ to be made, people make things happen
MrFanelli™05/10/2019
So can we trade from that in the new Binance Dex when RVN get listed?
kryptoshi05/10/2019
@Rikki RATTOE Sr. SEC Impresantor Yes Soon TM lol. :soontm:
Tron05/10/2019
@kryptoshi There are some things we can do to speed it up. For a new wallet, it shouldn't need to sync. For recovered wallet, it needs to sync from beginning of BIP44 wallet support on iOS so words can be moved between the two.
Other options include grabbing the first derived address and looking it up on an explorer to see when it was first used and sync from there.
Another option is to add an optional number with the 12 words so it knows when to start syncing.
There isn't a good reason on an SPV wallet to sync before the seed was created.
kryptoshi05/10/2019
Cool. Glad you are looking at speedup options.. :right_facing_fist: :left_facing_fist:
[Dev-Happy] Blondfrogs05/10/2019
@MrFanelli™ If the binance dex support RVN deposits. I am sure you would be able to send from it
MrFanelli™05/10/2019
Has binance reached out for any info or anything?
I seen that we ranked in some voting competition they had on twitter
for an ama
Rikki RATTOE Sr. SEC Impresantor05/10/2019
I believe we'll need to create a fund of approximately $300,000 in order to get a BNB-RVN asset created and listed on the Binance FDEX
[Dev-Happy] Blondfrogs05/10/2019
In order to work with binance we need Ravencoin integrated into Blockbook.
Tron05/10/2019
@MrFanelli™ I've reached back out to Binance on the AMA.
MrFanelli™05/10/2019
Awesome :smile:
kryptoshi05/10/2019
@Tron you are a natural on the interviews... cool as a cucumber. :sunglasses:
Tron05/10/2019
Thanks @kryptoshi
[Dev-Happy] Blondfrogs05/10/2019
Cool. We are done for today.
Please don't ask us any more questions :smiley:
Tron05/10/2019
Thanks everyone!!!!
[Dev-Happy] Blondfrogs05/10/2019
Cya everyone!!
S1LVA | GetRavencoin.org05/10/2019
Cya happy feet, Thanks
Thanks Tron
Seal <:cricat:> Clubber05/10/2019
:bepbep:
submitted by mrderrik to Ravencoin [link] [comments]

Much concern: Dogecoin block chain HAS SPLIT

Hey shibes,

Much bad news. THE DOGECOIN BLOCK CHAIN HAS FORKED. This is a bad thing.

ELI5: Your client is constantly downloading blocks and processing them, which is the way that Dogecoin works. Ten days ago, the developers made a change to the Dogecoin client that raised the limit of coins in a block from 500 million to 10 billion. So now some folks are running Dogecoin clients without that change, because they are older, and some folks are running newer clients. In block 42279, a transaction that broke the rule -- containing more than 500 million DOGE -- has prevented these older clients from advancing on the correct chain and they are now working on a bad ledger.
If you are attempting to send transactions and you hit this behavior, you ARE adding transactions to the bad chain.
There is a current risk of double spending and a lot of people are working on a bad ledger, both with mining and their personal clients. STOP sending DOGE (including pool payouts) until this situation is resolved by people that know more than I do. It might appear that you are still advancing past the bad block but your client might be going down the wrong fork!
Details: My client is synced and fine, and I sent a transaction in the last few minutes, but I've heard from several friends that they are stuck on a prior block have forked off the main ledger after block 42279. Apparently, 10 days ago, there was a commit to the dogecoin client that raised the transaction limit from 500 million DOGE to 10 billion DOGE:
https://github.com/dogecoin/dogecoin/commit/2ee5cb3396df66c10fef34480a183d00e3bec635
In block 42279 a 500m DOGE transaction was submitted which broke the block chain on clients older than that commit. I have heard from three separate folks now that their clients are stuck on block 42279 advancing on a separate Dogecoin chain.
http://dogechain.info/tx/3119125a77e1bee6f0786af4e15a8eea3ba1b64081e121796b552637a76f2eb1
We have a blockchain split on our hands. Bitcoin went through one of these too. It's going to need intervention.
What do I do? Stop sending DOGE and wait. I would also suggest waiting until the mining situation is sorted out, because there is a double-spend risk right now. You can view your client's current block in the Debug menu, under Help, for the Qt client.

UPDATE 4:48 AM UTC / 11:48 PM EST

How do I know if I'm on the wrong fork?

UPDATE 5:14 AM UTC / 12:14 AM EST

The network is responding. Between block 42475 and 42480 on the good chain, the network hash rate dropped from 20 GH/sec to 15 GH/sec and the difficulty dropped from 320.3 to 253.3.
Here's my getmininginfo from 2 minutes ago:
{ "blocks" : 42502, "currentblocksize" : 0, "currentblocktx" : 0, "difficulty" : 253.32507890, "errors" : "", "generate" : false, "genproclimit" : -1, "hashespersec" : 0, "networkhashps" : 14678218267, "pooledtx" : 698, "testnet" : false } 
That's what the good chain looks like.

UPDATE 5:32 AM UTC / 12:32 AM EST

My test client that I resynced as an experiment ended up on the bad fork. There's going to need to be an intervention here similar to Bitcoin's.

UPDATE 5:50 AM UTC / 12:50 AM EST

SCAMMERS ARE ATTEMPTING TO STEAL WALLETS IN THIS THREAD. IF YOU RECEIVE A MESSAGE LIKE THIS DO NOT COMPLY. DEVELOPERS WILL NOT PM YOU TO SEND THEM YOUR FILES.
http://puu.sh/6a5jz/da27d4ae05.png

UPDATE 7:31 AM UTC / 2:31 AM EST

Okay, I'm done with this thread, folks. The Dogecoin developers are on it and the amount of abusive private messages that I'm receiving mean I'm washing my hands.
Look for an official thread from developers next, the information is out and my role is done.
Credit to hoopycat -- please tip him -- who discovered the source of the problem, I'm trying to get the word out right now. I do not get credit for this post.
submitted by lachryma to dogecoin [link] [comments]

BITCOIN DIVORCE – BITCOIN CORE VS BITCOIN CASH EXPLAINED

Bitcoin and Bitcoin Cash are confusing, especially to newbies. They are likely unaware of the history and reasoning for the existence of these two coins. This ignorance is likely persisted by the censorship practised at bitcoin and Bitcointalk.org for several years. (rbitcoinbanned includes examples of the censoring.)
Most of the following is an explanation of the history of Bitcoin, when there was only one Bitcoin. Then it explains the in-fighting and why it forked into two Bitcoins: 1) Bitcoin Legacy and 2) Bitcoin Cash, which happens in the last section (THE DIVORCE). Feel free to suggest edits or corrections. Later, I will publish this on Medium as well.
BITCOIN WAS AN INSTRUMENT OF WAR
For Satoshi Nakamoto, the creator, and the initial supporters, Bitcoin was more than just a new currency. It was an instrument of war.
Who are they fighting against?
The government and central banks.
There is an abundance of evidence of this, starting with Satoshi Nakamoto’s original software.
BATTLE FOR ONLINE GAMBLING
Governments around the world ban online gambling by banning their currency from being used as payment. The original Bitcoin software included code for Poker. Yes, Poker.
Here is the original code: https://github.com/trottieoriginal-bitcoin/blob/mastesrc/uibase.cpp
Search for “Poker”, “Deal Me Out”, “Deal Hand”, “Fold”, “Call”, “Raise”, “Leave Table”, “DitchPlayer”.
Bitcoin gave the middle finger to the government and found a way to get around their ban. In the initial years, it was mainly gambling operators that used Bitcoin, such as SatoshiDice. Was this a coincidence? Gambling is one of the best, if not, the best application for Bitcoin. It was no wonder that gambling operators embraced Bitcoin, including gambling mogul Calvin Ayre.
Bitcoin enabled people to rebel against the government in other ways as well, such as Silk Road, which enabled people to buy and sell drugs.
ANTI-GOVERNMENT LIBERTARIANS AND CYPHERPUNKS
Libertarians seek to maximize political freedom and autonomy. They are against authority and state power. Cypherpunks are activists advocating widespread use of cryptography as a route to social and political change. Their common thread is their dislike for the government.
Bitcoin was created by libertarians and cypherpunks.
Satoshi Nakamoto used cryptography mailing lists to communicate with other cypherpunks such as Wei Dai. Satoshi Nakamoto wrote:
“It’s very attractive to the libertarian viewpoint if we can explain it properly. I’m better with code than with words though.”
Satoshi Nakamoto was rebellious to government control. Someone argued with Satoshi by stating: “You will not find a solution to political problems in cryptography.” Satoshi replied:
"Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”
Nakamoto was critical of the central bank. He wrote:
"The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.”
It is no wonder that the first supporters of Bitcoin were libertarians as well, who agreed with Satoshi’s ideology and saw the potential of Bitcoin to fulfill their ideology.
One of the biggest benefits that Bitcoin supporters want, is “censorship resistance”. What does this mean? It means: to be able to spend your money any way you want. It means: how to get around government regulations and bans. It means: how to do something despite the government.
Roger Ver, an early Bitcoin supporter, heavily criticizes the government for engaging in wars around the world that kills civilians and children. When he ran as a Libertarian candidate in an election against the Republicans and Democrats, he criticized the ATF and FBI for murdering children in their raid in Waco, Texas. At the time, Ver and many other merchants were selling fireworks on eBay without a license. The ATF charged Ver and sent him to prison, but did not charge any of the other merchants. (https://youtu.be/N6NscwzbMvI?t=47m50s) This must have angered Ver a lot.
Since then, Ver has been on a mission to weaken and shrink the government. When he learned about Bitcoin in February 2011, he saw it as his weapon to accomplish his goal…his instrument of war.
Ver was already a multi-millionaire entrepreneur. He sold his company, bought Bitcoins and was the first to invest in Bitcoin startups, such as Bitpay, Blockchain.info, Kraken, Bitcoin.com, Bitcoinstore.com and others. Then he worked full-time to promote Bitcoin. Bitpay became the largest Bitcoin payment processor. Blockchain.info became the largest provider of Bitcoin wallets. Much of the growth of Bitcoin since 2011 can be attributed to Ver's companies.
More evidence of Ver’s anti-government sentiment emerged when he recently announced that he is working to create a society with no government at all (FreeSociety.com).
HOW TO WIN THE WAR
To win the war, Bitcoin must be adopted and widely used by the masses. When people use Bitcoin instead of their national fiat currency, the government becomes weaker. The government can no longer do the following:
It is not only important to get the masses to adopt Bitcoin, but it is also important to get them to adopt it quickly. If it takes a long time, governments will have more time to think twice about allowing Bitcoin to exist and will have more justifications to ban it. They can claim that Bitcoin is used for ransomware, terrorism, etc. If Bitcoin is adopted by the masses to buy everyday goods, such as food and clothing, then it will be harder for them to stop it.
IS BITCOIN WINNING?
Yes and no.
Bitcoin has definitely become more popular over the years. But, it is not achieving Satoshi Nakamoto’s goals.
Satoshi defined Bitcoin and his goal. The title of his white paper is:
“Bitcoin: A Peer-to-Peer Electronic Cash System”
Is Bitcoin being used as cash? Unfortunately, it is not. It is being used as a store of value. However, the title of Satoshi’s white paper was not:
“Bitcoin: A Store of Value”
There is utility in having a store of value, of course. People need it and Bitcoin has superior features to gold. Therefore, it is likely that Bitcoin can continue gaining in popularity and price as it continues to compete and take market share away from gold.
However, both gold and Bitcoin are not being used as currency.
If Bitcoin does not replace fiat currencies, will it weaken governments? No, because no matter how many people buy gold or Bitcoin (as a store of value), they do not weaken governments. To do so, Bitcoin must replace fiat currencies.
BITCOIN LOSING TO FIAT
In the initial years, Bitcoin was taking market share from fiat currencies. But, in the past year, it is losing market share. Dell, Wikipedia and airlines have stopped accepting bitcoin. SatoshiDice and Yours switched to Bitcoin Cash. According to Businessinsider:
"Out of the leading 500 internet sellers, just three accept bitcoin, down from five last year.”
Why is Bitcoin losing market share to fiat? According to Businessinsider:
“when they do try to spend it, it often comes with high fees, which eliminates the utility for small purchases, or it takes a long time to complete the transaction, which could be a turn-off.”
Why are there high fees and long completion times?
Because of small blocks.
SCALING DEBATE – THE BIG MARITAL FIGHT
Why isn't the block size increased?
Because Core/Blockstream believes that big blocks lead to centralization to fewer people who can run the nodes. They also believe that off-chain solutions will provide faster and cheaper transactions. There are advocates for bigger blocks, but because Core/Blockstream control the software, Bitcoin still has the original, one megabyte block since 8 years ago. (Core developers control Bitcoin’s software and several of the key Core developers are employed by Blockstream, a private, for-profit company.)
Businesses, users and miners have asked for four years for the block size to be increased. They point out that Satoshi has always planned to scale Bitcoin by increasing the block size. For four years, Core/Blockstream has refused.
The Bitcoin community split into two factions:
This scaling debate and in-fighting went on for several years. You can read more about it at: https://np.reddit.com/BitcoinMarkets/comments/6rxw7k/informative_btc_vs_bch_articles/dl8v4lp/?st=jaotbt8m&sh=222ce783
SMALL BLOCKERS VS BIG BLOCKERS
Why has Blockstream refused to increase block size? There are a few possible reasons:
  1. They truly believe that big blocks means that fewer people would be able to run full nodes, which would lead to centralization and that the best roadmap is with off-chain solutions. (However, since 2009, hard disk space has exploded. A 4TB disk costs $100 and can store 10 years of blocks. This price is the equivalent to a handful of Bitcoin transaction fees. Also, Satoshi never planned on having every user run full nodes. He envisioned server farms. Decentralization is needed to achieve censorship-resistance and to make the blockchain immutable. This is already accomplished with the thousands of nodes. Having millions or billions of nodes does not increase the censorship-resistance and does not make the blockchain more immutable.)
  2. Blockstream wants small blocks, high fees and slow confirmations to justify the need for their off-chain products, such as Liquid. Blockstream sells Liquid to exchanges to move Bitcoin quickly on a side-chain. Lightning Network will create liquidity hubs, such as exchanges, which will generate traffic and fees for exchanges. With this, exchanges will have a higher need for Liquid. This is the only way that Blockstream will be able to repay the $76 million to their investors.
  3. They propose moving the transactions off the blockchain onto the Lightning Network, an off-chain solution. By doing so, there is a possibility of being regulated by the government (see https://np.reddit.com/btc/comments/7gxkvj/lightning_hubs_will_need_to_report_to_irs/). One of Blockstream’s investors/owners is AXA. AXA’s CEO and Chairman until 2016 was also the Chairman of Bilderberg Group. The Bilderberg Group is run by politicians and bankers. According to GlobalResearch, Bilderberg Group wants “a One World Government (World Company) with a single, global marketplace…and financially regulated by one ‘World (Central) Bank’ using one global currency.” Does Bilderberg see Bitcoin as one component of their master plan?
  4. They do not like the fact that most of the miners are in China. In this power-struggle, they would like to take away control and future revenues from China, by scaling off-chain.
Richard Heart gives his reasons why block size should not be increased, in this video: https://www.youtube.com/watch?time_continue=2941&v=iFJ2MZ3KciQ
He cites latency as a limitation and the reason for doing off-chain scaling. However, latency has been dramatically reduced since 2009 when Bitcoin started with 1MB blocks. Back then, most residential users had 5-10 Mbps internet speed. Now, they have up to 400 Mbps up to 1 Gbps. That’s a 40 to 200X increase. Back in 2009, nobody would’ve thought that you can stream 4k videos.
He implies that 10 minute intervals between block creations are needed in order for the blocks to sync. If internet speed has increased by 40-200X, why can’t the block size be increased?
He claims that bigger blocks make it more difficult for miners to mine the blocks, which increases the chances of orphaned blocks. However, both speeds and the number of mining machines have increased dramatically, causing hashing power on the network to exponentially increase since 2009. This will likely continue increasing in the future.
Richard says that blocks will never be big enough to do 2,000 transactions per second (tps). He says that all of the forks in the world is only going to get 9 tps. Since his statement, Peter Rizun and Andrew Stone have shown that a 1 core CPU machine with 3 Mbps internet speed can do 100 tps. (https://youtu.be/5SJm2ep3X_M) Rizun thinks that visa level (2,000 tps) can be achieved with nodes running on 4-core/16GB machines, bigger blocks and parallel processing to take advantage of the multiple CPU cores.
Even though Rizun and Stone are showing signifiant increases in tps with bigger blocks, the big blockers have never been against a 2nd layer. They’ve always said that you can add a 2nd layer later.
CORE/BLOCKSTREAM VS MINERS
According to Satoshi, Bitcoin should be governed by those with the most hashing power. One hash, one vote. However, Core/Blockstream does not agree with this. Due to refusals for four years to increase block size, it would seem that Core/Blockstream has been able to wrestle control away from miners. Is this because they want control? Is this because they don’t want the Chinese to have so much, or any, control of Bitcoin? Is this because they prefer to eventually move the revenue to the West, by moving most of the transactions off chain?
DIFFERENT AGENDAS
It would seem that Businesses/Users and Core/Blockstream have very different agendas.
Businesses/Users want cheap and fast transactions and see this as an immediate need. Core/Blockstream do not. Here are some quotes from Core/Blockstream:
Greg Maxwell: "I don't think that transaction fees mattering is a failing-- it's success!”
Greg Maxwell: "fee pressure is an intentional part of the system design and to the best of the current understanding essential for the system's long term survial. So, uh, yes. It's good."
Greg Maxwell: "There is a consistent fee backlog, which is the required criteria for stability.”
Peter Wuille: "we - as a community - should indeed let a fee market develop, and rather sooner than later”
Luke-jr: "It is no longer possible to keep fees low.”
Luke-jr: "Just pay a $5 fee and it'll go through every time unless you're doing something stupid.”
Jorge Timón: "higher fees may be just what is needed”
Jorge Timón: "Confirmation times are fine for those who pay high fees.”
Jorge Timón: “I think Adam and I agree that hitting the limit wouldn't be bad, but actually good for an young and immature market like bitcoin fees.”
Mark Friedenbach: "Slow confirmation, high fees will be the norm in any safe outcome."
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions.”
Greg Maxwell: “There is nothing wrong with full blocks, and blocks have been “full” relative to what miners would produce for years. Full blocks is the natural state of the system”
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I'm afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax”
Why don’t Core/Blockstream care about cheap and fast transactions? One possible reason is that they do not use Bitcoin. They might own some, but they do not spend it to buy coffee and they do not use it to pay employees. They aren’t making hundreds of transactions per day. They do not feel the pain. As engineers, they want a technical utopia.
Businesses/Users on the other hand, feel the pain and want business solutions.
An analogy of this scaling debate is this:
You have a car that is going 50 kph. The passengers (Bitcoin users) want to go 100 kph today, but eventually in the future, they want to go 200 kph. The car is capable of going 100 kph but not 200 kph. Big blockers are saying: Step on the accelerator and go 100 kph. Small blockers are saying: Wait until we build a new car, which will go 200 kph. Meanwhile, the passengers are stuck at 50 kph.
Not only do Big blockers think that the car can simply go faster by stepping on the accelerator, they have already shown that the car can go even faster by adding a turbocharger (even bigger blocks) and making sure that every cylinder is firing (parallel process on multiple CPU cores). In addition, they are willing to use the new car if and when it gets built.
CORE/BLOCKSTREAM VS USERS
If you watch this debate from 2017-02-27 (https://youtu.be/JarEszFY1WY), an analogy can be made. Core/Blockstream is like the IT department and Bitcoin.com (Roger Ver and Jake Smith) is like the Sales/Marketing department (users). Core/Blockstream developers hold, but do not use Bitcoin. Blockstream does not own nor use Bitcoin.
Roger Ver's companies used to use or still use Bitcoin every day. Ver’s MemoryDealers was the first company to accept Bitcoin. Johnny seems to think that he knows what users want, but he rarely uses Bitcoin and he is debating one of the biggest users sitting across the table.
In all companies, Marketing (and all other departments) are IT’s customer. IT must do what Marketing wants, not the other way around. If Core/Blockstream and Roger Ver worked in the same company, the CEO would tell Core/Blockstream to give Roger what he wants or the CEO would fire Core/Blockstream.
But they don’t work for the same company. Roger and other businesses/users cannot fire Core/Blockstream.
Core/Blockstream wants to shoot for the best technology possible. They are not interested in solving short term problems, because they do not see high fees and long confirmation times as problems.
BLOCKSTREAM VS LIBERTARIANS
There are leaders in each camp. One can argue that Blockstream is the leader of the Small Blockers and Roger Ver (supported by Gavin Andresen, Calvin Ayre, businesses and some miners) is the leader of the Big Blockers.
Blockstream has openly called for full blocks and higher fees and they are preparing to scale with Lightning Network. As mentioned before, there is a possibility that Lightning hubs will be regulated by the government. Luke-jr tweeted “But State has authority from God” (https://twitter.com/LukeDashjstatus/934611236695789568?s=08)
Roger Ver wants Bitcoin to regulate the government, not the other way around. He wants to weaken and shrink the government. In addition to separation of church and state, he wants to see separation of money and state. He felt that Bitcoin can no longer do this. He pushed for solutions such as Bitcoin Unlimited.
THE DIVORCE
To prepare for off-chain scaling, Core/Blockstream forked Bitcoin by adding Segwit, which I will refer to as Bitcoin Legacy. This is still referred to by the mainstream as Bitcoin, and it has the symbol BTC.
After four years of refusal by Blockstream, the big blockers, out of frustration, restored Bitcoin through a fork, by removing Segwit from Bitcoin Legacy and increased the block size. This is currently called Bitcoin Cash and has the symbol BCH.
Bitcoin Legacy has transformed from cash to store-of-value. It had a 8 year head start in building brand awareness and infrastructure. It’s likely that it will continue growing in popularity and price for a while.
Bitcoin Cash most resembles Satoshi’s “peer-to-peer cash”. It will be interesting to see if it will pick up from where Bitcoin Legacy left off and take market share in the fiat currency space. Libertarians and cypherpunks will be able to resume their mission of weakening and shrinking the government by promoting Bitcoin Cash.
Currently, Bitcoin Cash can fulfill the role of money, which includes medium of exchange (cash) and store-of-value functions. It will be interesting to see if off-chain scaling (with lower fees and faster confirmations) will enable Bitcoin Legacy to be used as a currency as well and fulfill the role of money.
This is an example of the free market and open competition. New companies divest or get created all the time, to satisfy different needs. Bitcoin is no different.
Small blockers and big blockers no longer need to fight and bicker in the same house. They have gone their separate ways.
Both parties have want they want. Blockstream can store value and generate revenue from their off-chain products to repay their investors. Libertarians (and gambling operators) can rejoice and re-arm with Bitcoin Cash to take on the government. They can continue with their mission to get freedom and autonomy.
submitted by curt00 to btc [link] [comments]

The Mike Hearn Show: Season Finale (and Bitcoin Classic: Series Premiere)

This post debunks Mike Hearn's conspiracy theories RE Blockstream in his farewell post and points out issues with the behavior of the Bitcoin Classic hard fork and sketchy tactics of its advocates
I used to be torn on how to judge Mike Hearn. On the one hand he has done some good work with BitcoinJ, Lighthouse etc. Certainly his choice of bloom filter has had a net negative effect on the privacy of SPV users, but all in all it works as advertised.* On the other hand, he has single handedly advocated for some of the most alarming behavior changes in the Bitcoin network (e.g. redlists, coinbase reallocation, BIP101 etc...) to date. Not to mention his advocacy in the past year has degraded from any semblance of professionalism into an adversarial us-vs-them propaganda train. I do not believe his long history with the Bitcoin community justifies this adversarial attitude.
As a side note, this post should not be taken as unabated support for Bitcoin Core. Certainly the dev team is made of humans and like all humans mistakes can be made (e.g. March 2013 fork). Some have even engaged in arguably unprofessional behavior but I have not yet witnessed any explicitly malicious activity from their camp (q). If evidence to the contrary can be provided, please share it. Thankfully the development of Bitcoin Core happens more or less completely out in the open; anyone can audit and monitor the goings on. I personally check the repo at least once a day to see what work is being done. I believe that the regular committers are genuinely interested in the overall well being of the Bitcoin network and work towards the common goal of maintaining and improving Core and do their best to juggle the competing interests of the community that depends on them. That is not to say that they are The Only Ones; for the time being they have stepped up to the plate to do the heavy lifting. Until that changes in some way they have my support.
The hard line that some of the developers have drawn in regards to the block size has caused a serious rift and this write up is a direct response to oft-repeated accusations made by Mike Hearn and his supporters about members of the core development team. I have no affiliations or connection with Blockstream, however I have met a handful of the core developers, both affiliated and unaffiliated with Blockstream.
Mike opens his farewell address with his pedigree to prove his opinion's worth. He masterfully washes over the mountain of work put into improving Bitcoin Core over the years by the "small blockians" to paint the picture that Blockstream is stonewalling the development of Bitcoin. The folks who signed Greg's scalability road map have done some of the most important, unsung work in Bitcoin. Performance improvements, privacy enhancements, increased reliability, better sync times, mempool management, bandwidth reductions etc... all those things are thanks to the core devs and the research community (e.g. Christian Decker), many of which will lead to a smoother transition to larger blocks (e.g. libsecp256k1).(1) While ignoring previous work and harping on the block size exclusively, Mike accuses those same people who have spent countless hours working on the protocol of trying to turn Bitcoin into something useless because they remain conservative on a highly contentious issue that has tangible effects on network topology.
The nature of this accusation is characteristic of Mike's attitude over the past year which marked a shift in the block size debate from a technical argument to a personal one (in tandem with DDoS and censorship in /Bitcoin and general toxicity from both sides). For example, Mike claimed that sidechains constitutes a conflict of interest, as Blockstream employees are "strongly incentivized to ensure [bitcoin] works poorly and never improves" despite thousands of commits to the contrary. Many of these commits are top down rewrites of low level Bitcoin functionality, not chump change by any means. I am not just "counting commits" here. Anyways, Blockstream's current client base consists of Bitcoin exchanges whose future hinges on the widespread adoption of Bitcoin. The more people that use Bitcoin the more demand there will be for sidechains to service the Bitcoin economy. Additionally, one could argue that if there was some sidechain that gained significant popularity (hundreds of thousands of users), larger blocks would be necessary to handle users depositing and withdrawing funds into/from the sidechain. Perhaps if they were miners and core devs at the same time then a conflict of interest on small blocks would be a more substantive accusation (create artificial scarcity to increase tx fees). The rational behind pricing out the Bitcoin "base" via capacity constraint to increase their business prospects as a sidechain consultancy is contrived and illogical. If you believe otherwise I implore you to share a detailed scenario in your reply so I can see if I am missing something.
Okay, so back to it. Mike made the right move when Core would not change its position, he forked Core and gave the community XT. The choice was there, most miners took a pass. Clearly there was not consensus on Mike's proposed scaling road map or how big blocks should be rolled out. And even though XT was a failure (mainly because of massive untested capacity increases which were opposed by some of the larger pools whose support was required to activate the 75% fork), it has inspired a wave of implementation competition. It should be noted that the censorship and attacks by members of /Bitcoin is completely unacceptable, there is no excuse for such behavior. While theymos is entitled to run his subreddit as he sees fit, if he continues to alienate users there may be a point of mass exodus following some significant event in the community that he tries to censor. As for the DDoS attackers, they should be ashamed of themselves; it is recommended that alt. nodes mask their user agents.
Although Mike has left the building, his alarmist mindset on the block size debate lives on through Bitcoin Classic, an implementation which is using a more subtle approach to inspire adoption, as jtoomim cozies up with miners to get their support while appealing to the masses with a call for an adherence to Satoshi's "original vision for Bitcoin." That said, it is not clear that he is competent enough to lead the charge on the maintenance/improvement of the Bitcoin protocol. That leaves most of the heavy lifting up to Gavin, as Jeff has historically done very little actual work for Core. We are thus in a potentially more precarious situation then when we were with XT, as some Chinese miners are apparently "on board" for a hard fork block size increase. Jtoomim has expressed a willingness to accept an exceptionally low (60 or 66%) consensus threshold to activate the hard fork if necessary. Why? Because of the lost "opportunity cost" of the threshold not being reached.(c) With variance my guess is that a lucky 55% could activate that 60% threshold. That's basically two Chinese miners. I don't mean to attack him personally, he is just willing to go down a path that requires the support of only two major Chinese mining pools to activate his hard fork. As a side effect of the latency issues of GFW, a block size increase might increase orphan rate outside of GFW, profiting the Chinese pools. With a 60% threshold there is no way for miners outside of China to block that hard fork.
To compound the popularity of this implementation, the efforts of Mike, Gavin and Jeff have further blinded many within the community to the mountain of effort that core devs have put in. And it seems to be working, as they are beginning to successfully ostracize the core devs beyond the network of "true big block-believers." It appears that Chinese miners are getting tired of the debate (and with it Core) and may shift to another implementation over the issue.(d) Some are going around to mining pools and trying to undermine Core's position in the soft vs. hard fork debate. These private appeals to the miner community are a concern because there is no way to know if bad information is being passed on with the intent to disrupt Core's consensus based approach to development in favor of an alternative implementation controlled (i.e. benevolent dictator) by those appealing directly to miners. If the core team is reading this, you need to get out there and start pushing your agenda so the community has a better understanding of what you all do every day and how important the work is. Get some fancy videos up to show the effects of block size increase and work on reading materials that are easy for non technically minded folk to identify with and get behind.
The soft fork debate really highlights the disingenuity of some of these actors. Generally speaking, soft forks are easier on network participants who do not regularly keep up with the network's software updates or have forked the code for personal use and are unable to upgrade in time, while hard forks require timely software upgrades if the user hopes to maintain consensus after a hardfork. The merits of that argument come with heavy debate. However, more concerning is the fact that hard forks require central planning and arguably increase the power developers have over changes to the protocol.(2) In contrast, the 'signal of readiness' behavior of soft forks allows the network to update without any hardcoded flags and developer oversight. Issues with hard forks are further compounded by activation thresholds, as soft forks generally require 95% consensus while Bitcoin Classic only calls for 60-75% consensus, exposing network users to a greater risk of competing chains after the fork. Mike didn't want to give the Chinese any more power, but now the post XT fallout has pushed the Chinese miners right into the Bitcoin Classic drivers seat.
While a net split did happen briefly during the BIP66 soft fork, imagine that scenario amplified by miners who do not agree to hard fork changes while controlling 25-40% of the networks hashing power. Two actively mined chains with competing interests, the Doomsday Scenario. With a 5% miner hold out on a soft fork, the fork will constantly reorg and malicious transactions will rarely have more than one or two confirmations.(b) During a soft fork, nodes can protect themselves from double spends by waiting for extra confirmations when the node alerts the user that a ANYONECANSPEND transaction has been seen. Thus, soft forks give Bitcoin users more control over their software (they can choose to treat a softfork as a soft fork or a soft fork as a hardfork) which allows for greater flexibility on upgrade plans for those actively maintaining nodes and other network critical software. (2) Advocating for a low threshold hard forks is a step in the wrong direction if we are trying to limit the "central planning" of any particular implementation. However I do not believe that is the main concern of the Bitcoin Classic devs.
To switch gears a bit, Mike is ironically concerned China "controls" Bitcoin, but wanted to implement a block size increase that would only increase their relative control (via increased orphans). Until the p2p wire protocol is significantly improved (IBLT, etc...), there is very little room (if any at all) to raise the block size without significantly increasing orphan risk. This can be easily determined by looking at jtoomim's testnet network data that passed through normal p2p network, not the relay network.(3) In the mean time this will only get worse if no one picks up the slack on the relay network that Matt Corallo is no longer maintaining. (4)
Centralization is bad regardless of the block size, but Mike tries to conflate the centralization issues with the Blockstream block size side show for dramatic effect. In retrospect, it would appear that the initial lack of cooperation on a block size increase actually staved off increases in orphan risk. Unfortunately, this centralization metric will likely increase with the cooperation of Chinese miners and Bitcoin Classic if major strides to reduce orphan rates are not made.
Mike also manages to link to a post from the ProHashing guy RE forever-stuck transactions, which has been shown to generally be the result of poorly maintained/improperly implemented wallet software.(6) Ultimately Mike wants fees to be fixed despite the fact you can't enforce fixed fees in a system that is not centrally planned. Miners could decide to raise their minimum fees even when blocks are >1mb, especially when blocks become too big to reliably propagate across the network without being orphaned. What is the marginal cost for a tx that increases orphan risk by some %? That is a question being explored with flexcaps. Even with larger blocks, if miners outside the GFW fear orphans they will not create the bigger blocks without a decent incentive; in other words, even with a larger block size you might still end up with variable fees. Regardless, it is generally understood that variable fees are not preferred from a UX standpoint, but developers of Bitcoin software do not have the luxury of enforcing specific fees beyond basic defaults hardcoded to prevent cheap DoS attacks. We must expose the user to just enough information so they can make an informed decision without being overwhelmed. Hard? Yes. Impossible. No.
Shifting gears, Mike states that current development progress via segwit is an empty ploy, despite the fact that segwit comes with not only a marginal capacity increase, but it also plugs up major malleability vectors, allows pruning blocks for historical data and a bunch of other fun stuff. It's a huge win for unconfirmed transactions (which Mike should love). Even if segwit does require non-negligible changes to wallet software and Bitcoin Core (500 lines LoC), it allows us time to improve block relay (IBLT, weak blocks) so we can start raising the block size without fear of increased orphan rate. Certainly we can rush to increase the block size now and further exacerbate the China problem, or we can focus on the "long play" and limit negative externalities.
And does segwit help the Lightning Network? Yes. Is that something that indicates a Blockstream conspiracy? No. Comically, the big blockians used to criticize Blockstream for advocating for LN when there was no one working on it, but now that it is actively being developed, the tune has changed and everything Blockstream does is a conspiracy to push for Bitcoin's future as a dystopic LN powered settlement network. Is LN "the answer?" Obviously not, most don't actually think that. How it actually works in practice is yet to be seen and there could be unforseen emergent characteristics that make it less useful for the average user than originally thought. But it's a tool that should be developed in unison with other scaling measures if only for its usefulness for instant txs and micropayments.
Regardless, the fundamental divide rests on ideological differences that we all know well. Mike is fine with the miner-only validation model for nodes and is willing to accept some miner centralization so long as he gets the necessary capacity increases to satisfy his personal expectations for the immediate future of Bitcoin. Greg and co believe that a distributed full node landscape helps maintain a balance of decentralization in the face of the miner centralization threat. For example, if you have 10 miners who are the only sources for blockchain data then you run the risk of undetectable censorship, prolific sybil attacks, and no mechanism for individuals to validate the network without trusting a third party. As an analogy, take the tor network: you use it with an expectation of privacy while understanding that the multi-hop nature of the routing will increase latency. Certainly you could improve latency by removing a hop or two, but with it you lose some privacy. Does tor's high latency make it useless? Maybe for watching Netflix, but not for submitting leaked documents to some newspaper. I believe this is the philosophy held by most of the core development team.
Mike does not believe that the Bitcoin network should cater to this philosophy and any activity which stunts the growth of on-chain transactions is a direct attack on the protocol. Ultimately however I believe Greg and co. also want Bitcoin to scale on-chain transactions as much as possible. They believe that in order for Bitcoin to increase its capacity while adhering to acceptable levels of decentralization, much work needs to be done. It's not a matter of if block size will be increased, but when. Mike has confused this adherence to strong principles of decentralization as disingenuous and a cover up for a dystopic future of Bitcoin where sidechains run wild with financial institutions paying $40 per transaction. Again, this does not make any sense to me. If banks are spending millions to co-op this network what advantage does a decentralized node landscape have to them?
There are a few roads that the community can take now: one where we delay a block size increase while improvements to the protocol are made (with the understanding that some users may have to wait a few blocks to have their transaction included, fees will be dependent on transaction volume, and transactions <$1 may be temporarily cost ineffective) so that when we do increase the block size, orphan rate and node drop off are insignificant. Another is the immediate large block size increase which possibly leads to a future Bitcoin which looks nothing like it does today: low numbers of validating nodes, heavy trust in centralized network explorers and thus a more vulnerable network to government coercion/general attack. Certainly there are smaller steps for block size increases which might not be as immediately devastating, and perhaps that is the middle ground which needs to be trodden to appease those who are emotionally invested in a bigger block size. Combined with segwit however, max block sizes could reach unacceptable levels. There are other scenarios which might play out with competing chains etc..., but in that future Bitcoin has effectively failed.
As any technology that requires maintenance and human interaction, Bitcoin will require politicking for decision making. Up until now that has occurred via the "vote download" for software which implements some change to the protocol. I believe this will continue to be the most robust of options available to us. Now that there is competition, the Bitcoin Core community can properly advocate for changes to the protocol that it sees fit without being accused of co-opting the development of Bitcoin. An ironic outcome to the situation at hand. If users want their Bitcoins to remain valuable, they must actively determine which developers are most competent and have their best interests at heart. So far the core dev community has years of substantial and successful contributions under its belt, while the alt implementations have a smattering of developers who have not yet publicly proven (besides perhaps Gavin--although his early mistakes with block size estimates is concerning) they have the skills and endurance necessary to maintain a full node implementation. Perhaps now it is time that we focus on the personalities who many want to trust Bitcoin's future. Let us see if they can improve the speed at which signatures are validated by 7x. Or if they can devise privacy preserving protocols like Confidential Transactions. Or can they figure out ways to improve traversal times across a merkle tree? Can they implement HD functionality into a wallet without any coin-crushing bugs? Can they successfully modularize their implementation without breaking everything? If so, let's welcome them with open arms.
But Mike is at R3 now, which seems like a better fit for him ideologically. He can govern the rules with relative impunity and there is not a huge community of open source developers, researchers and enthusiasts to disagree with. I will admit, his posts are very convincing at first blush, but ultimately they are nothing more than a one sided appeal to the those in the community who have unrealistic or incomplete understandings of the technical challenges faced by developers maintaining a consensus critical, validation-heavy, distributed system that operates within an adversarial environment. Mike always enjoyed attacking Blockstream, but when survey his past behavior it becomes clear that his motives were not always pure. Why else would you leave with such a nasty, public farewell?
To all the XT'ers, btc'ers and so on, I only ask that you show some compassion when you critique the work of Bitcoin Core devs. We understand you have a competing vision for the scaling of Bitcoin over the next few years. They want Bitcoin to scale too, you just disagree on how and when it should be done. Vilifying and attacking the developers only further divides the community and scares away potential future talent who may want to further the Bitcoin cause. Unless you can replace the folks doing all this hard work on the protocol or can pay someone equally as competent, please think twice before you say something nasty.
As for Mike, I wish you the best at R3 and hope that you can one day return to the Bitcoin community with a more open mind. It must hurt having your software out there being used by so many but your voice snuffed. Hopefully one day you can return when many of the hard problems are solved (e.g. reduced propagation delays, better access to cheap bandwidth) and the road to safe block size increases have been paved.
(*) https://eprint.iacr.org/2014/763.pdf
(q) https://github.com/bitcoinclassic/bitcoinclassic/pull/6
(b) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012026.html
(c) https://github.com/bitcoinclassic/bitcoinclassic/pull/1#issuecomment-170299027
(d) http://toom.im/jameshilliard_classic_PR_1.html
(0) http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/06
(1) https://github.com/bitcoin/bitcoin/graphs/contributors
(2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012014.html
(3) https://toom.im/blocktime (beware of heavy website)
(4) https://bitcointalk.org/index.php?topic=766190.msg13510513#msg13510513
(5) https://news.ycombinator.com/item?id=10774773
(6) http://rusty.ozlabs.org/?p=573
edit, fixed some things.
edit 2, tried to clarify some more things and remove some personal bias thanks to astro
submitted by citboins to Bitcoin [link] [comments]

Bitcoin Divorce - Bitcoin [Legacy] vs Bitcoin Cash Explained

Bitcoin and Bitcoin Cash are confusing, especially to newbies. They are likely unaware of the history and reasoning for the existence of these two coins. This ignorance is likely persisted by the censorship practised at bitcoin and Bitcointalk.org for several years. (rbitcoinbanned includes examples of the censoring.)
Most of the following is an explanation of the history of Bitcoin, when there was only one Bitcoin. Then it explains the in-fighting and why it forked into two Bitcoins: 1) Bitcoin Legacy and 2) Bitcoin Cash, which happens in the last section (THE DIVORCE). Feel free to suggest edits or corrections. Later, I will publish this on Medium as well.
BITCOIN WAS AN INSTRUMENT OF WAR
For Satoshi Nakamoto, the creator, and the initial supporters, Bitcoin was more than just a new currency. It was an instrument of war.
Who are they fighting against?
The government and central banks.
There is an abundance of evidence of this, starting with Satoshi Nakamoto’s original software.
BATTLE FOR ONLINE GAMBLING
Governments around the world ban online gambling by banning their currency from being used as payment. The original Bitcoin software included code for Poker. Yes, Poker.
Here is the original code: https://github.com/trottieoriginal-bitcoin/blob/mastesrc/uibase.cpp
Search for “Poker”, “Deal Me Out”, “Deal Hand”, “Fold”, “Call”, “Raise”, “Leave Table”, “DitchPlayer”.
Bitcoin gave the middle finger to the government and found a way to get around their ban. In the initial years, it was mainly gambling operators that used Bitcoin, such as SatoshiDice. Was this a coincidence? Gambling is one of the best, if not, the best application for Bitcoin. It was no wonder that gambling operators embraced Bitcoin, including gambling mogul Calvin Ayre.
Bitcoin enabled people to rebel against the government in other ways as well, such as Silk Road, which enabled people to buy and sell drugs.
ANTI-GOVERNMENT LIBERTARIANS AND CYPHERPUNKS
Libertarians seek to maximize political freedom and autonomy. They are against authority and state power. Cypherpunks are activists advocating widespread use of cryptography as a route to social and political change. Their common thread is their dislike for the government.
Bitcoin was created by libertarians and cypherpunks.
Satoshi Nakamoto used cryptography mailing lists to communicate with other cypherpunks such as Wei Dai. Satoshi Nakamoto disappeared after 2010, but we can refer to his writings. He wrote:
“It’s very attractive to the libertarian viewpoint if we can explain it properly. I’m better with code than with words though.”
Satoshi Nakamoto was rebellious to government control. Someone argued with Satoshi by stating: “You will not find a solution to political problems in cryptography.” Satoshi replied:
"Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”
Nakamoto was critical of the central bank. He wrote:
"The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.”
It is no wonder that the first supporters of Bitcoin were libertarians as well, who agreed with Satoshi’s ideology and saw the potential of Bitcoin to fulfill their ideology.
One of the biggest benefits that Bitcoin supporters want, is “censorship resistance”. What does this mean? It means: to be able to spend your money any way you want. It means: how to get around government regulations and bans. It means: how to do something despite the government.
Roger Ver, an early Bitcoin supporter, heavily criticizes the government for engaging in wars around the world that kills civilians and children. When he ran as a Libertarian candidate in an election against the Republicans and Democrats, he criticized the ATF and FBI for murdering children in their raid in Waco, Texas. At the time, Ver and many other merchants were selling fireworks on eBay without a license. The ATF charged Ver and sent him to prison, but did not charge any of the other merchants. (https://youtu.be/N6NscwzbMvI?t=47m50s) This must have angered Ver a lot.
Since then, Ver has been on a mission to weaken and shrink the government. When he learned about Bitcoin in February 2011, he saw it as his weapon to accomplish his goal…his instrument of war.
Ver was already a multi-millionaire entrepreneur. He sold his company, bought Bitcoins and was the first to invest in Bitcoin startups, such as Bitpay, Blockchain.info, Kraken, Bitcoin.com, Bitcoinstore.com and others. Then he worked full-time to promote Bitcoin. Bitpay became the largest Bitcoin payment processor. Blockchain.info became the largest provider of Bitcoin wallets. Much of the growth of Bitcoin since 2011 can be attributed to Ver's companies.
More evidence of Ver’s anti-government sentiment emerged when he recently announced that he is working to create a society with no government at all (FreeSociety.com).
HOW TO WIN THE WAR
To win the war, Bitcoin must be adopted and widely used by the masses. When people use Bitcoin instead of their national fiat currency, the government becomes weaker. The government can no longer do the following:
It is not only important to get the masses to adopt Bitcoin, but it is also important to get them to adopt it quickly. If it takes a long time, governments will have more time to think twice about allowing Bitcoin to exist and will have more justifications to ban it. They can claim that Bitcoin is used for ransomware, terrorism, etc. If Bitcoin is adopted by the masses to buy everyday goods, such as food and clothing, then it will be harder for them to stop it.
IS BITCOIN WINNING?
Yes and no.
Bitcoin has definitely become more popular over the years. But, it is not achieving Satoshi Nakamoto’s goals.
Satoshi defined Bitcoin and his goal. The title of his white paper is:
“Bitcoin: A Peer-to-Peer Electronic Cash System”
Is Bitcoin being used as cash? Unfortunately, it is not. It is being used as a store of value. However, the title of Satoshi’s white paper was not:
“Bitcoin: A Store of Value”
There is utility in having a store of value, of course. People need it and Bitcoin has superior features to gold. Therefore, it is likely that Bitcoin can continue gaining in popularity and price as it continues to compete and take market share away from gold.
However, both gold and Bitcoin are not being used as currency.
If Bitcoin does not replace fiat currencies, will it weaken governments? No, because no matter how many people buy gold or Bitcoin (as a store of value), they do not weaken governments. To do so, Bitcoin must replace fiat currencies.
BITCOIN LOSING TO FIAT
In the initial years, Bitcoin was taking market share from fiat currencies. But, in the past year, it is losing market share. SatoshiDice, Yours.org and Bitmain switched to Bitcoin Cash. According to Businessinsider:
"Out of the leading 500 internet sellers, just three accept bitcoin, down from five last year.”
Why is Bitcoin losing market share to fiat? According to Businessinsider:
“when they do try to spend it, it often comes with high fees, which eliminates the utility for small purchases, or it takes a long time to complete the transaction, which could be a turn-off.”
Why are there high fees and long completion times?
Because of small blocks.
SCALING DEBATE – THE BIG MARITAL FIGHT
Why isn't the block size increased?
Because Core/Blockstream believes that big blocks lead to centralization to fewer people who can run the nodes. They also believe that off-chain solutions will provide faster and cheaper transactions. There are advocates for bigger blocks, but because Core/Blockstream control the software, Bitcoin still has the original, one megabyte block since 8 years ago. (Core developers control Bitcoin’s software and several of the key Core developers are employed by Blockstream, a private, for-profit company.)
Businesses, users and miners have asked for four years for the block size to be increased. They point out that Satoshi has always planned to scale Bitcoin by increasing the block size. For four years, Core/Blockstream has refused.
The Bitcoin community split into two factions:
This scaling debate and in-fighting went on for several years. During this time, the controllers of bitcoin and Bitcointalk censored big blockers. Comments that criticized small blocks or supported big blocks, were deleted. You can read more about it at: https://np.reddit.com/BitcoinMarkets/comments/6rxw7k/informative_btc_vs_bch_articles/dl8v4lp/?st=jaotbt8m&sh=222ce783
SMALL BLOCKERS VS BIG BLOCKERS
Why has Blockstream refused to increase block size? There are a few possible reasons:
  1. They truly believe that big blocks means that fewer people would be able to run full nodes, which would lead to centralization and that the best roadmap is with off-chain solutions. (However, since 2009, hard disk space has exploded. A 4TB disk costs $100 and can store 10 years of blocks. This price is the equivalent to a handful of Bitcoin transaction fees. Also, Satoshi never planned on having every user run full nodes. He envisioned server farms. Decentralization is needed to achieve censorship-resistance and to make the blockchain immutable. This is already accomplished with the thousands of nodes. Having millions or billions of nodes does not increase the censorship-resistance and does not make the blockchain more immutable.)
  2. Blockstream wants small blocks, high fees and slow confirmations to justify the need for their off-chain products, such as Liquid. Blockstream sells Liquid to exchanges to move Bitcoin quickly on a side-chain. Lightning Network will create liquidity hubs, such as exchanges, which will generate traffic and fees for exchanges. With this, exchanges will have a higher need for Liquid. This is the only way that Blockstream will be able to repay the $76 million to their investors.
  3. They propose moving the transactions off the blockchain onto the Lightning Network, an off-chain solution. By doing so, there is a possibility of being regulated by the government (see https://np.reddit.com/btc/comments/7gxkvj/lightning_hubs_will_need_to_report_to_irs/). One of Blockstream’s investors/owners is AXA. AXA’s CEO and Chairman until 2016 was also the Chairman of Bilderberg Group. The Bilderberg Group is run by politicians and bankers. According to GlobalResearch, Bilderberg Group wants “a One World Government (World Company) with a single, global marketplace…and financially regulated by one ‘World (Central) Bank’ using one global currency.” Does Bilderberg see Bitcoin as one component of their master plan?
  4. They do not like the fact that most of the miners are in China. In this power-struggle, they would like to take away control and future revenues from China, by scaling off-chain.
Richard Heart gives his reasons why block size should not be increased, in this video: https://www.youtube.com/watch?time_continue=2941&v=iFJ2MZ3KciQ
He cites latency as a limitation and the reason for doing off-chain scaling. However, latency has been dramatically reduced since 2009 when Bitcoin started with 1MB blocks. Back then, most residential users had 5-10 Mbps internet speed. Now, they have up to 400 Mbps up to 1 Gbps. That’s a 40 to 200X increase. Back in 2009, nobody would’ve thought that you can stream 4k videos.
He implies that 10 minute intervals between block creations are needed in order for the blocks to sync. If internet speed has increased by 40-200X, why can’t the block size be increased?
He claims that bigger blocks make it more difficult for miners to mine the blocks, which increases the chances of orphaned blocks. However, both speeds and the number of mining machines have increased dramatically, causing hashing power on the network to exponentially increase since 2009. This will likely continue increasing in the future.
Richard says that blocks will never be big enough to do 2,000 transactions per second (tps). He says that all of the forks in the world is only going to get 9 tps. Since his statement, Peter Rizun and Andrew Stone have shown that a 1 core CPU machine with 3 Mbps internet speed can do 100 tps. (https://youtu.be/5SJm2ep3X_M) Rizun thinks that visa level (2,000 tps) can be achieved with nodes running on 4-core/16GB machines, bigger blocks and parallel processing to take advantage of the multiple CPU cores.
Even though Rizun and Stone are showing signifiant increases in tps with bigger blocks, the big blockers have never been against a 2nd layer. They’ve always said that you can add a 2nd layer later.
CORE/BLOCKSTREAM VS MINERS
According to Satoshi, Bitcoin should be governed by those with the most hashing power. One hash, one vote. However, Core/Blockstream does not agree with this. Due to refusals for four years to increase block size, it would seem that Core/Blockstream has been able to wrestle control away from miners. Is this because they want control? Is this because they don’t want the Chinese to have so much, or any, control of Bitcoin? Is this because they prefer to eventually move the revenue to the West, by moving most of the transactions off chain?
DIFFERENT AGENDAS
It would seem that Businesses/Users and Core/Blockstream have very different agendas.
Businesses/Users want cheap and fast transactions and see this as an immediate need. Core/Blockstream do not. Here are some quotes from Core/Blockstream:
Greg Maxwell: "I don't think that transaction fees mattering is a failing-- it's success!”
Greg Maxwell: "fee pressure is an intentional part of the system design and to the best of the current understanding essential for the system's long term survial. So, uh, yes. It's good."
Greg Maxwell: "There is a consistent fee backlog, which is the required criteria for stability.”
Peter Wuille: "we - as a community - should indeed let a fee market develop, and rather sooner than later”
Luke-jr: "It is no longer possible to keep fees low.”
Luke-jr: "Just pay a $5 fee and it'll go through every time unless you're doing something stupid.”
Jorge Timón: "higher fees may be just what is needed”
Jorge Timón: "Confirmation times are fine for those who pay high fees.”
Jorge Timón: “I think Adam and I agree that hitting the limit wouldn't be bad, but actually good for an young and immature market like bitcoin fees.”
Mark Friedenbach: "Slow confirmation, high fees will be the norm in any safe outcome."
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions.”
Greg Maxwell: “There is nothing wrong with full blocks, and blocks have been “full” relative to what miners would produce for years. Full blocks is the natural state of the system”
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I'm afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax”
Why don’t Core/Blockstream care about cheap and fast transactions? One possible reason is that they do not use Bitcoin. They might own some, but they do not spend it to buy coffee and they do not use it to pay employees. They aren’t making hundreds of transactions per day. They do not feel the pain. As engineers, they want a technical utopia.
Businesses/Users on the other hand, feel the pain and want business solutions.
An analogy of this scaling debate is this:
You have a car that is going 50 kph. The passengers (Bitcoin users) want to go 100 kph today, but eventually in the future, they want to go 200 kph. The car is capable of going 100 kph but not 200 kph. Big blockers are saying: Step on the accelerator and go 100 kph. Small blockers are saying: Wait until we build a new car, which will go 200 kph. Meanwhile, the passengers are stuck at 50 kph.
Not only do Big blockers think that the car can simply go faster by stepping on the accelerator, they have already shown that the car can go even faster by adding a turbocharger (even bigger blocks) and making sure that every cylinder is firing (parallel process on multiple CPU cores). In addition, they are willing to use the new car if and when it gets built.
CORE/BLOCKSTREAM VS USERS
If you watch this debate from 2017-02-27 (https://youtu.be/JarEszFY1WY), an analogy can be made. Core/Blockstream is like the IT department and Bitcoin.com (Roger Ver and Jake Smith) is like the Sales/Marketing department (users).
Core/Blockstream developers hold, but do not use Bitcoin. Blockstream does not own nor use Bitcoin. Roger Ver's companies use use Bitcoin every day. Ver’s MemoryDealers was the first company to accept Bitcoin. Johnny seems to think that he knows what users want, but he rarely uses Bitcoin and he is debating one of the biggest users sitting across the table.
In all companies, Marketing (and all other departments) is IT’s customer. IT must do what Marketing wants, not the other way around. If Core/Blockstream and Roger Ver worked in the same company, the CEO would tell Core/Blockstream to give Roger what he wants or the CEO would fire Core/Blockstream.
But they don’t work for the same company. Roger and other businesses/users cannot fire Core/Blockstream.
Core/Blockstream wants to shoot for the best technology possible. They are not interested in solving short term problems, because they do not see high fees and long confirmation times as problems.
BLOCKSTREAM VS LIBERTARIANS
There are leaders in each camp. One can argue that Blockstream is the leader of the Small Blockers and Roger Ver (supported by Gavin Andresen, Calvin Ayre, businesses and some miners) is the leader of the Big Blockers.
Blockstream has openly called for full blocks and higher fees and they are preparing to scale with Lightning Network. As mentioned before, there is a possibility that Lightning hubs will be regulated by the government. Luke-jr tweeted “But State has authority from God” (https://twitter.com/LukeDashjstatus/934611236695789568?s=08) According to this video, Luke-jr believes that the government should tax you and the government should execute heretics. Luke-jr's values are diametrically opposed to libertarians'.
Roger Ver wants Bitcoin to regulate the government, not the other way around. He wants to weaken and shrink the government. In addition to separation of church and state, he wants to see separation of money and state. He felt that Bitcoin can no longer do this, so he pushed for solutions such as Bitcoin Unlimited.
MIKE HEARN EXPLAINS BLOCKSTREAM
Mike Hearn is one of the first Bitcoin developers. He explained how Core/Blockstream developers (source):
THE DIVORCE
To prepare for off-chain scaling, Core/Blockstream forked Bitcoin by adding Segwit, which I will refer to as Bitcoin Legacy. This is still referred to by the mainstream as Bitcoin, and it has the symbol BTC.
After four years of refusal by Blockstream, the big blockers, out of frustration, restored Bitcoin through a fork, by removing Segwit from Bitcoin Legacy and increased the block size. This is currently called Bitcoin Cash and has the symbol BCH.
Bitcoin Legacy has transformed from cash to store-of-value. It had a 8 year head start in building brand awareness and infrastructure. It’s likely that it will continue growing in popularity and price for a while.
Bitcoin Cash most resembles Satoshi’s “peer-to-peer cash”. It will be interesting to see if it will pick up from where Bitcoin Legacy left off and take market share in the fiat currency space. Libertarians and cypherpunks will be able to resume their mission of weakening and shrinking the government by promoting Bitcoin Cash.
Currently, Bitcoin Cash can fulfill the role of money, which includes medium of exchange (cash) and store-of-value functions. It will be interesting to see if off-chain scaling (with lower fees and faster confirmations) will enable Bitcoin Legacy to be used as a currency as well and fulfill the role of money.
This is an example of the free market and open competition. New companies divest or get created all the time, to satisfy different needs. Bitcoin is no different.
Small blockers and big blockers no longer need to fight and bicker in the same house. They have gone their separate ways.
Both parties have what they want. Blockstream can store value and generate revenue from their off-chain products to repay their investors. Libertarians (and gambling operators) can rejoice and re-arm with Bitcoin Cash to take on the government. They can continue with their mission to get freedom and autonomy.
submitted by curt00 to btc [link] [comments]

Signatum Transaction Status: CONFLICTED (How to fix it) ProCurrency Staking Guide How to Restore The Primecoin XPM Wallet How To Speed Up A Stuck Bitcoin Transaction Signatum Wallet Sync Issue Fix (Date & Time)

The first Parity Bitcoin sync attempt didn’t go well. After Parity fixed the consensus bug I tried again. Recompiled Parity Bitcoin with the SegWit bug fix. Full validation sync with 24GB dbcache and "verification edge" set to block 1 took 38 hours, 17 minutes, was disk I/O bound most of the time. — Jameson Lopp (@lopp) November 12, 2018 If your wallet is sending transactions that get stuck, you may be using an old wallet that doesn’t calculate fees properly. Try one of these: COMPARISON. Ledger Nano X. Good for storing large amounts of crypto; Supports 1,000+ coins ; Can be used with iOS & Android; Learn More. BRD. Great wallet for iOS and Android; Supports many coins, like BTC and ETH; Clean interface makes it easy to use ... If that is your case then here are few ways to troubleshoot an out of sync qt wallet. Core doesnt sync blockchain - you We regularly publish content about Bitcoin, Ethereum, Altcoins, wallet guides, mining tutorials and trading tips. I'm on 0. Asked 2 years, 11 months ago. If initial synchronization takes too long, some people may be turned off from using bitcoin. If that is your case then ... If you are just getting into Bitcoins and started by installing the Bitcoin wallet on your computer you may notice that the synchronization process with the Bitcoin network is taking up quite some time. This is due to the very large blockchain that has been generated so far and it will continue to grow even bigger, so besides more than 10 Gigabytes of space you need to be ready to wait a bit ... Ahhh one of the worst things about Bitcoin.... I have dealt personally with this issue. The first time I ran Bitcoin Core (to use with Bitcoin Armory), I let my computer run for a full day before it finally completed it. This was over a year ago. ...

[index] [35142] [2124] [15941] [44685] [14781] [26603] [25826] [24248] [14035] [29648]

Signatum Transaction Status: CONFLICTED (How to fix it)

Here I show you how to restore a Primecoin wallet from a backup. The process is quite straight forward as you will see, but let me know if you get stuck and I'll do my best to help. I show you how ... PRO Wallet Out Of Sync - Another Solution To ... How to troubleshoot a stuck blockchain on Windows & Mac - Duration: 1:56. PRO Commerce 1,653 views. 1:56. How To Send Bitcoin Wallet to Wallet ... A Bitcoin transaction can fail to confirm, or become “stuck,” for many reasons. Stuck transactions may be confirmed after several days, but sometimes waiting isn’t an option. Fortunately ... Here's a simple fix you can try to do if you are still experiencing the "out of sync" problem with your Signatum wallet. I have been living with it for days now and it's only now that I figured ... Signatum Wallet Sync Issue Fix (Date & Time) ... PRO Wallet Out Of Sync - Another Solution To Fix - Duration: 9:31. Cryptocurrency Group 4,749 views. 9:31. How to Trace a Bitcoin Transaction using ...

#