Gold collapsing. Bitcoin UP.

[Bagatell]

Feliz Año Nuevo de España

 

[Mengerian]

Fraud proofs absolutely could be implemented without SW.

Yes, to me Fraud Proofs and Segregated Witness seem almost completely orthogonal. I just wanted to make sure there wasn't something I was missing.

I sketched out a method for doing so here:

https://gist.github.com/justusranvier/451616fa4697b5f25f60

Yes, thanks, your proposal was my primary reading when I was trying to understand the concept of fraud proofs.

I did have one comment/question about your proposed implementation. I am just wondering about the requirement that transaction in the block be ordered by transaction hash. I think this requirement can be eliminated is you construct the proof tree so that that the leaf nodes contain "existence proofs" for the transactions corresponding to each input of the transaction. In other words, the leaf nodes of the proof tree would contain block hashes, and partial merkle trees leading to the input transactions.

Would this work? Even though it seems like lots of information to include in the proof tree, I think it would actually result in more efficient fraud proofs. The fraud proof would then just consist of the existence proof of the proof-tree node, which contains the existence proof of the input transaction. And since the proof trees can be generated locally by full nodes, having more information in the proof tree is OK, especially since it is information full nodes need to keep track of anyway to generate the proof trees.

Thoughts?

 

[Norway]

@theZerg
I want to help on the Bitcoin Unlimited project.
I'm 45, live in Norway, learned to program om Commodore 64, have programmed a lot, but never on open source projects, worked as journalist for newspapers and art director for magazines, done startups that failed, studied nuclear physics at the University.

I have organized 8 bitcoin meetups this year. http://www.meetup.com/Oslo-Bitcoin-Meetup/

If there is anything you need help with, please ask!

Happy new year everybody!

 

[chainstor]

Happy New year to all.

2016 is going to be an interesting period in the development of Bitcoin, and I suspect BU will have front row seats.

 

[Justus Ranvier]

I did have one comment/question about your proposed implementation. I am just wondering about the requirement that transaction in the block be ordered by transaction hash. I think this requirement can be eliminated is you construct the proof tree so that that the leaf nodes contain "existence proofs" for the transactions corresponding to each input of the transaction. In other words, the leaf nodes of the proof tree would contain block hashes, and partial merkle trees leading to the input transactions.

Would this work? Even though it seems like lots of information to include in the proof tree, I think it would actually result in more efficient fraud proofs. The fraud proof would then just consist of the existence proof of the proof-tree node, which contains the existence proof of the input transaction. And since the proof trees can be generated locally by full nodes, having more information in the proof tree is OK, especially since it is information full nodes need to keep track of anyway to generate the proof trees

You can get rid of the ordering requirement if you can eliminate all cases where you need to demonstrate the non-existence of an item in the merkle tree. You don't want to be in a position where you need the full merkle tree in a proof, because even if those trees are small today they will not always be small.

I think you're right that putting the existence proofs, rather than just source block numbers, in the leaf nodes of the proof tree would eliminate the need to sort the transaction tree.

The proof tree itself would still need to be sorted by txid though, so that a compact proof can be created showing that a transaction in a block has no corresponding proof tree entry.

 

[Zangelbert Bingledack]

I'm trying to get ProHashing to see that altcoins are pointless. He asked why it would be a problem to switch everyone over to Litecoin, since it has more capacity. [LONG POST]

 

[theZerg]

@Norway awesome! What languages are u strong in? Do you like GUI network optimization interface with OS? You like nitty-gritty or broader scope? I can PM you with some ideas to get your toes wet.

 

[Zangelbert Bingledack]

Oh boy...

 

[Windowly]

There's a widespread misconception that translation is a simple, machine-like process. You don't just take the English words and transpose them into Chinese words. It's not as simple as just hiring any old English-Chinese translator. The translator has to

1) be very familiar with Bitcoin in general or else the translation will be incoherent

2) actually understand all the concepts covered or else the translation will be far less persuasive (and could be worse than not having a translation at all)

This is especially true when dealing with a paradigm shift like BU, where without pitch-perfect phrasing the reader will likely walk away confused. Ideally the translator will also have experience debating BU with other Chinese native speakers.

That is why having someone here participating would be ideal. They could get up to speed, bring the debate to Chinese Bitcoin forums, self-correct on the phrasing for maximum impact battle-hardened in some Chinese forum discussion, and even bring valuable feedback about how to tailor the message for maximum impact to a Chinese audience (may involve changes to content of the text itself, not just a straight translation).

In other words, we need a Chinese PR agent who is up to speed on understandings here and can write well. Failing that, a Chinese bitcoiner who can be given a solid grasp on BU philosophy and significance.

Hiring a lay Chinese translator would just be a waste of money. A Bitcoin-conversant Chinese translator would be acceptable but not ideal unless they are willing to take time to understand BU. Any misunderstanding is liable to show through in the text and get BU written off in China, so a mediocre translation may be worse than none unless it is only about the broadest strokes and doesn't get into any technical details.

Also, someone who is interested in BU already will be most motivated to go the extra mile, and they probably won't charge an arm and a leg for it.

You're absolutely right. Translation isn't a machine like process at all. Ideally anybody we pay we would pay enough that he or she would take the time to thoroughly understand the bitcoin space and BU before attempting to translate anything.

We'd also want to thoroughly test any translations to make sure there are no errors or misunderstandings.

Perhaps we can ask BTCC if they have any recommendations? Or one of the other Chinese exchanges? They should know people (either someone on their staff or someone else who is a good translator and also knows the Bitcoin space). Or they could recommend a PR agent who is willing to get up to speed on BU before helping us market this implementation.

 

[Mengerian]

You can get rid of the ordering requirement if you can eliminate all cases where you need to demonstrate the non-existence of an item in the merkle tree. You don't want to be in a position where you need the full merkle tree in a proof, because even if those trees are small today they will not always be small.

I think you're right that putting the existence proofs, rather than just source block numbers, in the leaf nodes of the proof tree would eliminate the need to sort the transaction tree.

The proof tree itself would still need to be sorted by txid though, so that a compact proof can be created showing that a transaction in a block has no corresponding proof tree entry.

Ok, cool. I also think it's very important for the proof tree to have a canonical structure so that it can be generated deterministically from the list of transaction in the block. So ordering by txid could be part of that.

If the proof tree can be generated deterministically, then it does not need to transmitted over the network, it can be generated locally by each node. The only information that needs to be communicated is the merkle root of the proof tree, which has to be included in the block and validated. In theory, the proof tree data does not even need to be stored locally by the nodes, it could be generated on-the-fly as needed.

Because of this, it might make sense for the proof tree data structure to be fairly large. We want to keep the data that needs to be communicated for the fraud proof small though, and I agree that we don't want to transmit whole merkle trees as part of the proof. Having the existence proofs of inputs in the proof tree leaf nodes would, I believe, result in the smallest possible fraud proofs for non-existent inputs.

 

[Norway]

@theZerg
I'm very strong in Norwegian, and below average in English. If you mean programming languages, I've done a lot of them. I think they are very similar, but I always spend 2-3 weeks to get into a new language/IDE.

I don't understand what you mean by "Graphic User Interface network optimization interface with Operating System". Maybe you just mean GUI optimization? (The "network" word puzzled me). I think I'm good at GUI, but who doesn't? lol

I believe a simple way for bitcoin to scale properly at long term, is to share the confirmation work between miners. No need for every single miner to confirm every single transaction. But thats future stuff.

I'll do my best to help with BU, it doesn't have to be programming, but it could be that too. Please PM me with some ideas to get my toes wet

 

[Zangelbert Bingledack]

 

[Norway]

@Zangelbert Bingledack
Lol, no shit! Bitcoin is eating Fed's lunch. Not today, but in the future. It's a constraint. A 100% constraint

 

[Erdogan]

The way I see it, a client ought to make it easy
to modify all those variables that reflect the individual
preferences of a node operator. The tolerance threshold for
misbehaving peers, for example and (of course) the acceptable
block sizes.

Block reward, block interval, difficulty etc. OTOH are consensus-critical
variables. Your communication will be ignored and your node banned if you
try to alter those.

And even if some majority change them, the chain will split and the majorcoins will go the way of the fiats. So this is really not a problem. And I see no reason to make it convenient to change those parameters.

 

[Zangelbert Bingledack]

The Bitcoin Unlimited way of thinking is permeating into the community consciousness.

 

[Erdogan]

@Aquent

Don't dismiss XT yet. It could be regarded as BU with a specific set of parameters chosen. It could be the Schelling point for the breakout from 1MB.

 

[Windowly]

And even if some majority change them, the chain will split and the majorcoins will go the way of the fiats. So this is really not a problem. And I see no reason to make it convenient to change those parameters.

I agree 100% about the blocksize reward. A 21,000,000 cap is what makes bitcoin, bitcoin and it shouldn't be easy to change that.

One of the beauties of the alt-coin space is that people can try other ideas and compete freely for market space.

I know in the end, of course the market decides. Still, it would seem to me that by just providing that option BU is promoting additional tinkering with that constraint.

 

[solex]

@theZerg
I want to help on the Bitcoin Unlimited project.
I'm 45, live in Norway, learned to program om Commodore 64, have programmed a lot, but never on open source projects, worked as journalist for newspapers and art director for magazines, done startups that failed, studied nuclear physics at the University.

I have organized 8 bitcoin meetups this year. http://www.meetup.com/Oslo-Bitcoin-Meetup/

If there is anything you need help with, please ask!

Happy new year everybody!

@Norway, and other potential volunteers, a great way to start is to tackle one of the BUIP002 BIP Implementations originally proposed for Bitcoin Core which are all to be separate commits. Some are trivially simple like the Core1MB and would be a good way to practice a pull request.

Edit: To be clear, there is no vote yet, so until the BUIP is passed by the membership then no pull req for it will be committed.

Happy New Year to everyone as well.
I have a feeling that in 12 months time we are going to look back and be totally amazed at what has been achieved.

 

[Zangelbert Bingledack]

One practical argument for making block reward user-adjustable:

I heard that in the November 2012 halving a few miners continued mining under the 50 BTC/block rules. The block rewards in the found blocks were of course worthless. They learned their lesson and probably won't try anything like that again.

Now suppose if the block reward had been easy to adjust in a GUI menu. "I'll just raise it to 51 BTC. See if they let it slide." Probably just one miner would have tried, and the word would have spread. By the halving perhaps there would have been no one even considering it.

Adding barriers makes the system brittle, like child with strict parents, liable to experience larger sudden changes because of the barriers allowing a "stick-and-slip" dynamic. The kid goes off to college and ends up getting alcohol poisoning because it was the first time he had any real freedom. Someone's going to offer it anyway, so the earlier it is offered the less pressure can build where a group of people would all pile on at once. A few odd people can try it out in an uncoordinated fashion, get burned, and there never comes coordinated action. Not having it is a security risk.

For example, imagine a miner's meme circulating in 2020 before the halving to 6.25 BTC is scheduled: "12.5 BTC continues if you believe it does. The halving is a figment of our imagination. Get ready with this patch: RedPill.exe" Having the option in there before then and letting random people try would inoculate against that.

 

[YarkoL]

In principle and in theory I suppose any variable
can be user-adjustable if there are means of signaling
it and a set of constraints and incentives that allow
market forces (or similar) to drive it towards consensus
or equilibrium.