Trying to parsing from the Exodus address (and build a database). The code below looks like a multi sig transaction. How can I get the public key ? Sender 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is the Receipients 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb Are the address below the data? 1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3 13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR {[
{
"n": 0,
"value": 9950000,
"addr": "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826",
"tx_index": 94812526,
"type": 0
},
{
"n": 1,
"value": 6000,
"addr": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
"tx_index": 94812526,
"type": 0
},
{
"n": 2,
"value": 6000,
"addr": "1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb",
"tx_index": 94812526,
"type": 0
},
{
"addr2": "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3",
"n": 3,
"value": 12000,
"addr": "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
"tx_index": 94812526,
"type": 1
}
]}
|
|
|
|
Thanks Zathras, I will check your library =) Check (and fix) ECDSA validity: Dim valid As Boolean = False
Do While valid = False
Dim rbyte As String = getrandombyte()
encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
valid = validateecdsa(encodedpubkey)
Loop
Encode a simple send transaction using Class B (requires sufficient fees at from address): Dim rawhex As String = mlib.encodetx(bitcoin_connection, from_address, to_address, currency, amount)
Thanks!  P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes! |
|
|
|
(Will check if the capital letter affect sha256)
They do, check out the discussion me and Zathras had today  We must have a standard for this. I vote small letters |
|
|
|
With each packet: * For sequence number 1 we SHA256 the entire length of the address (which could be anywhere from 27 to 34 bytes), result = 32 byte hash. * For sequence numbers 2 onwards, we take the previous 32 byte hash and SHA256 it again (and again), result = 32 byte hash. SEQNUM=1 {D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE3}44
SEQNUM=2 {000EC2C68806819E67A030E82A6AF98376DAC1065D7FE533DAF251D43AA836}3B
SEQNUM=3 {999722F745CC7EA5559D871285A697513D6D1F69294A472AB71499C280CFDA}72
SEQNUM=4 {23C4AC723733621964260EC4639D9DF3469E983E677B083457F325C6F56FA5}D0
SEQNUM=5 {A2989BBA3E4BF3B2995A8573E19450381C94CDE10F95A157756148217B0E37}1B
hash1 is d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344 I tried Dim sha256 As SHA256 = New SHA256Managed() Dim hash2 As Byte() = sha256.ComputeHash(hash1) hash2 came out as 4266395eef8a3a62fb74ed5ff4d6201573fd51318fce9eaf452eecb3ab9a8ba9 (Will check if the capital letter affect sha256) |
|
|
|
For ECDSA validity (I'll also put a check function into the masterchest library) I took my inspiration from the casascius bitcoin address utility - have a read through some of the pubkey and ECDSA stuff to point you in the right direction. Thanks! Thanks zathras. Will get some ecdsa information there. |
|
|
|
We haven't discussed what we will use to XOR data for a 'Selling MasterCoins for Bitcoins' package. I want to propose using the sending address whenever a Mastercoin message does not contain a recipient address.
Agreed. Though I actually think we should make it the sender address for everything because as you note, not all transactions will have a reference address. We may as well stick with an address we know will always be there. Unless you guys know of a reason for not using the sender address let's lock that in as our initial source for the SHA256 hashing & I'll update the amendment accordingly. Agreed, let's just use the sending address for all packages. This should go into the spec. Excellent, using the sender address for all transactions will simplify the coding (and lessen the bugs). |
|
|
|
Hi Grazcoin
You are the first to post to the the blockchain using the new multi sig. Nice work! ( I was able to parse your transaction =)
Data to Parse: 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
OBFUSCATED MASTERCOIN PACKET: 1bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57c
SHA256 HASH: 1af733f7aab3932561cd8e8a3ec1a724a047f0694a0b61c86ab48e63bba57cd0
REFERENCE ADDRESS: 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000000bc614e0000000000000000000000000000
01: 1 (01)
Trans Type: 0 (00000000)
Currency ID: 1 (00000001)
Amount for Sale: 12345678 (0000000000bc614e)
- The padded dataHex is 0100000000000000010000000000bc614e0000000000000000000000000000
- After obfuscation (using sha256 of the string '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX') and adding 02 at the beginning and a random tail, it becomes 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
- Within 4 iterations of searching for a valid pubkey (each time adding 1), a valid one is found.
- A transaction is created and signed.
- A parsing test shows the same values.
On blockchain.info, the transaction looks this way. Note that the input used for the transaction was too small to include also change (the change was less than the dust limit), so all the under-dust change got added to the fee. The fee then increased to 0.0001228 instead of the requested 0.0001. |
|
|
|
I was able to decode the 1st packet Data to Parse: 02d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3e5
OBFUSCATED MASTERCOIN PACKET: d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000014000000020000000000cc07c9000000000bebc200160000000000
Clear text looks ok 01: 1 (01) Trans Type: 20 (00000014) Currency ID: 2 (00000002) Amount for Sale: 13371337 (0000000000cc07c9) BTC Desired: 200000000 (000000000bebc200) Time Limit: 1 (1) But have a problem on the 2nd Data to Parse: 026c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28b5
OBFUSCATED MASTERCOIN PACKET: 6c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28
SHA256 HASH: 4266395eef8a3a62fb74ed5ff4d6201573fd51318fce9eaf452eecb3ab9a8ba9
REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 2e71803e3e20bb6994078a3f54e746cbb311972651a887baa5476d667315a3
Should the 2nd packet be 2x sha? Ok! With all this new found knowledge let's try decoding this 'Selling Mastercoins for Bitcoins' (SMFB from now on) message again. XOR Reference: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
Clear text Mastercoin message: <REMOVED FOR NOW :) >
Result: 02d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3e5, 026c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28b5
Some notes. When I SHA the reference I only take the first 62 bytes since this is the exact amount we need for the obfuscation. This will change the the SHA of the next iteration of hashes that follow so I'm open to discuss this. Once we agree on the output of these keys I think it's safe to try and broadcast a message Edit: Updated keys since I forgot to increment the amount of hashes. |
|
|
|
I use OpenSSL to check ECDSA validity. I believe Zathras has an implementation you could probably use since he is also using something Microsoft(y) to create his code, excuse my ignorance I'm not sure what language you are using Zathras.
Zathras is using Microsoft .net. Zathras, can I borrow your ecdsa validity check and multi sig sending module |
|
|
|
Thanks Tachikoma and Zathras , (Hurray! I feel like a student who (barely) passed the exam How do you check for ecdsa? |
|
|
|
Thanks again Zathras, Missing some paddings in my code. ( Will re-read the multi-sig protocol =) The code below is for sending 188 "satoshi" master coin. REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 01000000000000000100000000000000bc0000000000000000000000000000
SHA256 HASH: D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE344
OBFUSCATED MASTERCOIN PACKET: D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3
FINAL RESULT: 02D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3B4
if sending 188 MSC, Is this code correct? REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000460913c000000000000000000000000000000
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
OBFUSCATED MASTERCOIN PACKET: d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3
FINAL RESULT: 02d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3b4
|
|
|
|
Zathras, Ok I think I got it. Here is the code generated, for a simple send 188 Mastercoins using address 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B 02d52c390e52f1110413078a9db528769f06924666b4 ('02' is fixed and the last 2 hex 'b4' are random) Can anyone verify =) btw In Tachikoma's example 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B is the sender's address?
You're on the money there Tachikoma. You have a Mastercoin transaction, simple send, test mastercoin with an amount of 0.00001000.
For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated
Thanks for the detaied explanation. For simple send the transaction type is 0. first 4 bytes should be 00? (Why is it 01) No problems The first byte is the sequence number. Sequence numbers started at one in Tachikoma's original multisig and as per the latest revision also start at one for the suggested amendments (as we need a positive sequence number for our obfuscation process). |
|
|
|
You're on the money there Tachikoma. You have a Mastercoin transaction, simple send, test mastercoin with an amount of 0.00001000.
For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated
Thanks for the detaied explanation. For simple send the transaction type is 0. first 4 bytes should be 00? (Why is it 01) |
|
|
|
|
For the distributed exchange. Smart Property
1. Transaction type = 50 for creating new property (32-bit unsigned integer, 4 bytes)
2. Property Type = 1 for indivisible shares (2 is divisible currency) (32-bit unsigned integer, 4 bytes)
3. Property Name = “ master miner corp. \0” (21 bytes)
4. Number Properties = 1,000,000 indivisible shares (64-bit unsigned integer, 8 bytes)
To create the property, send data above to the exodus address.
(I think we should add if it is denominated in MSC or BTC)
This will become property of the Issuer (Sender)
Seller IPO (Initial Public Offering)
Allow anyone to post Max highest bid price for a share. Bidder must have sufficient BTC balance
At the end of IPO period.
Arrange Bids Highest to lowest
Ex. Total Shares 1,000,000
UserA 500,000 @ 9.0
UserB 400,000 @ 8.5
UserC 300,000 @ 7.0 <- Cut off
UserD 300,000 @ 7.0
Final Share Distribution (System post to exodus,Seller Address,Bidder Address?)
UserA 500,000 @ 7.0
UserB 400,000 @ 7.0
UserC 100,000 @ 7.0
What protocol should we use to post shares?
|
|
|
|
Another option is to ask bitcoin foundation to allow msc data transaction. like telcos buying cell phone frequency from the government.
JR has stated a core goal of remaining censorship resistant which necessitates a design that does not require any permission/allowances (though of course it would be fantastic to have their support). As for the 'buying' aspect, we're paying fees just like any other user of the blockchain - we'd like a miner to include our transaction and we thus pay them a fee to do so. As reward halving decreases the amount of bitcoins mined per block, transaction fees are going to be an increasing part of a bitcoin miner's revenue stream so more transactions for bitcoin is not necessarily a bad thing if done the right way (which is exactly what we're trying to do). Thanks! Maybe we can pay a higher mining fee ( on msc transactions) so that they will include it |
|
|
|
|
Maybe we can just do random padding (instead of all 0 paddings). Then just test if its valid.
Another option is to ask bitcoin foundation to allow msc data transaction. ( like telcos buying cell phone frequency from the government.)
|
|
|
|
Hi Zathras, Thank you. The Transaction fee is 100000 Data Sequence 1: 1 (01) Send Type: 20 (00000014) Coin Type: 2 (00000002) Amount for Sale: 100000000 (0000000005f5e100) BitCoins Desired: 1000000 (00000000000f4240) Time Limit: 6 (06) Transaction Fee Satoshi : 100000 (00000000000186a0) Please check this transaction 006a0000001400000001000000003b9aca000000000001c9c38006000000000001 006986a00000000000000000000000000000000000000000000000000000000000 Selling 10 MSC for 0.30 BTC. Is this correct? Data Sequence 1: 106 (6a) Send Type: 20 (00000014) Coin Type: 1 (00000001) Amount for Sale: 1000000000 (000000003b9aca00) BitCoins Desired: 30000000 (0000000001c9c380) Time Limit: 6 (06) Transaction Fee Satoshi : 100000 (00000000000186a0) Note: Fixed the previous transaction. Hey Bitoy, You're including the second byte of the second packet; that's a sequence number |
|
|
|
020100000014000000020000000005f5e10000000000000f424006000000000001
020286a00000000000000000000000000000000000000000000000000000000000
Try these instead BitBoy, I think these should work. A new problem exists though since that second public key is not a valid compressed ECDSA point. It would really help if I could figure out why not. Data Sequence 1: 1 (01) Send Type: 20 (00000014) Coin Type: 2 (00000002) Amount for Sale: 100000000 (0000000005f5e100) BitCoins Desired: 1000000 (00000000000f4240) Time Limit: 6 (06) Transaction Fee Satoshi : 66182 (0000000000010286) Data Code is 4tvtzmG2Ximf57U7rLZrDLHH6SbM8Ptqebfiqs6n1XDh9oYvdx 4ubsdohy5gbQBQ9tsqAgEw6QSt6gdKsCwCwSmmzao5YuR6NCHk Is tis correct? |
|
|
|
I've created public keys for a "Sell Mastercoin for Bitcoin" offer. I would appreciate it if an other developer could decode the keys and tell me what they think it says before I broadcast it to the world 020100000014000000020000000005f5e10000000000000f424060000000000018
02026a000000000000000000000000000000000000000000000000000000000000
Back to back meetings today but will take a look this evening Data Sequence 1: 1 (01) Send Type: 20 (00000014) Coin Type: 2 (00000002) Amount for Sale: 100000000 (0000000005f5e100) BitCoins Desired: 1000000 (00000000000f4240) Time Limit: 96 (60) Transaction Fee Satoshi : 1573482 (000000000018026a) 1 Test Master coin for sale for 0.01 BTC. These i'm not sure. Time Limit is 96 Blocks Transaction fee is 0.01573482 BTC |
|
|
|
Confirmed that is my address. Thank you Forgot this was for the contest participants - I'll do the lot at .025BTC so they get a bit more Note this sell offer is only open to dacoinminster for the coding contest. Thanks for your generosity lishbtc! I accept that offer of 835.2 MSC for 20.88 BTC (0.025 BTC/MSC). If you like, you can send the MSC straight to the contest winners: - Tachikoma gets (17.28/20.88)*835.2 = 691.2 MSC at 13NRX88EZbS5q81x6XFrTECzrciPREo821
- bitoy gets (3.6/20.88)*835.2 = 144 MSC at 1Fq37GNfyxSvnmye3QdxH6GpPAQ3enarfs
If you want to send the MSC straight to the contest winners, I'll pay you directly from the Exodus Address, otherwise I'm happy to use maxmint for escrow. Please don't be alarmed if I don't send the BTC right away. I tend to go hours at a stretch without checking email, and accessing the offline-only funds is a big pain (requires typing a password so long it makes my fingers hurt). Also, I'll be offline all weekend, as is my bizarre habit. However, if we get this going today, I should be able to pay by tomorrow at the latest. Now, you may be asking yourself, "How do I know those are the right addresses? Maybe J.R.'s bitcointalk account got hacked." If so, I'm glad you are being appropriately paranoid! I suggest we let those addresses sit for a few hours so that Tachikoma and bitoy have a chance to confirm/deny. (I'll PM them.) Thanks! |
|
|
|
|
Show Posts
