Bitcoin Forum
September 23, 2017, 02:46:23 PM *
News: Latest stable version of Bitcoin Core:  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 240 »
1  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 05:10:25 AM
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.
2  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 02:08:50 AM
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.

3  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 01:08:34 AM
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.
4  Bitcoin / Development & Technical Discussion / Re: BIP0151 nodes detected on mainnet on: September 18, 2017, 10:05:27 PM
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? Huh

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.
5  Bitcoin / Development & Technical Discussion / Re: Why does Bitcoin use UTXO as transaction inputs instead of just public keys? on: September 15, 2017, 02:12:01 AM
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.
6  Bitcoin / Development & Technical Discussion / Re: GSSSA - Hide your wallet in shares on: September 05, 2017, 07:24:13 AM
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  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.
7  Bitcoin / Development & Technical Discussion / Re: Bad signatures leading to 55.82152538 BTC theft (so far) on: August 31, 2017, 05:15:05 AM
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.
8  Bitcoin / Development & Technical Discussion / Re: Can Bitcoin Script be extended to be Turing Complete? on: August 30, 2017, 01:18:48 AM
Yes, via segwit script versioning.

But it is provably useless to have turing complete script:
9  Bitcoin / Development & Technical Discussion / Re: What percentage of the gossip network is still on 0.13.0 or equivalent? on: August 15, 2017, 05:22:51 AM
Do we know how many of the full nodes have upgraded to a version that understands SegWit style scripts?

About 90%.
10  Bitcoin / Bitcoin Discussion / Re: New Satoshi Emails on: August 11, 2017, 05:39:33 PM
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

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

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.

11  Bitcoin / Development & Technical Discussion / Re: Disconnect network service bits 6 and 8 until Aug 1, 2018 - discussion on: August 11, 2017, 01:49:13 AM
How typical Smiley
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.
12  Bitcoin / Development & Technical Discussion / Re: Disconnect network service bits 6 and 8 until Aug 1, 2018 - discussion on: August 09, 2017, 11:14:14 PM
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.
13  Bitcoin / Development & Technical Discussion / Re: Why some old clients follow hard-fork chain? on: August 09, 2017, 07:08:19 AM
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.
14  Bitcoin / Development & Technical Discussion / Re: Disconnect network service bits 6 and 8 until Aug 1, 2018 - discussion on: August 08, 2017, 11:04:54 PM
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!)
15  Bitcoin / Development & Technical Discussion / Re: Thought experiment on: August 06, 2017, 11:18:56 AM
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. Tongue
16  Bitcoin / Development & Technical Discussion / Re: Does anyone know why 0.12.x nodes relay transactions faster than later versions? on: August 05, 2017, 01:48:50 AM
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. Smiley

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  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.
17  Bitcoin / Development & Technical Discussion / Re: Malleated Transactions on: August 05, 2017, 01:34:07 AM
So your argument against a flexible format is because it requires a hardfork to change existing fields?

You've been scammed. "flextrans" _ISNT FLEXIBLE_.   Bitcoin can add fields fine, even without a hardfork: thats exactly what segwit does, for example-- it adds witness fields to every transaction!

Flextrans is less flexible and less efficient, doesn't completely fix malleability, and incorporates security error prone design features (like non-canonical encodings).  The only thing 'flexible' about is is the ethics of the person who gave it a deceptive name.

why don't we switch the www to hard coded binary formats,
The web is not a global consensus flooding network, among other reasons.  And in most fields XML is considered to be a massive failure.  Talking about making Bitcoin transactions in the network XML (with bonus proprietary binary packing method like EBML) would have been a great april first joke if classic hadn't poe's lawed this.

Also, classic is now a Bcash client... so I think this thread might now be more ontopic for the altcoins subforum.
18  Bitcoin / Development & Technical Discussion / Re: Why transactions inside blocks are not quite sorted by the fee? on: August 02, 2017, 09:09:03 AM
oh darn, yes in that case you can't tell if you should group without knowing if it used the txns natural feerate or the package feerate.  So much for my simple approximation. Smiley
19  Alternate cryptocurrencies / Service Discussion (Altcoins) / Re: Bitfinex BCC/BCH on: August 02, 2017, 08:27:54 AM
Considering that Bitfinex decided to only take a part of their users' BCH holdings instead of all of it,
Per their reports they didn't take any of it.  Bitfinex has margin trading, very simply stated that means that ignoring shorts there can be more bitcoins there being traded than they have.  They didn't want to make people who had short positions (which normally cancel part of these liabilities) get forced into short-BCC positions; so the otherwise fully covered obligations were not fully covered.

It sounds like they tried to come up with a rational and fair way to address this split; but I haven't heard an informed counterargument yet.

This is the kind of chaos that is created by these near zero notice chaos producing events. ... wait till you see all the pain and funds loss caused by BCC using addresses which are easily confused with Bitcoin addresses. Sad
20  Bitcoin / Development & Technical Discussion / Re: Why transactions inside blocks are not quite sorted by the fee? on: August 02, 2017, 06:38:31 AM
FWIW, if you think core is doing something-- you can check the getblocktemplate output yourself and remove all doubt! Smiley

Achow101 is right about the cause, if you look in the graph you will see a dip to low feerate right before the high feerate spike: thats the parent then its high rate descendant transaction.

You can think of it as logically working like this: if grouping a transaction with its descendants gives a higher feerate for the group than the transaction had, consider including the group.  They go in that order... the whole group in its group-feerate order.

If I were making graphs like yours, I think I'd logically merge all transactions that have unconfirmed parents into their parents, and show the combined rate.  I believe that graph will be monotone.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 240 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!