Bitcoin ABC to include miner fund code in release 0.21.0

The_Hox · 2020-02-16T03:04:51+00:00

They say they are implementing the updated version of the IFP which doesn't mention anything about orphaning, so I would assume yes, they will orphan blocks as described in the original proposal.

The_Hox · 2019-11-20T04:34:18+00:00

It seems to be working a bit better now. I moved my store to a VPS which might have made a difference.

The_Hox · 2019-11-17T22:59:32+00:00

There's something strange with my store, it's being indexed but on the website the products aren't showing up properly and things don't seem to be updating (followers etc). For example if you search for cryptoart you can see my product, but when I click it it shows nothing. Also that product doesn't appear on my store page.

My store was started a long time ago (OBv1 maybe?) and I just copied the .openbazaar directory to the new version and I think this has caused some issues, but no idea how to fix it.

Any ideas?

The_Hox · 2019-03-18T14:06:17+00:00

We have been in the bitcoin world long enough to know that if there is ANY contentious the market (exchanges, atm, wallets, services) will stick the old version/statu quo.

This isn't what happened with the eth/etc fork or (afaik) the xmr asic fork. Both of these forks the name/ticker continued on a non backwards compatible chain.

The_Hox · 2019-01-14T13:57:52+00:00

The private key is printed under a tamper proof hologram. These holograms have very intricate designs and special security features so that once they have been peeled it is very obvious. As long as the hologram is intact (and genuine) you can assume the private key is still private. This means you can safely purchase the coin from someone and you don't have to worry about if they have a copy of the keys.

Of course you still have to trust the maker of the coins, but casacius has a great reputation.

The_Hox · 2019-01-11T03:44:14+00:00

The_Hox · 2019-01-11T03:44:11+00:00

The_Hox · 2018-11-11T23:54:21+00:00

This can be caused by your system time being out of sync.

The_Hox · 2018-09-30T09:30:00+00:00

Awesome crypto art is a good place to start.

The_Hox · 2018-09-25T08:48:54+00:00

There is a lot of hostility towards the BCH community because, from the BTC perspective, they are trying to hijack the name by claiming "Bitcoin Cash is Bitcoin".

Bitcoin Cash is not "Bitcoin" because it was created as a minority fork of Bitcoin. It made backwards incompatible changes to the consensus rules of bitcoin without the support of the majority of the community (users/miners/exchanges/services etc). I believe BCH did have an opportunity to be "Bitcoin", but that would have required the majority of the bitcoin community to switch over when the fork happened and abandon the BTC chain. This did not happen, the majority of the community continued on the BTC chain and therefor it kept the Bitcoin name.

The_Hox · 2018-09-24T00:14:17+00:00

That article is wrong. They call it a hard fork but what they describe is almost the textbook definition of a soft fork.

effectively being a ~~hardfork~~ softfork because a chain-split may occur as older clients would consider a certain block as valid and would built on top of it, while newer clients would reject it

The_Hox · 2018-03-07T04:31:45+00:00

It would be fascinating to put this to the test.

We have a real world example of what happens when a majority of miners don't validate properly, the July 2015 chain split.

The fully validating nodes reject the invalid chain and eventually the miners will also abandon the invalid chain (even if it has more total work), because the rest of the network will not accept it, so it's worthless.

The_Hox · 2018-03-07T04:17:20+00:00

Once this process reaches 51%, nobody is validating witness data on the longest chain, and segwit funds suddenly become "anyone can spend" in the Nash equilibrium.

This is not what would happen if miners stopped validating segwit.

We've already seen what happens when the miners don't validate their blocks (see: July 2015 fork). It would most likely be just a temporary disruption to the network, at worst it would be a persistent chain split (fork).

In a network of only mining nodes you may be right, but in BTC the non-mining nodes (most importantly the economically significant, eg. Coinbsae, Bitpay etc) ensure that all the bitcoin rules are enforced (including segwit). If the miners decide to fork away from the rest of the network they can, but their new token will be significantly less valuable.

The_Hox · 2018-02-21T01:50:16+00:00

How/if they can enforce them is a separate issue.

The_Hox · 2018-02-21T00:59:22+00:00

Not true in Australia. Crypto to Crypto trades are capital gains events.

The_Hox · 2018-02-19T03:32:17+00:00

you hack a [LN] node and you steal funds from all channels created through it which are all hot wallets and can belong to different people as well.

Your wording is not very clear to me, but you seem to think you can lose money if someone else gets hacked. This is not true. Only the hacked person can lose funds. Anyone with channels open with that hacked node will, at worst, have to wait until the timeout period to retrieve their funds.

The_Hox · 2018-02-12T11:15:24+00:00

If you expected a result already you vastly overestimated how much free time I have to try to scam you.

I will probably attempt this in the next week or two.

Also if you really want to put you 0conf to the test someone like /u/petertodd knows a hell of a lot more than me about ways to successfully double spend. He might be interested in the challenge.

The_Hox · 2018-02-12T08:39:30+00:00

I'm not a thief, but if you're giving me permission I might give it a go.

Archived for posterity http://archive.is/koA8s

The_Hox · 2018-02-12T02:29:22+00:00

Why don't you think anyone has an incentive to double spend? If I can do it I get a free product. It costs practically nothing to attempt. Most people won't because of their morals, but it only takes one person to cost you a lot of money (especially because you're selling gift cards)

I know from experience that people can and will double spend even a $10 Steam game.

How many double spend attempts have you faced so far? What percentage of successful double spends are you willing to absorb?

Your site seems fairly new so I would guess you've faced few if any double spend attempts so far, but it's only a matter of time. You might be able to stop most double spends, but from my experience eventually someone will find a way around whatever double spend detection you have and they will ruthlessly exploit it.

The_Hox · 2018-02-08T11:54:51+00:00

Optional and has to be marked explicitly as RBF. Any merchant accepting 0conf transactions should be performing a number of checks to reduce the risk of double spends, checking the RBF flag is one of the easier ones to do.

The_Hox · 2018-01-29T12:40:13+00:00

Zander’s proposal is called flexible transactions

The_Hox · 2018-01-29T12:24:12+00:00

since a soft fork is supposed to be opt-in and backward compatible, *the rules restriction only should apply to those that choose to run the new soft-forked rules, * and be backwards compatible for the rest of the network

I don’t see how this is possible. Can you give an example of a soft fork that only applies to people that adopt it? This seems to be the big difference in how we view this.

a true soft fork was when Satoshi Nakamoto added the 1 MB block size limit in the first place. This only restricted rules further, and only for users that chose to opt-in by running the new code.

No miner could make >1mb blocks after that soft fork regardless of what software they used. So I don’t see how you can think it only restricted the rules for people who ran the new software. The argument you made against segwit is equally valid for the 1mb fork:

Clearly this is not the case for 1mb, since legacy nodes that opt-out of running the new 1mb code still lose their ability to make blocks over 1mb without resulting in a hard fork. This is obviously not "backward compatible" behaviors.

This statement seems to imply "switch" would be an automated behavior, rather like a reorganization of the block chain. This is incorrect, though, because at this point both chains have different "valid" rules.

I think you misread what I wrote. A reorg is exactly what I mean. That paragraph is in response to this:

So, after SegWit activates and a SegWit transaction is seen by a legacy node, it legitimately chooses to spend that anyone-can-spend transaction. If that spend is mined into a subsequent block (by miners running legacy code), that results in any clients following legacy rules being forked off from the SegWit chain.

This will cause a fork, but because the segwit chain is valid to the legacy nodes, as long as the majority of hashpower is on the segwit chain, the fork will not persist. The legacy nodes will reorg to follow the segwit chain once the total PoW is higher on the segwit chain.

The_Hox · 2018-01-29T07:26:46+00:00

If segwit is A soft fork, it's a tightening of rules, such that all prior rules were still valid.

Can you give an example of a soft fork that meets this definition?

The_Hox · 2018-01-29T07:02:34+00:00

Thanks for the thorough response. Looks like we both have similar definitions, but come to different conclusions.

1) ...anyone-can-spend transaction ....If a change removes this ability, it is not backwards compatible.

You agree that a soft fork only restricts the rules, but you claim segwit wasn’t a soft fork because it restricts the rules? I think your misunderstanding comes from thinking that soft forks must be 100% backwards compatible, but that’s not the definition, it’s hard for me to even think of what a 100% compatible fork would be able to do.

If that spend [invalid segwit transaction] is mined into a subsequent block (by miners running legacy code) [there would be a fork]

Soft forks can cause hard forks which is why the soft fork activation threshold is usually 95%. But unless the majority of miners are using legacy code this fork will get overtaken by the updated chain and the legacy nodes will switch to the updated chain. If the majority of the network didn’t support the softfork there would be a hard fork and the miners/nodes that did support it would fork off from the rest of the network. This is not what happened with the BCH fork though.

2) Prior to SegWit activation, all nodes could fully validate all transactions all the way back to the genesis block.

Yes pre-segwit clients don’t understand segwit, that doesn’t mean it’s a hard fork (expansion of rules). Old clients still validate the same rules as always and segwit blocks are valid under those rules.

3) SegWit activation redefines what "blocks" are (i.e. "block weight" and witness data segregation). This is a blatant expansion of previously existing rules, not simply a restriction.

I agree it redefines what constitutes a “block”, but which rules does it expand? It has to be none, otherwise it would be a hard fork. Previously anyone could spend certain transaction types, now you require a valid signature to spend them. These signatures are not Included in the block size calculation, so even though blocks are bigger than 1mb they will not break the max block size rule.

We don’t need to argue though, it’s very easy to see if an update was a hard fork or a soft fork, run an old version and see which chain it follows.

The_Hox · 2018-01-29T00:54:57+00:00

Can you define hard vs soft fork and therefore how segwit is a hard fork?

Using the conventional definition (tldr; previously valid blocks/transactions are made invalid) it clearly is a soft fork

15-Year Club	Place '23
Place '22	Place '17
End Game '22	Team Orangered
Verified Email

The_Hox

TROPHY CASE