Bitcoin Forum
January 23, 2019, 02:05:12 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 ... 65 »
  Print  
Author Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)  (Read 128809 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Ferroh
Member
**
Offline Offline

Activity: 112
Merit: 100



View Profile
October 18, 2013, 05:49:56 AM
 #81

Fix the "implimented" typo on mastercoin.org, it's bugging me Smiley
1548209112
Hero Member
*
Offline Offline

Posts: 1548209112

View Profile Personal Message (Offline)

Ignore
1548209112
Reply with quote  #2

1548209112
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1548209112
Hero Member
*
Offline Offline

Posts: 1548209112

View Profile Personal Message (Offline)

Ignore
1548209112
Reply with quote  #2

1548209112
Report to moderator
1548209112
Hero Member
*
Offline Offline

Posts: 1548209112

View Profile Personal Message (Offline)

Ignore
1548209112
Reply with quote  #2

1548209112
Report to moderator
1548209112
Hero Member
*
Offline Offline

Posts: 1548209112

View Profile Personal Message (Offline)

Ignore
1548209112
Reply with quote  #2

1548209112
Report to moderator
prophetx
Legendary
*
Offline Offline

Activity: 1442
Merit: 1000


he who has the gold makes the rules


View Profile WWW
October 18, 2013, 11:21:38 AM
 #82

Our first blog article giving you the latest updates and news in now available online!  Please excuse the stock wordpress template.

Hello, Mastercoin World
http://blog.mastercoin.org/2013/10/18/hello-mastercoin-world/

Here is a summary, for the rest click on the link.

Quote
We would like to welcome you to the first issue of the Mastercoin blog.

Each week, right here, rather than having to wade through hundreds of forum posts you will find a summary of the most relevant developments related to Mastercoin.  The focus of the blog initially will be on summarizing project developments, service announcements, exchange market updates, and Mastercoin Foundation financials and developments.  If you have any important news scroll down to the form at the bottom and let us know about what you are working on.

The first two weeks of October brought us some exciting news with more code releases coming out for the $25,000 Code Contest and the final awards going to four developers.  Check the repositories out on GitHub, install them and test them so our community of developers can get your feedback and thoughts!

We also have a proposal...

$25k Code Contest Complete!

Repo Updates & Announcements

Market Update

Protocol & Proposals

Mastercoin Foundation Financials

Job Openings


WINGS Beta is live - list your project for only 200 WINGS (erc20 coin) at https://wings.ai - over $750 Million raised by ICOs with WINGS
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
October 18, 2013, 11:43:23 AM
 #83

Our first blog article giving you the latest updates and news in now available online!

Great article! Weekly updates will be a really helpful way to keep track of all things Mastercoin – thanks a lot for this.

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
HammerFist
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 18, 2013, 05:36:37 PM
 #84

Like a real man, he only wants MasterCoins for his contest winnings Smiley
Atta boy! 
dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1022


Rational Exuberance


View Profile WWW
October 18, 2013, 05:38:33 PM
 #85

Our first blog article giving you the latest updates and news in now available online!

Great article! Weekly updates will be a really helpful way to keep track of all things Mastercoin – thanks a lot for this.

I apologize that this thread does not yet reflect the new coding contest. I plan to change the OP and thread title to reflect whatever we are currently working on, and I'd like this to become the development thread (to separate it from the discussion thread). Rough sketch of the next coding contest is here: https://bitcointalk.org/index.php?topic=265488.msg3358444#msg3358444

I had a long phone-call this morning with the board, which was very productive (Ron's minutes from the meeting should be public soon), but that call put me behind on other obligations. I may be unresponsive/offline for awhile - sorry!

dacoinminster
Legendary
*
Offline Offline

Activity: 1260
Merit: 1022


Rational Exuberance


View Profile WWW
October 21, 2013, 07:15:37 PM
 #86

I have updated this thread with the official rules about contest #2. My intention is to have all development-related discussion here, but I'm not going to be a jerk about it (if people post development stuff in the other thread, they might get a gentle reminder from me).

The other thread is now intended to be for general MasterCoin discussion.

Please take a look at the rules for this contest, and let me know if anything isn't clear. Note that I added one thing to the original proposal: for the PC clients we need both Linux and Windows to be supported.

Thanks!

-J.R.

Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 07:32:52 PM
 #87


Thanks, updated it.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 07:41:38 PM
 #88

I've simulated 200.000 simple send public keys to make sure brute-forcing is viable, the highest sequence I needed was 19.

Here is the distribution over a 20.000 sample set. Where k is amount of sequence alterations needed and v the amount of keys.

Code:
{0=>10005, 2=>2511, 4=>649, 1=>5032, 3=>1208, 7=>64, 5=>309, 8=>37, 6=>136, 9=>23, 10=>13, 11=>9, 12=>3, 13=>1}

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 07:42:03 PM
 #89


good Smiley
now to the next difference between http://mastercoin-explorer.com/ and http://masterchain.info/
http://mastercoin-explorer.com/transactions/28ffa93e3d3091f7c501585fd741327d3c58ef3f45bcd94f72166889798283cf claims that the tx is valid but
http://masterchain.info/tx/28ffa93e3d3091f7c501585fd741327d3c58ef3f45bcd94f72166889798283cf.json says that the tx has an ambiguous sequence [119, 119, 120]



Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 07:43:19 PM
 #90

I'm currently not implementation sequence checking in that regard, I hope to convince J.R. it's not the best solution. If it becomes part of the spec I will implement it as well. But as I said in the other topic I don't really agree with it.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 07:51:13 PM
 #91

I've simulated 200.000 simple send public keys to make sure brute-forcing is viable, the highest sequence I needed was 19.

Here is the distribution over a 20.000 sample set. Where k is amount of sequence alterations needed and v the amount of keys.

Code:
{0=>10005, 2=>2511, 4=>649, 1=>5032, 3=>1208, 7=>64, 5=>309, 8=>37, 6=>136, 9=>23, 10=>13, 11=>9, 12=>3, 13=>1}

I see that the brute force for getting a valid point is indeed shorter/simpler with compressed pubkey.
Still I would prefer to limit the amount of outputs we use from 4 to 3.
What about sending all the change to the multisig output instead of having another change output? Will this be considered a valid tx by your parser?
And what about encoding the recipient address in a remaining place of the second pubkey + using a third pubkey (reducing another output?)


Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 07:57:56 PM
 #92

Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 08:19:43 PM
 #93

Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:
I prefer that we support both - extra change address (like your current implementation) as well as change inside the multisig.

I am also for supporting both extra target address (like your current implementation) as well as embedded target address whenever possible.

dacoinminster: do we get an OK here?


Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 08:24:01 PM
 #94

Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 21, 2013, 08:27:05 PM
 #95

I've simulated 200.000 simple send public keys to make sure brute-forcing is viable, the highest sequence I needed was 19.

Here is the distribution over a 20.000 sample set. Where k is amount of sequence alterations needed and v the amount of keys.

Code:
{0=>10005, 2=>2511, 4=>649, 1=>5032, 3=>1208, 7=>64, 5=>309, 8=>37, 6=>136, 9=>23, 10=>13, 11=>9, 12=>3, 13=>1}

Thanks Tachikoma, this also reflects my testing (I ran a much larger set after posting).  Given Peter's feedback also I think it's very unlikely we're not going to be able to churn a public key into a valid ECDSA point with my proposed byte rotation technique.

As per my previous posts, I propose we adopt this as the method for making our keys ECDSA valid.

The question then becomes one of what we put before the last byte (ie do we encrypt/obfuscate), and how much effort to we go to make it look like random data.

If we already run brute force iterations to make the pubkey valid, we could consider doing the same for the non-compressed pubkeys (MIP1) and have 2 outputs instead of 4, plus extra place for future required data. I didn't check how much more iteration that would take, but it would add much less contamination to the blockchain.


We're using compressed keys so we only have to worry about the X co-ordinates and can thus store data - that's kind of the point.  If we had to make a valid ECDSA key from an uncompressed key, let's take example mastercoin X co-ordinates of 0100000014000000020000000005f5e10000000000000f424006000000000000.  The y co-ordinates must be 4B808A82AA5574B899D629F4EC7D77B044D75230FD13C7530F2E6CA5E03D95C8 - we can't change these and still remain ECDSA valid so there is no data we can embed here, and if we can't embed data in the Y co-ordindates, what's the value in using them?  This is why I've personally never viewed uncompressed keys as viable - but hey, I'm certainly not the authority on these matters so happy to be corrected Smiley


Is this really necessary? We have no control over the sequence number for a change address, is it fair to disregard a transaction based on random luck? I would like to propose to do a sanity check before invalidating a transaction based on sequence. You could try to decode the address and see if the transaction_type and the other options based on that transaction_type make sense. If one of the addresses with the same sequence for instance does that, but an other does not you know which one is the data address and which one the target. If that also fails it seems safe to flag it as invalid but I think we should try harder before falling back to invalid.

It's not really about removing ambiguity about which address is the data address, the sequence numbers and the requirement that they not be all in continuous sequence are for ensuring we always pick the right reference (destination) address.  If we have ambiguous sequence numbers then sure we can decode each address to look for the data, but how do we know we're sending the mastercoins to the right recipient and not to the change address?  Note in simple sends change doesn't need to = sending address.  Example based on change and reference having the same sequence number.

Edit for clarity.


Smart Property & Distributed Exchange: Master Protocol for Bitcoin
grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 08:28:14 PM
 #96

I'm currently not implementation sequence checking in that regard, I hope to convince J.R. it's not the best solution. If it becomes part of the spec I will implement it as well. But as I said in the other topic I don't really agree with it.

It is a good idea to avoid sending such a tx in the first place, but once such a tx got sent, there is no clear way to differ which output is which, and a good solution is to consider the tx as invalid.


grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 08:35:35 PM
 #97

Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

I suggested supporting additionally the "compressed tx" (2 or 3 outputs) while keeping the "uncompressed tx" (4 outpus) as well.
GUI users could still use the "uncompressed tx".
I just don't want to develop the "compressed tx" if you guys don't intend to support it.


grazcoin
Sr. Member
****
Offline Offline

Activity: 284
Merit: 250



View Profile
October 21, 2013, 08:39:43 PM
 #98

We're using compressed keys so we only have to worry about the X co-ordinates and can thus store data - that's kind of the point.

Thanks. I have already agreed to go for the compressed pubkeys:

I see that the brute force for getting a valid point is indeed shorter/simpler with compressed pubkey.

And http://masterchain.info reflects that.


Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 21, 2013, 09:19:44 PM
 #99

I suggested supporting additionally the "compressed tx" (2 or 3 outputs) while keeping the "uncompressed tx" (4 outpus) as well.
GUI users could still use the "uncompressed tx".
I just don't want to develop the "compressed tx" if you guys don't intend to support it.

What problem are you solving by encoding the receiving address in the public key?

I rather spend time working on implementing more of the protocol then rewriting the way we encode it at this moment.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 21, 2013, 09:21:53 PM
 #100

Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

I suggested supporting additionally the "compressed tx" (2 or 3 outputs) while keeping the "uncompressed tx" (4 outpus) as well.
GUI users could still use the "uncompressed tx".
I just don't want to develop the "compressed tx" if you guys don't intend to support it.


We have to be a little careful here - if we include change in the multisig then unless we immediately redeem it, users will see their bitcoin balance drop by changeamount which could cause confusion and fear.  With the current method the bitcoin balance never drops as we return change in the original transaction.

As I've made a lot of posts on the topic, to summarize my proposed spec changes in simple form:

* We use only compressed keys (sounds like we have consensus on this now, thanks Grazcoin)
* We use only ECDSA valid points (eg via my suggestion to rotate the last byte)
* We obfuscate the data so it appears like a random key, but do not invest too much effort in encryption as censorship essentially boils down in its simplest form to miners blocking transactions with an output to Exodus

Points 1 & 2 are easy (eg I know Tachikoma and I both already have code that does this and it shouldn't be too much work for grazcoin).  Point 3 may take a little more effort depending on just how far we go to make the key look 'real'.

JR, care to weigh in?

Thanks! Smiley

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 ... 65 »
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!