keep
March 14, 2021, 5:30am
1
如图：
ckb1qnfkjktl73ljn77q637judm4xux3y59c29qvvu8ywx90wy5c8g34f4w8raf48mcz5pmqhxcakacdclfg57nl6m5kgph（anyonecanpay地址）
ckb1qjda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xws62e0l68720mcr286t3hw5ms6yjshpg5p3nsu3cc4acjnqazx4x4cu04x5l0q2s8vzumrkmhphra9zn60lg6hp3t3 （从secp256k1地址往anyonecanpay地址转了1100ckb，然后资产就在这个地址了！无法找回这笔资产）
0x0812ce6c6857c0fb7f5d12de17122c402c84b73b0bad68a1de61f8a1a21d43ab（这笔交易的hash）
这笔1100ckb资产现在不知道在那里，将从keypering创建的钱包助记词导入到neuron中，找不到这笔资产。
yixiu
March 14, 2021, 6:54am
2
类似的情况，之前在比特派钱包升级的过程中遇到过，虽然后面解决了，但给用户带来比较大的困扰。
既然如今又有小伙伴遇到类似的情况。我想就把这个问题再延申一下，拿出来一起讨论。
我们知道，CKB底层比较灵活，通过使用不同的lockscript可以实现不同的feature。我的问题是：
1、随着以后的需求增加，新增了很多lockscript来满足这些需求，对于用户而言，会带来什么影响？举例说明：用户A使用支持acp这个feature的地址像用户B的常规地址（没有额外feature）发送CKB，用户B能不能收到？反过来，用户B像A发，A能不能收到？还是说，发之前，AB双方都必须要知道对方的地址是什么lockscrip才行？
2、对于用户而言，不管CKB底层在未来支持多少种lockscrip（比如 acp、多签、隐私等等），他们不care，也不需要理解这技术层面实现的细节，他们在意的是，**能不能始终只用一个对外的CKB地址，不管对方是使用什么lockscrip地址发来的token，他都能收到。**这就好比说，一休哥有一张招行卡，卡号是123456，你知道我的姓名和卡号，你可以通过招行，也可以通过其他行给我转账，我都可以收到，而不是说，因为我的银行卡是招行的，你必须要使用招行卡给我转账我才能收到；更不是说，因为你只有浦发银行，你要求我去浦发那边开一张卡后，告诉你我浦发银行的账号，你才能给我转账。
希望我们趁着在硬分叉前，在lockscrip还不多的当下，能把这个事情讨论清楚，以便迎接更多的feture，更大的人群。
2 Likes
keep
March 14, 2021, 12:29pm
3
接原帖，后续又进行了几笔转账测试了以下。
2.再次用keypering钱包的Secp256k1地址给Anyone Can Pay地址转账，仔细核对了下地址，发现output的地址跟我输入的地址不同，不知为何？
所有 outputs 里的 lock script 是不会被执行的，所以 target address (亦即 lock script) 可以是任意的。只要 target address 没有填错就不存在收不到的问题。
2.再次用keypering钱包的Secp256k1地址给Anyone Can Pay地址转账，仔细核对了下地址，发现output的地址跟我输入的地址不同，不知为何？
output 的地址和你输入的地址其实是同一个 lockscript，只是一个显示成了长地址( ckb1qnfkjktl73ljn77q637judm4xux3y59c29qvvu8ywx90wy5c8g34f4w8raf48mcz5pmqhxcakacdclfg57nl6m5kgph )一个显示成了短地址( ckb1qypdt3cl2df77q4qwc9ek8dhwrw862985l7sshgdp5 )，你观察一下可以看到这两个地址里的交易是同一笔交易，所以资产还在，没有丢失，这点请放心。
更新：
我再仔细看了下图片，看起来确实图片中左边的 output 跟期望的长/短地址都长得不太一样。
PS. 如果只是试用产品，建议先在 testnet 上验证下，避免资产不必要的损失。
hello 目前 Keypering Keypering 自身的转账只支持 secp256k1 这个默认的 lock, 如果想用 acp lock 转账需要调用 keypering 的 api, 并且通过 lockhash 指定用于签名的 lock
