What wallets support Trezor? - myTREZOR (our login-free web wallet)
- Electrum (currently there's Electrum fork, but devs confirmed that they'll accept it to Electrum's mainline).
- Multibit HD confirmed their work, they already have some integration done.
- Armory devs confirmed their work on Trezor integration
- GreenAddress.it has already some integration done (see https://twitter.com/GreenAddress/status/479939415088062464)
- Wallet32 Andoid app confirmed their work on Trezor integration
- Blockchain.info raised their interest in Trezor as well, although we're in early stage there.
Just for the records: myTREZOR is enabled by Bits of Proof, beating them all by at least a half a year and counting. |
|
|
|
The coindesk post might sound a little misleading but that happens in communication. I hope they will at least correct the link to myTREZOR  The CoinDesk article was compiled without interaction with me, interpreting quite freely a press release and our web sites. The back end serving the transaction history for myTREZOR was developed by Bits of Proof. It was delivered in source code to SatoshiLabs and is operated by SatoshiLabs. The Bits of Proof software stack is a generic purpose foundation for enterprise use of Bitcoin as demonstrated also by this project. It is the shared goal of CoinTerra and Bits of Proof to establish BOP as an industry standard. Details of this plan will be out in few days and will be surely positive for TREZOR. |
|
|
|
|
Yes.
It is our common plan with CoinTerra to make the Bits of Proof software stack an industry standard for enterprise use of Bitcoin. Details of the plan will follow in a few days.
|
|
|
|
|
+1
A cool idea for certificate validity and revocation. Maybe even extensible to trust net by examining sources of the UTXO.
|
|
|
|
I think you have to consider what is your intention for using R30? As a general purpose non-cryptographic hash? As a general purpose cryptographic hash? Or as a PoW function? Irreducibility of computation isn't really that important for the first two categories but is (in theory) pretty important for a PoW. Say someone found a way to produce SHA-256 hashes 10,000x faster for a given amount of die space. It wouldn't do anything to compromise the security of SHA-2 as a cryptographic hash but it would allow one to exploit the bitcoin network for cheap. This is why I indicated using something like: R30(nonce + H(blockheader)) < target
Where: H= a secure cryptographic hashing function (i.e. SHA-2) Blockheader = arbitrary length blockheader (excluding the nonce) Nonce = 64 bit (don't make Satoshi's mistake of using a nonce "too small") Agree, R30 is interesting as perfect POW not as much as cryptographic hash. As side note: I am not sure Satoshi made a mistake here. Maybe he wanted the block header is updated with new transactions instead of rolling a nonce until a block is found. |
|
|
|
|
The hash function should be defined for certain a block size.
Padding is an optional preprocessing step for the case the block size is not met exactly at input, and is then on bits not bytes.
I would leave that aside until the algorithm is not settled.
|
|
|
|
|
Remove message length encoding. That's a foreign concept to a hash function.
|
|
|
|
If I were to use this for real (or had more time for fun) I'd rewrite it using a vector of longs and also parallelise it since computation on (groups of) longs can be executed with CPUs cores in parallel only synchronising at change of generation. I am sure the BigInteger with the analytic form of rule 30 already beats your javascript with 2 magnitudes  It turns out that the performance of the below is pretty dismal if compared with SHA-256 as implemented by the standard java runtime libraries. My guess is that memory allocation / shuffling for increasing length of BigIntegers dominates it. This needs a pre-allocated store of the right size. private static BigInteger r30hash (BigInteger input)
{
BigInteger result = BigInteger.ZERO;
for ( int i = 0; i < (80 * 7 + 32) * 8; ++i )
{
input = input.xor (input.shiftLeft (1).or (input.shiftLeft (2)));
if ( i >= 80 * 7 * 8 && input.testBit (i + 1) )
{
result = result.setBit (0);
}
result = result.shiftLeft (1);
}
return result;
}
|
|
|
|
I think with machine code the shifts of the 64 bit registers can automatically be chained. Maybe assembler code in C/C++ would be efficient. Of course, a hardware implementation could be made even much faster than that.
In reality only Bitcoin miners who would use dedicated R30 hardware would be competitive.
Sure. Writing software for this is just for research and fun. The best in class code in whatever software layer will be still lots of magnitudes away of an ASIC for R30, since it is utmost simple, homogenous and parallelizable at finest scale with constant memory (if any) need. This efficiency combined with irreducibility of computation, no inverse and ability to satisfy any difficulty would make it the perfect proof of work. The ability to satisfy any difficulty is something that yet bugs me.. I wish I could convince myself that it has this property, in the limited generation of 7N. Since there is 80 bytes input to determine 32 bytes output, there is plenty of freedom to create whatever pattern though. |
|
|
|
If I were to use this for real (or had more time for fun) I'd rewrite it using a vector of longs and also parallelise it since computation on (groups of) longs can be executed with CPUs cores in parallel only synchronising at change of generation. I am sure the BigInteger with the analytic form of rule 30 already beats your javascript with 2 magnitudes |
|
|
|
I don't believe it's a requirement to select the hash bits from the central column ...
It is apparent that chaos converges to order toward both left and right, so intuition says to stay in the middle if you want maximum entropy. |
|
|
|
Here is a more efficient implementation, not yet parallel, but already illustrates the power of simple design for implementation. Hashing the argument in hex (assumed block header) to 32 bytes of output after 7 * 80 * 8 rounds with rule 30. package com.bitsofproof.r30hash;
import java.math.BigInteger;
public class Main
{
public static void main(String[] args)
{
BigInteger input = new BigInteger (args[0], 16);
BigInteger result = BigInteger.ZERO;
int rounds = (80 * 7 + 32) * 8;
for ( int i = 0; i < rounds; ++i )
{
BigInteger q = input.shiftLeft (1);
BigInteger r = input.shiftLeft (2);
input = input.xor(q.or(r));
if ( i >= 80 * 7 * 8 )
{
if ( input.testBit (i+1) )
{
result = result.setBit (0);
}
result = result.shiftLeft (1);
}
}
System.out.println(result.toString (16));
}
}
|
|
|
|
But how to prove that 7N is enough mathematically?  We enumerated all three bit patterns and 7N is enough to propagate any change to the middle column, even in worst case pattern. A pattern with repetition cycle of more than 3 bits or a random pattern must start local triangles that propagate at a higher slope than the worst case two bit pattern 01010 ... Is this enough? Well, enough for what? I think we should first be clear of properties needed for the purpose of block header hashing. My take is: - no known inverse - Wolfram demonstrated nicely that the middle column gives no clue of the input after a few generations. - full propagation - the nonce should be able to flip any bit in the hash - we think given with 7N generations. - proof of work - means no shortcuts, irreducible, given more clearly than in SHA256 - able to meet any difficulty target - thats a hard question, but did someone prove it for SHA256d? I think not. If there was an attempt to prove this, it would be easier for this one. did I missed some? |
|
|
|
- has constant memory requirement, that is just two arrays one of the current and one for next generation of the evolution,
Actually, I use only one array for the cellular automaton in my implementation. I save a single value in a temporary variable, then write the result of the next generation into the array, and for the next calculation I use the temporary variable instead of the value in the array, iterated from left to right for all the cells. I do not think such algorithm should be optimised for space, rather time. Yours is rather sub-optimal doing everything sequentially although substitutions are independent and not using that even in software operating on bit arrays is faster than on individual bits. I think I will write one that beats this with a few magnitudes for fun Later today .. now I rather play with the kids. |
|
|
|
|
I have no idea of hardware design, but guess that the whole net could be laid out as is without a memory, it would just need exact clocking.
|
|
|
|
|
With such hash function:
- the work needed is exactly quantified by number of logical operations, no implementation specific gimmicks.
- units implementing rule 30 are identical and utmost simple
- all units can run in parallel for a single layer
- has constant memory requirement, that is just two arrays one of the current and one for next generation of the evolution,
- irreducibility of computation could be rigorously proven
Its single parameter is the number of evolutions before emitting the hash.
This parameter should be set >= 7 times input width.
|
|
|
|
|
It seems the 0,1,0,1 ... and 1,0,1,0 ... two bit patterns are the worst case that need >7N evolutions.
And there is a corner case of 0,0,0 ... hat leads to a hash of 0,0,0....
|
|
|
|
It seems 7 is the bare minimum for a setup like in Bitcoin 80 bytes -> 32 bytes hash.
I got 7 too by trial and error. But is that the worst case pattern? And what about the leftmost value? Thats the beauty of the minimum design. One can enumerate all patterns to figure the worst case, since inputs are only 3 bit wide there are only 8 possible patterns. The leftmost must be fine. Actually there are 2 2 bit patters in addition 0,1,0,1 ... and 1,0,1,0... so we have 10 cases. |
|
|
|
It seems 7 is the bare minimum for a setup like in Bitcoin 80 bytes -> 32 bytes hash.
I got 7 too by trial and error. But is that the worst case pattern? And what about the leftmost value? Thats the beauty of the minimum design. One can enumerate all patterns to figure the worst case, since inputs are only 3 bit wide there are only 8 possible patterns. The leftmost must be fine. |
|
|
|
It seems 7 is the bare minimum for a setup like in Bitcoin 80 bytes -> 32 bytes hash.  |
|
|
|
|
Show Posts
