Gold collapsing. Bitcoin UP.

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
Can you elaborate on what you're referring to? Does the current BCH code have properties that make the expected average block time not 10 minutes?

I vaguely recall Tom Zander saying that the new difficulty adjustment algorithm would result in block times slightly different from 10 minutes, which seems pretty bad, but I'm not sure where to find discussion of this.
I don't think that was reproduced.
I asked Tom why I was unable to the effect he claimed, neither on Neil's (kyuupichan's) simulator, nor on his own simulator, but didn't get a reply.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1061#post-48288

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1062#post-48320

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1062#post-48556
 

NewLiberty

Member
Aug 28, 2015
70
442
For those that asked me what I've been thinking about next, I wrote on yours.org;

On the path to Freedom of innovation
Am working on a project that is closely aligned with this.
It is a combination of IDE purpose built for blockchain development projects, especially related to scripting and smart contracts on Bitcoin Cash, Ethereum, EOS, and other platforms.
Combined with collaboration tools and project management.
Hopefully will have something useful in a month or so.
 

NewLiberty

Member
Aug 28, 2015
70
442
but its hard to imagine why BU member's would place a vote that is clearly not in the best interest of BU...
Pretty easy to imagine.
People vote their self interest, not a collective interest.
At best they might vote what they may consider a collective interest, but it is always colored by their self interest as to what that collective interest might be. Many biases exist there, it is why the voting is done.
All democracies are like this.

There has also been some active discussion within the core communication channels on how to subvert BU's democratic process to undermine it.
 

NewLiberty

Member
Aug 28, 2015
70
442
I had the delightfully good fortune to help out with a recent gathering of the different development teams.. It was a great experience for me, and I am looking to do more for them, the meetings seem like a very good structure which keeps it sufficiently disorganized to be a sort of hot house of creativity, but still produce a very refined output.

The one thing that really got me very excited in the last gathering was the limited form of pre-consensus that makes for a new upgrade method. It solves what has been in my view one of the big problem with achieving mass adoption in retail operations. Retailers need a point of sale system that can be run by a complete idiot with almost no training. "Designed by genius to be used by idiots"

The problem with these point of sale systems is that they have to stay in place for many years and probably don't get maintained very well, if at all.

They won't have any technical resources to do anything, so when things like hard forks happen, suddenly these PoS systems all become useless junk. That doesn't work, the retailers will throw them out.

So instead, a new mechanism of pre-consensus can be used so that the old op_codes can be enabled over time without breaking all the in place equipment each time there is a hard fork.

The way it works is that if there is a script function that the node doesn't recognize, it can set it aside and wait for it to be included in a block and that other blocks are built upon it. It doesn't reject it, or accept it, it waits to see what all the miners do.

Implementing this means that PoS systems can be mass produced and we can finally get on the road to mass adoption..
 
Last edited:

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
Jorge Timon and CSW are having a big twitter fight that revisits what we were discussing here back in May regarding the phrase "overpowered by an attacker" in the SPV section of the whitepaper. After all, @awemany was correct that the key Core devs mistake it to mean a majority attacker. This is the root of all the "full node" silliness.
And many more tweets along similar lines. I don't think Timon is lying, though, just echoing Greg's misunderstanding.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@albin and anyone else who wants to claim their Bitcoin Gold and avoid the malware:

I just pushed a fork of Vitalik's excellent pybitcointools (actually a fork of the bitcoincash fork by Conio), with a script included to claim the Bitcoin gold.

The code is here, in the bitcoingold branch: https://github.com/awemany/pybitcointools/tree/bitcoingold

Extremely brief docs:

In addition to the trivial changes to support BTG instead of BCH transaction signing (setting the FORK_ID to 79 and tx version to 2, though the latter is likely not even necessary), three scripts are included:

"claimgold.py": This script will build a one-input to one-output transaction from a former BTC P2PKH input (which is now a BTG output) to another BTG output.
The idea is to move the funds away using a transaction signed offline, and move them into any online wallet that can then be used for further conversion of the BTG. I used coinomi on an android emulator.

The script requires a bit of manual work of pulling out the outpoint of a P2PKH output by using the blockchain.info explorer or your own, txindexed bitcoind. It further takes the output number, transaction id, private key for signing the script and will then output a hex transaction script for BTG on stdout.

This script "goldclaim.py" is the dangerous one and needs to be reviewed carefully. I have also added a test of the ecdsa_raw_sign functionality in Vitalik's library using old test vectors that floated around on BCT. As it is signing deterministically, I hope I am on the safe side there.

Furthermore, there is a "goldaddrconv.py" to convert between BTG, BCH/BTC and regtest addresses (for example, if you use a regtest bitcoind to call decoderawtransaction on the BTG transaction (any bitcoind works, Core/Cash, doesn't really matter) to doublecheck it.)

Finally, there is "injector.py" which speaks just barely enough of the bitcoind protocol directly so that you can inject a transaction into the BTG network. This script should be
universal enough to be used for BCH/BTC as well (after changing the magic bytes), so maybe it is of further use, too.

Of course, the usual disclaimer applies: I do not take responsibility for loss of funds or anything else that might happen if you use that code. The code has neither been reviewed nor thoroughly tested yet!

Given the nature of python imports, you should be able to use the scripts out of the box - without any further installation of the tweaked bitcointools. You should also make sure that no other version of pybitcointools will be used/imported by/available to the goldclaim.py script, to not accidentally sign BTC transactions!

(A bitcoind's decoderawtransaction should indicate SIGHASH_FORKID in the scriptsig by having byte 0x41 as the last byte of the first part, and one should check at least this. But moving BTC and BCH funds away from that address before using the above claimgold.py script is a good idea in any case.)
 
Last edited:

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
the big bang theory aired tonight.

now a bunch of bitcoin core/cash er's are fighting about which is which on the /r/bigbangtheory


looks bad for BTC, BCH'ers are giving sound advice / good TRUE comments, while BTC'ers comments read like FUD and lies, the typical crap... "no devs" "Chinese miners" "roger ver" ...
 

molecular

Active Member
Aug 31, 2015
372
1,391
regarding that r/bigbangtheory thread: now 80% of comments (anything not related to the episode) are removed. Looks like a wasteland, the mods did much work ;-).

I wonder what kind of impression the bitcoin crowd makes when we act out our infighting like that in foreign places. Probably that of a bunch of unreasonable children gone completely into rage mode over some non-issue, which is the truth (or at least not far from it), really.

If I was an outsider to Bitcoin I'd probably say: "Those nerds just can't handle that kind of money. It's gotten to them.", with a bit of envy and a lot of aversion. "Get your shit together guys!", of course failing to see the magnitude of the problem being faced or even realizing what kind of problem that is.
 
Last edited:

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
I've made my call. I am 75% cretin >60% of my predictions will come to be - I will reveal on the 31st.

IDx4iKt1x1MX2+3DzhuUvVpypop/Qiq3T9uBNz8jgJVxV/eC5OfNIU5SeRImuapSivDUfAjUIsM636yhbTSzqfU=
FYI

November 31 prediction.
2X - BTC upgrade to 2MB block limit is successful.
1X - Bcore forked to a new PoW
BCH is up trading >0.10 BTC
BTC1 - has seen some 0-Day exploits and BU node abortion and mining are increasing.
BTC is trading around $10,000

IDx4iKt1x1MX2+3DzhuUvVpypop/Qiq3T9uBNz8jgJVxV/eC5OfNIU5SeRImuapSivDUfAjUIsM636yhbTSzqfU=

1. Wrong
2. maybe 50% we have BTG
3. Correct BCH was 0.067BTC at the time.
4. 50% BTC1 reported buggy - but BU looking a little stagnant.
5. Correct BTC was around $4700

looks like I have better luck guessing at price.

So with some stretch of the imagination 60% of my prediction came to fruition with a relative high degree of certainty.

I'm looking forward to catching up.
 

NewLiberty

Member
Aug 28, 2015
70
442
On block time:

At a higher level of analysis, there are edge cases that occur the shorter the block time. The one mentioned in the Monero stackexchange is one of these, there are others. Shorter block time allows for more types of attacks, it also decreases the window of opportunity for a Finney attack.

On balance of risks, a Finney attack is low risk. Miners are attached to their geography, making them relatively easy to enforce law against. To the extent this is true, Finney attacks are mitigated by legal recourse.
In Monero however, Finney attack risk is higher because miners are all fairly well anonymous, so it makes some sense to balance toward shorter block times on Monero than it does for Bitcoin.

To reduce block time on Bitcoin, it will be important to measure these relative risks. Must measure the properties of the existing network, and simulate the effect of changes under a variety of conditions, attack scenario, and competing forks and economic environments. The closer the block time gets to zero, the more edge cases appear.

...
There may be a perfectly safe block time which is less than 10 minutes and also preserves sufficient scalability forward, I don't know if there is or not. There is likely quite a lot of research to determine this one way or the other, and as I am one who is quite happy with the 10 minutes, I look forward to reviewing the research done by others rather than doing more on this one.
 
Last edited:

molecular

Active Member
Aug 31, 2015
372
1,391
@AdrianX

whats the next BTC ATH?
i mean, whats the top before the next pit stop?
depends what you define as "pit stop": 20% "corrections" are probably going to be frequent for a while. A 60% one might be in the cards around $13k (so: drop to 5000). Could happen early next year.

This also depends heavily on Bitcoin Cash reception. It looks pretty great from a fundamental viewpoint. Loads of people (and merchants) seem to be coming around and realizing Bitcoin Cash better depicts their own visions of what Bitcoin is than core. It takes time and effort to realize the consequences (shift the value). So, a "flippening" still cannot be ruled out from this viewpoint. Just imagine bitpay finally being fed-up enough and enabling Cash payments for merchants, for example. That could trigger it. (I'm still betting on a "slow takeover", though)
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
@lunar: When I noticed that LN invented extra punishment/penalty transactions to deal with certain scenarios in the complexity explosion - that's when I was becoming a lot more sure about the incentives behind LN.

Any sane dev would step back at that point and say "wait a bit, this looks much worse than before. Let's start over and/or go the simple, existing route.".

Except those that like Rube-Goldberg contraptions or are "properly" incentivized to like them.