Wow I go away for a weekend and everybody decides to release awesome stuff. Very cool! I especially like Grazcoin's implementation on top of libbitcoin! It makes a lot of sense going for this approach and I can't wait to see what else comes out of it. Great job guys; really digging the various implementations  |
|
|
|
I looked through it and it appears to have been a bug in my own code. So thanks for the bug report  Your transaction should show up now.I would really urge you to don't implement address encoding at this moment though and continue straight to multisig. We should try not to create unspendable outputs. |
|
|
|
|
I tried to dive into it but it's late here so I'm a bit foggy. But I think it might be because the sequence number is off. I think it's looking for 69 but 70 is found. Does this make sense?
|
|
|
|
0.0002 MasterCoins seems like a plan. Let's do that |
|
|
|
|
Ah, with namespace I was actually talking about the amount of user based currencies that could exist until the unique identifiers run out. If the creation is free you can just spam creations until you fill up the 4-bytes that are reserved for identifiers.
|
|
|
|
So let's talk smart assets.
A few questions I had by reading the current specs.
Currently it looks like you don't have to spend any funds to create an asset. Wouldn't this indirectly mean that if I made a small script I could register all possible currency identifiers and break the system? Perhaps setting a required mining fee amount would fix this issue.
I expect most smart-properties to be some kind of dividend paying security. With his in mind it would be great if we could explicitly supply a bitcoin-address when using the "Purchasing a Currency Offered For Sale" method to buy shares, to keep it simple we could also define that when buying smart-properties the default dividend address is the Mastercoin address used for the payment.
I agree that smart property is more important than distributed e-commerce (which would effectively make a distributed silk road). Note that I've previously mentioned that I plan to add a "pay dividend" command to the spec. I agree with Tachikoma that we ought to add some friction to creating smart properties. Rather than pay the fee in bitcoins to the miner, I think we should destroy a small number of MasterCoins (increasing their value). How about we set the minimum fee to: | Property Name Length | Minimum Fee | | 1 | 5000 MSC | | 2 | 2000 MSC | | 3 | 1000 MSC | | 4 | 500 MSC | | 5 | 200 MSC | | 6 | 100 MSC | | 7 | 50 MSC | | 8 | 20 MSC | | 9 | 10 MSC | | 10 | 5 MSC | | 11 | 2 MSC | | 12 | 1 MSC | | 13 | 0.5 MSC | | 14 | 0.2 MSC | | 15 | 0.1 MSC | | 16 | 0.05 MSC | | 17 | 0.02 MSC | | 18 | 0.01 MSC |
. . . and so on . . . In this way, most people will register "Quantum Miner Shares Class B" rather than "QM", but if someone wants to burn a lot of money on a short name, they can This is just one way we could do it - if you guys have suggestions, I'd like to hear them. My main goal is to keep it as simple as possible without creating a single hard-coded value that we'll have to change later. Incidentally, if two people DID register "QM", the second one would be displayed as "QM[2]". There's no enforcement that names must be unique - only currency identifiers, which are assigned in the order currencies and properties are created. Why base the price on name length? |
|
|
|
I've setup a VM to play around with masterchest-wallet but I think I might be missing a dependencies: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text **************
System.IO.FileNotFoundException: Could not load file or assembly 'System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
at Masterchest_Wallet.Form1.SQLGetSingleVal(Object sqlquery)
at Masterchest_Wallet.Form1.lnkwcont_LinkClicked(Object sender, LinkLabelLinkClickedEventArgs e)
at System.Windows.Forms.LinkLabel.OnLinkClicked(LinkLabelLinkClickedEventArgs e)
at System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Label.WndProc(Message& m)
at System.Windows.Forms.LinkLabel.WndProc(Message& msg)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18051 built by: FX45RTMGDR
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
Masterchest_Wallet
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Animazing/Documents/wallet/Masterchest_Wallet.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
Win32 Version: 11.0.50709.17929 built by: FX45RTMREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18022 built by: FX45RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.17929 built by: FX45RTMREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18037 built by: FX45RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18022 built by: FX45RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.17929 built by: FX45RTMREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
Masterchest
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Animazing/Documents/wallet/Masterchest.DLL
----------------------------------------
Microsoft.VisualBasic.PowerPacks.Vs
Assembly Version: 10.0.0.0
Win32 Version: 10.0.40219.1
CodeBase: file:///C:/Users/Animazing/Documents/wallet/Microsoft.VisualBasic.PowerPacks.Vs.DLL
----------------------------------------
System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.17929 built by: FX45RTMREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.18058 built by: FX45RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Numerics
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.17929 built by: FX45RTMREL
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Any idea what I need to install Zathras? |
|
|
|
|
So let's talk smart assets.
A few questions I had by reading the current specs.
Currently it looks like you don't have to spend any funds to create an asset. Wouldn't this indirectly mean that if I made a small script I could register all possible currency identifiers and break the system? Perhaps setting a required mining fee amount would fix this issue.
I expect most smart-properties to be some kind of dividend paying security. With his in mind it would be great if we could explicitly supply a bitcoin-address when using the "Purchasing a Currency Offered For Sale" method to buy shares, to keep it simple we could also define that when buying smart-properties the default dividend address is the Mastercoin address used for the payment.
|
|
|
|
|
You can't connect it to a blockchain wallet directly. You can however export your blockchain wallet keys and put them into a normal bitcoind instance.
|
|
|
|
|
Cool, congrats to the release!
I don't have access to windows. Is there a way to try this out anyway?
|
|
|
|
|
What I was trying to say, before others also misinterpret my words, is that J.R. is not as well versed in the whole technical aspect of multisig transactions as the current developers are. He needs to rely on information he is being given from the other developers like me and Grazcoin.
|
|
|
|
|
There is nothing wrong with using uncompressed public keys; I'm all for it.
The problem is that you can't guarantee that your uncompressed public key is also a valid ECDSA point, this is the part I'm worried about since it would be fairly easy for the reference client to add a simple check to see if a public key is actually a valid one and flag it as nonValid if this is not the case.
I think it's time the Mastercoin foundation appoints an official developer that will be the Linus to our Linux. He/She should decide on the official implementations so that after hearing all the sites the discussion a decision can be made on the official spec. I'm afraid J.R. is not the perfect candidate to this because he is too detached from the actual development.
|
|
|
|
I'm using bitcoin-ruby to test my points. A ruby wrapper around some OpenSSL functions. 1.9.3-p286 :002 > require 'bitcoin'
=> true
1.9.3-p286 :003 > Bitcoin::Key.new(nil, '02010000000000000002000000000000000d000000000000000000000000000000')
=> #<Bitcoin::Key:0x007ffe639629e0 @key=#<OpenSSL::PKey::EC:0x007ffe63962940>, @pubkey_compressed=true>
1.9.3-p286 :005 > Bitcoin::Key.new(nil, '02000000000000000002000000000000000d000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid compressed point
1.9.3-p286 :006 > Bitcoin::Key.new(nil, '0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000')
OpenSSL::PKey::EC::Point::Error: invalid encoding
Perhaps something like python-ecdsa or similar might be able to do the same. |
|
|
|
|
Ouch. In that case I'm not sure anything can be done in the current implementation.
It would probably help if Electrum would check the height of an output and disregard the output if the output has not matured yet. I will see if this is something that could be implemented I believe the height is already stored in the wallet so it should in theory be possible.
|
|
|
|
I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point. 0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000
A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address. I also played with a version that rotates the first 0 to the end, but miners seem to take the tx as is. Can you please show me on the satoshi code (and better on the protocol) where the list of public keys in BIP11 are checked to be valid ECDSA points? Obviously this isn't done otherwise your transaction would be rejected. The fact that the reference client currently does not check if a public key is actually a valid one does not mean we should also disregard it. What happens if an update does check for the validity and none of the transactions get accepted anymore? I'm trying to think ahead. |
|
|
|
|
You could freeze the address if you know to which address the outputs belong. I think that would be the easiest way to overcome it.
|
|
|
|
I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point. 0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000
A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address. |
|
|
|
how about having only 2 outputs: - dust limit to 1EXoDus
- All the rest to the BIP11 that includes [changeAddr, (modified)recipientAddr, dataAddr]
This is not very different from what we have now. We just drop 2 extra outputs (to recipientAddr and to changeAddr). In order to avoid spending of the tx by the recipient address, we would modify it lightly (e.g. by changing the first 0 to 1), so it is still readable, but it can't sign the tx. By using this method we avoid the need to differ between the outputs (there are only one simple and one multisig). We don't have to change the recipient address, as far as I know you can only use public keys, not addresses. The problem is that you can't just make a public key that looks like an address since it's hex only. We could convert an address to hex but this would increase the amount of bytes needed for encoding. The other problem is that multisigs are harder to spent then a normal address at the moment. However this could be tackled by automatically creating a 'clean-up' transaction from a mastercoin-client that looks for all multisigs and send them to a normal address. |
|
|
|
I just released the sourcecode for Mastercoin-explorer.com. You can find it as always on my github account. I just want to publicly say that since everything I build was greatly bootstrapped by the excellent work of bitcoin-ruby that I will be sharing part of whatever bounty money comes my way with the author of said library, you can hold me to that. |
|
|
|
|
Show Posts
