Spread some XEM!

General Discussion
#101


here is my waiting list:
NBYOKP-4LSLQX-RJ7H3P-QXGFTT-TB66HM-MDUU5D-4TO7 firefighter waiting +15000


You have to wait minimum 24h as I stated on this thread, regulary. Since I'll will send money back after ca 24h and just at about 7 o'clock (UTC -> GMT)

But if you need money back faster. I'll send you tonight.
All others who send me much money today (Guess Tompa sends me 100K) should just tell me here or via PM so I would also send back tonight otherwise you will get it back tomorrow evening.






dont worry there is no problem, you can send back anytime when you want :)
#102

@ firefighter Very good points… I'm afraid of the same thing… So I'm proposing scaling back down in amounts… It is just for testing and we don't want to loose a big sum, nor do we want to scare some NEMsters who maybe don't have 100K or 500K to play with…

About Telegram - you see if you want to join us… You can start by going here: telegram.me/Tomislav and send me a message…
asey10, Mindwalker and I are there for the moment… Invitation is open to all :slight_smile:

I would really like to try out the multisig and how it works… :smiley:

#103

@ firefighter Very good points... I'm afraid of the same thing... So I'm proposing scaling back down in amounts... It is just for testing and we don't want to loose a big sum, nor do we want to scare some NEMsters who maybe don't have 100K or 500K to play with...

About Telegram - you see if you want to join us... You can start by going here: telegram.me/Tomislav and send me a message...
asey10, Mindwalker and I are there for the moment... Invitation is open to all :-)

I would really like to try out the multisig and how it works... :-D


I've tested multisig already and it works fine. It cots 6 xem per cosignator extra fee for tx.

I've have a shared account with owon know. Guess we both got donation for translating stuff and we put the xem in one account.
We choice a 4 cosignator approach so now one of us can kick out the other one.

We can do some cosig test if you like. But you have to pay the fees for account. Since i spended much XEM for testing till now.
Just don't use your main account as cosignator for test.

Scaling back for normal operation will be good. Anyway we can scalling up with multisig accounts.
I would like sedimer, tompa, myself as holder of cosignators (each with to keys) where everybody can send high volume to and will received back (minus fee for tx).
Then 3 other trusted accounts (That are already here) will receive the second key of us. So if one of us is not available the 5 people could remove 1 cosignator and have access to money again.




BTW
I now own privatekeys 11111111111111111111111111111111111111111111111111111111 upto FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF


Protect as multisig accounts with 1 cosignator which I have the private key for.



#104


Wee need to be very careful because someone not morally strong could easily get into the loop with few smaller rounds and then when trust is earned start to receive bigger amounts (100K) and then when he/she gets 500K from several of us - just vanish...

For coordination - we could all be in one Telegram group. That way we can easily notify entire group on the status of the round/loop.
PM with Telegram usernames if you are not already in some NEM group there... And if you are, you already have my T username and just contact me :-)

I have another proposition - why wouldn't we practice creation and use of multisig (on separate, newly created accounts)?
I should probably create a new thread just for that (and I think I will if there is interest shown here) and we can also use Telegram for that as well (especially for initial starting help/support) since it is way quicker to chat that way...


Yeah we have to be really carefull. As longer this thread lasts as more likely a scammer will f**k our as*.
BTW I don't like the Idea of an extra app (Do even know telegram) to communicate.

So I won't really do anymore spreading to new people since my intention was not raising Importance. I just wanted to know if Importance is raising and I wanted to gain experience which Account I could trust for what degree.

Anyway I'm still interested in experimenting, so I would really design a spreading net (Net of Cycles/Loops). Where we all can have some fun.

Before spreading should happen we should select a Risk Model.
Who will compensate the loose if a scammer takes a way money.

Own Responsible Model
Everybody selects his next partner by his own trust level and if he's wrong, he have to compensate the loose.
We can make cycles and loops which can be choosen from each individually.

For Example. Tompa send me 100k and I send 50k to johndoe and 50k to scamdoe and johndoe sends 25k to sedminer and 25k scammatic. We have lost 75k in total. I would pay Tompa 50k and johndoe pays Tompa 25k.

Shared Risk
If some sends to a preselected Account and this Accounts doesn't send back. The lose is shared between all spreader in cycle. 
We define presets of sending.

For Example. Tompa send me 100k and I send 50k to johndoe and 50k to scamdoe and johndoe sends 25k to sedminer and 25k scammatic and all should have send back to Tompa.  We have lost 75k in total. 18.75k each for Tompa, me, johndoe and sedminer. So the last three send Tompa each 18.75k back.

Shared Risk Model opens new scam vectors too.


We could reduce probability and impact by using Multisig Accounts but we should be aware the on some day we will loose money.


So hopefully my post helps even if it shows some negativ aspects.

Update: We don't have to select one Risk model. But we should select the risk model between spreaders who spread to them self. Cause then the gaming rule are set in front of incident and we don't have to get emotionally on this issue

FireF

Hello,

just one more negativ post :-)

How would I betray you. I would start sending you 10k and afterwards highervolumes even 500k. Would have a high balance also. And then if you trust me and all send me 100K upto 500k or even 1M I would tell something like I'm currently on vacation and don't have access to wallet.
And promise you to compansate your waiting time. And then deaster happens, I've forgotten my wallet password in vacation but try to send back. And then I'm away.

So trust here should be always be monitored otherwise you've got scammed. Like mladen00 scammed me with just 512 xem (Since he had high balance, I risk to send him).

So beware that you will loose XEM someday. But you will find people here that are really trustworthy.

As I told my boss a few years ago. He can trust me up 4,000,000.00 Euro after I've access to such money I'm away.
For about 20 years I had access to much money 50,000 Euro a day (100,000 Deutsche Mark) cash and that was really fun to have such a responsibility.

FireF

Update: Solution is, that we all knew (talk) about waiting spread backs, so we know for sure anybody has access to highamount.



sounds are good. you pointed out well.

your idea about risk model is fine in the beginnig but we need to develop your idea. i mean we need algorithm or something. the problem is starting here, how should we develop an algorithm for the reliable people model or shared risk model, and how can we integrate on nem?
#105

i dont know anything about multisig account.

i have a couple of question

-can someone explain what is it?
-how is work?
-is there any tutorial for multisig account?
-what multisig accounts benefits?

#106

Asey:
http://blog.nem.io/how-to-use-multi-signature-accounts/
https://forum.ournem.com/tutorials/how-to-use-multisig-on-nem-guide/ (slightly outdated)

#107

Hi all,

I'll be back tomorrow. It's now one week that I've been really often at my computer till late night. At my wife is going mad, if I do today again. But XEM is so much fun for me, thats why I was so often here. :smiley:

We see us tomorrow and I'll will try not to be much here on weekend.

Please do not spread to me, unless you can wait till monday. I'll send back XEM after reading book for my kids. Cause after my posting today it wouldn't be a good Idea to hold your XEM  till tomorrow :smiley:


See you FireF

#108

Just to start discussion, here is a draft of a basic loop protocol (italics is more optional):

Suppose parties P1…Pn want to n-cycle an amount X starting and ending with P1.
P1 creates a multisig account M, adding himself and P2…Pn as cosigners.
P2…Pn each transfer X plus a smaller amount Y to M.
Once P1 sees (n-1)*X + (n-1)*Y  in M, she transfers X to P2.
P2 transfers X to P3.
P3 initiates a transfer of X from M to P2 and P1…Pn sign the transaction.
.
.
.
Pn transfers X to P1.
P1 initiates a transfer of X from M to Pn and P1…Pn sign the transaction.
P1 initiates transactions of Y to P2…Pn, P1…Pn sign them

There is no incentive for any party to run away with the money. But if say Pk drops out of the cycle just having received X for whatever reason anyway, Pk+1 would, after not having received X for an agreed upon time (which has to be checked in the blockchain by all remaining parties), initiate a transfer of X from M to himself, so the cycle can be completed.
Pk would be removed from the cosigners, so P1…Pn minus Pk can authorize this transaction.
Why would parties P2…Pk-2 sign this transaction? Well here comes the small extra amount Y into play, they will receive Y + Y/(n-1) when the cycle is complete.

some Problems:

- quite complex
- needs a second communication channel to agree on path, amount, ultimatum time for dropouts and so on. But this is probably inevitable anyway.
- fails if more than one party drops out (but can be fixed if, should Pk drop out, the cycle is broken and Pk+1…Pn receive X + Y from M and P1 receives X from M)
- n-1 cosigners could collaborate to betray the remaining one (but that is a generic weakness of multisig)
- much money is transferred back and forth from and to the mutisig account. Unclear for me what that does to the POI score. After all the loop idea was to avoid such transactions in the first place.
- money laying in the multisig account probably lowers POI of the depositors. Can a multisig account harvest?
- fees

#109

Looks like you have to be making transactions on a daily basis to keep your percentage increasing.

I went from 0.7% to 2.2% over 2-3 days, but didn't make and transfers yesterday or today and it's gone back down to 1.34%.

#110

Maybe it is also relative to number of active harvesters?

Sent from my Lumia 800 using Tapatalk

#111

Thought again and quite obviously there is a much simpler solution for looping than my first proposal - for reference call it loop 0.2

Say P1…Pn want to n-cycle the amount X
P1 makes safety deposit X to multisig
P2 transfers X to P1
P3 transfers X to P2
.
.
.
Pn transfers X to Pn-1
Pn receives safety deposit

If Pk breaks the chain, she is removed from cosigners and Pk-1 receives the safety deposit.
No back and forth transactions, multisig transactions are minimal.

#112

Thought again and quite obviously there is a much simpler solution for looping than my first proposal - for reference call it loop 0.2

Say P1..Pn want to n-cycle the amount X
P1 makes safety deposit X to multisig
P2 transfers X to P1
P3 transfers X to P2
.
.
.
Pn transfers X to Pn-1
Pn receives safety deposit

If Pk breaks the chain, she is removed from cosigners and Pk-1 receives the safety deposit.
No back and forth transactions, multisig transactions are minimal.


Mindwalker thats simple and simple is in that case very very good.


I set up a save address  as Multisig. Tampa, Sedimer and my self. So we can make a first run.
Wait till Multisig account has first tx out, so we know for sure it's working.
I'll post the privy key of multi sig too, so everybody could import it to his wallet, and see balance and tx really easy.



Multisig = NB6OBU-Z2TZV5-HM3NGF-QX3I3M-QUDMMZ-NFTITU-ANKV
priv key = 2b759b44cb0dc58a6d606eb2c35767f8ad828d79f9f664475b6c661ab0c80d59

All three cosign have to sign the tx first. Don't put any xem in before

Update:
Everybody to be in the first test need 10k of xem and has to PM me with his NEM Address. I will post a List who send to who afterwards-
I want to make sure that we don't paid out accidentally



#113

Don't trust following user, because i still waiting  (>2200 blocks) for return back my xem!!! >:( >:( >:( >:(


Bonz NDB44P-C3EXPR-MINBZJ-SY7IUC-AFLJE2-Q3ZE7V-DYOK
wakasaki808  NCR2AY-ZS25HR-PFOSAO-OR3MHO-SZRAVZ-FGX6D7-4UE

#114

So if we want to not just do some cycle but make transactions from each member of the network to each other one, there is a simple way of doing that (well two to be precise). Let's call it loop 0.3

But first some notation: 1,2,3, …, n  are the participating accounts. 0 is the multisig account with 1…n as cosigners, as mentioned before.

So a cycle could be written as 0123450 for example, meaning first 1 has to transfer to 0 (safety deopsit), then 2 to 1 and so on until at last 5 receives the deposit from 0. In this example of course we don't have the full set of possible transactions, for example 1 to 3 is missing.

To fix this, we have to regard the cases where n is even and n is odd separately:

n even

Think of the numbers being arranged in a circle.
Start with 0.
Next number is always the next clockwise one that has no transaction with the actual number yet.
If no such number can be found, the algorithm terminates.

So for example n=4 would lead to 01234024130, and n=6 to 012345624613503625140.
It can be shown that this is alway a cycle, meaning the first and last number are the same: the multisig account.
It can further be shown that removing a 0 in the middle, thereby reducing multisig transactions, can't be done without implying back and forth transactions.

n odd

Remove the 0 for a while.
Apply the "n even" algorithm to the other numbers, starting with 1.
Add 0 to the beginning and the end.

For example n=5 leads to 0123451352410, n=7 to 01234567357246147362510.
1 has to make the safety deposit and receive it himself at the end. So we have one back and forth transaction here, which is inevitable.

#115

@Nowii:
I sent you 2525 XEM with 72579997c3a3d48213c43d26e8d966caf2f28ce20cbf89a5fce8036938c01a61 which i never got back.
Now you spread me 1000 XEM with deb8fc0d83efc746e41776fa4c317a43dc812b2c27fd3d0f6d5d3809d68dedf8.
So I'll keep them, leaving you 1525 XEM owned to me.

#116

Sorry if I'm missing where this is mentioned but is part of how POI works having transactions to different partners, so a loop would create in theory multiple sends to just the one other user, and multiple receipts from one other user? 'B' is only ever interacting with 'A' and 'C'.


If I'm wrong, stop reading here :wink:


If there was a list all willing and trusted participants there are a couple of other ways to go about it I think. Rather than a loop, it could be set up more like sporting fixtures, A and B transact, C and D transact, and one 'spot' would be what Mindwalker was calling '0' (safe deposit). Next round starts only when [font=Verdana]all of Round 1 transactions are complete. [/font]


Working whilst writing this so might have overlooked something or just need stronger coffee…

#117

So if we want to not just do some cycle but make transactions from each member of the network to each other one, there is a simple way of doing that (well two to be precise). Let's call it loop 0.3

But first some notation: 1,2,3, ..., n  are the participating accounts. 0 is the multisig account with 1..n as cosigners, as mentioned before.

So a cycle could be written as 0123450 for example, meaning first 1 has to transfer to 0 (safety deopsit), then 2 to 1 and so on until at last 5 receives the deposit from 0. In this example of course we don't have the full set of possible transactions, for example 1 to 3 is missing.

To fix this, we have to regard the cases where n is even and n is odd separately:

[u]n even[/u]

Think of the numbers being arranged in a circle.
Start with 0.
Next number is always the next clockwise one that has no transaction with the actual number yet.
If no such number can be found, the algorithm terminates.

So for example n=4 would lead to 01234024130, and n=6 to 012345624613503625140.
It can be shown that this is alway a cycle, meaning the first and last number are the same: the multisig account.
It can further be shown that removing a 0 in the middle, thereby reducing multisig transactions, can't be done without implying back and forth transactions.

[u]n odd[/u]

Remove the 0 for a while.
Apply the "n even" algorithm to the other numbers, starting with 1.
Add 0 to the beginning and the end.

For example n=5 leads to 0123451352410, n=7 to 01234567357246147362510.
1 has to make the safety deposit and receive it himself at the end. So we have one back and forth transaction here, which is inevitable.


You blow my Mind :-D Cool.

But I don't like the idea of cosig 1 .. n. Cause I may sounds secure but if someone want to do bad things he simply would have to cosig acounts and then he has a way to stop sending out the many.  And it would could 6 * n fee for multisig.

I like the Idea of trusted group of person so every body who wants to join spread cycle can judge for him self if he has Trust in this group. If not he don't spread.

Guess we can start with Loop 0.3 after I've got info who wants to join with multsig controlled by tompa, sedimer and firefighter (myself).


firefighter
#118

@esc747
We do currently not know the PoI algorithm, so everything is speculative. And with we I mean myself  :wink:
It is my understanding that PoI has a PoS component plus some algorithm somehow rewarding many and big transactions to many different peers. A wild (or probably not so wild) guess would be that this is some variant of Google's PageRank incorporating transaction sizes and probably other things.
In PageRank multiple links from one site to another are just ignored. For PoI one could speculate, that for example only the net total and direct transfer between two peers counts. So if A transfers 500k to B and B transfers 250k back to A, that would be counted like one transaction of 250k from A to B.
I believe PoI ist much more clever than that, because that could be exploited by just circling a large amount forever between 3 peers.

Regarding your question, I am not sure if I understand it.
Could you explain more about the sporting fixture approach? I don't know anything about that.

#119

@FireF
You got a point there.
To summarize for me:
With cosign 1…n we have a multisig fee of 6n, plus the risk of more than 1 out of n cosigners dropping out. Not to forget the long duration of cosigning the last transaction n times.
With cosign 1…t, with t being a number of trusted members, the risk would be t-1 of those defrauding all others of the security deposit.

With t>=3  I would definitely prefer your variant. For a "final" version possibly t=4 since t-1=3 people are much more trustworthy than t-1=2.

I have already added your multisig account to my wallet. So I would like to participate.

#120

Sorry if I'm missing where this is mentioned but is part of how POI works having transactions to different partners, so a loop would create in theory multiple sends to just the one other user, and multiple receipts from one other user? 'B' is only ever interacting with 'A' and 'C'.


If I'm wrong, stop reading here ;)


If there was a list all willing and trusted participants there are a couple of other ways to go about it I think. Rather than a loop, it could be set up more like sporting fixtures, A and B transact, C and D transact, and one 'spot' would be what Mindwalker was calling '0' (safe deposit). Next round starts only when [font=Verdana]all of Round 1 transactions are complete. [/font]


Working whilst writing this so might have overlooked something or just need stronger coffee...



I would start with Loop 0.3 to test and train how it works. Then later we can extend this simply building block to a more sophisticate emulation of real Transaction. I've there some Idea but guess Mindwalker will come up with a better one, cause me thinking pattern is complicate and Mindwalker is able to do things simple.

I would to something like this.

m = multisig
m1 = controled by one trusted group
m2 = controled by other trusted group

Lets say  n= 9

0)
m1 <- 1 (100k)
m2 <- 2 (100k)

1a)
    <- 4  <- 50k
2                8
    <- 6  <- 50k


1b)
    <- 3  <- 50k
1                7
    <-  5 <- 50k


Balance 8 = -100k
Balance 7 = -100k

2)
                            <-3 (25k)
7 <-(100k)      <- 6 (50k)
                  5        <- 2 (25k)   
                            <- 1 (25k)
8 <-(100k)      <- 4 (50)k
                            <- 9 (25k)
Balance
5 = -100k
3 = -25k
2 = -25k
1 = -25k
9 = -25k

2b)
          - 3 (25k)
      -  - 2  (25k)
5 <-
      -  - 1  (25k)
          - 9  (25k)

Balance
3 = -50k
2 = -50k
1 = -50k
9 = -50k

3)
2 <- (50k) 3 <- (100k) 4 6 8 5 7

Balance
7 = -100k
1 = -50K
9 = -50K

4)
1 <- (50K) 9 <- (100K) 6

Balance
7 = -100k
6 = -100K


5) each 100k
7 6 5 4 3 2 1 8 9 2 3 4 5

Balance
6 = -100k
5 = -100k 

6)
5 m1
6 m2