- The exit requires as little as 10% selling their coins in the previous majority ledger, which effects a huge decrease in the value of the remaining coins there due to the negative wealth effect, while increasing the value of their new ledger by approximately the equivalent amount of positive wealth effect. Thus the small minority of the "rogues" can enrich themselves in the expense of the majority by so doing, creating a new majority ledger in terms of marketcap. Very much interested in hearing rebuttals which take into account the human psychology and stay on the ground of voluntarism  If your main point is how few "rogues" (~10%) it takes to switch to a new majority ledger, I think you may be neglecting the arbitrage opportunities that would create. Arbitrage seems to undo the cascade effect of the small exchange float, with arbitrageurs profiting from that market inefficiency. That is, if the scenario is such that 10% of investors are motivated to switch their portfolio allocations (whether slowly or quickly), then by hypothesis the remaining 90% are not motivated to change their portfolio allocations. But the actions of the 10% result in the portfolios of the 90% changing anyway, against their will. For example, suppose the 90% only wanted to hold a "tiny bit" of their crypto-wealth as LTC and all the rest as BTC, but now the ongoing price change has left them with say "5x a tiny bit" of LTC and a little less BTC. Insofar as the 90% are mostly strong hands,* not price chasers, they will react by bringing their portfolios back in line. That means they will do the opposite to what the 10% are doing, but with 9x the force: sell their allocations in the minority ledger, now for a giant premium, and buy more BTC at these cheap prices. I believe this negates the "small float" issues of having only a tiny amount of each coin available on exchange at any one time (not to mention that when prices move drastically a lot of coins [and fiat] come out of hiding). In the end it seems like the price will balance out as one would expect, with the market cap of the new ledger being about 10% that of the Bitcoin ledger, as I think Litecoin once was. The price will of course overshoot to the downside temporarily depending on how fast the switch happens and how weak the average hands are (but exhausting the coins on exchange and thereby bringing coins out of hiding means awakening the Smaug-level strong hands). And any overshoot is yet a further opportunity for arbitrage to further entrench the majority ledger investors who have the strongest hands. So I tend to think "it all boils down to normalcy" with this one. That is, 10% switching just means 10% switching. If they switched to Litecoin, for example, that would put its market cap at something like 10-15% of Bitcoin's, and for lesser-valued coins a bit closer to 10%. * Which is one of the nice things about having a mature ledger that has used years of extreme volatility to throw all but the strongest hands off the broncoI'm glad some people around here have the good foresight to save their quality posts. Those were 2 good walks back in time. I completely agree but don't have as much time nor energy to express it. |
|
|
|
Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.
i like this proposal b/c it theoretically accomplishes several things at once: 1. "clears" out the unconf tx set via incentives to capture fees 2. eliminates the "burstiness" and propagation delays related to large block transmission latency (ideally block messages should transmit just as fast as real time tx's themselves) 3. works off the assumption that most nodes and miners have nearly identical mempools 4. eliminates wasteful hashing of block "receiving" miners. questions: 1. how much work and time is involved in decompressing an IBLT for verification/validation and addition of unknown tx's compared to the current method of receiving decompressed tx's contained within a block? 2. how strong is the assumption that nodes and miners have nearly identical mempools? 3. what are the most common problems that could occur if adopted? IBTL only saves you from sending same data twice. e.g. 500 tps = 75 MB block. In current implementation every node has to download 150 MB of data (first all transaction, and then again all transaction ordered in block) No, I don't think that's right. They already have all the TX's in mempool. They'd only need to download the few TX's they don't already have, which should be miniscule. That would be the power of the IBLT. nevermind |
|
|
|
Yes, and this is why I was in favour of Gavin's original 20MB + 40%/year growth. Many people were concerned about the exponential growth of the blocksize limit under this proposal, but in my mind it was just a sensible way to slowly transition from a hard limit to this "Nash equilibrium" limit. Whether 40% was the *perfect* number to match BW and storage growth was never really that important in my mind. Let's allow the network to grow! So... we just need a great visualization of this. If an idea is good enough AND people can understand it easily and quickly, it spreads faster than others and takes over. Haha, OK I tried to think up a good visualization for this today, but came up blank. Did you have any ideas? In my mind, the default ideal visualization is some kind of familiar physical analogy. However, it's hard to find physical systems that are perfectly isomorphic (homomorphic?) to any given concept. So failing that, create some kind of quasi-physical or more complex/strange physical analogy. And if that also can't be done, then use piecemeal visual metaphors for parts of the explanation and visual tokens (non-isomorphic but loosely representative, like in Peter Todd's anti-increase propaganda video) for the rest, accompanied by written/spoken explanation. It would be important to have a good representation of the mining/consensus process first, then show what would happen in various scenarios of concern. I don't have specific ideas on what sort of physical analogies could be used for, say, the Nash equilibrium*, but it would be something to come up with sort of on the fly. The best thing would be a simulation, where the viewer could play with the blocksize settings and see the results. But creating something like that is way outside my skillset. *Note: I don't mean something like a graph showing the mathematical aspects, but rather something like a physical system whose "moving parts" and their movements all correspond to aspects of the system that is being explained. A bit like how a scale, together with its possible motions, is isomorphic to the balance of power in a relationship: when one side goes up, the other goes down. it's really too bad that the anti-increase 1MB core dev crowd can't understand the concept that tx fees and block size limits should in fact be settled by economic market forces. if anything, the myriad of technicals proposals flying around that ignore these economics is evidence to this confusion. |
|
|
|
Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.
i like this proposal b/c it theoretically accomplishes several things at once: 1. "clears" out the unconf tx set via incentives to capture fees 2. eliminates the "burstiness" and propagation delays related to large block transmission latency (ideally block messages should transmit just as fast as real time tx's themselves) 3. works off the assumption that most nodes and miners have nearly identical mempools 4. eliminates wasteful hashing of block "receiving" miners. questions: 1. how much work and time is involved in decompressing an IBLT for verification/validation and addition of unknown tx's compared to the current method of receiving decompressed tx's contained within a block? 2. how strong is the assumption that nodes and miners have nearly identical mempools? 3. what are the most common problems that could occur if adopted? |
|
|
|
as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?
I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune. Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated. The transactions were always valid. To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions. So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do). This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change. As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them. So how come they appear in the unconfirmed transaction list on blockchain.info? Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit. Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork. So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork? I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus. Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain. Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks. Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain). and your definition of a hard vs soft fork? |
|
|
|
That seems to be correct.
And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?
i wonder why they would even be held. why not ignored? Good question. it's interesting how us non CS trained participants can blur things together. i guess i should speak for myself; as one unit, as opposed to a separate base protocol layer governed by rigid communication rules interacting with an overlaying program, like Bitcoin Core and other wallets, which have the flexibility to interact with the protocol in any number of ways, including loose agreements. |
|
|
|
That seems to be correct.
And ... each node holds a different set of non-standard and invalid transactions, because they are only held, not propagated. Correct?
i wonder why they would even be held. why not ignored? |
|
|
|
as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?
I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune. Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated. The transactions were always valid. To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions. So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do). This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change. As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them. So how come they appear in the unconfirmed transaction list on blockchain.info? Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit. Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork. So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from changes to the protocol which defines what is acceptable as a block and requires a fork? |
|
|
|
as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?
I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune. Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated. |
|
|
|
I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.
First off, you can't take a 1BTC address and create 10000 zero balance outputs with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.
Second, even if the attacking miner constructs non zero output TX's, he can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject the bloated block since they don't recognize any of the content.
There's a difference between non-standard transactions and invalid transactions. Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however. Clients do not relay nonstandard transactions, nor accept them into mempool, but will nonetheless accept a solved block that contains them (provided each TX in the block is still valid). Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740. They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time! BLOCK #309740: 10,486 DUST OUTPUTS
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749
BLOCK #309657: 7,490 DUST OUTPUTS
ADDRESS SENT FROM TX HASH N_OUTPUTS
===================================================================================================================
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749
A miner can fill a block full of nonsense transactions very easily. thanks for clarifying that. as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks? |
|
|
|
Let me ask again.
Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?
https://blockchain.info/en/unconfirmed-transactions2MB, not much. thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees. Well to be fair, the reason why we don't see this attack is because with the 1MB limit it is not possible to pull off. If BTCGuild started to do this, they could only take 3% of the blocks to 1MB, which is immaterial. I think it would technically be very easy for a pool/miner to add a huge number of transactions into a block. For every address they have with 1BTC, they could create 10,000 transactions with 0.0001 fee each (which they receive back in the coinbase transaction) by simply creating a chain of transactions in rapid succession. With 100BTC, they cloud create 1M transactions at zero cost because they would only include the transactions in their own block and recover the fees. In the real world though, a pool could only do this a few times before miners would abandon them en mass, destroying the pool's business in the process. So it seems unlikely At large solo miner with maybe 0.1% or 0.3% of the hash rate could start to inject very large 1GB blocks every 200 or 400 blocks or so, but in that case I could very easily see the rest of the pools agreeing to ignore those massive blocks. And even if they didn't coordinate to ignore them, the large blocks would propagate so slowly they might not be included anyway. (The attack requires transmitting a full block since Gavin's IBLT wouldn't help here). Another way to address the issue of one or two rouge pools making large blocks, is to set a floating blocksize cap that resets with each difficulty adjustment and is based on an average of the last x number of blocks plus some overhead. Now to implement the attack an attacker would need to create false transactions that everyone mines on to bring up the average, but this would become too expensive since the fees would be lost to other miners. I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted. First off, you can't take a 1BTC address and create 10000 zero balance outputs with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network. Second, even if the attacking miner constructs non zero output TX's, he can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject the bloated block since they don't recognize any of the content. |
|
|
|
Let me ask again.
Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?
https://blockchain.info/en/unconfirmed-transactionsI have glanced over that page a few times, and it seems, when it is high (4000 tx or more), it is filled with transactions that are never going to be included; dust, and zero fee transactions that should have a fee due to size and output age. Logically, when blocks are not full, the queue of valid transactions should be zero. I think we will not see a long list of valid unconfirmed transactions before we are quite close to the block size limit on a 24 hour basis. that's even stronger evidence against this attack. if the available unconf tx's are mostly invalid b/c of dust limits or being non-std, then those couldn't be included in such a bloated block. |
|
|
|
Let me ask again.
Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?
https://blockchain.info/en/unconfirmed-transactions2MB, not much. thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees. |
|
|
|
Let me ask again.
Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?
Is this idle curiosity or important to you? If important probably I could fork the satoshi client and instrument it. But then we'd have to collect data, etc. Its a medium time length project. i ask b/c of this bloated block attack being floated around. we know that full nodes have unconf tx sets that correspond by somewhere over 90%; which is why IBLT could work to communicate across the network that a new block has been solved. the ppl who argue against raising the 1MB cap say that an attacker could create these bloated blocks to torment small miners. the question is, where would they get the extra tx's to construct this bloat? from the unconf tx set or would they have to construct them themselves at considerable cost? to answer this, it would be helpful to know the extent to which the unconf tx set gets cleared out every 10 min per block and the absolute size of the set so as to determine how many unconf tx's are left over that could be used in such an attack. if i look at my 4 full nodes memory use, it's averaging around 200MB, but with around 500-600MB VSwap. as i understand it, VSwap is to be considered a form of memory use so the total is around 800MB, which is consistent across my nodes:  |
|
|
|
|
Let me ask again.
Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?
|
|
|
|
what's the latest working version of Ubuntu that will work with 0.93.1?
I haven't run it yet but I did compile 64-bit Armory under Ubuntu 15.04. It went through without a hitch. I'd imagine it runs fine. how about for 32 bit cpu's? so the highest Ubuntu version download link on your website labelled 13.10 is incorrect dated? |
|
|
|
|
what's the latest working version of Ubuntu that will work with 0.93.1?
|
|
|
|
sudo apt-get install libprotobuf-dev The full procedure: Using myTrezor.com - disable the pin first!
sudo apt-get install git python python-dev python-setuptools cython libusb.1.0-0-dev libudev-dev libprotobuf-dev
git clone https://github.com/trezor/python-trezor.git
cd python-trezor
sudo python setup.py install
sudo python cmdtr.py set_homescreen -f kocicka.png (or the name of your 128x64.png file)
Set your pin back.
To go back to the original screen:
sudo python cmdtr.py set_homescreen when i run: sudo python setup.py install
i get this: Error compiling Cython file:
------------------------------------------------------------
...
cdef extern from "stdlib.h":
void free(void* ptr)
void* malloc(size_t size)
cdef extern from *:
object PyUnicode_FromWideChar(const wchar_t *w, Py_ssize_t size)
^
------------------------------------------------------------
hid.pyx:14:46: Expected ')', found '*'
hid.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation.
error: Setup script exited with error: command 'gcc' failed with exit status 1
cypher@ubuntu:~/python-trezor$ sudo python cmdtr.py set_homescreen -f kocicka.png
Traceback (most recent call last):
File "cmdtr.py", line 8, in <module>
from trezorlib.client import TrezorClient, TrezorClientDebug
File "/home/cypher/python-trezor/trezorlib/client.py", line 7, in <module>
import mapping
File "/home/cypher/python-trezor/trezorlib/mapping.py", line 1, in <module>
import messages_pb2 as proto
File "/home/cypher/python-trezor/trezorlib/messages_pb2.py", line 4, in <module>
from google.protobuf.internal import enum_type_wrapper
ImportError: cannot import name enum_type_wrapper which leads to same error above. does it matter that i'm running 32 bit? |
|
|
|
I'd need to know what kind of image file to provide (size, format,...)
Any image of size 128x64. Python Imaging Library will take care of conversion into black-white. wonderful, thanks!  the flying spaghettig monster looks impressed EDIT: or maybe it's shocked to find itself inside a trezor device is it possible to do this with 12.04 Ubuntu? python-Trezor doesn't seem to work for me  it should work. are you getting a specific error? edit: what I did: ~/bitcoin/python-trezor\> ./cmdtr.py set_homescreen -f fsm_128x64.png
you also need recent enough firmware on your trezor (not sure which version), otherwise trezor will complain i get this: cypher@ubuntu:~/python-trezor$ ./cmdtr.py set_homescreen -f trezor.png
Traceback (most recent call last):
File "./cmdtr.py", line 8, in <module>
from trezorlib.client import TrezorClient, TrezorClientDebug
File "/home/cypher/python-trezor/trezorlib/client.py", line 7, in <module>
import mapping
File "/home/cypher/python-trezor/trezorlib/mapping.py", line 1, in <module>
import messages_pb2 as proto
File "/home/cypher/python-trezor/trezorlib/messages_pb2.py", line 4, in <module>
from google.protobuf.internal import enum_type_wrapper
ImportError: cannot import name enum_type_wrapper
cypher@ubuntu:~/python-trezor$ |
|
|
|
|
Show Posts
