I wanted to understand how multisig transactions work, so I wrote a little python app to provide a GUI for the process. You can download it here: http://s000.tinyupload.com/?file_id=00465450645705168931 (I have no idea if it works on Windows and you need to make sure you're running darkcoind on test-net! You *could* use it on main-net but I wouldn't risk it just yet.)  Doing multisig manually is a pain in the arse, this is a prototype for an easier GUI way of doing it, that's all, which I am trying to port to the web so anyone with a browser can try it, and so anyone using OpenBazaar or something similar can eventually use it too. Multisig isn't only useful for dealing with other parties, you can create a multisig address that requires multiple keys for your own use, so you need say 2 of 3 (x of y, it's up to you) keys to unlock it, for added security, or in case you lose one. You are right, for the real world it needs some kind of time-out, and some other stuff, but one ice cream fuelled lunchbreak at a time...  It NEEDS to be a tab on our wallet. Have you told DRKLord? Yeah, having an easy to use multisig GUI in-wallet would be fantastic. I'm just trying to come up with possible approaches to it, and demonstrating that if an idiot like me can do it, Evan + co have no excuse! flare is on the case I believe...  |
|
|
|
BTW, how can the data of the internet be passed through 1000 masternodes without clogging things up? Is that even remotely possible? I'm not technical, so I'd appreciate any insight. Thanks As bandwidth (and CPU, and disk space) demand grows, MN ops are going to have to pay for much beefier servers. Which shouldn't be a problem, as revenues will grow accordingly. |
|
|
|
Hey Crouton, can you explain to me, as if I'm an old lady.... er 'cause I am an old lady, how one would use this? I'd like to do a write up, but I only have a cursory understanding. I'd like to know: Why one would use this?: can one trade dissimilar coins with this? is it for items as well (a market?) conceptual things like a contract? What else? How does it work?: I see you generate a public key, who has the private key? Is there a timed element, so that the parties can retrieve their funds if the transaction isn't completed successfully? I think that's what it needs. The contract must be timed so that the arbitrator address can eventually return the funds. I don't see a timing function there? I know I'll have other questions, but that's it ATM  BTW, I LOVE THIS!I wanted to understand how multisig transactions work, so I wrote a little python app to provide a GUI for the process. You can download it here: http://s000.tinyupload.com/?file_id=00465450645705168931 (I have no idea if it works on Windows and you need to make sure you're running darkcoind on test-net! You *could* use it on main-net but I wouldn't risk it just yet.) Doing multisig manually is a pain in the arse, this is a prototype for an easier GUI way of doing it, that's all, which I am trying to port to the web so anyone with a browser can try it, and so anyone using OpenBazaar or something similar can eventually use it too. Multisig isn't only useful for dealing with other parties, you can create a multisig address that requires multiple keys for your own use, so you need say 2 of 3 (x of y, it's up to you) keys to unlock it, for added security, or in case you lose one. You are right, for the real world it needs some kind of time-out, and some other stuff, but one ice cream fuelled lunchbreak at a time... |
|
|
|
Behold, CCMF is coming soon to a Masternode near you!  Anything BitRated can do, I can do... well, probably! |
|
|
|
Ah, just anonymised another few hundred DRK. I do like watching that process. what setting (1-8) are you using ? 3 - then sending from a new virgin address via a VPN (also paid for in DRK) until we have built-in IP obfuscation. Secure enough for my orders from inflatablenuns .com! (Which are mailed to a rented mailbox paid for in cash by a rented street urchin, and couriered from there to me by the local gay biker gang, who would never tell, because they simply adore me.)  |
|
|
|
Ah, just anonymised another few hundred DRK. I do like watching that process. |
|
|
|
Is the timing likely to be influenced by NY BitLicences? Doesn't sound like it should. ETFs should be able to go through under existing regulations and supervisions.
Is there any reason why we couldn't set-up a master node offering on, say, the NASDAQ?
Sir Crouton gave me a way to potentially think about structuring an entity that could have shares in Master Nodes, while keeping them decentralized - multisig. The owners become owner/operators, the listed entity pays upfront for some rights over future income (or through some sort of sale and leaseback) - both entities control the flow of funds through multisig, with a third trustee, such as an audit firm or lawyer, acting as independent key holder.
Trustees could be outside the USA to ensure access is difficult or impossible to obtain for Feds, etc.
Then it all comes down to what services are running on master nodes. But if they can opt-out of certain types of services, then the NASDAQ entity could file audit reports on the basis of income from legitimate adult infrastructure services, plus mixing income.
Cryptographic multisig is potentially very useful in a number of situations, and currently woefully underutilised, probably because it's a pain in the arse to do, hence my attempts at a UI to explain it to myself and possibly make it useable and useful to others. Now that I have a grasp of the mechanics, I'm going to try and port my simple app to the web so it's useable from anywhere, like a BitRated for DRK, but obviously with a much better name. Also bear in mind that although one of the most common multisig configurations is with three parties, (buyer, seller, arbiter) there can be any combination of required keys to the lock that you like - 2 of 3, 3 of 4, 7 of 9, 243 of 401... and I haven't tested it but I see no obvious reason why multisig addresses of whatever configuration can't be locked together in higher level multisig addresses - which might give rise to a way of making things like large scale voting, elections, any kind of situation where consensus is required computationally unbreakable while remaining completely transparent and auditable. In the MN-net for example, you could have different consensual blocs as well as individual MN ops... really this is fantastic tech. |
|
|
|
People that announce IPOs and take money from US citizens are asking for trouble. SEC Charges Bitcoin Entrepreneur With Offering Unregistered Securities
FOR IMMEDIATE RELEASE
2014-111
Washington D.C., June 3, 2014 — The Securities and Exchange Commission today charged the co-owner of two Bitcoin-related websites for publicly offering shares in the two ventures without registering them.
An SEC investigation found that Erik T. Voorhees published prospectuses on the Internet and actively solicited investors to buy shares in SatoshiDICE and FeedZeBirds. But he failed to register the offerings with the SEC as required under the federal securities laws. Investors paid for their shares using Bitcoin, a virtual currency that can be used to purchase real-world goods and services and exchanged for fiat currencies on certain online exchanges. The profits ultimately earned by Voorhees through the unregistered offerings totaled more than $15,000.
Voorhees agreed to settle the SEC’s charges by paying full disgorgement of the $15,843.98 in profits plus a $35,000 penalty for a total of more than $50,000. http://www.sec.gov/News/PressRelease/Detail/PressRelease/1370541972520#.VAN0xvldVWWBig banking gets away with billion$ in fraud every day and the SEC wastes taxpayer money on some guy trying to earn a few bucks off his own initiative - I guess if you're earning shitloads with your rich banking buddies you can afford the right bribes. Government: stealing your money and using it to pay armies of useless shitbags to steal more of your money! I suppose the SEC will be coming after me next for the two Masternode shares I run. |
|
|
|
lets say darkcoin gets to $35 or more,starting a node will cost a lot of money,before you get your investment back will take a long time and only after that time you make some money,in the crypto world there are much better ways to make money with such an investment.Now it's a great time to start a node but not when darkcoin costs $35.why will pay $35000 to make some small cash out of it,it's better to daytrade Bitcoin or something else with that kind of money.
If DRK reaches $35 then your payments are worth more too. And MNs will have other revenue streams. And gambling more money daytrading just means you'll lose more money daytrading, for the 93.6% * of daytraders who are crap at it. *Figure plucked out of my arse, but I bet it's close. |
|
|
|
That's one sexy interface. You're a lunch hour legend!  More than XMR has achieved in six months. |
|
|
|
The current price is of little relevance. I believe the current low price reflects some lingering uncertainty. If Evan presents solid, working solutions the price will go up again. Time is of the essence, however. For Darkcoin to be the #1 privacy centric currency, we have to be running at 100% (enforced, provably random masternode payments, no bugs, user friendly DS+) prior to Monero achieving their own version of user friendliness. It seems that the Monero GUI won't be here for at least a month, so there is still time for either coin to succeed. Alternatively, both coins could find some measure of success.
Jesus Christ it takes a day, tops. I completely redid my CCMF Multisig demo today in my lunchbreak.  |
|
|
|
I realize that the system has similarities. What I believe is novel is the (snipped) "nomination" system based on the hash of the block, the need for the nominated MNs to respond with blockchain-writable transactions within 2 blocks of being nominated, and the deterministic picking of a "winner" based on the responding MNs. This negates the need to maintain an off-blockchain "list" of active MNs, which I believe is what caused the forking problems in previous releases, where some nodes were rejecting blocks off of a belief that the MN receiving payment was not a valid MN, for whatever reason. You can see this in all the questions about "is my MN appearing ok?" It should not be possible for one person's list of active MNs to be different than another person's, yet I believe that this is what we still have today. "I'm seeing 850 active MNs but Joe sees 842" is a very difficult problem to solve, so my proposal moves all MN "activeness" into the blockchain where it becomes indisputable.
When MN payments were first introduced, forking occurred as the network propagation process could take longer than the blocktime. Since then the inter-MN comms are *much* faster. If I see 850 active MNs, you and Joe also see 850, any change is propagated within seconds at most. There will always be fringe cases, but that's what the voting system across multiple blocks is is for. It's critical for future services that MN's maintain comms discrete from the slow blocktime. |
|
|
|
How's everybody's Ducknote hedge doing ?
Crikey, I bought a few gazillion at 0.00000000000000000000000000005 or something, if I sold now I'd be nearly £50 up!  |
|
|
|
Is this about taking over from TOR, or making money from the masses?
It's about providing a service that is faster and easier to use than TOR, that isn't owned by the NSA. How anyone chooses to use or monetize that service is up to them. We can eat the cake and still have it. |
|
|
|
*SNIP* - Yeah, sorry for walls of text.
Am I missing something here? Where is such an "announcement" stored? A masternode can only sign its ping with its provided private key, which has no relation to a DRK address holding 1k except via signed message by the actual address giving authority for said masternode key to act on its behalf. Yes, and such a message could be put into the blockchain and act as the 'initialization' transaction for a MN. This ties the 1000 DRK to the public address of the MN. From that point on, the 1000 DRK will be watched, and if it moves then the MN will have to be re-initialized before it is capable of being paid again. Frankly I'm kind of surprised/shocked that such a thing is not already being done. (Although I have been keeping up with DRK for a long time, I have never really looked into implementation details of MNs....) No wonder RC3 had so many damn forking problems! Valid MNs need to show up in the blockchain somehow, otherwise how will you ever have consensus what's a valid MN? Perhaps the solution is to have additional space in the blockchain for storing these messages (this is what you were thinking all along, isn't it (you're a genius!))? They'd exist for all eternity unless pruned at some point in the future (though that would need some workaround to keep the blocks paying them in the past valid when the evidence of their being a masternode is removed), but I'm not sure that matters... You would actually be able to make a "list" of sorts then based on the messages in the blockchain, but it wouldn't vary at all from node to node! Now you get it. Assume the same address could initiate a stop command in a future block to not have his old MN clutter up the payments by never responding. However, I don't see any incentive for people to do this, so there needs to be some mechanism where the block finder can insert the stop message on behalf of the masternode. You might think the lingering nodes wouldn't be an issue, but something absolutely has to be able to issue a "stop" command in case the 1,000 DRK move. Unless you could possibly modify the protocol to have nodes reject any tx formed out of the 1,000 DRK input without a "masternode stop" command included in a prior block? If you allow for removal after X number of missed pings, you have the (tiny) vector of the block finder being able to remove a masternode if he found the right blocks, but I don't know of any incentive to do this. Well, no, I think you're over-complicating things here. There are really kind of 2 lists: one for "valid" MNs and the other for "active" MNs. By creating an initialization transaction and putting it into the blockchain, a MN declares itself as "valid". It remains "valid" for as long as the 1000 DRK does not move. This means that it is *capable* of being nominated and receiving payment, *if* it proves itself to be "active". Upon nomination by block n, it has to ping back in or before block n+2. This proves it as being "active" and eligible for receiving payment in block n+3. A MN maintains its "active" status as long as it keeps responding to all nominations with pings in a timely manner. If a MN does not respond in time to a nomination, it will be marked un-"active" until the next time that it responds to a nomination. That "activating" ping will bring it back to the "active" list, but it will not be eligible for payment in that block because it was non-"active" for the previous nomination. And again, all of this information will be 100% determinable in the blockchain. Now we're just stuck with n block finder (that happens to have his node in the list of candidates) pretending he didn't get pings from some or all of the other candidates. Perhaps this vector is small enough to just discard. That's the point of having the nomination take place by the hash of block n, and valid+active MNs have to get their "ping" transactions inserted into either block n+1 or n+2. (Maybe this should be lengthened to 3 or 4 or 5. It would require some testing and modeling.) Presumably block n+1 will not be mined by the same miner as block n+2. And then block n+3 is the one that actually makes payment to the winning MN. (Although maybe the payment should actually happen in block n+4, with the winner being determined by the hash of block n+3. So block hash n+3 declares the winner out of the pinging MNs in blocks n+1 and n+2, and n+4 must pay. This may be better than having the block hash of n+2 determining the winner, and being paid in n+3.) The winning MN must be one of the MNs who validly pinged in block n+1 or block n+2 and whose nomination matches block n. It's all right there in the blockchain, so there's no way for anybody to cheat. And the likelihood of the miner of blocks n, n+1, n+2, and n+3 all being the same person, and happening to be one of the MNs nominated by the hash of n, is so small as to be negligible. I mean this is basically somebody who is 51% attack capable, so we would all be screwed anyway. And as long as the MN payment remains small relative to the block reward (4 DRK to miner, 1 DRK to MN per block) there would be no incentive for a miner to withhold a block in order to wait until he found one that nominated one of his own MNs. Give up 4 DRK in order to possibly earn 1 DRK? It just wouldn't make sense. I suppose the only way this can really be attacked is by a malicious miner not including any ping transactions in blocks that he mines. This would unduly penalize MNs who don't deserve it. Such an attacker would throw a monkey wrench into the system, but they could not profit from it since the MN payment must still be included in every block. You have almost described how the current system already works. The 1000DRK for each MN already live in the blockchain, and those addresses are monitored. MN votes already accumulate over multiple blocks. And MN comms are, need to be and will continue to need to be far faster than the 2.5 min average block time. |
|
|
|
I don't understand why you people saying we will start marketing after RC5. Any reason we can't start it now?
None at all, go for it! |
|
|
|
so just to be clear .. the current mn protocol doesn't work since the network doesn't pay each mn the same amount of the drk that are should receive? I read people are talking about rewriting most of the code, fixing it in the algo and more but doesn't that mean that all the work in the last past months has been for nothing  kristov atlas has not even checked it out rigth? Even said he has a plan .. wonder what it is. It sounded to me that the way the mn are working now is from the table, and it can not be fixed like a bug or something but has to be rewritten from scratch..? mn are putting the hole network at risk of attack..? not so happy with the news as a lot of people I imagine.. Are there some positive points I missed or did not understand ..? thanks The MN code works pretty well as is, but it isn't perfect, and MNs currently rely on pools running correctly configured software to get paid their fees for anonymising coins etc. All that's being discussed are possible alternative methods of making the process better. AFAIK Kristov has full code access and we know he has been working with Evan for a while now, but remember DRK is a constantly evolving platform, not a clone/rename/premine/IPO/release/pump/dump shitcoin. We're doing something new here, and this is a great thing. At the end of the day MNs are getting paid pretty well, just with a few niggles. Reworking the platform to improve this is just one of many ongoing tasks, it's not currently even that big of a deal in the grand scheme of things. |
|
|
|
Enforcement, in itself, is just a workaround to ensure compliance. In other words, enforcement is not a good solution. What is needed is a protocol-based solution that works without forking and is non-voluntary.
+1 Why not use MN with X11+ as pool. I understand the need for enforcement, but I actually don't like it. The lurking thought is that it demonstrates a level of control over the network. That has many unintended consequences. For example, * Those who would spin, could spin a view around the reality of decentralisation * Those who would regulate, could spin a view around administration of a network If we do it, I hope we can nuke that part of the code soon after it serves its purpose. ALL nodes on the network are responsible for enforcing the propriety of ALL blocks mined in ALL Bitcoin-derived crypto-currencies. Hash doesn't match the block? Reject. Block contains an invalid transaction? (e.g. improperly signed?) Reject. Block doesn't conform to formatting specifications? Reject. Of course it represents a level of control over the network. That is the entire point: that the network behaves according to a specified set of rules, which are clearly implemented in the software and spelled out in the source code. Each node (whether mining, masternode, or just an end-user wallet) acts independently to implement all of these rules, and to reject bad blocks and/or transactions before they propagate throughout the network. Enforcing Masternode payments should not be rocket science. But it will require a hard fork. The spork method (which, IIRC, basically requires a 'switch' being thrown by Evan) implies a method of control that could possibly make people uncomfortable. Sporkage is just putting the rules you mention into action. Same as if they were hardcoded in the first place. |
|
|
|
Enforcement, in itself, is just a workaround to ensure compliance. In other words, enforcement is not a good solution. What is needed is a protocol-based solution that works without forking and is non-voluntary.
+1 Why not use MN with X11+ as pool. I understand the need for enforcement, but I actually don't like it. The lurking thought is that it demonstrates a level of control over the network. That has many unintended consequences. For example, * Those who would spin, could spin a view around the reality of decentralisation * Those who would regulate, could spin a view around administration of a network If we do it, I hope we can nuke that part of the code soon after it serves its purpose. I agree with AlexGR, and I'm pretty sure the devs do too. I know flare is looking at ways to put MN fee payments directly in the hands of the MNs themselves. |
|
|
|
|
Show Posts
