It looks like you're in Python 2. Py2 represents bytes in a latin-1 encoded string. Sometimes you'll see ascii characters, other times you'll see something like \x18 which means the byte 00011000, aka 18 in hex, or 24 as an integer. A private key is just a bunch of bytes back-to-back.
raw is the binary representation of the address. The address in addr is ...
Pyethereum is the core blockchain related logic: transactions, blocks, contract VM, etc....
Pyethapp uses both pydevp2p for the p2p logic along with Pyethereum to create a complete Ethereum client.
So if you want a complete networked Ethereum client use Pyethapp. If you just want to experiment with the blockchain related logic you can use Pyethereum by ...
The tutorial you reference is very old in terms of how fast this technology is moving. If you're trying to learn how to create, deploy, and call functions on a contract, I would recommend you look at Solidity and the Web3 API. Although I really like Serpent as well, there's much less documentation making the learning curve a bit steeper.
If you want to ...
pythereum and pythapp - your question tags - are Python implementations of Ethereum's core library and command line client respectively. They are orthogonal to the language in which smart contracts are written.
So the short answer to your question is: no.
Having said that, have a look at Serpent: https://github.com/ethereum/wiki/wiki/Serpent
Ethereum smart contracts need to compile to EVM (Ethereum Virtual Machine) bytecode. There are no Python to EVM compilers, and for some of the challenges, see What is the merit of creating new smart contract languages like Solidity instead of using other languages?
The options are to use a Python-like language Serpent or a recent (Nov 2016) experimental ...
Use t.gas_limit and t.gas_price.
For gas limit, since you usually only want to set it once:
Set t.gas_limit before t.state(). Example t.gas_limit = 3000000
Otherwise can do self.s.abi_contract(code, gas=3000000,...
(You can set the gas_limit much higher for testing purposes so that you can deploy a very big contract, but best to keep it lower than the ...
The message hash must be generated using the original message, without hex-encoding it first.
var message = "0x" + original_message.toHex();
var message_hash = web3....
What can I do to ensure my transactions hit the blockchain as fast as possible?
Most simply, the miner who finds the next block must have your transaction in their pool, and choose to include it. Because they choose, you cannot "ensure" inclusion, only increase your chances.
In an ideal world, for maximum speed, you would peer directly with all the miners, ...
The size of data field is dependent on the block gas limit.
In the Ethereum public blockchain, the limit for the data field was 89kb as of Feb 7, 2016. Source. You can use a similar methodology to check for the limit now.
However, In a private blockchain, there's no limit to the data field. You can set the block gas limit value in your genesis file. Source
It appears that encoding the integer 0 no longer equates to \x00 (as the documentation would imply). This can be seen both in your example, and in the fact that it can't be decoded:
>>> decode('\x00', big_endian_int)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
To get a working version in a virtualenv on Ubuntu 17 I first did (as per @audiomason suggestion above - I haven't tried without this step):
pip install ethereum==1.6.0 pyethapp==1.2.0
then (fixes this)
pip install pyelliptic==1.5.7
then (fixes this)
pip install tinyrpc[websocket]
It then works :-)
The answer is patience. pyethapp is rather a proof of concept implementation than a production ready node.
I had to wait several hours until I noticed the client started to synchronize the main network. It's very slowly sync'ing for some days now and I have only the first million blocks on disk. Keep waiting for the rest.
TL;DR pyethapp works, but prepare ...
As @dbryson said that tutorial is ancient.
To add to some Python references, see pyethapp and its documentation including Getting Started.
web3.py may also help.
As you might be using Serpent, it is unlikely to go away since it's what Vitalik Buterin uses for parts of his development and research, but few in the community have been able to contribute ...
Account generation is slow by design.
Part of the account generation process involves scrypt or pbkdf2, password hashing algorithms that are designed to be slow in order to mitigate brute force attacks on your private keys.
If you look here in the pyethereum source you can see the parameters that are used for each of these hash functions. Both use a work ...
I had the same problem. I had created a wallet using geth and somehow I wrote down the wrong password. I used the simple python code below to solve the issue. I know it's not pretty, but I just needed a quick solution to my problem. Someone else might pick this up and make a proper tool, or perhaps I get around to it one day as a good python learning ...
the decode_abi function expects binary data
0x3078616263646566 is the hex representation of the UTF-8 encoding of the string "0xabcdef". "0" is hex 30, "x" is hex 78, and so on. Try passing in b'\xab\xcd\xef' as the data, instead.
You can generate this byte string from hex with:
raw_bytes = codecs.decode('abcdef', 'hex')
assert raw_bytes == b'\xab\xcd\xef'
It's also worth checking out ...
(This isn't a full answer - as I'm not familiar with how Pythereum does things - but might be a potential starting point.)
Have a look at the State() class in state.py.
This appears to have some code for the following:
Loading a state trie from a given root (line 138);
Getting data from the trie for a specific address (line 175);
Decoding that data from ...
I had the same issue. It looks like the database layer in pyethereum has been abstracted out such that databases other than leveldb can be used. The challenge is that even if you pass a leveldb object into the db parameter of trie.Trie(db, root_hash) you are going to have issues with the way it calls the get put and delete methods. Leveldb uses upper case ...
eth_sendTransaction is not on the list of Allowed Methods shown at http://www.myetherapi.com/
eth_sendTransaction assumes that the node has access to the private key of the account that you're sending from, but myetherapi does not. So you'll have to sign locally and use sendRawTransaction. The most convenient way to do that (in Python) is with the w3.eth....
There will be differences between EVM implementations as to how they get the job done, but they all should produce the same results if they conform to the yellowpaper. I took a look at the VM code for EthereumJS - runCode.js which I have outlined below. You can also use these resources to understand how a VM might be implemented:
Section 3.8.4 of the ...
The values that you present for the result of the signature are not correct. I did this using the same transaction you show and the privatekey provided by you. When you sign the transaction using the private key that you show, you get:
The JSONRPC returns the data field hex-encoded and the decode_abi function expects binary data, so you need to decoded the data field before calling decode_abi.
logdata_hex = filterChanges['data']
logdata = logdata_hex.decode('hex')
# the addresses will be hex-encoded
data = ethereum.abi.decode_abi(['address', 'address', uint256'], ...
If i'm not misstaken, this is stated in EIP 155:
If block.number >= FORK_BLKNUM and v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing the hash of a transaction for purposes of signing or recovering, instead of hashing only the first six elements (ie. nonce, gasprice, startgas, to, value, data), hash nine elements, with v replaced by ...
Is the above architecture safe? (What happens if server is compromised of the server is biased)
Provided the users keys are stored only locally on the users device, this is a pretty safe architecture. However, I can imagine a possible attack vector where traffic between your users and your node is compromised, and incorrect information about the ...