Bitcoin Forum
December 11, 2018, 06:41:06 PM *
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 ... 547 »
181  Bitcoin / Bitcoin Technical Support / Re: How can P2SH outputs be spent? Non multisig. on: June 16, 2018, 06:46:54 PM
My mistake, thank you.  Carla makes the redeemScript and gives the hashed result, her address , to Bob.

Still, my point is that Carla needs the same redeemScript to send to Josh. After she does sends to Josh, Josh is not spending that TX just yet. In the meantime someone else, Nigel, looks at the TX Carla executed and sees the redeemScript. He can then spend the TXO and leave Josh empty handed. This is my theory, and what I am trying to reproduce on testnet.
Presumably Josh has his own redeemScript and does not share one with Carla so his redeemScript is unknown unless he has used it before. Furthermore, once Carla's transaction is confirmed, no one can spend that output.

You mentioned that redeemScripts are not retrieved from previous Tx's. I'm assuming you're not referring to P2SH addresses? From your explanation it sounds like a typical P2PKH where only the owner of the private key, associated with the public key of the address can spend the TX.
I misunderstood what you meant by "retrieving redeemScripts from previous transactions". You can retrieve a redeemScript for a previous transaction. However when a transaction is validated, redeemScripts are not retrieved from previous transactions (which is what I thought you meant).

My claim is this: If you are spending an UTXO of type P2SH that encapsulates the hash of an OP_TRUE, you can create a P2SH raw transaction with code that spends (conditioned on not being multisig) by using the redeemScript which was revealed in the previous TX.
That is true.

However, no one who legitimately wants to receive money would give someone else an address for an OP_TRUE script. With P2SH, they can specify any script they want, and most scripts that people use still have a public key and a signature. Additionally, well known scripts such as an OP_TRUE have known addresses and people have bots that actively look for transactions sending to an OP_TRUE address and sweeping the funds immediately.

I have a few questions please.

Q1: The redeemScript became visible on the blockchain after some amount was spent from TX, correct? How can we know it was supposed to correspond to
? Just by looking at [3 5 4]?
The script itself is the
part which is expanded into the script. You can decode this as a script and you will get that script.

Q2: In your example, clearly the recipient of tx is a P2PKH address
. That's simply because it happened to be the case that the owner of
knew how to solve the the redeemScript and just executed a tx in code, correct?
Not necessarily. It could be anyone who knew the redeemScript (by having generated it himself at some point) who created the transaction and sent it to 1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V. It doesn't have to be the owner of that address.

What if let's say it was a P2SH address instead, and the TX resulted in a further unspent. Would anyone be (again) able to see the redeemScript and solve it even further? So unless the chain of TX's stops with a multisig or a P2PKH address, it can be further spent over and over again by anyone who can see and use this type of redeemScript?
No, it depends on the redeemScript. Not all redeemScripts are anyone-can-spend. You can specify anything you want, and most P2SH scripts that people use still require a signature.

Q3: Would I be able to reproduce such a transaction in Node and let's say bitcore-lib? I don't see why not but I am still trying to find specific details on github.
I don't think bitcore-lib allows you to create and spend from non-standard scripts (which is what you want) unless you make raw transactions yourself and construct the scriptSig and redeemScript manually.
182  Bitcoin / Development & Technical Discussion / Re: Different sites report different blockchain sizes? on: June 16, 2018, 12:11:12 AM
There are many reasons the reported sizes may be different. It depends on what they are actually measuring as "blockchain size".

A naive way of measuring would be to just take the size of the datadir for a bitcoind instance. However, this is going to include a bunch of extra data which is not actually the blockchain. This would include data like log files, wallet files, the UTXO set database, the block index, and the transaction index if that is enabled.

There may also be a discrepancy if one site does not run a segwit enabled node. Since a Segwit block is physically larger than the stripped block that a non-segwit node would receive, sites that support Segwit will report a larger blockchain.

Additionally, a site may receive more orphan blocks than another site which means that they are storing more blocks on disk. They may be measuring this as well which will cause the reported blockchain size to differ from sites that have received different orphan blocks.
183  Bitcoin / Bitcoin Technical Support / Re: How can P2SH outputs be spent? Non multisig. on: June 16, 2018, 12:06:12 AM

Bob sends 0.5 BTC to Carla, who is the owner of a P2SH address of the form 3xxxxxx.

For Carla to spend the 0.5 BTC and pay Josh, who also has a 3xxxxxx P2SH address, she needs the redeemScript from Bob.
No, this is incorrect. Carla does not need the redeemScript from Bob, she already has the redeemScript. In order for Bob to send Bitcoin to Carla, he has to have received an address from Carla to send to. Bob cannot just make up an address that Carla can theoretically spend and say he paid her. Rather Carla needs to create the address and give the address to Bob. So Carla would have to create the redeemScript, hash it and Base58 Check encode that to get the address. Then she gives the address to Bob so he can pay here. Thus Carla has the redeemScript and can spend the coins.

RedeemScripts are not retrieved from previous transactions.
184  Bitcoin / Development & Technical Discussion / Re: Getting connected to the Bitcoin Lightning network on: June 16, 2018, 12:00:26 AM
Have a read of It explains the steps for the testnet. The mainnet version is not ready yet.

There is no need to sync the blockchain or run LND by yourself. The Lighting App handles all of that for you. Furthermore, it uses a BIP 158 (Neutrino) light client so there is no need to sync the entire blockchain at all.
185  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: June 15, 2018, 05:33:20 PM
Bitcoin Core 0.16.1 has been released:
186  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.16.1 Released on: June 15, 2018, 05:30:03 PM
Bitcoin Core version 0.16.1 is now available from:


This is a new minor version release, including new features, 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:


How to Upgrade

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. Existing
wallets that were created with older versions are not affected by this.


Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes

Miner block size removed

The `-blockmaxsize` option for miners to limit their blocks' sizes was
deprecated in version 0.15.1, and has now been removed. Miners should use the
`-blockmaxweight` option if they want to limit the weight of their blocks'

0.16.1 change log

### Policy
- #11423 `d353dd1` [Policy] Several transaction standardness rules (jl2012)

### Mining
- #12756 `e802c22` [config] Remove blockmaxsize option (jnewbery)

### Block and transaction handling
- #13199 `c71e535` Bugfix: ensure consistency of m_failed_blocks after reconsiderblock (sdaftuar)
- #13023 `bb79aaf` Fix some concurrency issues in ActivateBestChain() (skeees)

### P2P protocol and network code
- #12626 `f60e84d` Limit the number of IPs addrman learns from each DNS seeder (EthanHeilman)

### Wallet
- #13265 `5d8de76` Exit SyncMetaData if there are no transactions to sync (laanwj)
- #13030 `5ff571e` Fix zapwallettxes/multiwallet interaction. (jnewbery)

### GUI
- #12999 `1720eb3` Show the Window when double clicking the taskbar icon (ken2812221)
- #12650 `f118a7a` Fix issue: "default port not shown correctly in settings dialog" (251Labs)
- #13251 `ea487f9` Rephrase Bech32 checkbox texts, and enable it with legacy address default (fanquake)

### Build system
- #12474 `b0f692f` Allow depends system to support armv7l (hkjn)
- #12585 `72a3290` depends: Switch to downloading expat from GitHub (fanquake)
- #12648 `46ca8f3` test: Update trusted git root (MarcoFalke)
- #11995 `686cb86` depends: Fix Qt build with Xcode 9 (fanquake)
- #12636 `845838c` backport: #11995 Fix Qt build with Xcode 9 (fanquake)
- #12946 `e055bc0` depends: Fix Qt build with XCode 9.3 (fanquake)
- #12998 `7847b92` Default to defining endian-conversion DECLs in compat w/o config (TheBlueMatt)

### Tests and QA
- #12447 `01f931b` Add missing signal.h header (laanwj)
- #12545 `1286f3e` Use wait_until to ensure ping goes out (Empact)
- #12804 `4bdb0ce` Fix intermittent failure. (jnewbery)
- #12553 `0e98f96` Prefer wait_until over polling with time.sleep (Empact)
- #12486 `cfebd40` Round target fee to 8 decimals in assert_fee_amount (kallewoof)
- #12843 `df38b13` Test starting bitcoind with -h and -version (jnewbery)
- #12475 `41c29f6` Fix python TypeError in (MarcoFalke)
- #12638 `0a76ed2` Cache only chain and wallet for regtest datadir (MarcoFalke)
- #12902 `7460945` Handle potential cookie race when starting node (sdaftuar)
- #12904 `6c26df0` Ensure bitcoind processes are cleaned up when tests end (sdaftuar)
- #13049 `9ea62a3` Backports (MarcoFalke)
- #13201 `b8aacd6` Handle disconnect_node race (sdaftuar)

### Miscellaneous
- #12518 `a17fecf` Bump leveldb subtree (MarcoFalke)
- #12442 `f3b8d85` devtools: Exclude patches from lint-whitespace (MarcoFalke)
- #12988 `acdf433` Hold cs_main while calling UpdatedBlockTip() signal (skeees)
- #12985 `0684cf9` Windows: Avoid launching as admin when NSIS installer ends. (JeremyRand)

### Documentation
- #12637 `60086dd` backport: #12556 fix version typo in getpeerinfo RPC call help (fanquake)
- #13184 `4087dd0` RPC Docs: `gettxout*`: clarify bestblock and unspent counts (harding)
- #13246 `6de7543` Bump to Ubuntu Bionic 18.04 in (ken2812221)
- #12556 `e730b82` Fix version typo in getpeerinfo RPC call help (tamasblummer)


Thanks to everyone who directly contributed to this release:

- 251
- Ben Woosley
- Chun Kuan Lee
- David A. Harding
- e0
- fanquake
- Henrik Jonsson
- JeremyRand
- Jesse Cohen
- John Newbery
- Johnson Lau
- Karl-Johan Alm
- Luke Dashjr
- MarcoFalke
- Matt Corallo
- Pieter Wuille
- Suhas Daftuar
- Tamas Blummer
- Wladimir J. van der Laan

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

Note this thread will be self-moderated to keep out the spam that usually appears in these release announcement threads.
187  Bitcoin / Development & Technical Discussion / Re: Earning LN routing fees on: June 14, 2018, 09:46:17 PM
I'm using lnd as my client. What should I look for in my log to determine if such an event has occurred?
I'm not currently running LND, so I'm not sure. However, you should see log lines related to circuits.
188  Bitcoin / Alternative clients / Re: Ledger manager and Ledger Wallet Bitcoin on: June 14, 2018, 05:40:30 PM
Have you set up the Ledger yet? The device configuration and setup happens completely on the device itself and does not require a computer or any interaction with a computer.
189  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core : Release v0.16.1 GitHub on: June 14, 2018, 05:39:08 PM
Bitcoin Core 0.16.1 IS NOT released yet. It has only been tagged. We are still doing the deterministic build process. The release is only official when Wladimir posts the release announcement to the mailing lists.
190  Bitcoin / Development & Technical Discussion / Re: Earning LN routing fees on: June 14, 2018, 05:35:20 PM
How can I determine if someone decided to relay through my node? Through incoming connections?
You will see that someone has offered you an HTLC and then you have offered someone else an HTLC.

Are open channels imperative to earning routing fees?
Yes, routing occurs over open channels, you cannot route without multiple open channels.

If so, how many are optimal?
It depends on how many coins you have and how man you are willing to put into each channel.
191  Bitcoin / Development & Technical Discussion / Re: Bitcoin walletnotify's confirmations number can be increased? on: June 14, 2018, 06:28:17 AM
Can we increase this number?

If can't, we should revise coin's source code itself? where?
You can't, not without modifying a lot of code. It's almost all in Bitcoin Core does not actually track the number of confirmations for a transaction; there is no trigger for that. Rather it just records the block height the block including a transaction was found and calculates the confirmations from the current block height. You will need to add something which, for each block, checks all known transactions in the wallet, calculates their confirmations, and triggers walletnotify for transactions at whatever confirmation count.
192  Bitcoin / Bitcoin Technical Support / MOVED: Offline Bitcoin Transactions with Short Message Authentication Protocol on: June 14, 2018, 01:46:09 AM
This topic has been moved to Trashcan.

Duplicate thread
193  Bitcoin / Development & Technical Discussion / Re: Leaf-Node weakness in Bitcoin Merkle Tree Design on: June 11, 2018, 08:22:24 PM
Protecting against this is fairly trivial. Actually fixing the problem requires a hard fork unfortunately as the entire merkle tree structure needs to be redone.

The cost of exploiting this vulnerability is pretty high. With as much hashrate as Bitmain, there are easier and cheaper attacks that can be performed against SPV wallets that are inherent to how SPV wallets work. I wouldn't be too worried about this.
194  Bitcoin / Development & Technical Discussion / Re: Get hash of oldest stored block (Core pruned mode)? on: June 10, 2018, 07:58:30 PM
getblockchaininfo will tell you the height of the oldest stored complete block. You can then look up its hash using getblockhash.
195  Bitcoin / Development & Technical Discussion / Re: Bitcoin money back. Very useful function. on: June 10, 2018, 07:31:54 AM
This is impossible to do in Bitcoin.

Doing such contracts requires using the Bitcoin scripting language. However the scripting language does not have access to output amounts, nor does it have access to other UTXOs which it would in order to have the correct balance for an address.
196  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 08, 2018, 06:57:30 PM
Your proposal itself requires a fork as it is a change to the consensus rules.

If you want to be taken seriously, then you should post to the bitcoin-dev mailing list and create a BIP

What is the point of this? You are just extending the period of time that something is unconfirmed for. Merchants, when they see coins sent from such addresses, will simply not accept the coins until the 100 confirmation mark because they know that the coins can be double spent anyways. It is just the same security as unconfirmed transactions.
197  Bitcoin / Development & Technical Discussion / Re: The usability of Lightning network on: June 08, 2018, 08:30:19 AM
Of course it is going to change! Once the Lightning Network is actually out of the experimental phase, developers will shift focus towards UI/UX. Currently, they are working on making sure that the various Lightning Network software can actually interact with each other and making sure that all of the technical details work. The most important things for a Lightning Network software is to ensure that the user doesn't lose their funds. UI/UX comes last, after everything that works in the backend is complete.
198  Bitcoin / Development & Technical Discussion / Re: What is RPC attack? on: June 08, 2018, 07:32:04 AM
bitcoind's JSON-RPC interface is used to issue commands to bitcoind to have it do things. Having access to the JSON-RPC interface of a node means that you have a significant amount of control over that node. For example, an attacker can dictate what nodes that node connects to, send coins from the wallet, shut down the node, etc.

The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.

To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: That script can also generate a secure password for you to use.

Additionally, you should add rpcallowip=<ip> lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.
199  Bitcoin / Development & Technical Discussion / Re: Need some clarification on usage of the nonce in version message on: June 08, 2018, 07:09:12 AM
No, it is a 64 bit integer which obsoletes your point concerning the birthday paradox entirely  Roll Eyes
Oops, forgot about that.

Regardless, my point still stands as the birthday paradox is largely unrelated to the point I was making:
While this is still fairly small, it is trivial to make this a non-issue by randomly generating a random value. Sure you can take a shortcut and no one would really care, but for the benefit of the network, we want to reduce these chances to as close to 0 as possible. We want the best possible and your idea is not the best possible.

That is the reason for doing this.

Perhaps then, you can explain to me why you think it shouldn't be done this way.
200  Bitcoin / Development & Technical Discussion / Re: Address from signature. on: June 06, 2018, 06:11:59 AM
The point of the stake your address thread is to post your address, not just a message and a signature. You should see addresses in there, not just messages and signatures.

But even with just a message and signature, you can still get an address, it just may not be the correct one.

Signature verification requires three items: the signature, a message, and a public key. Typically you pass all three into a verification algorithm which tells you whether the signature is true or false. However, with just the signature and the message, you can get a public key which is valid for the message and signature. You can then compute the address for that public key.

Keep in mind that any signature and message combination can be used to produce a public key. That does not mean that the private key for that public key is the one that actually produced the signature or that the message is the message that was actually signed. Part of signature verification is to also provide the public key to prove that the owner of the private key for that public key signed the message, not just that the message and signature are both valid. The public key is an important part of signature verification.
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 ... 547 »
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!