Bitcoin Forum
November 22, 2018, 11:58:40 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  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 ... 239 »
281  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 03, 2017, 07:24:22 PM
I have learned recently that brainwallets are not a good idea, mostly because I lurk the bitcoin reddit and I think I saw you posting about it.

Now my fear/question is: are Electrum seeds also compromised? In theory isn't it the same as brainwallets? It creates a seed and this seed contains everything. I think the new HD wallet in bitcoin core is not like that (you can't "spawn" everything with a single seed) but with electrum it seems the same idea to me than brainwallets and now im worried... (im not a coder or anything so I dont understand the details, it just seems the same to me in practice)

The two main problems problems with brainwallets is that (1) humans created the randomness and humans are surprisingly bad at that (and, worse, can't tell how bad they are) and (2) they depend on human memory to perfectly remember a long highly random string.  Human memory is not very good at this either.

Electrum seeds, used correctly, don't have either of these problems.
282  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: January 03, 2017, 06:55:38 PM
I think it's amusing that the two people in this thread loudly trumpeting brainwallets are someone who says they have a fetish for cracking passwords and someone who has posted extensively about wallet cracking and tried to sell scam wallet cracking tools.

This fits right in with the fact that person who popularized the idea and created was cracking these kinds of keys and complaining about how few he was finding online before creating the site.

Food for thought.
283  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.13.2 Released on: January 03, 2017, 09:06:08 AM
0.13.2 is out and here is the release announcement:

Hash: SHA512

Bitcoin Core version 0.13.2 is now available from:


Or by bittorrent:


This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:


To receive security and update notifications, please subscribe to:



Microsoft ended support for Windows XP on [April 8th, 2014](,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

- From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Change to wallet handling of mempool rejection
- -----------------------------------------------

When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error.  The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).

0.13.2 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- - #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
- - #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell)

### RPC and other APIs
- - #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery)
- - #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english)
- - #9122 `f82c81b` fix getnettotals RPC description about timemillis (visvirial)
- - #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
- - #9194 `f26dab7` Add option to return non-segwit serialization via rpc (instagibbs)
- - #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke)
- - #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa)
- - #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke)

### Block and transaction handling
- - #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz)
- - #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm target of 1 block (morcos)
- - #9196 `0c09d9f` Send tip change notification from invalidateblock (ryanofsky)

### P2P protocol and network code
- - #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing (TheBlueMatt)
- - #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj)
- - #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa)
- - #9058 `286e548` Fixes for test timeouts on travis (#8842) (ryanofsky)
- - #8865 `4c71fc4` Decouple peer-processing-logic from block-connection-logic (TheBlueMatt)
- - #9117 `6fe3981` net: don't send feefilter messages before the version handshake is complete (theuni)
- - #9188 `ca1fd75` Make orphan parent fetching ask for witnesses (gmaxwell)
- - #9052 `3a3bcbf` Use RelevantServices instead of node_network in AttemptToEvict (gmaxwell)
- - #9048 `9460771` [0.13 backport #9026] Fix handling of invalid compact blocks (sdaftuar)
- - #9357 `03b6f62` [0.13 backport #9352] Attempt reconstruction from all compact block announcements (sdaftuar)
- - #9189 `b96a8f7` Always add default_witness_commitment with GBT client support (sipa)
- - #9253 `28d0f22` Fix calculation of number of bound sockets to use (TheBlueMatt)
- - #9199 `da5a16b` Always drop the least preferred HB peer when adding a new one (gmaxwell)

### Build system
- - #9169 `d1b4da9` build: fix qt5.7 build under macOS (theuni)
- - #9326 `a0f7ece` Update for OpenSSL 1.1 API (gmaxwell)
- - #9224 `396c405` Prevent FD_SETSIZE error building on OpenBSD (ivdsangen)

### GUI
- - #8972 `6f86b53` Make warnings label selectable (jonasschnelli) (MarcoFalke)
- - #9185 `6d70a73` Fix coincontrol sort issue (jonasschnelli)
- - #9094 `5f3a12c` Use correct conversion function for boost::path datadir (laanwj)
- - #8908 `4a974b2` Update bitcoin-qt.desktop (s-matthew-english)
- - #9190 `dc46b10` Plug many memory leaks (laanwj)

### Wallet
- - #9290 `35174a0` Make RelayWalletTransaction attempt to AcceptToMemoryPool (gmaxwell)
- - #9295 `43bcfca` Bugfix: Fundrawtransaction: don't terminate when keypool is empty (jonasschnelli)
- - #9302 `f5d606e` Return txid even if ATMP fails for new transaction (sipa)
- - #9262 `fe39f26` Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)

### Tests and QA
- - #9159 `eca9b46` Wait for specific block announcement in p2p-compactblocks (ryanofsky)
- - #9186 `dccdc3a` Fix use-after-free in scheduler tests (laanwj)
- - #9168 `3107280` Add assert_raises_message to check specific error message (mrbandrews)
- - #9191 `29435db` 0.13.2 Backports (MarcoFalke)
- - #9077 `1d4c884` Increase wallet-dump RPC timeout (ryanofsky)
- - #9098 `ecd7db5` Handle zombies and cluttered tmpdirs (MarcoFalke)
- - #8927 `387ec9d` Add script tests for FindAndDelete in pre-segwit and segwit scripts (jl2012)
- - #9200 `eebc699` bench: Fix subtle counting issue when rescaling iteration count (laanwj)

### Miscellaneous
- - #8838 `094848b` Calculate size and weight of block correctly in CreateNewBlock() (jnewbery)
- - #8920 `40169dc` Set minimum required Boost to 1.47.0 (fanquake)
- - #9251 `a710a43` Improvement of documentation of command line parameter 'whitelist' (wodry)
- - #8932 `106da69` Allow bitcoin-tx to create v2 transactions (btcdrak)
- - #8929 `12428b4` add software-properties-common (sigwo)
- - #9120 `08d1c90` bug: Missed one "return false" in recent refactoring in #9067 (UdjinM6)
- - #9067 `f85ee01` Fix exit codes (UdjinM6)
- - #9340 `fb987b3` [0.13] Update secp256k1 subtree (MarcoFalke)
- - #9229 `b172377` Remove calls to getaddrinfo_a (TheBlueMatt)


Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - BtcDrak
- - Cory Fields
- - fanquake
- - Gregory Maxwell
- - Gregory Sanders
- - instagibbs
- - Ivo van der Sangen
- - jnewbery
- - Johnson Lau
- - Jonas Schnelli
- - Luke Dashjr
- - maiiz
- - MarcoFalke
- - Masahiko Hyuga
- - Matt Corallo
- - matthias
- - mrbandrews
- - Pavel Janík
- - Pieter Wuille
- - randy-waterhouse
- - Russell Yanofsky
- - S. Matthew English
- - Steven
- - Suhas Daftuar
- - UdjinM6
- - Wladimir J. van der Laan
- - wodry

As well as everyone that helped translating on [Transifex](

Version: GnuPG v1

284  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 31, 2016, 09:54:11 PM
Just because 95% of the blocks that the miners produce doesn't mean that non-mining Bitcoin related companies and other Bitcoin users support SegWit (Note: ready to implement != support).
Well no one is forced to implement it; so ready to implement does suggest a small amount of support at least. FWIW, before segwit's activation was set in Bitcoin Core I reached out directly to most of the non-mining Bitcoin related companies that I could fine to specifically prompt for opposition. I received back many positive responses, none opposed, and the only negative comment was from a party that hoped activation would take longer so they would have more time to add support-- it's still possible that they don't support it,  apparently not enough to send a respond saying so. After that there was a public discussion on the bitcoin-development list and the only party that argued against it was Tom Zander.

Technically speaking, the threshold is 50.694% (or potentially less depending on luck) for activation as the miners who support SegWit could decide to ignore blocks that lack a signal of support for SegWit.
Yep, only just over half is strictly needed if they're willing to orphan the other almost-half.
285  Bitcoin / Development & Technical Discussion / Re: Some magic? on: December 28, 2016, 10:59:27 PM
Arubi doesn't have a bitcointalk account, and saw others being blamed for their transaction and asked me to post this:

mw1vkYok3eGrccuMx5Ztbj3RH6Pyrb8b8z H5Fm9/Ejebxv5KybIf+hUgGcubVp3B6bxcl7RVMLUS7EABFn75VsV+S+sNW5Oc02M/awPv8tHAeIS+PJtU5qVyA= "I am not amaclin :) :  -  arubi"
286  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 28, 2016, 05:40:35 AM
Why was 95% adoption rate selected for activation as oppossed to 80% or 50% or even 5%?
So that the soft fork deploys with supermajority. It will essentially have consensus when it deploys. This ensures that the new rules will be deployed and enforced by the miners. The 95% rule has been used for all previous soft forks, no reason to change that now.

Not all-- we've increased it over time in response to prior instability and as we all learned better the implications.  BIP30 just used a 'past this time' decree. BIP16 was based on 55% and just used a time for the actual activation, and resulted in months of low levels of orphaned blocks being produced.  Satoshi used several hard cut softforks that were just triggered on blockheights.  BIP34 was the first to use 95% but it actually started enforcing the rules for a subset of blocks at 75%.

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  But we saw no reason to lower the criteria:  basically when it activates the 95% will have to be willing to potentially orphan the blocks of the 5% that remain if they happen to mine invalid blocks.   If there is some reason when the users of Bitcoin would rather have it activate at 90%  (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

So basically setting the criteria high protects the stability of the network in the common case, but never ties anyone's hands against something not activating. By default the safest thing happens, but no one can exploit this in an attack.

Because of this, the trade-offs favor a high threshold.
287  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:27:06 PM
But then you come back to the problem of choosing the secure password, don't you?
Which brings you back to the point that you need to learn about choosing secure passwords.
Ah ha, but no-- the requirements for the password security are much lower.

With a brainwallet, the moment you use it everyone in the world can begin cracking it-- in parallel with all other keys they are cracking at no extra cost.  They can also apply precomputed rainbow tables to try may of the passwords they tested in the past against it-- at low cost. They also can see the bounty attached to it.

If a wallet is encrypted it has a salt and (hopefully) an expensive KDF. The attacker cannot attack multiple files in parallel. If the whole wallet is encrypted, they don't know what their payoff will be and most importantly they can't even begin cracking until they get the file.  The security becomes multi-factor: You must have the file and the passphrase.  Theft of the file may also be noticed, giving you time to react.

So if your passphrase is a little weaker than you intended it to be-- there is likely no great harm.

288  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:18:04 PM
Sorry, I didn't mean that they cannot be seized by any type of government.
Mine isn't running a torture camp in Guantanamo - applying a hammer to my head would be illegal where I live.
Plus then I'd most definitely forget it Smiley
Hand, not head, for that reason! Smiley  (also, hitting people in the head tends to make them unconscious and then they can't answer. Hitting them in the hand is very painful but leaves them able to talk.)

Especially if you're not worried about torture-- use encryption! it also resists seizure in just the same way-- but: it works like a salted password hash stored privately. O(N*M) work to try N passwords for M people, and to even start you must steal a copy of the private data which you have hopefully not posted in a public database. Tongue  If you want to generate it securely and _also_ attempt to memorize it, sure knock yourself out, an extra backup doesn't hurt.
289  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 12:09:10 PM
Also nobody is talking about the advantages of (strong) brain wallets, that are actually making them more secure than PRNG based wallets.

Besides of the two I mentioned already:
- They don't rely on anyone's (publicly known) implementation of the "entropy"
Unless you never intend to sign a message they do... and they also depend on a human's easily predictable production of "entropy".

There are hundreds of millions of dollars worth of Bitcoin secured by the CSPRNG setup in Bitcoin Core. It is peer reviewed by quite a few subject matter experts. That is a pretty strong bit of auditing there, ... can you say the same for your scheme?

- They don't require backups
Human memory is very fallible.  We often just don't remember what we don't remember so we don't often realize how bad it is.   A fever, blow to the head, or other illness can easily kill single memories even of things you used frequently-- a brain wallet is the hardest kind to remember: to be secure it must be unusually random, and you should not be using it frequently (if you use it frequently, you will end up leaking it somehow) and being almost right is not good enough!

Backups are also easy if you don't need to redo them. They are practically free:  A small USB stick costs a few dollars, paper costs cents. You can make many backups and secure them with a weak password that your family also knows and really can never be forgotten-- but attackers with a FPGA farm in china cannot crack your password protected backed up wallet!

There is more:
- They cannot be seized
Equally true of a pasword protected backup wallet.  And both can be seized after finding evidence of you using them in the blockchain or on your computer and then liberally applying a hammer to your non-dominant hand.

- They don't need to be carried
Yes, this is perhaps the one advantage-- if you are a refugee who can literally carry _nothing_ without severe risk of losing it. But even there you would be much better off with a few backups of that key securely hidden back at home in case you do forget it and do someday find yourself in a place where you can pick it up.

- Their existence can be denied
- Even if someone can prove that a brain wallet had existed at some point in time, he's still unable to prove that you have not forgotten the password
Both equally true for an encrypted non-brainwallet.

You see, in my opinion, the biggest enemy of the brain wallets should be the government.
Brainwallets are irrelevant to the government-- they don't add any protection from the a government except in the refugee case, but they are the friend of the coin thieves -- no surprise considering they were invented by one.

You seem to have ignored my point that a brainwallet is equivalent to storing an unsalted password hash in a public database. Do you consider that incompetent security?
290  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!)[Mod note: DO NOT USE BRAINWALLETS] on: December 27, 2016, 11:59:10 AM
The advice would be to have a computer generate it randomly.  (the next best advice is to choose it with dice but it takes so many rolls to even get 128 bits, that I have found that users don't actually comply with the procedure; a treatment that the patient will not follow is not a good treatment, no matter how perfect it is if used flawlessly). Studying the result in practice isn't politics, it's science.  Developers are not magically anointed with an ability to not make these errors, they appear to be even more vulnerable: to quick to enamor themselves with fancy schemes but just as unable to really comprehend billions of attempts per second as any other human. It isn't a question of being stupid, I do not think I can securely use a brainwallet and I do not think I am stupid.
291  Bitcoin / Development & Technical Discussion / Re: block reward that can never be spent on: December 27, 2016, 11:55:54 AM
This article claims that the block immediately following every halving can never be spent.
(I knew that only genesis block reward cannot be spent)

Is that true?
No, it's not true.
292  Bitcoin / Development & Technical Discussion / Re: Brain wallet, step-by-step guide (FIXED!) on: December 27, 2016, 11:25:23 AM
Brainwallets were literally invented by someone who was out to rip people off; no joke!

piotr_n: Errors like you talk about are what happen sometimes when technical experts given all the time in the world work on secure entropy.  What do you think will happen when you ask less technical end users to take care of it for themselves?

Predictable failure, that is what results. And, of course, if your crypto code is broken-- your security is toast anyways: your signatures will give away your key.

People _massively_ overestimate their ability to choose unguessable strings. They come up with absurd munging schemes that are easily predicted and exploited by attackers.  The result is that brainwallets cause funds loss _constantly_.

Why is it when it turns out that some website was using an unsalted hashing scheme to store their users password hashes in a private database people pull out the torches about how incompetent the web developer is-- but when people construct brainwallet software which stores the users hashed password in a PUBLIC database-- unsalted-- where every found password results in an irreversable theft of Bitcoin, some people fall over themselves to recommend it?

... because that is exactly what a brainwallet is doing:  A public key is a hash of the private key (with special homomorphic properties that makes it useful for signatures). When you use a brainwallet you are computing an unsalted password hash and sticking it in a public database along with the amount you can steal by cracking it.  Because they are unsalted, an attacker can target N users with ~O(1) effort just like any other unsalted password hash.
293  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 27, 2016, 11:06:41 AM
2. Anyone spending unconfirmed transactions
This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement

Again, you are showing profound confusion.  If you do not spend _your own_ unconfirmed coins you can be restricted to make only a _single_ transaction until you receive a confirmation... meaning you might easily be waiting an hour before you can make a second payment after making a first while waiting on a block.

Without the ability to spend unconfirmed transactions you cannot engage in many useful protocols like cross chain atomic swaps or coinswaps.

1. Wallet authors tracking spent bitcoins
According to GMaxwell no one cares, apparently.

A bit of a wrinkle there. Tracking if a payment has been made is what I was referring to above, but that text is referring to needing code to _unfuck_ a wallet after a chain of transactions has been disrupted with malleability. I'm not aware of any wallet that does this today, not even core. It too hard to do right, compared to just fixing the malleability. The distinction is that no amount of "modular" cosmetic ID can help that, because once the transaction chain is broken, it's broken.  Previously I was responding above the kind of cosmetic issues you were discussing when you suggested that a non-normative ID could help.

but segwit just offloads the risk to a third party like any side-chain as was intended in the original design.

You are just spouting nonsense here. Who is the third party? What risk is offloaded?  I think at this point you are literally just making things up and not even earnestly expressing your own confused views.

None of them are peculiar to SegWit but #3 requires it.
Lightning does not require segwit. Simply repeating it over and over again will not make it true.
294  Bitcoin / Development & Technical Discussion / Re: Some magic? on: December 26, 2016, 10:38:33 PM
An ECDSA signature itself does not prove knowledge of a discrete log.

You can pick a random message and a random signature  then compute the public key this signature,message pair would be valid for.

To accomplish this, you must-- of course-- make sure the message does not contain any commitment to the public key.

Bitcoin's signatures include a commitment to the scriptPubkey-- but nothing requires you to have the EC public key there.

This cute construction is not secure: if you'd seen that txn before confirmation you could have modified the destination and computed a new pubkey.

If you take a look at Roconnor's covenants post you'll see he uses the same kind of pubkey recovery to turn checksig into an operation for verifying a hash of the masked transaction-- which otherwise the script doesn't have access to.
295  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 26, 2016, 10:22:19 PM
I would have gone for |r| and |s| personally so no explicit rejection would be required. I wasn't sure that N-s was negative for all values of N,
You are showing an impressive level of ignorance here: N-s is _never_ negative, s is a field element.  

both DER encoding and ECDSA malleability are already addressed and not usable as a "malleability fix" argument for SegWit.
Malleability in Bitcoin goes far beyond just signature encoding malleability. Multistep multiparty protocols like coinswap require that the other signer in a 2 of 2 not be able to invalidate a chain (or extreme amount of additional protocol phases); this can never be accomplished with a DL signature since they inherently must have a random input, so long as the signature itself is part of the identifier. Segwit's approach to eliminating signature malleability gives a guaranteed solution to all forms that would potentially invalidate a chain of transactions.

There has only ever been one other proposal that provided an equally complete solution, but it had the downside of doubling the UTXO set size and roughly doubling the amount of transaction hashing work.

It would be a side-chain if the changes weren't being implemented. I do indeed know nothing about LN.

Clearly you don't-- because this statement makes no sense.

The driver for SegWit seems to be purely LN

This is an rbtc talking point-- it has no basis in reality.   Segwit is largely orthogonal to lightning, and proposed long after it. The reason people keep claiming it is because segwit is above reproach and lightning is less well understood and easier to FUD.

2. It is the architecturally correct solution for outsourcing the txID generation-that's it. If you are going to do that, then make it a plugin module then it doesn't need to be in Bitcoin at all and anyone can use their own, including legacy (maybe a default module). It is a poor solution just for malleability and a straight-jacket for txID generation.

You seem to be confused about what a txid is really used for.   From your comments it seems that you think that wallets are somehow distinguishing payments that way. That isn't the right way to distinguish a payment... Bitcoin Core doesn't, it tracks outpoints (either as inputs for conflict handling or outputs for payments).  No one cares much about the cosmetic implications of malleability, they're largely irrelevant.

Transaction IDs are an essential part of the Bitcoin consensus rules. A transaction selects the coins it will spend by specifying the transaction IDs of the transactions that created those coins.  These IDs are included under the subsequent transaction's signature.  If something happens to change a transaction's TXID then all subsequent descendant transactions are invalidated. This is what people care about.

No amount of module whatever can do anything to help that.  So what you propose would only ad a cosmetic issue that almost no one cares about ('I can't look up the txid I was expecting in a block explorer')-- and if anyone cared it would already be solved, as it's not a consensus change.
296  Bitcoin / Development & Technical Discussion / Re: Strange Tiny blocks on: December 25, 2016, 07:04:34 AM
But if you had to choose between submitting a 100 kb block and not submitting a block at all... You're going to submit the 100 kb block, obviously. You are still getting 12.5 BTC and are confirming a sizable number transactions.
That isn't actually the choice being made here-- tiny blocks are created even when there is plenty of reasonably high fee paying backlog.

When a 100 kb block is solved, 900 kb of capacity was not just lost. The miner responsible introduced 100 kb of capacity. Not 1 mb, but still a lot more than zero. Mining is all probabilistic, remember. The block could never have been solved at all, and the mempool would be 100 kb bigger as a result.
At an instant this is true, but the empty block still serves to increase the difficulty and reduce the rate of block finding in the next interval. If it happens on an ongoing basis it does reduce capacity.

Even if a block has no transactions at all other than the coinbase - which does not happen a lot nowadays except in some technical cases - the block is still improving the integrity of the block chain, giving recently confirmed transactions and blocks another confirmation, and introducing 12.5 BTC to most likely many people at once (enthusiasts like you and me). It is not by any means a waste and should not be considered unwelcome or inappropriate.

Unfortunately the parties producing small blocks do so because they haven't validated the prior block. So they add only a false confirmation and erode the security of lite clients rather than contributing to security as empty blocks did in prior years before this practice became common.
297  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 24, 2016, 10:53:05 PM
This has been done in Bitcoin,
Not just done in Bitcoin, but we came up with that improvement; and ripple borrowed it long after-- including the code for it. I put him on ignore after that post: There is nothing worse to deal with in this subforum than a chest-thumping altcoin promoter bragging about an altcoin being superior on the basis of code or techniques they coped from Bitcoin Core.
298  Bitcoin / Development & Technical Discussion / Re: Flexible Transactions - BIP134 on: December 17, 2016, 08:13:44 AM

This article is overtly dishonest. I rebutted it on reddit. I think it's shameful that Tom is either so ignorant or so outrageously dishonest to have published such a thing.

299  Bitcoin / Bitcoin Discussion / Re: How Many Bitcoin Full Nodes Are Operated By Businesses? on: December 14, 2016, 08:49:04 PM
my node uploads about 700MB a day .... i wouldnt call that a lot of bandwidth
You probably aren't accepting inbound connections, or are potentially in a /16 with many other nodes so you are connected to less often.   About 300GB/month transfer is not atypical for a node with inbound connections.

BIP152 reduces the data used to send blocks, but that data was only about 12% of the overall.
300  Bitcoin / Bitcoin Discussion / Re: NOT Upgrading to SegWit who's with me?! on: December 14, 2016, 08:21:13 PM
The amount of uncorrected lies in this thread is really absurd.

Segwit doesn't have anything to do with lightning. Lightning is already possible without it and can't be blocked. So if you're against having actual scalablity in Bitcoin: well too bad and fuck you: you already lost the day Satoshi released the software.  Similar, sidechains at least of the federated type are existing, unblockable, and undetectable.  If you want to force other people to not use them? Again too bad. You can't.

BitcoinBarrel, the notice in your software has nothing to do with segwit.  You're inconsistent with the network because you're not even running something that implements CSV.  You should at least run 0.13.0; if you do you won't get a notice until segwit activates.

Another factor that is part to me not having updated yet, is that people complain about the notifications that pop up when you receive transactions. They are gone.

I am not aware of any change here, have you opened an issue?
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 ... 239 »
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!