Only Sweden managed to put up a fight for the votes
Topic: NXT :: descendant of Bitcoin - Updated Information - page 1583. (Read 2761647 times)
Europe (and US?) have been quite convincingly trampled by the Russians and Chinese.
Only Sweden managed to put up a fight for the votes
Only Sweden managed to put up a fight for the votes
[need coffee, somehow quote of colored coin threads and BTC asset fragmentation was dropped...]
Anything is possible. For something like that to work, it would require N participants to all agree to honor each others coins at 1:1
For example, the people that end up with the asset names: "BTC", "BTC2", "BTCxyx", etc all agree that they will redeem each others BTC for actual BTC.
The only problem is if something goes wrong, eg. issuer of "BTC2" gets hit by a bus. What happens? Everyone with BTC2 redeems it at the other issuers, so now all the participants have a bunch of BTC2, but he is no more. On a small scale, it would work like a group self-insuring, but what if we are talking about 100BTC worth?
I don't think that approach will work at large scales, due to "hit by bus" scenario.
OK, so plan B.
Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.
On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.
On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.
The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.
In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.
So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.
James
Anything is possible. For something like that to work, it would require N participants to all agree to honor each others coins at 1:1
For example, the people that end up with the asset names: "BTC", "BTC2", "BTCxyx", etc all agree that they will redeem each others BTC for actual BTC.
The only problem is if something goes wrong, eg. issuer of "BTC2" gets hit by a bus. What happens? Everyone with BTC2 redeems it at the other issuers, so now all the participants have a bunch of BTC2, but he is no more. On a small scale, it would work like a group self-insuring, but what if we are talking about 100BTC worth?
I don't think that approach will work at large scales, due to "hit by bus" scenario.
OK, so plan B.
Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.
On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.
On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.
The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.
In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.
So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.
James
I am not sure if exactly this is what needs to be applied but something similar sounds very logical. We can not just leace things in a way in which the seller can cheat the buyer.
I was thinking about implementing a system like Freelancers Milestone Payments, where everything works in their way, with the difference, that if dispute arrives, the third party is not one centralised person or node, but, 51% or at least some major part of the network.
In addition, in cases in which disput is present, the network is forced to vote and solve the dispute, as for this voting, each participant some small amount of NXT/BTC, part of the deal, which took place between the two problematic parties.
This way, as two parties know that if they can not make 51% of the people to support their side if they try to cheat (e.g. realise this is impossible), and in the same time, if they know that in cases in which they make problematic disputes (when trying to cheat), they pay penalty fees for this and at the end to not succeed to cheat, they will in the long run simply stop trying to cheat and everything will go smoothly.
If you are not faimliar with Freelancers Milestone system, this is how it works:
Party A sends money to Party B, but money are "stuck" in the middle, where no one can use them, A can not get them back and B can not receive them entirely.
Party B makes payment (online service, or sends product) to A in a similar way,then, A has receieve the product, but has already sent money and can not get them back. So A have even no interest to lie. Then A sends himself the money to B (to be more precise, finishes the milestone payment, and transfer the money stuck in the middle finally to B), or, if he decides to cheat, he says: I will not finish the milestone payment to B, he didnt send me the BTC (he lies). Then the majority of the network asks B, is this true, and B shows a BTC blockchain transaction reference, which with arbitrary message can be applied to the deal as a referal note, so he proves that he has sent exactly this amount to exacty A's address for exactly this deal. Then, the 51% (or some big enough part) of the community sends the money finally to B (only A or 51% of the comunity has the power to do this action). At the end, for A trying to cheat, he is penalized for some amount of money in the next deal he tries to make in the network, and the penalty is spread over the network as fee which can be forged, as there is a written exception that only A can not forge that fee.
What developers think about this and can it be implemented? We need to establish 100% trustfull system, current way is no working in practise.
Also please link to colored coins and what they have to do with trustfullness.
Winners can you sent me the accountnumbers please
Done sir! (PM'ed u) CfB,
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
Any chance that u have their accounts ready?
--------------------------------------------------
My Address: 14256227273582846692
Mises_77
@CFB. I have a question regarding AM. Can we make messages sent to any particular account public? I was thinking we could use public messages as a feedback/trust system. For example, if account "x" was selling something, I could go on blockchain explorer, lookup up that particular account, view public messages sent from previous users who had successfully purchased from account "x". Thanks.
They r public by default.
I will provide them to you.
Winners can you sent me the accountnumbers please
Winners can you sent me the accountnumbers please
Thank u.
Btw, I noticed u do a lot of work for free, send ur account too, plz.
Did anyone tested the NEW version of the solaris client!
awesome work marcus03!
https://bitcointalksearch.org/topic/nxt-full-feature-clients-progress-tracking-thread-412138
Pin
CfB,
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
Any chance that u have their accounts ready?
I will provide them to you.
Winners can you sent me the accountnumbers please
@CFB. I have a question regarding AM. Can we make messages sent to any particular account public? I was thinking we could use public messages as a feedback/trust system. For example, if account "x" was selling something, I could go on blockchain explorer, lookup up that particular account, view public messages sent from previous users who had successfully purchased from account "x". Thanks.
Any chance of API calls to let NRS do encryption, decryption, signing and verification for clients?
This is insecure, we r moving away of this.
marcus03, wow man thumbs up good work
(...)
plan B.
Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.
On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.
On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.
The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.
In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.
So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.
plan B.
Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.
On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.
On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.
The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.
In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.
So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.
Ok nice plan B. We have to explain it to everyone.
Basically you create an application which anyone can run on their computers (call it Duck 1.0) which interfaces with the NXT client (and with the BTC client/daemon). Everyone who runs Duck is now a part of the Duck community (much like everyone who runs the NXT client is a part of the NXT community). Duck contains code which was developed (by community consensus and is open source etc.) to perform one main function - to handle/issue a NXT asset which we might call ReserveBTC. Someone (Issuer 1) running Duck can define their own BTC pegged asset - lets call it myBTC1. They can then send the BTC backing their asset to Duck. Someone else (Issuer 2) does the same for myBTC2.
When I want to buy some myBTC1 Issuer 1 sends me some myBTC1. Duck will always buy or sell ReserveBTC, myBTC1, myBTC2 and any other BTC variant because it always has the BTC to back it up/redeem it.
For running the Duck software, the issuers publicly display their trustworthiness which encourages customers and there may be other benefits too.
-Arbitrary message encryption
What algo r u going to use?Still looking for a Curve25519 implementation in Delphi/Pascal, but I'm pessimistic. Would make much sense to use the existing private and public keys.
Any chance of API calls to let NRS do encryption, decryption, signing and verification for clients?
Any chance that u have their accounts ready?
Mine is 18229868146885750725
Nice work marcus03, lookin good.
CfB,
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
result of the rewards vote for sites and social media.
would you be so kind to pay the people that won, thank you.
S3MKi 82 (31.3%)
allwelder 57 (21.8%)
Mac Red 42 (16%)
yulkisa 39 (14.9%)
Damelon 13 (5%)
Passion_ltc 11 (4.2%)
Coinonaer 8 (3.1%)
apenzl 3 (1.1%)
Mises_77 3 (1.1%)
pablito89 2 (0.8%)
^[GS]^ 2 (0.8%)
1) 50,000
2) 30,000
3) 20,000
4) 5,000
5) 5,000
6) 5,000
7) 5,000
8)3,000
9)3,000
10)3,000
11)2,000
Any chance that u have their accounts ready?
Mine is: 4263528265010429437
wow marcus03, that looks amazing. too bad i dont use windows.
-Arbitrary message encryption
What algo r u going to use?
hi dudes. Is it current block?
43606 12292439833850569026 17 Cтyдзeнь 2014 19:37:53
0 0 + 0 0 B
2 4445643119525148577 257 %
43606 12292439833850569026 17 Cтyдзeнь 2014 19:37:53
0 0 + 0 0 B
2 4445643119525148577 257 %
+1
hi dudes. Is it current block?
43606 12292439833850569026 17 Cтyдзeнь 2014 19:37:53
0 0 + 0 0 B
2 4445643119525148577 257 %
43606 12292439833850569026 17 Cтyдзeнь 2014 19:37:53
0 0 + 0 0 B
2 4445643119525148577 257 %
Jump to: