Bitcoin Forum
September 23, 2018, 09:20:47 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  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 ... 238 »
141  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 11:02:38 AM
Also, It looks like the new 256 bit hash format is part of the current segwit proposal, correct?
Yes, Segwit script v0 P2WSH (the p2sh for segwit) uses 256bit SHA2; both boosting the security to 128 bits, and removing ripemd160 from the potential locations of weakness.

There is a 160 bit supported, but only for single key checksig only. Basically so that the very common single key case that gains little from the 256bit hash isn't any longer than non-segwit.
142  Bitcoin / Bitcoin Discussion / Re: Alleged Bitcoin Founder Satoshi Nakamoto creating Bitcoin Core Competitor on: May 03, 2017, 09:03:14 AM
Why do you write "alleged creator" instead of "established fraudster"?

Wright has show himself to be a fraudster beyond any doubt, and even before it there was almost nothing supporting his claims... a significant percentage of this forum has a better claim on being Satoshi than this con-man. True: they're not claiming it and he is, but they haven't been caught lying about it over and over again.

Wright has been fanning the blocksize drama all along-- it's a simple formula for separating less technical business people from competent engineers that could point out the obviousness of his fraud.

Sounds like the funding for this thing is fake too: http://hoaxchain.com/media1.html
143  Bitcoin / Bitcoin Discussion / Re: Is diversity in bitcoin client implementations a good or a bad thing? on: May 03, 2017, 08:34:43 AM
If one implementation goes down or has a bug, then only the users of that implementation are affected.

This is true for many things but not for consensus systems.

In a consensus system with multiple major implementations if _any_ implementation has an issue everyone has an issue-- and if there is just a "disagreement" but none are objectively wrong, then there is still an issue.

The reason for this is that for a consensus system the primary purpose is to be consistent, so any inconsistency is a failure, regardless of whom is "right" vs "wrong" or even an otherwise harmless difference.  Inconsistency immediately creates an opportunity for funds theft, when you think a state is final but it really isn't and it gets reversed.

An implementation is a _precise_ definition.  A pile of paper is not, or to the extent that it is precise it's still not that relevant: if paper says X and the network does Y, then Y it is, you can't generally just undo Y later without undoing transactions that people thought were final and irreversible.  Good specs are useful to aid understanding and analysis, but cannot define the network because they cannot control its action from moment to moment.

The implications are clear to anyone who has spent a reasonable amount of time doing serious engineering for a distributed consensus system.
144  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 08:24:34 AM
My intuition is that on average it requires twice as many P2SH addresses to be generated as the "birthday problem" would (since each new address in one set is effectively a new potential match in the other set)?
You've got it.

You should generally think of birthday problem numbers as approximate in any case,  because to achieve the bound you need lots of storage.  A cost optimized solver will make some time/memory tradeoff and usually end up using a couple times more computation than the birthday number in exchange for little to no storage.  (google floyds cycle finding algorithim)

And yes, thats the risk-- that your counterparties degree of freedom in choosing part of the contract will let them find an alternative contract with only collision like work, rather than with second-preimage like work.

You can mitigate by having multiple rounds of communication with commitments, but few to no one will implement this in practice:  Each communication round is a huge software engineering and UI cost, and most people don't understand this collision vulnerability (or _any_ collision vulnerability) even after having it explained.  The longer hash should also be somewhat more secure against second preimages assuming our hash functions become weakened by attacks in the future.

[Basically _any_ time I've seen a collision come up in discussions about the protocols people-- even people who should know better-- get them wrong. Someone on Reddit just the other day argued that a 64-bit collision would take 2^64 work, so I generated one based on his message.. then he argued that I got really lucky to have managed to produce one using only a 32-bit nonce and couldn't provide another, so I did... Tongue  they're highly unintuitive to people)
145  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 03, 2017, 12:40:04 AM
The "birthday problem" calculates the odds of ANY TWO addresses in a set matching EACH OTHER.
Unless I'm misunderstanding gmaxwell's post, he's talking about ONE address in a set (the work) matching a specific given address (the contract).

I'm sorry if I was unclear.   You are not provided with an address. You are provided with a public key.   Now you construct many possible addresses looking for a pair where one is a plausible contract and the other lets you spend all the coins.

You show your counterparty one, then spend with the other.
146  Bitcoin / Development & Technical Discussion / Re: The case for moving from a 160 bit to a 256 bit Bitcoin address on: May 01, 2017, 11:45:37 PM
how long would it take to burn through 255 addresses at only 3 TPS,

I think you haven't caught the real reason that 256 bit addresses are important.  Any N-bit address has only N/2 bits of security against collision, right?

So here is the interesting attack:  You give me your pubkey, and then I create my pubkey for a 2-of-2 (or some other more elaborate contract), and then we pay to the resulting address.

Oops.  In the background I did ~2^80 work and found a colliding address which didn't have the same policy, and I use it to steal the funds.

2^80 is a lot of work, but it isn't enough to be considered secure by current standards.

Unrelated, it's also the case that many hashes of the same vintage of ripemd160 have been significantly broken or substantially weakened.

there's a lot of other "wasting room" on the transaction, and the most important one to me is the hash of 256 bits indicating the transaction.  This is overkill.   There is also the 32-bit number indicating the "output number of the transaction" as if transactions would contain 4 billion outputs.   This is wasted space.
You are free to store transactions however you like and negoiate with your peers to send them however you like, there is no need for space to be wasted as a product of serialization.  Using a larger hash does take up more resources but the difference is pretty small compared to the rest of the transaction.
147  Bitcoin / Bitcoin Discussion / Re: "Bitcoin" Unlimited Officially #REKT on: April 26, 2017, 12:36:30 AM
his is down to G Max &
Please show how I've "kept" anything at anything, or retract your slander.
148  Bitcoin / Bitcoin Discussion / Re: "Bitcoin" Unlimited Officially #REKT on: April 26, 2017, 12:07:44 AM
um you forget the core 2013 DB event
You mean the _day one_ bug in the software Satoshi wrote?  Software prior to 0.8 would fork against _itself_.   BU _intentionally_ forks like that as part of its design, they call it "emergent consensus" because the proper term of "consensus failure" is rightfully pretty scary.

.. but wait.. core crashed 560 nodes on the 17th... hmmmm

No it didn't. You're looking at spider restarts, not actual outages. Funny that you'd make this same "mistake" Bu previously did and got called out for https://www.reddit.com/r/Bitcoin/comments/61bkqe/the_astounding_incompetence_negligence_and/

Off the top of my head I can only recall exactly one straight up remotely triggerable crash that has ever existed in the Bitcoin codebase--  a divide by zero added via the bloom filtering extension that Hearn demanded be deployed far too hastily-- and it was found and fixed by the developers before any attacker every found and exploited it.
149  Bitcoin / Bitcoin Discussion / Re: Segregated Witness vs Bitcoin Unlimited vs Do Nothing on: April 25, 2017, 10:12:51 PM
It started with Core...
No it didn't.
I guess this means you know who was behind ddos attack?
The post I was responding to has someone who was claiming to be responsible.
150  Bitcoin / Bitcoin Discussion / Re: Segregated Witness vs Bitcoin Unlimited vs Do Nothing on: April 25, 2017, 07:22:35 PM
It started with Core...
No it didn't.
151  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 25, 2017, 12:00:09 AM
G***it.  For Bitcoin talk moderators there is an edit button on every post right next to the quote button.  The edit screen looks almost identical to what you get when you quote a message.

After years of moderating I finally managed to reply by instead editing someone's post.  Sorry 2112. I'm going to try to get theymos to un#$@ things.   I have my reply but I don't have your original message. If by chance you have it, you could just repost. Otherwise we're stuck waiting for it to get fixed.

I am very sorry for this screwup.
152  Bitcoin / Bitcoin Discussion / Re: ViaBTC finally read all the BIPs about Segwit on: April 24, 2017, 11:08:40 PM
Personally I liked that they were bragging that they weren't being paid, just a couple weeks after https://www.cryptocoinsnews.com/viabtc-open-bitcoin-exchange-raising-200000-funding-led-bitmain/  (and with jihan already 50% owner prior to the investment).
153  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 24, 2017, 03:40:35 AM
We are living in XXI century. Machine-generated and machine-verifiable codes are the way to go.
I did say unless there is a very strong validation framework.  (We have machine verified code in libsecp256k1-- but the tooling does not scale especially well, so far)

Quote
Why would use of an array preclude side-channel resistance? Use absolutely any high-level abstraction in your code,
On most modern platforms, including Intel's x86_64 parts,  accesses to an array take measurably different time based on the the value of address mod cache_line_size-- because loads are always of a full cache line, but data at the beginning of the cache-line is available first.  There are actual demonstrations of using this sidechannel to recover keys.

In the constant time parts of libsecp256k1 we use boolean operations to construct oblivious loads (which read all the data, and select the proper row with masking) whenever we need to access a table with a secret index for this reason.

Quote
use processor-dependent intrinsics.
Intrinsics do not allow you to control register allocation, and on many code the entire performance advantage of using the SIMD operations can be wiped out by unnecessary spills and loads. Compilers are getting better at it... but it's not necessarily a gain.  We've use assembly elsewhere in particular to get access to the carry chain flag, which is not otherwise easily exposed. It's not really a much of a maintenance burden since we use inline assembly that avoids having to deal with difference in the calling conventions between platforms.
154  Bitcoin / Bitcoin Discussion / Re: Fuck: SegWit, LN, Blockstream, Core, Adam Back, and GMazwell on: April 23, 2017, 06:02:31 PM
when the blockchain is lagging as hell because we cannot even get confirmations quickly ( unless you put extra-ordinary fee ) [...]
That's right, nobody will use bitcoin.
The only way that the fees will be "high as hell" is if people are using Bitcoin very heavily and highly valuing the transactions they make.
155  Bitcoin / Bitcoin Discussion / Re: Shocking: Small amount of chinese miners block 88% of segwit support by services on: April 23, 2017, 05:59:11 PM
34% of miners support Segwit
That is 34% of hashpower, it may well be 99% of miners.  That is also signaling rather than support-- there are miners that support segwit who are not signaling it due to pressure or payments from others.
156  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 23, 2017, 10:24:09 AM
I would have never thought consistency might have been a problem with integer values until I kind of learned this the hard way,
Very valuable lesson there.

FWIW, I would not expect any non-trivial program to be completely bug free unless it had a very vigorous validation framework around it that was substantially larger than the code itself; or unless it had something on the order of one man day of review per line of code by at least two different persons and at least a moderately good validation framework around it.

There has been a lot of broken crypto code out there used for generating keys, a lot of it due to underlying broken bignum implementations. There is a reason the tests in libsecp256k1 are as extensive as they are. Smiley
157  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 23, 2017, 03:50:09 AM
You've missed part of my post:

" just not gratuitously slower. It is also optimized for the specific kinds of operations which are performed in elliptic curve crypto-- which seldom consists of repeatedly multiplying values in a loop, but instead has sequences of multiplications and additions and the FE representation is built to make these additions very fast. "

The library was originally written using GMP for field arithmetic, then reduced to using it for verification only, then reduced to not using it at all when the new code was faster for that actual usage on most hosts.

The verification angle also has two other issues you aren't considering: consensus consistency.  Use of GMP in validation would make the exact behavior of GMP consensus critical, which is a problem because different systems run different code. (GMP also has a license which is more restrictive than the Bitcoin software).

If you don't mean using GMP but just using different operations for non-sidechannel sensitive paths-- the library already does that in many places-- though not for FE mul/add. FE normalizes do take variable time in verification. If you have a speedup based on that feel free to submit it!
158  Bitcoin / Bitcoin Discussion / Re: Banks have bought the Core Team on: April 22, 2017, 04:35:30 AM
only one single "reference implementation", by a single team.  That is total centralisation in my book.
Bitcoin is developed by dozens and dozens of people (something like over 400 total contributors to the Core project overall). It is a bit open source collaboration of many independent parties. Not a single team.

Bitcoin's creator was vigorously opposed to multiple implementations for sound technical reasons,  https://bitcointalk.org/index.php?topic=195.msg1611#msg1611

Satoshi understood the dynamics, and so do most competent potential contributors-- which is why they choose to collaborate with the Bitcoin project rather than go off and create something that will almost certainly be incompatible.

To the originators of this awful troll thread:  What banks?  If you can't name them you're fking full of shit.

It's so absurd we went _YEARS_ with the whole fking bitcoin industry barely spending a cent to support development,  and then when a couple developers founded a generic blockchain services company and choose to fund just one and a half full time headcount to contribute to the Bitcoin project the shills rain down about bank take over-- never mind that our company isn't even funded by banks.

I think it's no coincidence that the leaked hacking team newsletter was warning governments that blockstream might fund privacy technology for Bitcoin and then later all these absurd attacks started when I published the confidential transactions design and implementation.

Welcome to being pawns of state actor driven social manipulation teams, all of you.
159  Bitcoin / Development & Technical Discussion / Re: how long bitcoin core stores different branches for the case of reorg on: April 20, 2017, 10:47:13 PM
Pruning removes them when it removes other blocks of the same age,  otherwise forever. there is no point in having to rewrite data to save a couple megabytes here and there.
160  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: April 19, 2017, 05:20:37 AM
libsecp256k1 is a crypto library-- not a bignum library.

Its primitive operations are constant time for sidechannel resistance, they're not expected to be faster than GMP for most things-- just not gratuitously slower. It is also optimized for the specific kinds of operations which are performed in elliptic curve crypto-- which seldom consists of repeatedly multiplying values in a loop, but instead has sequences of multiplications and additions and the FE representation is built to make these additions very fast.

Your benchmarking technique which makes no use of most of the output is also likely to get poor results due to parts of the benchmark being optimized out.

The functions you are calling are not exposed parts of the library, are not stable interfaces, and shouldn't be used by external software-- as I mentioned, it's not a bignum library. The functions that it exports are defined in include/secp256k1.h ... you are bypassing the public interface by including the .c file.

As an aside, why would you ever want to perform arithmetic over 2^256 - 4294968273? The group order would be unsurprising...
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 ... 238 »
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!