Gold collapsing. Bitcoin UP.

rocks

Active Member
Sep 24, 2015
586
2,284
@Bloomie
If there is any evidence of this please share it. It would mean that Adam was actively participating in the censorship and not just condoning it with a blind eye, and he should be called out on it (very loudly). Adam participating in censorship might just open a few more eyes as well.
 

Bloomie

Administrator
Staff member
Aug 19, 2015
510
803
Not sure why people are surprised that Bitcointalk is deleting unflattering posts, hasn't that been going on for a while? Look at Fatman's post. Half the stuff he's quoted is gone from that thread.



Edit: Screenshot for posterity
 
Last edited:

rocks

Active Member
Sep 24, 2015
586
2,284
I wouldn't be tweeting about it if I didn't see evidence, but it doesn't mean that Back's the one deleting posts. It does mean that he naively (or deviously) chose a poor place for discussion, and he should take some heat for it.
It means that he not only picked, but insisted on, the venue and then that venue magically censored posts that presented views/arguments against his views.

It does not matter if he was the one deleting posts or not, the collusion is too strong to ignore.

This isn't a random reddit or BTC thread, it is Adam's own thread.
 

sickpig

Active Member
Aug 28, 2015
926
2,541
I wouldn't be tweeting about it if I didn't see evidence, but it doesn't mean that Back's the one deleting posts. It does mean that he naively (or deviously) chose a poor place for discussion, and he should take some heat for it.
maybe the author (BTCjohn) of the comment decided to delete the post for whatever reason? too naive?

edit: definitely too naive
 
Last edited:

Fatman3002

Active Member
Sep 5, 2015
189
312
I woke up to see three of my posts having been deleted from the Back thread. One was me responding to brg444 with a gif of an attack dog, so I wasn't surprised by that one. The other two were comments regarding the wisdom of choosing BCT as a venue. I thought they were reasonable and sufficiently relevant, but I guess they didn't beat iCEBREAKERs stunning technical insights.
 

Windowly

Active Member
Dec 10, 2015
157
385
I woke up to see three of my posts having been deleted from the Back thread. One was me responding to brg444 with a gif of an attack dog, so I wasn't surprised by that one. The other two were comments regarding the wisdom of choosing BCT as a venue. I thought they were reasonable and sufficiently relevant, but I guess they didn't beat iCEBREAKERs stunning technical insights.
Use this forum instead. The moderation here is much lighter.

I wonder if it's possible to respond here on a thread and then post the link in BCT or if they'll delete that as well.
 
  • Like
Reactions: VeritasSapere

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
To add color. Theymos has always engaged in censorship. I first picked it up in 2012(?} when I noticed it going on for some of my criticisms of a couple of mods, namely Bsdbear & Hazek for doing just that and moving /burying posts in different off topic threads. The deception was stunning and is a big part, I'm sure, why Bsdbear came back around in 2015 to lock the old gold thread. Watching them grow into totalitarians had been shocking.
 

Inca

Moderator
Staff member
Aug 28, 2015
517
1,679
The /r/bitcoin Armstrong thread is hilarious. Sycophants like brg444 and the usual gang spouting the party line interspersed with [deleted] and people making oblique references to censorship.

I guess the final attempt at keeping a semblance of superficial normality is to allow a thread to be seen but tightly control the message.

He is killing that subreddit far better than any ideological opponent could!

Great to see Brian Armstrong come out finally like this and directly question the Core team itself. It seems to me a fairly blunt request for a new professional team of programmers to assemble around another implementation. I view his blog as a direct rebuke of the team developing Core and their attempts to halt bitcoin scaling. When the market bypasses this attack (and I use the word carefully) then difficult questions should be asked of those who supported this scheme. I really wouldn't be surprised to find big money and big banks had been secretly bankrolling Back et al.

I hope Jeff, Gavin and the undecideds at Core are listening. Core has no power. Only 30% of nodes are apparently running the latest Core release (2162 nodes) meaning with only a small nudge towards BU and XT, Core ceases to be the most popular client. No wonder they fear a hard fork - if the network fails to install the next Core release (with popular additions like RBF) then the market has already decided the deprecate the current Core developer team by not installing their latest 'improvements' in favour to historical releases.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
So I wasn't following the discussion for a few days and now it feels like things are exploding, so much new stuff here! :)

So let me first reiterate what I said in Gavin's BU-critique thread: IMO with our limited resources, we really want to focus on the core features of BU first, including a well-written patch set for block size (meaning: including a test suite etc.), and then start 'our own thing'. (Which I think will probably eventually necessarily lead to larger deviation from Core in terms of the code base).

I think we do not lack people grasping Bitcoin to a high degree, but we simply do lack devs at the moment.

It is great that we have such a flurry of so many ideas and proposals around and I think this is also a another sure sign that something else was and is broken in Core: The arrogance of parts of the dev team did a great deal of damage to the fostering of a creative and inventive community. I remember people suspecting this effect in action in the debates on reddit and what is going on here now is pretty much proof of that suppressive effect having existed. Politburos will succumb to group-think (a danger around here, too!) and aren't that creative at some point anymore. This feels like a lot of fresh air now. Oh and happy new years, by the way :)

Along these lines: I feel that as much as we want new BUIPs, I think we're going to want BUIPs voting on prioritizing other BUIPs soon...

Some ideas and opinions on the posts in the last couple days:

-----
If you want to change the way the blockchain is represented, the goal should be making it easier to search for unspent outputs. Even better would be to build the basis of a proof system that makes it possible to bootstrap a node without viewing the entire blockchain, with better security than "trust a majority of miners to not print themselves unlimited bitcoins."
Maybe I am still not seeing a fundamental error in my line of thinking, but if the protocol (and most/all full nodes) would enforce UTXO commitments, don't we get truly better security than 'just trusting the miners'?
I mean:
Lets say we have a hard fork that makes all nodes calculate some determined UTXO merkle tree and lets them put the root hash into the block header.
Further, one can put the cumulative amount of unspent outputs at every level into the merkle tree. This would give you a nice and easy way to make sure that the inflation schedule is adhered to. The root node of the UTXO (and maybe also STXO) tree would be [amount, hash], with amount necessarily summing to the total amount of issued coins since genesis, which as we all know is a fixed formula just depending on block height.
So this would solve, as far as I can see, the problem of miners printing themselves unlimited Bitcoins.

Remains the problem that miners reprint history and for example expire some coins at their own choice.

I think the security and trust assumptions in this area are complex, but I see it this way:

Some people run full nodes today. I have to trust other people that they want to continue running the Bitcoin network and continue running to run full nodes that I can connect to, or else my coins are worthless. I think the idea that Bitcoin is trustless because I can verify everything since genesis in some sense is a very weird - and on some level even wrong - approximation. A single node that I own that contains transaction history is worthless without a network of other nodes existing that are like-minded.
With UTXO commitments, I'd go from trusting at least some other people wanting to continue to run full nodes to at least some other people continuing to run honest full nodes. Just a very small section of honest nodes would be enough, as they could all produce the necessary fraud proofs should miners collectively start to misbehave.
Now, if UTXOs are used to allow 'less-than-archive full nodes' that forget some history, I can still let my full node request history from a sufficiently long period back, such as a year or a couple of years, and start validating from the UTXO back then plus all transactions that happened since then, and make sure that all those transactions that happened since then follow all applicable rules.

This would, I think, create a chain of interlinked 'trusting the network to be honest for any larger stretch of time', which I personally think is totally sufficient for a smoothly functioning Bitcoin network.

Furthermore: I think this latter danger with such an approach of miners dropping old coins could be further alleviated by those people who would be affected (owners of old coins that miners nefariously want to 'forget') setting up tracking of their coins through the UTXO trees. This should be a comparatively low amount of data and would be enough to produce fault proofs that his or her coins are being fraudulently dropped. For a very small fee, I could insure my coins against such an action - which might also be a way to pay archive nodes.
Additonally, a schedule to coalesce old UTXOs (being unspent for a long while) together could be implemented that means that old-coin-owners just have to update themselves yearly or so with a comparatively small set of data.

I share Gavin's 'UTXO uh-oh' thoughts because the UTXO set is the only thing that is growing and can grow very fast and needs to be stored (currently) and if hardware doesn't keep up, we would eventually need to implement a scheme to separate the UTXOs into an active and inactive set and shelve those away in a way that has as small amount of additional pain as possible for old coin holders.

-----

While I agree with much of this sentiment, I think you are overstating the extent of Gavin's criticisms. They were mostly "cosmetic" in nature from what I could tell (Gavin prefers that unused code should be deleted rather than commented out, and that changes to the main branch should be done with larger comprehensive pull requests rather than a bunch of small ones).
The complaint about comments is, but I think the complaint that there should be a test suite is not cosmetic. Testsuites are painful to write but they do add a lot of confidence regarding the correctness of the code. I'd love to find the time to grok Gavin's test suite and port it over to BU, and even said/promised I'll look into it, but didn't find any time yet...

Remember also that the BU code received significant testing on Testnet as well, and--like @Inca said--the changes were very minimal in the first place!
Yes, and that's why I think @theZerg made a good compromise given the limited resources: Test the real thing under the best conditions possible (testnet) and then hope that it works. Which is indeed something very different than untested code (which almost never works...)

That being said, I think we should take this very light criticism as a test of character. If Bitcoin developers have historically deleted unused code rather than sometimes commenting it out, then let's just agree to do the same thing. If Bitcoin developers are used to submitting their pull requests in a certain way (excuse my lack of experience with GitHub if what I just wrote sounds silly), then let's do the same thing.
Yes, I agree that we should follow the heritage of Core's conventions in this area as much as necessary - unless it makes sense (with a sufficient argument) to do otherwise.

-----
@Inca, @rocks, @VeritasSapere and the whole RBF discussion:
I personally think RBF is unneeded and I think there will always be a boundary of things we won't include - for example, people could argue that BU is only Unlimited when it includes a multi-player Tetris clone that allows games between BU full nodes and that it also contains a full reimplementation of Monkey Island as an easter egg... ;-)
So I mostly agree with @rocks in post #4385 on this issue.

I think a way out of this and similar issues without too much hateful arguments within our community is that of prioritization: I hope most can see that well tested and documented blocksize code is more important than a fancy way to deal with RBF, for example, so I'd vote for first doing that.
Of course, if someone submits a PR from outside that implements a nice way to deal with RBF, the resource requirements on @theZerg (or who else might work on this in the position of a BU'ler ...) to pull it are of course a lot less than doing the full implementation, so the cost calculation changes and so the prioritization changes...
-----
@Richy_T, post #4383:

Thank you, though this obviously wasn't a lot of work. One way to attack this (or improve the estimate, depending on where you are coming from) would be looking at storage cost in more detail. I think there is probably a small but non-negligible term that makes cost of storage not a constant but a linear function with time.

I like the idea of eventual O(1) Bitcoin. Meaning pruning and some kind of coalescing/commitments. This of course also relates to the UTXO stuff above.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
Ok, I was just informed that I got above a 10k character message limit, so here's my second part:
-----
Still catching up. I just wanted to say thanks for this, it's been something that's been needed for a long time. Currently I'm running the tc.sh script to control bandwidth use but it really is something that needs to be built in. Much more so than many of the other things that are getting shoe-horned in.
There are solutions (I forgot the name of one of the binaries on Linux) that do traffic shaping by rerouting libc calls through LD_LIBRARY_PRELOAD hackery. Has anyone ever tried those?
They obviously only work for shared library builds of Bitcoin. So that might be a clear advantage of @theZerg's approach.

-----
[...]

Note that in this metaphor the people crowded around the guy with the podium (obviously representing Core) don't all support Core's chosen direction. In fact, we can imagine that many of those signs say "Raise the Block Size Limit Now!" But those people are still part of the problem by failing to recognize that we don't need Core's permission to raise the block size. They're the people fretting on Reddit that "Core is killing Bitcoin" and threatening to sell all their bitcoins for alts. The guy walking away? He's the guy running (or coding up) an alternative implementation like Bitcoin Unlimited. That's what we need more of.
Agreed, however I think there's some minor value in what happened in the past blocksize trench wars on reddit. The repeated and drawn-out process of rehashing the old arguments again and again showed more and more people the ridiculous of Core's position and the undercurrents of conflicts of interest and so forth. I am also sure theymos' actions will hurt his team more in the long term than it hurt us. And his actions were his way of participating 'in the trenches'...

I think people clearly started to walk away and the plank is at best very instable now.

-----
This is already becoming too long and it is fully a draft I have not re-red it etc, but I wanted to conclude by saying that in my opinion Desktop Linux failed for one and one reason alone. It never listened to the users. While microsoft for example makes it easy to make your printer restart printing if you have run out of pages or ink once pages or ink is added, desktop linux makes it a nightmare. While microsoft seems to allow the mouse to easily move around in linux for some reason it can be utter annoyance. There are a million of other little annoyances as the above. All utterly easily fixable, but because the devs isolated themselves and so created further and further group think thus lossing touch, very simple things that helped the user were not done.
As a ~20 year desktop Linux user, I feel I just have to say something here :)
I think Desktop Linux failed only if you buy into the repeated battle cry that Linux absolutely has to be on the Desktop.

I think Desktop Linux is just fine and happy in the niche it caters to: People who want to use Linux on the Desktop.

For Bitcoin, the whole equation looks a lot different: First, I think it is absolutely fine if core Bitcoin software (core as in low level, not as in 'Core') caters (mostly!) to a similar 'niche' audience like Desktop Linux users, meaning people who know how to r/w/compile/set up/run/secure code on hardware using only a CLI, people who are closer to the bare metal or in the 'left brain mode' like @Peter R. described.

However, bitcoind is just a small (but of course, essential) part of what is the Bitcoin ecosystem. Many people probably just use a smartphone wallet for most interactions with the Bitcoin network.

But the low limit 1MB limit is affecting them and the whole rest of the ecosystem.

Consensus and network layer and all that.

IOW: The problem isn't that Facebook runs on user-unfriendly Linux. The Linux servers in the background are not affecting the users. An equivalent problem in Bitcoinland would be that those 'Linux servers' prescribe any web site served on them to have a green-on-black look.
-----
@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!
LOL, same here @ C-64, and otherwise academically a surprisingly close hit :) With a nuclear physics background (experimental?), you surely know your Poisson statistics.. :)
@Norway, if you are ever going to organize a BU-specific meetup in Oslo where English is o.k., please post in the event section on this forum. Oslo is reachable enough for me that I'd consider going there just to meet some fellow BU'lers.

Furthermore, I'd also like to see things @theZerg (and he wrote about some in some PMs some of us exchanged for the gitian builds) proposes as further work. I think it would be best for that to have maximum visibility and be public, though.
-----
@Peter R

I've neglected mentioning this because of the potential for self-deception and self-congratulation (and just didn't want to jinx it), but the theymos-controlled forum censorship has served as a wonderful filter. The resulting subreddits are quite a bit more distilled with a lower SNR, while this forum here is concentrated nitro-glycerin. The unthinking and the authoritarians are conveniently penned in in Bubble Boy land. This is also a fruit of censorship and a miracle of antifragility.

The situation seems more bullish than ever.
Yes, but don't jinx it!! :)

That said, what you describe as effective filter will have a dangerous overlap with 'Evaporative Cooling of Group Beliefs'. We need to make sure we don't get too deep into group think, but I am optimistic our community is already diverse enough in opinion.

(Oh and I personally usually don't gather too much from lesswrong and I think some parts are tending to be nuts instead of rational. But that 'evaporative cooling' description is one of the few things that resonated well with me...)

-----
Here's a chart that should exist, but I have not yet seen:

The odds of a bitcoin transaction being reversed start off high with 0 confirmations and drop stepwise with the first confirmation and each additional one.

The odds of a LN transaction being reversed are related to the odds of a dishonest participant being able to cheat and prevent the victim from broadcasting a refund transaction during the critical interval.

That risk is probably either constant with time, or else maybe increases with time since channel opening.

The odds of a LN reversal are probably lower than that of a 0-conf bitcoin confirmation, but the risks should cross over at some point.

It would be great to 1) know how many confirmations that takes, and 2) see it represented graphically.
That's a great idea, but I think it would rather be a schematic informative chart because the exact parameter values are not known yet and are hard to gather. (Especially so for LN since that damn thing doesn't exist yet...)


-----
Finally @ Adam Back's PR attempt: Let him do it, I think it is great to place the pointers over here, but the existence of BU means we parted ways. Just as @Peter R. said ...
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
So I wasn't following the discussion for a few days and now it feels like things are exploding, so much new stuff here! :)

So let me first reiterate what I said in Gavin's BU-critique thread: IMO with our limited resources, we really want to focus on the core features of BU first, including a well-written patch set for block size (meaning: including a test suite etc.), and then start 'our own thing'. (Which I think will probably eventually necessarily lead to larger deviation from Core in terms of the code base).

I think we do not lack people grasping Bitcoin to a high degree, but we simply do lack devs at the moment.

It is great that we have such a flurry of so many ideas and proposals around and I think this is also a another sure sign that something else was and is broken in Core: The arrogance of parts of the dev team did a great deal of damage to the fostering of a creative and inventive community. I remember people suspecting this effect in action in the debates on reddit and what is going on here now is pretty much proof of that suppressive effect having existed. Politburos will succumb to group-think (a danger around here, too!) and aren't that creative at some point anymore. This feels like a lot of fresh air now. Oh and happy new years, by the way :)

Along these lines: I feel that as much as we want new BUIPs, I think we're going to want BUIPs voting on prioritizing other BUIPs soon...

Some ideas and opinions on the posts in the last couple days:

-----

Maybe I am still not seeing a fundamental error in my line of thinking, but if the protocol (and most/all full nodes) would enforce UTXO commitments, don't we get truly better security than 'just trusting the miners'?
I mean:
Lets say we have a hard fork that makes all nodes calculate some determined UTXO merkle tree and lets them put the root hash into the block header.
Further, one can put the cumulative amount of unspent outputs at every level into the merkle tree. This would give you a nice and easy way to make sure that the inflation schedule is adhered to. The root node of the UTXO (and maybe also STXO) tree would be [amount, hash], with amount necessarily summing to the total amount of issued coins since genesis, which as we all know is a fixed formula just depending on block height.
So this would solve, as far as I can see, the problem of miners printing themselves unlimited Bitcoins.

Remains the problem that miners reprint history and for example expire some coins at their own choice.

I think the security and trust assumptions in this area are complex, but I see it this way:

Some people run full nodes today. I have to trust other people that they want to continue running the Bitcoin network and continue running to run full nodes that I can connect to, or else my coins are worthless. I think the idea that Bitcoin is trustless because I can verify everything since genesis in some sense is a very weird - and on some level even wrong - approximation. A single node that I own that contains transaction history is worthless without a network of other nodes existing that are like-minded.
With UTXO commitments, I'd go from trusting at least some other people wanting to continue to run full nodes to at least some other people continuing to run honest full nodes. Just a very small section of honest nodes would be enough, as they could all produce the necessary fraud proofs should miners collectively start to misbehave.
Now, if UTXOs are used to allow 'less-than-archive full nodes' that forget some history, I can still let my full node request history from a sufficiently long period back, such as a year or a couple of years, and start validating from the UTXO back then plus all transactions that happened since then, and make sure that all those transactions that happened since then follow all applicable rules.

This would, I think, create a chain of interlinked 'trusting the network to be honest for any larger stretch of time', which I personally think is totally sufficient for a smoothly functioning Bitcoin network.

Furthermore: I think this latter danger with such an approach of miners dropping old coins could be further alleviated by those people who would be affected (owners of old coins that miners nefariously want to 'forget') setting up tracking of their coins through the UTXO trees. This should be a comparatively low amount of data and would be enough to produce fault proofs that his or her coins are being fraudulently dropped. For a very small fee, I could insure my coins against such an action - which might also be a way to pay archive nodes.
Additonally, a schedule to coalesce old UTXOs (being unspent for a long while) together could be implemented that means that old-coin-owners just have to update themselves yearly or so with a comparatively small set of data.

I share Gavin's 'UTXO uh-oh' thoughts because the UTXO set is the only thing that is growing and can grow very fast and needs to be stored (currently) and if hardware doesn't keep up, we would eventually need to implement a scheme to separate the UTXOs into an active and inactive set and shelve those away in a way that has as small amount of additional pain as possible for old coin holders.

-----


The complaint about comments is, but I think the complaint that there should be a test suite is not cosmetic. Testsuites are painful to write but they do add a lot of confidence regarding the correctness of the code. I'd love to find the time to grok Gavin's test suite and port it over to BU, and even said/promised I'll look into it, but didn't find any time yet...



Yes, and that's why I think @theZerg made a good compromise given the limited resources: Test the real thing under the best conditions possible (testnet) and then hope that it works. Which is indeed something very different than untested code (which almost never works...)


Yes, I agree that we should follow the heritage of Core's conventions in this area as much as necessary - unless it makes sense (with a sufficient argument) to do otherwise.

-----
@Inca, @rocks, @VeritasSapere and the whole RBF discussion:
I personally think RBF is unneeded and I think there will always be a boundary of things we won't include - for example, people could argue that BU is only Unlimited when it includes a multi-player Tetris clone that allows games between BU full nodes and that it also contains a full reimplementation of Monkey Island as an easter egg... ;-)
So I mostly agree with @rocks in post #4385 on this issue.

I think a way out of this and similar issues without too much hateful arguments within our community is that of prioritization: I hope most can see that well tested and documented blocksize code is more important than a fancy way to deal with RBF, for example, so I'd vote for first doing that.
Of course, if someone submits a PR from outside that implements a nice way to deal with RBF, the resource requirements on @theZerg (or who else might work on this in the position of a BU'ler ...) to pull it are of course a lot less than doing the full implementation, so the cost calculation changes and so the prioritization changes...
-----
@Richy_T, post #4383:

Thank you, though this obviously wasn't a lot of work. One way to attack this (or improve the estimate, depending on where you are coming from) would be looking at storage cost in more detail. I think there is probably a small but non-negligible term that makes cost of storage not a constant but a linear function with time.

I like the idea of eventual O(1) Bitcoin. Meaning pruning and some kind of coalescing/commitments. This of course also relates to the UTXO stuff above.
i've been looking at SW more closely. what do you think about this from Pieter:

"In addition to that, you could also right now not prove the spending of a non-existing input. If it's an existing input that was previously spent, you cannot actually, if someone claims oh I'm spending this particular output, how do you go prove that the input wasn't there? We have no means of proving that it was(n't?) there. Every block could commit to the entire UTXO set, which would allow you to make a proof. But there's an easier solution here, and I felt stupid when gmaxwell told me about this. Oh, you told gmaxwell? Hm. Well, you can instead make the witness contain the height of the block which produced the outputs, and the position within the block, and if it's wrong you can just show a proof that the transaction you claimed was there wasn't there. So by adding these two, maybe a dozen bytes to the witness, we could make these proofs for every single consensus rule in Bitcoin right now."

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

also, theymos stated that UTXO are expensive calcs to make and the fraud proofs surrounding UTXO's are large.