speed of technological development
We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security. Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173 vs ethereum still behind bitcoin 0.1 without a strong safe to use address system. Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster. |
|
|
|
what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market
Seems pretty unlikely, heh. BCH supporters made a pretty huge song and dance about how SegWit supposedly wasn't part of Satoshi's vision and isn't "true" to Bitcoin, so there'd be an inordinate quantity of humble pie to swallow if they went down that route. It's too much of a marketing U-turn to take it seriously. BCH already incorporates part of segwit-- BIP143, the segwit signature scheme they've just renamed it "safesigs" and present it like it's their own brilliant invention. They're working on merging BIP173 (the error protected base32 addresses we created) but renaming it "cashaddress"... Sense a pattern here? They've been going on about 'flextrans' which contains exactly the same design feature about segwit that they've thrown so much "not Satoshi's vision" mud about-- that new transactions don't commit to past signatures (a necessary criteria for fixing malleability). They've gone on about "schnorr signatures" but their implementation there is just our prior abandoned code with the copyright headings removed and their own names added. Don't make the mistake that honesty or technical merit are even considerations in their marketing. For all it matters for their marketing there is no u-turn so long as they don't admit it. If you can tell that they are full of crap you aren't in the bcash target audience. Now the interesting point is that 2Xcoin is going after the same unsophisticated audience, splitting that market. |
|
|
|
I saw the thread title and figured it would be a necopost of a 2011 thread.  |
|
|
|
but bitcoin software is a special case as consensus rule changes require mass spontaneous upgrades
No it doesn't, in fact a decenteralized system cannot change like that. If bitcoin can be forced into "mandatory mass upgrades" then it has failed. Moreover, well constructed changes in consensus rules are detected and responded to by existing software: (And not just at the change, but in advance too!)  I don't really appreciate the tone here, that's not warranted.
I apologize for offending, but you appear to be wading in somewhat uninformed and telling other people what they should do. This is very insulting. I don't mean to offend, but with your approach you are going to get a blunt response. Also, I didn't imply a centralised world,
Perhaps you didn't intend to, but a world where we depend on trusted parties with special secret keys that have special powers is that kind of world. original post. Forums, reddit, mailing lists are all centralised forms of communication to some degree. All of those suggested alternatives to an alert/notification system require a level of trust. They are not trustless.
And none are official, people use all of them and many more. There are singular methods of communication that are highly controlled but communication between people is not. Yes, this justification applies equally to a client alert/notification system.
It does not, because a message displayed on your screen commanding urgent and immediate action does not provide a timeframe for public review and communication to take place. Multisignature is better described as semi-decentralised. It depends on a trusted authority, the that the authority is a (perhaps informal) corporation rather than a natural person doesn't change the fact that such a system has a fixed center. Not only should users not want to depend on one, prudent parties don't want to be one because of the generation of completely uncompensated risk. (It becomes attractive to compromise or even kidnap key holders in order to generate false notices; no one pays us to take on risks like that so we want. The kind of people who wouldn't care about that are the kind of people who on no account should you ever trust with it...) This would be my preliminary proposal for a "best practice" notification system: You will have more luck with proposals if you first demonstrate empathy and a high degree of understanding. I don't feel that you are doing that here. In particular, the claims that consensus systems require sudden/unexpected changes or that we're currently not able to have users detect consensus rule changes -- when we already have mechanisms for this which work. |
|
|
|
Without some kind of carefully crafted notification, there will always be users who never ever update. It feels like stagnation is built into this system and it will never be overcome.
It sounds like to me that you're making assumptions which are simply not true, then fixating on particular solutions. People do upgrade, this is a fact and we've seen it quite clearly in practice. If you want software to nag users when it's really old, it could do that independent of there being any alert system. So the concern is that if you or any other developer with access to an alert system is compromised, "with access to" -- instantly you begin by just _presuming_ a centralized hierarchical world with privileged parties that have power over others. I guess my response would be, doesn't that concern also apply to users simply downloading the software? No, only _new_ users that downloaded it when it was compromised; not everyone already out there. You could counter that by saying that users can check the source code, but the reality is apart from some very select people, users aren't reviewing source code, Most users do not, a few do. If the few that do find problems, they can sound alarms; protecting others (see the prior point). prevent malicious developers or compromised developers exerting control. Multisignature is still trusted and centralized. |
|
|
|
I see what you're saying, but I'm still not convinced and am going to remain in disagreement. (That's okay, can't agree on everything.)
Kinda matters when you're presuming to tell other people what to do. Why not have an informative window prior to installation of the update? Explaining these very things, with something like a quick executive summary: This update contains XXXXX, some users may not wish to update, **you do not need to update**.
If you do not agree you are welcome to continue using the previous version.
Please click cancel and continue using your current client Because this requires the source to be honest about XXXXX. In other words, it requires trust. We are philosophically opposed to building systems which have an ongoing and realtime trust requirement both out of concern for the security of our users but also as a factor in our own personal safety. |
|
|
|
Our node implementation has full support for bip-0151.
Might be a waste of your time there, I expect it to change when it gets review and public implementation work. Why are we seeing and speaking to Bitcoin Core nodes with bip-0151 support on mainnet but no source code in GitHub. The paper says "Reference implementation" and it is blank. Is this closed source development we are detecting on mainnet or is there a public branch with the code?  You're probably connecting to fake bitcoin core nodes, there are a lot of them mostly run by blockchain analytics companies, thanks for identifying a new distinguisher. |
|
|
|
|
Alice pays address 1Bob for his monthly paycheck
Bob uses the 1Bob coin to pays address 1Carol for dinner
Alice pays address 1Bob again his next paycheck
Mallory shows up and replays the transaction where 1Bob is paid to 1Carol
Bob is sad.
There are many other cases like this. If you address all of the one by one, you just end up with an inefficient and inflexible version of the UTXO model.
|
|
|
|
Almost everyone I've ever seen link to their own binaries on virus total was in fact distributing malware. Virustotal is worthless for the kind of custom malware that is often posted on this forum and gives people a false sense of security. There are many programs out there for shamir secret sharing, such as http://point-at-infinity.org/ssss/ most implementations I've seen leave a lot to be desired, including insecure random number generation which doesn't grant full information theoretic security, to incorrect share splitting such that sub threshold collections are sufficient to recover most of a key, to just gross timing sidechannels which any secret key handling software should avoid. It is my view that In general, secret sharing is largely snake oil in practice because you must have a computer to split and join keys and if that computer is compromised your security is gone. If you really had a compromise immune computer, just leave your key there and avoid the pointless ritual. Bitcoin has multisignature which allows split keys without any single point of failure. Anyone considering secret sharing should first have a darn good reason they aren't using multisig. |
|
|
|
He waited 4 years to try to avoid detection.
Unless I'm missing something the party moving these coins may not be the thief... he could have sold them or deposited them in an exchange 4 years ago and they're just moving now. |
|
|
|
Shameful. Shameful if they're legit, shameful if they're edited. Here was my response to "CipherionX"'s attempts at getting leaks. Publishing someone's private messages without their consent is
generally considered unethical. In some situations it is less of a
big deal and may be excusable, in others it is a really big deal.
Satoshi didn't make those emails public and I think it's not really
anyone elses right to do so. If he wanted them public, presumably he
would have made them public or would make them public now. Breaking
his trust is a disrespect to the great contribution he made to the
world.
Publication of his private emails may create personal risk of theft or
physical harm for him and his family. The damage created from a loss
of privacy can't be undone and it may not be obvious from even careful
analysis what elements of a message may be revealing. Even the
smallest of details could be potentially identifying. Disclosure of
his private correspondence may have terrible consequences, far worse
than publishing most other person's private emails.
From message which have previously been leaked, we know that Satoshi
complained about the fixating and focusing on him and his identity.
Too bad the people he complained about doing this did not respect his
wishes.
His private messages have also been utilized by scammers to aid their
inept impersonations.
Obsession with Bitcoin's creator detracts from the greatness of his
accomplishment: he built a system where it doesn't matter who created
it or why-- because we don't have to trust it or each other.
I hope that people will delete private messages they have and forever
protect them from disclosure rather than publish them.
I have done so, and whatever I have or find I will not disclose and
will continue to endeavor to secure so that I cannot disclose it
through error or future weakness. Perhaps if you sit back and
consider this some you will realize that there is some merit to these
points, and you'll choose to abandon this project. I hope you do.
Cheers,
|
|
|
|
How typical Last time you ran out of technical argument, you've also gone to question my credibility. I'm not questioning your credibility, just pointing out that you're making yourself look stupid when you insult me for not noticing things that were discussed long before you noticed them. I believe I did read it and haven't found anything else than "downloading some blocks".
You just dress it up with fancy words, like "incompatible consensus rules", "wasting of network resources", "helping both sides", "etc." - all propaganda bullshit, which at the end of the day comes out to the same thing: you don't want to download (and verify) their blocks and txs and you don't want to send them your blocks and txs.
WTF dude, please actually read, AFAICT no one ever talks about downloading blocks in that thread. Bitcoin already typically won't download and will never attempt to verify their blocks. Instead, the PR points out things like this: Consider a node with 8 peers, all s2x nodes. At some height the s2x issuance activates, and s2x stops sending valid blocks to our node. Yet the s2x network then takes hours (like Bcash, or over a day like the btc1 testnet) to mine the even a single additional block, and because s2x has no replay protection invalid tx signatures will also not cause banning. When s2x does get a block it will only disconnect a single peer and may find connection slots exhausted all over the net (due to attacks or increased demand from other links cutting). If it has a single connection up to the Bitcoin network, if it has more blocks it may not even notice s2x blocks are invalid if they're part of a less-work chain, since s2x doesn't use the HF bit. All of this disruption, potentially quite severe and damaging (e.g. esp if our node in question is a Bitcoin miner) is avoided by not making a hard cut change to the network topology, but instead adopting a topology from the moment the node starts that will continue to be good for it in the future, with the change happening over time rather than as a network wide system-shock.
It's pretty sad that posters on rbuttcoin are reading and understanding better than some people here. |
|
|
|
Recently you've had two invalid blocks routed by bitcoin core clients and you hadn't even realized it before I told you.
lol. You were weeks behind the discussions on this, I knew about them in minutes. You discredit yourself with your efforts to brag. Not everyone needs to make a big deal about it. Now you are trying to convince me that one large block which the core nodes are going to reject right away, without routing and trying to verify it, is an issue?
It would be only one block! You would not download any of its children, as the further headers will not link anymore. Go read the actual discussion in the PR rather than being uninformed. Downloading some block is not a concern in the slightest. You are handicapping your intellect by being arrogant and presumptive. you should not be adding them to then peers database in the first place. No, then that introduces a simple attack where I advertise your addresses with other bits to prevent people from connecting to you. Moreover, the bits change: someone can start S2X up to check it out and switch back. Disconnecting is harmless and gets you the latest information. that this can only be beneficial after the fork has already happened. The PR discussion contains a step by step description of why that isn't the case. Please, do all of us a favor by actually reading it. or "banblock=<somehash>" command line prompt.
We have this-- the invalidateblock RPC. If most of the users follow the fork, then it will win. If not, it will stall out. I agree that user's decide, but there are altcoins that have fewer users than Bitcoin has active developers yet maintain a non-trivial market cap. The fork with the most hashing power will have an overwhelming advantage. If 95% of miners go with SW2X, then the main chain will have a 3 hour block time.
This would destroy confidence in the main chain.
I disagree. A large interblock time is safe, if inconvenient, and the same arguments apply to the hysteria about the halving potentially killing hashrate. |
|
|
|
|
The developers of BCash went and submitted patches to XT, unlimited, etc. to turn them into bcash notes. So that is likely what you are seeing.
|
|
|
|
IMHO miners would be crazy to go into 2MB big blocks hard fork.
I agree, but I think not everyone understand Bitcoin as well as you. It has zero chance to work in a long term, while creating a very bad precedence.
I still think you just don't understand what this is trying to do. It's intended to be both in the interest of S2X nodes and non-S2X alike. We need to adapt the topology before the fork happens, thankfully they helpfully identify themselves. (in part because they already influence their own peering decisions, selfishly: they don't want non-s2x nodes to have the same benefit it seems!) |
|
|
|
find a way to reliably take a DNA sample from them
Some people are chimeric and some of their tissues have different DNA than others. e.g. due to combining with a sibling in the womb.  |
|
|
|
What I have seen by monitoring the network is that 0.14.x software has been (so far) the fastest to relay blocks.
Which is understandable as it relays blocks before verifying it.
Just to clarify: they are only sent before being completely verified only for opportunistically sent compact blocks to peers who have specifically requested it. (And they are not completely unverified even then, POW, presence of all the data, etc. is still checked first) What is not understandable for me, though...
Why pre 0.13.0 software is faster in relaying transactions?
0.14 is "faster" at relaying transactions, much faster in fact, but it has higher _delay_ because the delays are intentional and older versions had a bug that bypassed the original privacy protections for transactions, and also wasted a lot of bandwidth in the process. I was just thinking, might this lower performance be caused by the memory pool feature, that groups txs so the blocks could be miner for more dosh? Nah. Ancestor feerate handing is very efficient. It does take a little bit of time, but we have since made the rest of the processing much faster to compensate. E.g. since 0.12 we eliminated _disk_ accesses which always happened for accepting an unconfirmed transaction to the mempool, as you can imagine that was a pretty big speedup. Nodes are not supposed to relay transactions as fast as possible, doing so leaks the origin of transactions in the network pretty badly. It also wastes bandwidth from sending single transactions at a time in INV packets and from transactions crossing in flight. Unfortunately performance enhancements back around maybe 0.8 or so broke the original transaction relay delays. In recent versions transactions are queued to be advertised to peers, then sorted by dependency (to eliminate orphans) and fee-rate (so most tx most likely to get mined quickly relay faster), any replaced or evicted or remotely advertised transactions are eliminated, and what remains is sent on a random timer (with a 5 or 10 second expected time, which ends up being 100ms scale for the node in aggregate) and rate limited to a couple times the networks nominal total rate. I expect that as further privacy improvements happen, the average delay will go up somewhat further. These delays are still negligible in general. You can read more at https://github.com/bitcoin/bitcoin/pull/7840 and in the release notes. Also it's likely that the main reason you see more transaction traffic from old nodes is that they don't implement fee-filter so they will relay you a lot of stuff that you just will discard, like low fee spam. |
|
|
|
|
Show Posts
