 Show Posts
|
|
Pages: « 1 2 [3] 4 5 »
|
|
To the dude who just read the above message and then tried to log in to my wallet: I have 2FA turned on and your ip is logged at two sites.
|
|
|
|
Can someone test my signed message? I don't really understand how it works, but this came out of the tutorial. -----BEGIN BITCOIN SIGNED MESSAGE-----
This is alberthendriks from bitcointalk.org on 2015-07-07. I sign this message so I can later prove that I still have control over my account.
-----BEGIN SIGNATURE-----
13EDLzhBbe1aEmFfDRGsekw7iVs2e356o6
G7boxuY/0QhUZBIjwI/ESCgh26Kl/3N985H5lrJuRyipYt9Tm50s3h/gG10BbCFV7RxgZwXGS6ysi+Q60Kpgjqk=
-----END BITCOIN SIGNED MESSAGE-----
|
|
|
|
|
Do you have experience with Ruby on Rails?
|
|
|
|
|
Interesting discussion on this page actually. How is it decided that a block is "wrong"? I understand that the block is not according to specs, but well yeah, you know what I mean.
|
|
|
|
|
I've seen some discussions of users selling or buying bitcointalk accounts. Another day I saw a discussion between two hero members praising each other and saying that you should really use the other one's (paid) services. Because of the trading of accounts, I don't trust the status of any account anymore.
|
|
|
|
|
I agree with the security part. But why would auto euro withdrawal be more risky than auto coin withdrawal?
The iDeal deposit is now fully working and committed. I'm also quite far with the withdrawal part. For the beginning I want to generate a Sepa file with all the withdrawals of that day that I can manually upload to my bank. The bank also has functionality to auto-upload the Sepa file, but like you said, that might not be a good idea.
I found out that I also need to implement fees.
|
|
|
|
Hi all, I'm building a centralized crypto exchange, a fork of peatio (my fork is at https://github.com/alberthendriks/peatio, no new commits yet). Peatio was developed by Chinese in Ruby on Rails and has all functionality that you expect from a crypto exchange. The code is also very neat. It uses CNY as fiat currency. fiat money transfers from and to peatio are very cumbersome. So I added euro and Ideal. Ideal is my "usp": it is the Dutch most populair method for instant online (fiat) payments (way more popular than creditcards). You can buy bitcoins with euro ( www.bitonic.nl) but there's no way yet to send euro's directly to a crypto echange, or at least not with ideal (afaik). Peatio is suitable for many crypto's, though at this point probably not too many at the same time. I have no clue yet which crypto's I'm going to add. There are two main issues: 1. I'd like to let people be able to automatically withdraw their EUR. Anyone have an idea? I'm looking for something like this, but then for the euro market. https://stripe.com/docs/tutorials/sending-transfers . The original Peatio only supports a manual process for withdrawal (and also for deposit). 2. How will I attract a marketmaker? I could marketmake myself, but the software for that will take a long time to write. Features I'd like to add soon besides the above are: Branding (design) of frontpage. Solve some security threaths. Solve some bugs in Peatio (note that many issues on their github are actually support requests). Once I get all of the above working I can put up a production site. Long-term features include creditcard payments and anything that www.mollie.nl supports. Mollie also supports a decent bitcoin->euro conversion (but not the other way around). I also want to add Dutch translation and more altcoins. I need to do a legal check of the website. After that I'll try to attract a Chinese business partner to conquer China ;-). More info and a demo url will follow. This is my first contact with Ruby. The Ideal payment works but is not committed yet (some minor flaws still need to be solved). You will find that my code could be better, as I do most of the work in the Controller instead of the Model. The code changes are small though and can easily be refactored later when I understand the model. Peatio is powerful software and works well for the Chinese market. I found that I have the expertise to make it suitable for the West with little effort, so that's why I'm doing it. |
|
|
|
|
If no bid comes in within 24h I'll cancel the auction. I'm thinking of setting up an exchange myself.
|
|
|
|
|
Why not hit $15k? We've had 2011 and 2014, now let's get 2015. And then crash to $1000.
|
|
|
|
|
Description: Cryptox.com domain name.
Starting bid: 2.5 btc
Buy it now: 6 btc
End date and time: 2015-07-06 11:59 AM CET (=GMT+2:00). Time of this post: 2015-06-29 09:00 PM CET.
Payment methods accepted: direct btc payment
Additional information:
Cryptox used to be one of the first cryptocurrency exchanges, hence the name was logically chosen. They went bankrupt years ago and I bought their domain name.
|
|
|
|
Not sure if I'm serious, but anyone wants to place a non-binding offer for my Cryptostocks account? See screenshot (exactly as is). accepting btc and probably monero (still need to setup an account for monero though). In case the Kinetics and up with me, of course you'll still get them. ----------------------  |
|
|
|
|
Did anyone get their shares yet? Looks like a nice usecase for coloredcoins.
|
|
|
|
|
I want to link my Bitcointalk name with BTCJam's. Verification code: 312ec960-ed88-43bf-8ac8-fc52adc2d7d6
|
|
|
|
|
Yes I know, but it gives such a great feeling to find dependencies within sets of bits that were possibly unintended.
|
|
|
|
|
I'm still attacking SHA-2 (256). Of course I know it's not going to work out, but it's a nice and learnful hobby.
Sometimes while hobbying, I run into stupid questions. Like this one:
Wikipedia claims that the best preimage attack on SHA-2 is actually reduced (41 rounds) in time 2^(253.5).
It seems trivial to have a full 2^256 attack (so where do I go wrong?) if SHA is really a bit pseudorandom. Input to SHA is 447 (free) bits; output is 256 (fixed) bits. I make some propagators to rule out trivially conflicting bit assignments. I make 191 non-locally-conflicting random bit-assignments (propagating after each assignment). I have 256 free bits left. Since there are 256 free bits and the output is also 256 bits, I expect to have 1.0 solution left. I search for it with brute-force.
|
|
|
|
|
Are these bounties still on? If so, could you post expiry dates and/or expiry events?
|
|
|
|
|
For anyone who might be interested, I figured out the protocol between electrum (i.e. client) and electrum-server.
OT: For the sake of colored bitcoins, my teammates and me are changing vision by the hour. My current vision is that we should adjust the electrum server (and extend the below protocol) and use a js client.
The google doc mentioned in this thread mentions other methods as well, such as 'blockchain.address.get_balance'. These methods actually don't exist in electrum nor in electrum-server.
Here's my document:
----------------------------------
Electrum server/client message specs
The information below was gathered by looking at the source code that generates the messages. This may have lead to errors.
protocol uses json format.
CLIENT TO SERVER (requests)
general format:
[
{'method':"method",'id':"id",'params':[...]},
{'method':"method",'id':"id",'params':[...]},
{'method':"method",'id':"id",'params':[...]},
{'method':"method",'id':"id",'params':[...]},
...
]
(edit: Note that the above is a single http / scp / whatever request, but I also use the term request for any one entry inside it. Same for response.)
where "id" is a message_id which is just a counter that's increased after each message.
example:
[{'method':'blockchain.transaction.get','id':5,'params':['aec13bHASH43',3700000]}]
used values for 'method': see below.
SERVER TO CLIENT (responses)
general format:
[
{'id': "id", 'result': "result"},
{'id': "id", 'result': "result"},
{'id': "id", 'error': "error"},
{'id': "id", 'result': "result"},
...
]
where an entry with id=5 is a response to a request with id=5
REQUEST / RESPONSE SCENARIO'S
below are the possible values for 'method' (in a request from client) and the corresponding (simplified) statement for the value of 'result' in the response. (method -> result).
Note that instead of the 'result'-key we could have the 'error'-key. Those cases are not specified here.
Note that params is part of the request.
Note that the filenames (.py) are files in the client where the calls can be found
Note that "/" (single) stands for "or" (as in "either .. or" but not both). No division is used below.
wallet.py:
'blockchain.transaction.broadcast' * -> urlopen(bitcoind_url, {'method': 'sendrawtransaction', 'params': params, 'id': 'jsonrpc'}).get('result')
//* note: blockchain.transaction.broadcast will not return key 'error'. Instead, the error message would be in the result
'blockchain.transaction.get' -> urlopen(bitcoind_url, {'method': 'getrawtransaction', 'params': [tx_hash=params[0], 0, height=params[1]], 'id': 'jsonrpc'}).get('result')
'blockchain.address.get_history' -> BlockchainProcessor.get_history(addr=params[0], FALSE/true)
'blockchain.address.subscribe' -> BlockchainProcessor.get_status(addr=params[0], FALSE/true)
verifier.py:
'blockchain.headers.subscribe' -> BlockchainProcessor.header
'blockchain.block.get_chunk' -> -1 / BlockchainProcessor.get_chunk(index=params[0])
'blockchain.transaction.get_merkle' -> BlockchainProcessor.get_merkle(tx_hash=params[0], tx_height=params[1])
'blockchain.block.get_header' -> -1 / BlockchainProcessor.get_header(height=params[0])
merchant.py:
'blockchain.numblocks.subscribe' -> BlockchainProcessor.height
unused server-accepted values for 'method':
'server.version' -> version.VERSION (also sets the version)
'blockchain.address.unsubscribe' -> 'ok' / 'authentication error'
|
|
|
|
|
