Bitcoin Forum
May 23, 2018, 03:31:36 PM *
News: Latest stable version of Bitcoin Core: 0.16.0  [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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 242 »
481  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 25, 2016, 02:00:53 AM
iCEBREAKER, surely there is better fodder for the classic r3kt party?

When people make fun of petty crap like that it gives the impression that there is nothing substantive to say.

I think it's best the weird personal attacks to others: As the Irish proverb says, "Never wrestle with a pig. You'll both get dirty, but the pig will like it."
482  Bitcoin / Bitcoin Discussion / f2pool not supporting roundtable was Re: 「魚池」BTC:270 Phash/s - LTC:500 Ghash/s - New Server in U.S. on: February 25, 2016, 01:43:43 AM
Unprofessional how? I say this without malice. Greg, you're not much of an ambassador - leave the negotiations to someone else and stick with the tech explanations which you are very good at.
See Peter Todd's nice explanation on Reddit:

The Medium post wasn't officially released with Adam Back as 'Blockstream President' - you're thinking of the draft, which was released publicly by accident.

FWIW, Adam Back wasn't the person who actually typed in "Blockstream President" in the original Medium draft - IIRC the document was edited on Samson Mow's laptop and he probably actually typed it in based on what he assumed Adam Back would sign as.

Before the final copy was released officially Adam Back asked for that title to be changed to individual after consulting with others, including other Blockstream employees, as well non-Blockstream Bitcoin devs such as myself, both at the meeting and on IRC. That actual edit was probably made by Samson again.

The rational for that change was pretty simple: Adam Back didn't feel he could speak for Blockstream officially without further consultation with others at Blockstream. Similarly, rather than use the more common term 'Bitcoin Core Developer', we specifically used the term 'Bitcoin Core Contributor' to avoid giving the impression that the Bitcoin developers who signed were signing on behalf of all Bitcoin Core developers (edit: I personally argued for even more clear language along those lines, but everyone was getting tired so I decided to drop the issue, and instead I made it clear in my tweet rather than delay things even further).

Since an earnest piece of confusion existed here the professional way to handle it would have been to first simply send an email "Hey, what happened here?"  Not to issue a public ultimatum; especially when the subject matter in question was a title on a on a document, and doubly so when the party being attacked didn't even have the technical ability to change it themselves. Even in the least charitable interpretation of the facts, F2Pool making a public fuss and threatening to change their operating behavior over this matter does not give me an impression of a thoughtfully managed organization.

Mistakes happen, however, and I do not think they should be vilified for it, but nor do I think it should be flushed from history.

483  Bitcoin / Bitcoin Discussion / f2pool not supporting roundtable was Re: 「魚池」BTC:270 Phash/s - LTC:500 Ghash/s - New Server in U.S. on: February 24, 2016, 11:03:17 PM
I for one think the posts are an example unprofessional practices on the part of F2Pool, and are of topical interest to miners considering using the pool. I hope history isn't whitewashed through their removal.
484  Bitcoin / Bitcoin Discussion / Re: So the bitcoin classic (2MB) coup was compromised? on: February 24, 2016, 10:58:26 PM
perhaps we should return mining to individual wallets and eliminate chinese pools by replacing PoW with something energy efficient and more importantly 1cpu=1vote rather than the current "union block voting"

I don't intend to insult you, but do you believe that you're the first person to think of this?

It's like saying "lets just have world peace".  It would be _fantastic_ to be in a world where hashrate was much more uniformly distributed. But wanting it to be true and there existing mechanisms to make it true (and to do so without even worse side effects) are not the same thing.
485  Bitcoin / Development & Technical Discussion / Re: sendrawtransaction wire protocol? on: February 24, 2016, 05:12:57 PM
Actually, if node b rejects your message, it will respond to you with a 'reject' message which will include an error code for the reason of the rejection.
Might.  Rejects can be useful for software diagnostics but you shouldn't count on them for much.

You should always INV first. While handing nodes loose transactions currently works, it may not work forever. (and in some configurations, like nodes without relay set, may get you instabanned). It's also better for privacy, generally, since sending a loose transaction pretty much guarantees you are the source of the transaction.
486  Bitcoin / Bitcoin Discussion / Re: How good is prune mode! on: February 24, 2016, 04:11:03 PM
thats not what the original version of what prune mode was envisioned.
the original vision was to no longer keep spent data. but keep every unspent
Which is precisely what it does. All the information on unspent outputs is retained. This is why a pruned node set to keep 550 MB of the most recent blocks ends up needing about 2GB space currently.

if people dont have full history of unspents. then they cannot validate that a transaction is authentic.
why oh why do people think that making full node clients into crippled versions is a good thing. because fundamentally its not. if you want lite clients then download a lite client

stop trying to advertise that running in lite mode is better then sliced bread. if you want to say your a full node then dont cripple yourself or believe your still a full node after enabling such features
A pruned node is a full node, and does the same verification as a non-pruned node.

Please confirm that you understand this and realize your error now.
487  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core 0.12 full initial sync: results and analysis on: February 24, 2016, 01:38:30 PM
Those pauses aren't pauses. You're going by log entries, which only note when verification has completed. Verification can only proceed in order (block _chain_, after all). When a peer is slow sending a block, you'll continue to get blocks from other peers in parallel but the rest of the pipeline will have to wait until the slower block finishes. Once it does it will catch up, and you'll get a burst of messages. If a peer truly and persistently stalls the process it will be kicked off. So long as your network is staying active, it's doing what it can. (There are times during IBD where network activity does fall down, which can be improved... but it sounds like your IO is slow enough that this isn't a factor for you.)

35 hours is a horribly long time, though I'm sure much better than prior versions.

The primary cause being disk in your system is very slow (5400 RPM laptop drive being tens of times slower than a modern SSD).  If you were to run with a larger dbcache setting you would likely see vastly improve performance-- the defaults are sized to keep the software still runnable on systems with fairly low memory. (It can't really set it automatically, because, unless you had much more ram than you do, bitcoin would end up hogging most of your memory when you wanted to use your computer for other things-- the fact that you have more memory doesn't mean it's okay for Bitcoin to use it)

By comparison, I normally measure under 4 hours on a fast desktop with a home internet connection (with dbcache cranked up).
488  Bitcoin / Bitcoin Technical Support / Re: Wallet.dat file not working on .12 version pune mode on: February 24, 2016, 02:48:01 AM
Pruning works fine with a wallet. But you cannot just switch in an old out of date wallet and have it work: The wallet has no knowledge of any transactions that might have happened while it was offline, and so to catch it up the node must rescan... but a pruned node cannot rescan.

If you had put the wallet in first before starting the node with pruning the wallet would be fine and fully functional. The same goes for importing keys, you can only import loose keys without rescan.

In the future there may exist rescanning servers that can give you the transactions you're missing (if any), but doing this privately is quite tricky; and I doubt Core would rush in to a half-solution which destroyed your privacy when you have the option of not using pruning or not installing a cold wallet after pruning has taken effect. The initial work has started to enable such a thing with an API to import single transactions along with proofs that show they were in the blockchain.
489  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core version 0.12.0 released on: February 23, 2016, 10:03:17 PM
They removed the --with-libressl build option.
This option was removed because the only purpose it served was to override _disabling_ building with libressl, now that OpenSSL's exact behavior is no longer normative to the Bitcoin consensus. Libressl builds are no longer disabled by default.

commit 59783884766d00866e190ba5ae761916e932df10
Author: Wladimir J. van der Laan <>
Date:   Mon Sep 28 16:06:38 2015 +0200

    build: remove libressl check
    Now that BIP66 passed, OpenSSL is no longer directly part of the
    consensus. What matters is that DER signatures are correctly parsed, and
    secp256k1 crypto is implemented correctly (as well as the other
    functions we use from OpenSSL, such as random number generation)
    This means that effectively, using LibreSSL is not a larger risk than
    using another version of OpenSSL.
    Remove the specific check for LibreSSL.
    Includes the still-relevant part of #6729: make sure CHECK_HEADER is
    called using the right CXXFLAGS, not CFLAGS (as AC_LANG is c++).

490  Bitcoin / Development & Technical Discussion / Re: Pasting untrusted blocks/ and chainstate/ to new pruned node safe? on: February 21, 2016, 10:16:56 PM
srinikethan, I think your expectations are unrealistic.

It takes a long time-- tens of seconds to hash the UTXO set on a fast host. No random peers are just going to do this for you today. (Incrementally updating a tree structured hash could be done, but only with a considerable on disk and in memory overhead.)3

Even if they do, anyone can spin up as many nodes as they want, simply asking other nodes and then refusing to run if they disagree is just a DOS vector.

If, instead, you ban ones that disagree with you this just guarantees you'll only be connected to the party that gave you the bad data.

So what has this accomplished?

This also has ignored my point that format of these databases is likely not secure against malicious input, and might well result in remote code execution for the party that gave them to you.

As far as machine specific random values go-- yes that could probably be done, though then your node would stop working when you upgraded hardware/software and it would get in the way of copying state between systems which you control where there is no trust issue.
491  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: February 20, 2016, 12:29:58 AM
CSV doesnt exist yet, but isnt there a BIP for it that is pending with high likelihood it will get adopted?
There is a BIP... and no released software that implements it, no implementation of the soft-fork for it yet, etc.  (as you may note, the deployment section of the BIP is empty.)

I didnt see anywhere in the CSV BIP that you can only use it with RBF enabled.
Without replacement, someone could announce a inferior sequenced spend first and block the superior sequence spend; undermining the intended operation. The op_code would still "work" but wouldn't achieve the intended effect as reliably.

It just feels very lopsided to forever prevent any other sequenceids without RBF.
I think there might be misunderstanding on this point.  Opt-in replacement is just local node policy-- virtually every release of Bitcoin Core has twiddled policy in some way or another, local policy is invisible to the blockchain, and there is nothing forever about it in any way.

As I understand it, if things go live as it is,
It's already "live"; in that there appears to be a non-totally negligible amount of hashpower running it. There is no activation or enforcement of it-- it's inherently unenforceable as it is purely local policy.

then to maintain backward compatibility we would be stuck with RBF enabled for anything but -1 and -2
No-- policy can, and is, pretty liberally changed between versions. It's generally more compatible and more safe to have things go from replaceable to non-replaceable; and every proposed usage of the sequence field (short of ones that turn stuff totally unrelated data into it) seen so far involves some kind of replacement (if not exactly the BIP125 kind).
492  Bitcoin / Development & Technical Discussion / Re: Consensus supported sequence numbers on: February 19, 2016, 11:13:10 PM
The original proposal only affected memory pools, so it isn't secured by POW.  If locked transactions could be included in blocks, then the rule could be a consensus rule.
This is confused.

See even the see even the title of BIP68: "Relative lock-time using consensus-enforced sequence numbers."

The idea is that this would be consensus enforced (via a soft-fork).

What you saw with "mempool only" is due to process now used for soft forks in Core: Where possible core prefers to first implement the functionality as policy in order to gain experience with the design and implementation and to allow not-very-secure experimentation with client software in order to facilitate development and gain operating experience.  (this was done for CLTV, it's also currently being done for median-time-past (since 0.11.2)... and will be done with sequence enforcement).

No replacement of transactions in the blockchain is required, nor do I think it would provides any value-- certainly not enough to justify the huge layering violation; e.g. it would totally break SPV assumptions: "Here is proof you were paid", "Uh, how do I know that some later transaction didn't replace it?" "Uhh, let me send you the whole blockchain for the timeout window". It would also be less efficient than BIP58, since you'd end up with perpetually carrying around transactions that were ultimately replaced.

Both schemes require that there is at least one block by an 'honest' miner (meaning accepting the superior sequence spend, even if bribed to take an inferior one) before the inferior sequenced transaction timeout expires.

Can you compare what you're thinking of to BIP68 and highlight any advantages?

It is surprising that sequence numbers dont work as it is documented... I had thought CHECKSEQUENCEVERIFY was already on mainnet,
Huh? Sequence numbers work precisely as documented (they currently don't do much of anything; though BIP68 seeks to change that...).  CSV is a very new proposal, why did you think it was active on mainnet?
493  Bitcoin / Development & Technical Discussion / Re: Pruning and automatic checkpointing on: February 19, 2016, 10:53:34 PM
Reindexing exists exclusively because the local state may have become corrupted.  Trusting the state of a corrupted node is not what you really want to do in a reindex.

Specifically, prior errors in signature validation (nodes not updated for soft-forks or nodes run with an incompatible OpenSSL update) caused nodes to both accept and reject signatures that they shouldn't have accepted. A reindex currently clears that state.

On a fast host a reindex for me takes under three hours; so that puts an absolute upper bound on the improvement possible.

The bigger question is why are you reindexing in the first place?

I think the general direction in Bitcoin Core is a complete removal of checkpoints or anything resembling them. Other fixes have no largely mooted their original utility, and they have reliably caused severe misunderstandings of the security model (including, unfortunately, in academic papers) which have been harmful far beyond the narrow advantages they provide.
494  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: February 19, 2016, 10:45:42 PM
what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]
CSV doesn't exist yet; but sequence locks generally _require_ replacement in order to be usable: Otherwise someone could race with a less mature sequence and mempool preclude the more mature sequence.

I believe the rational in the design is that any transaction which is not marked _final_ will ultimately be subject to some kind of replacement. The conservative behavior for wallets that don't understand the details is that they should consider anything non-final ... as... non-final.  As other use cases come up the policy could be further restricted to specify what kinds of replacement should happen in what cases. BIP125 is very generic, which means that further changes to limit it's behavior are less likely to create surprise exposure for anyone.

495  Bitcoin / Development & Technical Discussion / Re: RBF transactions to be enabled at the next core update on: February 18, 2016, 01:36:40 AM
Sorry, I'd like to start kind of a different thread as I am actually interested in the machinery of it.
I know it's in the specs, but I hate reading those, mostly because they are too often useless.
And I really care to know it.
Won't read the spec. Won't read the code. ... why would anyone expect you to read an answer here?  Next time try offering money when you want to demand one on one spoon-feeding.

Until then you get copy-pasta:


This policy specifies two ways a transaction can signal that it is replaceable.

    Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
    Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.

Implementation Details

The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:

One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,

    The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
    The replacement transaction pays an absolute higher fee than the sum paid by the original transactions.
    The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.)
    The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
    The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.

The initial implementation may be seen in Bitcoin Core PR#6871 and specifically the master branch commits from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).

496  Bitcoin / Development & Technical Discussion / Re: Would a fork to SHA-3 be usefull because of the destroyed mining market? on: February 17, 2016, 11:21:00 PM
I shake my head in sadness at how hard decentralized things are to reason about.

On these days I wish we'd all switched to speaking lojban.

"Low ping times"-- what does that mean?  A ping time has a destination.  Low ping times to _what_?   Miners in china do not have high cosmically absolute ping time, no such thing exists-- the idea that it does is an artifact of centralized thinking.  They may have high ping times to _you_, but they have low ping times to each other. From their perspective it is you, someone far from china, which has the high ping time.

What is the concrete effect of this?  In the Bitcoin consensus you need to have low latency towards the greatest mass of cooperating hash-power. Amplifying the importance of low delay, e.g. by decreasing the interblock interval, would increase the profitability of operations geographically near that center of mess and decrease it elsewhere.

Exactly the opposite effect you hope to achieve.
497  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core vs. Bitcoin Classic on: February 16, 2016, 03:17:38 AM
The 1mb is not part of original design. Increasing the block-size is.
If arbitrarily increasing the size without regard to external considerations was the "design" it would have been preprogramed to do it automatically, just as it decreases the subsidy automatically, or controls difficulty automatically. Try again.
498  Bitcoin / Development & Technical Discussion / Re: Pasting untrusted blocks/ and chainstate/ to new pruned node safe? on: February 15, 2016, 11:59:31 PM
Beyond the issue of potential problems in the data itself-- there has been no auditing or effort to make sure these raw database files are safe for malicious input. (In the case of the bdb wallet files, I'm reasonably confident that they are not safe.)

Running a database (chainstate, txindex, blockindex) or wallet from an untrusted third party might result in giving them arbitrary code execution on your system.

The loadblock raw blockfile imports, otoh, are handled the same way as data from the network and are designed to handle untrusted input.
499  Bitcoin / Development & Technical Discussion / Re: Bitcoin 0.12 release on: February 11, 2016, 09:13:59 PM
This could be the greatest plus thing we need and then I would be more than happy in contributing again.
When you talk about future, how far is this future? thanks  Wink
I think it would be done now, if not for all the drama in the last year.

In 0.12 you can run a pruned node and you'll at least relay blocks on the tip.

I hope to see more sophistication maybe towards then end of the year; I'm hesitant to give any concrete numbers in the current climate.
500  Bitcoin / Bitcoin Discussion / Re: ToominCoin aka "Bitcoin_Classic" #R3KT on: February 11, 2016, 03:51:07 AM
It seems like even Garzik doesn't agree with the '28 days' nonsense.
28 days seems to be the consensus for an “if we must” hard fork. In the context of a production upgrade cycle at a financial shop, 28 days is more like an emergency update than planned update. 3–6 months is a minimum in that context.
I've told the 'forkers' this several times.
I've wondered if any of them have any experience with large scale production systems at all-- esp any that must have multi-vendor interop.  It's unbelievable.
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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 242 »
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!