Bitcoin Forum
September 25, 2018, 06:17:10 PM *
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 59 ... 238 »
161  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).
162  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.
163  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.
164  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.
165  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
166  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!
167  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.
168  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.
169  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...
170  Bitcoin / Bitcoin Discussion / Re: Roger Ver has been compromised on: April 18, 2017, 09:05:21 PM
segwit dos not solve quadratics.. it makes it 4x worse:
0.12 4k maxtxsigops (~10sec validation time)
0.14 16k maxtxsigops (~8min validation time)
This is unadulterated jibberish technobabble.

A block that has even _one_ segwit transaction takes less time to verify than the worst case block with no segwit.

The consensus rule for non-segwit signature operations is 20k before segwit and not changed (it can't be increased by segwit as that would be a hardfork), and segwit transactions are much faster to hash (on average and especially in the worst case where they are thousands of times faster).

I am only responding to this habitually dishonest bullshitter because his comments have been quoted in the media.
171  Bitcoin / Development & Technical Discussion / Re: [bitcoin-dev] I do not support the BIP 148 UASF on: April 18, 2017, 07:41:57 AM
As soon as a transaction is sent from an address with an insufficient balance, that's when the split will occur.
This is a profound misunderstanding of how Bitcoin works, there are no 'balances' in the system.

And unmodified non-segwit miners will not initiate a split under any condition.

Quote
Any rollout of segwit must include majority hash power
No, that is one sufficient condition, it can instead include basically all of the users (in particular, economically significant users). Either are sufficient alone.  The users define what are the miners and if the user define mining to include segwit, it does... from their perspective it is impossible to violate the rules, and any miner that tries just stops existing-- just as litecoin miners do not exist as far as Bitcoin users (and their nodes) are concerned today.
172  Bitcoin / Development & Technical Discussion / Re: Interesting... on: April 17, 2017, 07:18:00 PM

Not /that/ interesting Smiley -- it doesn't identify anything that increases the worst case processing time over checksig.

That roll was slow was already known to me, the else thing is news to me.

173  Bitcoin / Bitcoin Discussion / Re: Did Craig Wright turn out to be Satoshi Nakamoto on: April 15, 2017, 11:00:50 PM
his special skills?
His special skills are that he once wrote a visual basic registry editing tool (which somehow qualifies him to create Bitcoin...) and that he's dead so that he can continually humiliate himself and people that believe he created Bitcoin, unlike Wright.
174  Bitcoin / Development & Technical Discussion / Re: just out of curiousity, why would segwit impact asicboost on: April 13, 2017, 09:32:10 PM
Because Segwit effs up the block architecture at such a low level...
The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.
175  Bitcoin / Development & Technical Discussion / Re: Why would make the extra merkle commitment asicboost uneconomical? on: April 12, 2017, 06:35:57 PM
Because it's a 12x-ish additional work factor, thats all.  Is 12x a killer? Depends on how specifically that you've constructed it.

Trying to put it all on one big device and you run into IO/memory bottlenecks much easier-- your 100 million midstates is over 64gbit/sec of data, that device goes down and your farm is down. The device is also highly non-covert, so you cannot keep what you are doing secret from your facilities staff. It is much more straightforward to user local FPGAs to generate the collisions.  And from what I'm told use of local devices to generate is how the unreleased spoondooles design worked.

Consider: today miners could use centralized devices to generate midstates, but instead the S9/R3 miners have fairly expensive FPGAs with 16MB of attached dual channel DDR2133 to generate the ~2000 midstates per second they need.  (When will Trezor ship with such an incredible FPGA? Never, I assume Tongue ) They could use a centralized device to do so, but they don't. (well it looks like privately bitmain runs two S9s per controller, twice that).

If you've adopted a design with distributed generation, then you can't escape the cost-- perhaps you could deal with it, but that doesn't mean the infrastructure anyone has already built does deal with it.
176  Bitcoin / Development & Technical Discussion / Re: Fast parallel block validation without UTXO-index on: April 12, 2017, 06:18:19 PM
This is semantics.
It isn't-- because the speedups you conjecture creating already exist.

You propose that your design moves accessing the UTXO data out of the critical path for block validation, on the basis that you will have already validated the transactions and so don't need to access that data.

Bitcoin Core does not have UTXO accesses in the critical path in the same case and doesn't write in the critical path either. So it would not see the benefit you expect for this reason. (not that it wouldn't potentially have benefit, just not the benefit you are suggesting at least not for the reason you suggest)

Cheers
177  Bitcoin / Development & Technical Discussion / Re: Fast parallel block validation without UTXO-index on: April 12, 2017, 09:56:58 AM
I don't understand the specifics of the code, so can you enlighten me? What you're saying sounds like semantics: "It's after in separate batch steps" sounds like it is still done when a block validates,

It's not semantics. When validating blocks the vast majority of the time the UTXO set is not used by bitcoin core; because the UTXOs are in the cache already (due to mempool) and nor are the result of the block's changes written out-- they're buffered until the node flushes-- and very often never get written at all because the newly created outputs are spent by a later block before the system flushes them.

OP suggests that the structure he proposes reduces the delay at the time a block is processed compared to Bitcoin Core's UTXO database, but it shouldn't-- at least not for that reason-- because the database is only used at block processing times in the exceptional case where a transaction shows up by surprise.
178  Bitcoin / Development & Technical Discussion / Re: Fast parallel block validation without UTXO-index on: April 11, 2017, 10:49:54 PM
I think what tomtomtom7 is trying to say is that the common approach (used not only by core) is that even though the node verifies the transactions before a block is announced, the actual moment when the UTXO database is updated (and the changes committed to it)  is during the block's validation.
That is what I understand him to be saying, but it isn't true for Bitcoin Core. For Core, the moment when the UTXO database is updated/and changes committed is _not_ during block validation.  It's after in separate batch steps which apply big batches of changes at a time; specifically to mostly get interacting with the database out of the critical path.

This is also why if you shut your node off uncleanly you'll see it going and reprocessing dozens of blocks-- their effects hadn't been applied to the database yet.
179  Bitcoin / Development & Technical Discussion / Re: Fast parallel block validation without UTXO-index on: April 11, 2017, 04:28:52 PM
This in contrast to Core's model which needs sequential reads and writes to the UTXO index, even if all scripts are already verified.
This is not how Bitcoin Core works. No access to the disk normally at all happens when a block is verified except for transactions that have not yet been seen, reading or writing.
I am not talking about disk reads and writes, I am talking about UTXO index reads and writes.
There are no UTXO index reads or writes in the normal case (transaction recently seen.) in Bitcoin Core.
180  Bitcoin / Development & Technical Discussion / Re: Fast parallel block validation without UTXO-index on: April 11, 2017, 08:29:57 AM
This in contrast to Core's model which needs sequential reads and writes to the UTXO index, even if all scripts are already verified.
This is not how Bitcoin Core works. No access to the disk normally at all happens when a block is verified except for transactions that have not yet been seen, reading or writing.
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 ... 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!