Bitcoin Forum
June 28, 2022, 08:52:53 PM *
News: Latest Bitcoin Core release: 23.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 ... 54 »
1  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: May 30, 2019, 01:31:17 AM
Hash: SHA512

Hello all,

this is to announce that we're awarding:
* 10 BTC to JoinMarket, for the first practical CoinJoin solution, and continued research into progressing this domain.
* 10 BTC to Wasabi, for building a more end-user accessible solution and larger adoption.

The remainder of the funds is left for future solutions with more ubiquitous impact on the ecosystem.

For those watching, 822f559df14894bd57bdd1ef0ab983228b7816a69d035cc1c5d18fb569ee5e94 is the payout transaction, crediting
several individual contributors directly as requested by the winning projects, and aggregating the remaining bounty funds
into a single UTXO. It is (obviously) a joined transaction, mixed with other transfers.


2  Bitcoin / Development & Technical Discussion / Re: Segregated Witness legal flaw and its probable technical solutions on: June 29, 2017, 08:33:06 PM
Yes @Pietre, I do agree, several problems will be fixed but one problem will be created: the signatures that you think 'in particular are only required to validate the blockchain state '  will loose their immutability for this simple fact that they are not been hashed. right?

The statement above is false. The signatures are still hashed and committed to by blocks. No immutability is lost. If you don't believe me, please read BIP 141 carefully:

A new wtxid is defined: the double SHA256 of the new serialization with witness data:


A new block rule is added which requires a commitment to the wtxid.


A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:

The data is removed from the transaction merkle tree, and instead committed to in the witness merkle tree. That witness merkle tree is committed to in the coinbase.
3  Bitcoin / Development & Technical Discussion / Re: Segregated Witness legal flaw and its probable technical solutions on: June 29, 2017, 05:17:07 PM
Let's take a moment and chew it: Current light clients can't check UTXO and prevent double spends, post-SegWit 'semi-ligh' clients can.

The only thing the 'SegWit semi-ligh' client you describe can do is verify that no historical inflation occurred. It cannot be used to verify incoming SegWit payments in a meaningful way beyond what a light client today can do, so it's useless for any economically relevant entity to rely upon.

It is how SegWit encourages this kind of nodes and leaves no incentive to remain a prehistoric fat and resource consuming dinosaur. Clear?

Perfectly clear, but I disagree. Nodes can already prune history, and I think in the future nearly every node will. This does not impact security, as they still download and verify everything. If you feel like running a 'semi-ligh' node which is basically useless, still needs to maintain the full UTXO set (likely the largest resource cost of running a node in the near future), and in return only get a small constant factor of bandwidth reduction, be my guest.

That 'only' difference is a huge one Roll Eyes  Roll Eyes

No, it's a technicality. The same data is still committed to in the wtxid. It's just moved.

When something is discarded from SHA2 process and txId, it is no longer necessary for validating the integrity  of the hashing process and the block header

This is wrong. The witnesses are committed to by the wtxid, which are included in the witness merkle tree, which is committed to by the coinbase, which contributes to the block header.

You cannot change a witness and expect a block to still be valid, except to your pointless 'semi-ligh' node.

and we just need UTXO to check double spend and become a full node
 ... Oops! we got a validator node (in your terminology) without any obligation to store the signatures for future use.

Again, nodes already don't have any obligation to store signatures (or anything) for future use.
4  Bitcoin / Development & Technical Discussion / Re: Segregated Witness legal flaw and its probable technical solutions on: June 28, 2017, 09:55:20 PM
A full node is capable to handle temporary chain splits and to choose the right sequence by checking for double spend and not the signatures.

That's a nonsensical security model. You're allowing an attacker to take anyone's money with invalid signatures, but not spend it twice? He'll just pay you and then steal the money back. No need for a double spend.

Without the ability to validate signatures, you can effectively not validate any useful property of the system. If that's the model you want, it already exists, and it's called a light client. All SegWit does in this regard is reducing the bandwidth for such nodes. It doesn't change the requirements for nodes that do need to validate.

5- March 2028: The court issues a verdict: "As there is no electronic signature proof 'attached' to the transaction

There is just as much proof in SegWit transactions as in others. The only difference is that it does not contribute to the txid. It's still included in transactions and blocks, it's still required for validation, and it's still committed to.

There is indeed a new storage model possible where someone chooses to delete old signatures but not delete the rest. However (1) there is already no guarantee that nodes keep around everything for you, and if you want proof in the future that a transaction took place you'll need to keep it yourself (which every wallet software does) (2) that new model is only useful for serving light clients that already don't care about the signatures anyway.
5  Bitcoin / Development & Technical Discussion / Re: Segregated Witness legal flaw and its probable technical solutions on: June 28, 2017, 08:28:45 PM
Validating nodes need to download and verify the signatures. This is true now, and will be true after SegWit.

Validating nodes do not need to keep signatures around after validation. This is true now (pruning), and will be true after SegWit.

Anyone who has a transaction included in the chain can construct a proof that this happened (SPV proof), and this proof includes the signature that was used. This is true now, and will be true after SegWit (using the wtxid merkle tree instead of the txid merkle tree).

6  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: June 24, 2017, 12:28:00 AM
In order to get collision with a 40% chance on a set of 2 ^ 80 addresses, you need a memory size of 2.4 * 10 ^ 25 bytes. And even applying algorithms that use a trade-off between memory and calculation time - it will still be a huge size.

That's not correct. Floyd's cycle-finding algorithm can be used to find colliding script hashes with O(1) memory, for just a factor 3 slowdown.
7  Bitcoin / Development & Technical Discussion / Re: Segwit details? SEGWIT WASTES PRECIOUS BLOCKCHAIN SPACE PERMANENTLY on: March 16, 2016, 01:27:36 PM
From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However:
  • The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
  • Has less effect on bandwidth, as light clients don't need the witness data.
  • Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
  • Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).
8  Bitcoin / Development & Technical Discussion / Re: Elements Project testnet sidechain alpha released on: June 09, 2015, 11:47:37 AM
Running with -testnet is default. You can run with -notestnet, but this will result in an error, as the "main chain" code is disabled in all but the unit tests.

For the features, look here:

The peg is two-way, but relies on a federation of functionaries that hold the coins in multisig and verify transfers.

On the sidechain side, a 21M UTXO entry is awarded to the functionaries, who transfer coins out of it whenever transfers on the Bitcoin side into the sidechain happen.


Signed blocks are blocks where the proof-of-work mechanism is replaced with a traditional signature. Block creation, for test purposes, is done by a federation as well, rather than by mining.
9  Bitcoin / Bitcoin Technical Support / Re: JSONRPC - not working with Bitcoin - others are 100% working on: February 22, 2015, 05:20:50 PM
Hard to say without seeing the script...
10  Bitcoin / Development & Technical Discussion / Re: BIP 66 status (miners' votes) on: February 22, 2015, 06:00:09 AM
See any of these graphs (different time ranges): (1 week) (5 weeks) (half a year) (since genesis)

11  Bitcoin / Development & Technical Discussion / Re: Is bitcoin v0.10's new libsecp256k1 safe & without mathematical backdoors? on: February 05, 2015, 06:48:35 AM
void print_number(double x) {
    double y = x;
    int c = 0;
    if (y < 0.0) y = -y;
    while (y < 100.0) {
        y *= 10.0;
    printf("%.*f", c, x);
Why 100?

I guess some comments here would help. It's just guaranteeing a print of 3 significant digits, so it counts how many places to shift the comma by to bring the number between 100 and 999.....
12  Bitcoin / Development & Technical Discussion / Re: Is bitcoin v0.10's new libsecp256k1 safe & without mathematical backdoors? on: January 29, 2015, 03:26:53 AM
However, libsecp256k1 takes its nonce as input to its API, and from that point on signing and verification are deterministic functions. Any nonce skew would need to occur in the Bitcoin code which calls into libsecp256k1; however, since November nonce generation has been deterministic as well (using RFC6979). This code has been audited and replicated by myself and others; it is also unit tested.

This is not technically true anymore. Since recently, there is a full RFC6979 implementation inside libsecp256k1, with test vectors that were generated by another implementation (feel free to review it; it's too recent to go in Bitcoin Core v0.10.0 still, though). The reason for this change was making sure that the easiest way for using the library is always safe - the old API allowed you to shoot yourself in the foot if you passed in a bad nonce.
13  Bitcoin / Development & Technical Discussion / Re: Is bitcoin v0.10's new libsecp256k1 safe & without mathematical backdoors? on: January 29, 2015, 03:15:54 AM
Hi colinistheman,

it's very good that people have concerns about the security of code, or the process used to assure it. I hope your concerns have been addressed by now.

Your post made me realize one thing though: you probably haven't seen gmaxwell's reddit post ( This explains the reason for the at the time somewhat cryptic "we have reason to believe it is better tested". I encourage you to read the details there, but in short: we found a very tricky (but most likely harmless) bug in OpenSSL itself while writing this library - because the tests did comparisons with OpenSSL and failed once. It's by no means a proof that libsecp256k1 is bug free (more review is always welcome), but it does show that its testing practices pay off.

We should probably change the language in the release notes, now that the OpenSSL bug it was referring to has been disclosed.

I've been looking at the code, and theres quite a few magic numbers in there Sad

Most of the constants are taken directly from the secp256k1 standard, or computed using algorithms explained in code. But more comments to explain where they come from would not be a bad idea. We'll add some.
14  Bitcoin / Development & Technical Discussion / Re: Remove block validations in order to speed up initial sync from known client on: January 26, 2015, 05:51:05 AM
-checklevel only changes the level of consistency checks done at startup, it doesn't affect actual validation during network synchronization or otherwise.

If you're syncing from a known node which you fully trust, just copy its $DATADIR/blocks and $DATADIR/chainstate directories to the new system.

15  Bitcoin / Development & Technical Discussion / Re: Block size on: January 21, 2015, 07:16:07 PM
"Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it.

This is true for a softfork (a change where new blocks are acceptable to old software, like BIP16, BIP30 and BIP34 were).

For a hardfork (like increasing the block size limit), which is changing the rules that all full nodes already validate, you need to get those full node to agree with the upgrade, or they will not accept the change. Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway.

One way of looking at it is saying that it's the network deciding which rules they believe the system should enforce (by choosing to run software that implements those rules). Miners are just clients to the network, who create blocks satisfying the rules the network wants, and are paid for that. Miners can choose to enforce stricter rules than what is demanded by the network, however.
16  Bitcoin / Development & Technical Discussion / Re: 0x00 prefix for R and S values in DER signature on: November 26, 2014, 11:42:39 PM
It's a DER requirement to prefix a 0x00 byte to an encoded integer if the integer otherwise starts with a byte >= 0x80. If not, it would be interpreted as a negative number.
17  Bitcoin / Development & Technical Discussion / Re: BIP proposal: Canonical Deterministic Signatures on: August 07, 2014, 01:45:58 PM
BIP 62 already contains a proposal to make S values deterministic (by making it eventually a consensus rule inside version=3 transactions).

Instead of forcing an even value, it forces the value to be in the lower half of the range. Reason: makes signatures on average half a byte smaller. This is also what Bitcoin Core does since 0.9 (and afaik BitcoinJ as well).

EDIT: seems your code already does this, but the text says "even".
18  Bitcoin / Development & Technical Discussion / Re: ECDSA Signatures allow recovery of the public key on: April 12, 2014, 03:41:10 PM

Can anyone think of any reason why the Bitcoin client requires the user provide the address (something it can and already does compute)?

It's done to force people to verify the public key.

As any combination of signature and message results in a recovered public key. you may incorrectly assume it's a valid signature without verifying it is coming from whom you think it is.
19  Bitcoin / Development & Technical Discussion / Re: Non-canonical signatures: looking for detectives on: December 15, 2013, 12:49:30 PM
Do you remember which version started enforcing those rules?

20  Bitcoin / Development & Technical Discussion / Re: strip the reference client to a border router on: October 28, 2013, 10:32:20 AM
Can we just embed the relevant part of OpenSSL to the code, so we don't need to worry about compatibility?
Personally, I would rather advise you to replace it with the code made by sipa, so you would not need to worry about NSA backdoors Smiley

In due time. At this point, it hasn't by far received enough auditing to become responsible for securing millions of dollars in transfers.
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 ... 54 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!