Bitcoin Forum
October 28, 2021, 06:46:55 PM *
News: Latest Bitcoin Core release: 22.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 ... 800 »
1  Bitcoin / Development & Technical Discussion / Re: Enforcing 'n' signatories & signing order for m-of-n P2SH Vs. Multisig on: April 22, 2015, 01:02:54 AM
The only significant limitation is that P2SH are limited to 520 bytes because pushes to the stack of more than 520 bytes are not valid.
The bad news is we likely will have that limitation for a while as changing it would require a hard fork.
Do the current consensus code accepts blocks with pushes over than 520 bytes?
(I think yes, but not sure)


No the blocks are invalid because they contain invalid txns.   This is not a "IsStandard() check it is an valid vs invalid check. A block containing a txn with a push larger than 520 bytes is no more valid than one containing a coinbase generation of 500,000 new Bitcoins. 
2  Bitcoin / Development & Technical Discussion / Re: Theoretical minimum # of logic operations to perform double iterated SHA256? on: April 21, 2015, 01:56:46 AM
As I understand it, (and I could be wrong here) what is actually absolutely required to spend energy for, is the output.  IOW, you could at least in theory design a system that answers the one-bit question, "is there a nonce meeting the difficulty target within <some range of nonces>" by actually spending the energy to write exactly one bit.  Everything else can be reversible, so the greater the amount of computation you can do without any external effects required the more of it can be done "free" (albeit at ridiculously high complexity) but no matter what, you have to write the output.  

In theory yes but even proponents of reversible computing don't believe leakage will be that low.  There is the energy cost required to perfectly isolate the circuit from the outside environment so even if your raw circuit was perfectly reversible the total system energy cost will be much higher.

Also theory is just theory.  In theory it is possible for someone to make a miner with 5,000,000 G/J (instead of 1 G/J) using plain boring classical computing.  Granted you aren't going to do it with 20nm silicon but in theory it can be done.  Now 5,000,0000 PH/s well we know that is not possible without a massive reduction in the "work" needed to complete a single hash.  "In theory" is a nice way of saying nobody has proved it impossible. Smiley
3  Bitcoin / Development & Technical Discussion / Re: Theoretical minimum # of logic operations to perform double iterated SHA256? on: April 21, 2015, 01:48:05 AM
Indeed. It seems obvious that reversible computing is the future for Bitcoin mining ASICs, and could be the first major commercial application of the technology. I have been looking forward to seeing informed comment on it.

Maybe in 50-80 years.  Nobody has successfully implemented a 32 bit adder using reversible computing.  If you think quantum computing is in its infancy well reversible computing hasn't even been born yet.  Despite the theory being published in 1973 to date there has been pretty much no practical demonstration of implementing the most trivial of reversible circuits.

Part of the problem is that the circuit must be very insulated from the outside environment in order to remain reversible.  To date this means a lot of very expensive near zero superconductors but even esoteric problems like a stray cosmic ray striking your circuit can leak to large scale leakage.  To say the future of mining obviously involves reversible computing is sort of like suggesting Honda should stop researching hybrids and start researching hyperdrives because obviously on a long enough timeline some form of faster than light travel is an obvious requirement for a spacefaring civilization. Smiley There is a lot of potential improvement in classical computing.  We something like a million times less efficient than the thermodynamic limit.  

Also as Peter points out there is still an energy time tradeoff.  If I gave you today a reversible miner which ran on near zero energy but had a hardware cost $10,000 of per GH would you be interested?   If the technology is more expensive on an amortized per hash total lifecycle cost than classical computing well it doesn't really matter how little energy it uses.


4  Bitcoin / Development & Technical Discussion / Re: Multisig questions on: April 05, 2015, 06:51:19 PM
Now that most P2SH redeem scripts are standard you can create multisig scripts which uses addresses (pubkehash) instead of pubkeys.  Client support for signing that script is another thing.  So this is more a client implementation detail not a protocol limitation.
5  Bitcoin / Development & Technical Discussion / Re: Slowing down block propagation on: April 05, 2015, 06:15:10 PM
The problem is that simply having an IP address that is accessible or completing a low diff POW doesn't mean you are actually a node.   Proving you are actually a node especially over an extended period of time is a non-trivial problem.
6  Bitcoin / Development & Technical Discussion / Re: How BW Pool chose DiscusFish block over AntPool ? on: April 02, 2015, 04:37:51 PM
When two miners solve different blocks at the same height at roughly the same time they will both broadcast the block to the network.  A node will only relay and build off the first block at a given height in a race condition.  This means until the next block was solved some of the network considered DF block and some considered AP block to be the 'best block'.  The network is temporarily 'divided'.  Miners will be working on different forks however the fork is resolved by a reorg when a miner solves the next block. In this case it was BW and since they received DF block first they extended that chain.   If a miner/pool which received AN block first and thus was extending that chain solved the next block then the network would have reorged to that fork instead.

Now all this assumes that both pools are operating nodes which follow the standard consensus rules.  It would be possible for two (or more) pools to reach a secret agreement to always build the fork containing each others blocks in a split but that would be a losing proposition unless the pools had more than 50% of the total hashrate combined.  There is no evidence that is what happened in this scenario just pointing out that it is always possible.
7  Bitcoin / Development & Technical Discussion / Re: Why does 256-bit ECC offers equivalent security of 128-bit symmetric encryption? on: March 31, 2015, 02:08:31 AM
Everything is compared to symmetric encryption because baring a flaw in the algorithm there is no method to find a symmetric encryption key faster than O(n) steps.  All other algorithms have solutions than can be found in less steps.

ECC is "secure" because the Elliptic Curve Discrete Logarithm Problem is infeasible for large sets however there are solutions to the ECDLP which are faster than O(n) but the fastest (such as pollard's rho) is still O(n1/2).  Since the solution can be found in faster than O(n) steps it requires a larger key for an equivalent level of security.

Keep in mind that the ratio of relationship of O(n1/2) between key size and bit strength only applies to ECC and only because there no faster solution is currently known.   This can change over time.  The strength of a given RSA key has declined over time as faster solutions to the integer factorization problem have been found.  Today to achieve '128 bit security' requires a 3,072 bit RSA key.
8  Bitcoin / Development & Technical Discussion / Re: Transactions which spend coinbase outputs early on: March 30, 2015, 07:16:06 PM
Either way, I haven't seen any numbers that show that a CPU can't recalculate merkle roots as fast as an ASIC can exhaust a whole 2^32 nonce range. Is that actually an issue?

No and probably will not be for sometime if ever.

Quote
I agree that it would be better to have the extra nonce right in the header to avoid recalculating the merkle root entirely, but while I find the extended header idea interesting, I'm not sure it's in sufficient need that it would be worth all the extra work and support.

A hard fork and new block header format just to move the extranonce to the header?  No it probably isn't worth it.  My post was more to illustrate that expanding the header is possible while still being backwards compatible with existing ASIC hardware.  Eventually the header will probably need to be updated for one reason or another.
9  Bitcoin / Development & Technical Discussion / Re: Transactions which spend coinbase outputs early on: March 30, 2015, 05:10:11 PM
If the point is to make getting more work easier by not having to hash 10-20 Kb of coinbase data, then why not ...

The 'work' is recreating the merkle tree not the single hash of a single tx.  A change to the tx set will require recomputing the merkle tree.   It really isn't that much of a problem.  If the block header is updated it would be very smart to put a extanonce in the header itself to prevent needing to recompute the merkle tree but hashing even the full merkle tree is not that much of a load compared to the cost of ECDSA validation.  So I would chalk it up as a "it would be nice to do if we are updating the header format anyways".
10  Bitcoin / Development & Technical Discussion / Re: pubkey and pubkeyHash on: March 29, 2015, 07:51:44 PM
But the script will verify if <pubKeyHash> is the hash of <pubKey>. How can Alice's public key relate to Bob's, they won't match right?

The script verifies the pubkey in the current txn hashes to the pubkeyhash in the output of the PRIOR txn.
11  Bitcoin / Bitcoin Discussion / Re: How did Satoshi managed to stay anonymous? on: March 29, 2015, 07:49:39 PM
Satoshi's coins are stored in multisign wallets.

The blockchain disagrees with you.
12  Bitcoin / Development & Technical Discussion / Re: pubkey and pubkeyHash on: March 29, 2015, 07:26:17 PM
Alice. 

When Carol sent coins to Alice it was a Pay2PubKeyHash transaction.  The address Alice gave Carol contains the PubKeyHash.  So the output of Carol's txn (called PkScript) contains only the PubKeyHash.

When Alice spends that txn she needs to include in the input (ScriptSig) the PubKey which hashes to the PubKeyHash in the prior txn.



13  Bitcoin / Development & Technical Discussion / Re: Thinking about ways to make it more difficult to link IP address to txn creator. on: March 29, 2015, 06:35:40 PM
       
  • If they've connected to a machine that has the wallet containing the key of the original txOut whose owner they're trying to find, that node will disconnect them as a misbehaving node, because the keys they provide don't match.
  • If they've connected to a machine that doesn't have the wallet containing the key to the original txOut, That node will just reject the transaction due to penny-flooding prevention and no fees.
  • Because they can tell which thing happened, they can tell whether the node at this IP address owns, or owned, the address corresponding to the original txOut.

A txn with an invalid signature will be invalid to all nodes.   All nodes validate signatures of txns and will not relay invalid txns.  A node sending invalid txns will be seen as misbehaving and will be banned.  Wallet behavior is different than node behavior.  A node should respond consistently based on what is known publicly (regardless of what private keys are in the local wallet or even if there is a local wallet).  If that isn't the case then there is an information leaking bug.  There was a 'penny flood' bug in the past but it didn't involve invalid signatures and has been patched consistently as of v0.80 (plus some earlier versions).

Quote
And it looks to me like a node that repeatedly sends a tx with an invalid transaction [sic] signature, gets disconnected AND DoS banned, and if the sender tries to reconnect any time in during the next 24 hours, the connection gets rejected.

Exactly.  All nodes verify txns before relaying thus all nodes will ban a node sending a txn with an invalid signature.


Quote
And those 1-satoshi transactions, AFAIK, are still getting mined and into the block chain somehow; I would presume that either some node operated by the attacker is mining them, or they are taking advantage of some bug in the security of one of the existing pools.
Transactions which have outputs less than the dust threshold are valid. They are non-standard but any miner can include non-standard but valid txns in the block to be solved.  Some pools will accept non-standard txns.
14  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 02:51:51 AM
The lack of checksum enforcement on the mnemonic means that many people directly use the 'mnemonic' as a "brainwallet".

Which has what to do with the claimed lack of deniability?  So some people may choose to misuse the proposal that doesn't weaken the security of those who use it as proposed (random value encoded as mnemonic plus optional passphrase with deniability).
15  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 02:49:36 AM
From what I understand: if the ninjas are unable to brute-force the secret passphrase and are unable to extract it from either the suspect or his property then the deniablility that the addresses are associated with the suspect is not further weakened.

However, gmaxwell suggests that it is unreasonable to assume such ineffectiveness on the part of the ninjas and, once the secret master key is revealed, absurd for the suspect (after already admitting to owning the dummy wallet) to claim that the secret wallet is not his.

Then there is no such thing as deniable cryptography under any circumstance.  The definition of what is deniable has been stretched to a point where no possible cryptographic system can fit it and thus there is no point in either using the term.  I would hope you can see that if you graphed all scenarios involving deniability at least some of them would fall on the spectrum short of torture.

Honestly if you suspect you will be tortured in the near future you should NOT use deniable cryptography.  Why? because it is deniable.  Say you give up the sacrifice key but they torture you.  Maybe now you aren't holding out to protect the key but the fact that it is very likely they will kill you once they get it.  Eventually you crack though and give them the second key.  Bad news for you is that one of the torturers turns to the other one and says "what if there is a third key".  Now there is no third key but you can't prove that there isn't.  Under torture you may swear there is no third key but of course you would say that.  So with no way to provide what they want and no way to prove you don't have what they want you are going to die a very slow and painful death.

No deniable system can prevent compromise due to a weak key or disclosure of key by force.   The first is a limitation of any cryptographic system and the second isn't even a cryptographic problem.   It is like saying locks on your door aren't useful because I could always torture you until you open it.
16  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 02:36:46 AM
Part of it is because the application space of  BIP39 is unclear. If the keys are chosen securely then there is no gain from having a KDF (and no real harm in having a weak one, except for code complexity). If people use it like a brainwallet then given what we know about how users choose "random secrets" then the KDF is seriously inadequate; considering the infrequency of use and the huge attacker advantages (precomputation because brainwallet schemes cannot be effectively salted, and hardware advantages) you'd likely want something that takes several seconds on the best hardware the user has access to.

It isn't random mnemonic OR passphrase it is random mnemonic AND (optional) passphrase.   The comparison to brainwallet is inaccurate.  Would you call bitcoin core's encrypted wallet a brainwallet?  Of course not unless you stretch the definition to the point of being silly.   You need the wallet.dat PLUS the (optional) passphrase.  Here you need the mnemonic PLUS the (optional) passphrase.    Precomputation isn't possible in either scenario.
17  Bitcoin / Development & Technical Discussion / Re: Transactions which spend coinbase outputs early on: March 27, 2015, 10:05:16 PM

Thanks for finding it.  That was the thread.  I think this post is clearer:
https://bitcointalk.org/index.php?topic=626377.msg6975690#msg6975690
18  Bitcoin / Development & Technical Discussion / Re: Transactions which spend coinbase outputs early on: March 27, 2015, 07:15:00 PM
There is no way in hell that there'd ever be miner support for something that would destroy the value of their investment in ASICs.

Luckily that is not correct.  A while back I proposed a way to expand the header while still maintaining compatibility with existing ASICs (but would require a hard fork and updated mining software). Maybe I can find a link.  The header will eventually need to be updated when the Unix time value overflows the 32 bit integer but we have a 'little' while before that happens.
19  Bitcoin / Development & Technical Discussion / Re: Rearranging sig and pubkey order before broadcasting an m-of-n transaction on: March 27, 2015, 07:09:42 PM
Only the sigs are required in the input for P2PKH as the pubkeys are already provided in full in the output of the previous transaction.

Correction, the output contains only the pubkeyhash not the pubkey so the ScriptSig will need to provide both the Signature and the PubKey.  There is only one possible order however.

Quote
can I rearrange the sigs to make the transaction valid before I broadcast it to the network?

Yes.  The ScriptSig is mutable.  You or anyone can change the order of the Signatures.  The person broadcasting the txn will need to ensure they are in the correct order before broadcasting.  If in an invalid order the txn will be dropped as invalid.  Technically nodes could be designed to change the order as necessary and 'fix' the txn for you but they don't as that could be used as a DDOS vector.  Keep in mind that changing the order of the signatures (or anything in the ScriptSig) will change the TxId.
20  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 27, 2015, 04:44:05 PM
Unfortunately for you, they also own a laptop computer with a fast gpu an in a fraction of a second they've found your other wallet just by searching a few billion nearby keys;

Care to explain further?  I am not sure what you mean by nearby key.  The output of PBKDF2 should approximate a random oracle.  The closest thing would be a brute force attack on weak passphrases to search for potential key trees.  I remain skeptical of an attack vector which is faster than a brute force search of passphrases and certainly not one which can be done with a gpu in a second.  So lets make sure we are talking about the same thing.


Let m be a given BIP39 mnemonic and p and p' be two distinct passphrases.  Unique seeds s and s' and produced using BIP-33.  I argue that s' can not be derived without knowing p' even if m and p are known if s' is sufficiently strong to make brute force search infeasible.

s = PBKDF2(m, "mnemonic"+p, HAMC-SHA512, 2048) where s is the derived seed, m is the mnemonic (128 bit to 256 bit random value), and p is the passphrase.

I see nothing in the details which makes it weaker than a hypothetical KDF so lets simplify it to a generic representation as:
s = KDF(m, p) where s is the derived seed, m is a random value with at least 128 bits of entropy and p is a user supplied passphrase

So given two unique passphrases and the same mnemonic we have:
s = KDF(m, p)
s' = KDF(m, p')

Are you saying that s' can be derived knowing m & p and not knowing p' just using a GPU powered laptop?  If not then there is no way to link any child derived keys (BIP32) without knowing p even if m is known.  If there is some vulnerability please show it to me.
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 ... 800 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!